We’ve recently worked on several mobile app development projects for tablets and phones running iOS, Android and Windows. Thanks to these projects, we’ve identified some key do’s and don’ts for managing your product backlog requirements for mobile application development efforts.

Here are some of the common business features and technical requirements/constraints for both consumer-facing apps and corporate internal apps that could show up in the product backlog:

  • Responsive UX Design (screen size, orientation, device features, etc.) – for this you will need to identify a limited set of target device configurations for acceptance
  • Required corporate branding/corporate style guides
  • Choosing between a native app style UI that is device specific vs. a common style cross-platform UI
  • Stringent speed/performance targets for initial app loading, screen navigation, response to user actions
  • Connected vs. Disconnected Operations requirements – you need to clearly define what features work when there is no connection
  • Data security and Personally Identifiable Information (PII) protection
  • Support for multiple OS and multiple versions of an OS
  • Support for multiple types of mobile browsers
  • Integration with companion apps on the device
  • Cloud/web service integration to access corporate systems of record
  • App Store submission requirements (i.e. Google Play, Apple App Store and the Windows Store). Each store has its own unique sets of UX requirements, minimum performance, storage management, legal/copyright, privacy notification requirements, content age appropriateness designation, etc.
  • App version management
  • Code-sharing across device and OS platforms
  • Graceful degradation of the app functions in case of failures
  • Process improvement support, especially for corporate vs. consumer apps that are targeted for mobile workers
  • Security and device management for corporate apps

The items in the list above may all need to be considered when you first start working with the product owner to both build the product backlog for the mobile app and help define the overall scope and timeline for the project. For consumer apps deployed through app stores in particular, the timeline for publishing to the stores — and factoring in the review and acceptance process — needs to be considered up front. Read More…

Previously, we looked at how to implement localization of an iOS app using storyboards. Then we discussed how to localize text that is generated programmatically. In this final article, we will examine how to determine the current locale of the device, and how to use that information to communicate with a web service. This is obviously very useful in those situations where your app is downloading data from a web service and needs to be able to display the correct text for the current locale. Read More…

This post is the third part of an ongoing series on localization of iOS apps. Please read part one and part two

In part two of this series, we looked at how to implement localization of an iOS app using storyboards.  Today we’ll continue with that app, and examine how to localize text that is generated programmatically. We’ll also clean up the project a bit, to bring some organization to the localized data files.

This project is available at the AIS GitHub. Read More…

This post is the second part of an ongoing series on localization of iOS apps. Please read part one here, if you missed it. 

While this post on the MacRumors Forum is a good tutorial for bringing Localization (L10n) to your iOS app, it’s a little sparse in detail, has some updates that change the process, and assumes a few steps.  A couple of bugs have also been discovered that need to be worked around to successfully initiate localization in a new iOS app in Xcode.

Today I’ll attempt to clarify some of these steps, and dig into the minutiae that are important to a successful development and deployment cycle.  What follows is an example of creating an app from scratch and adding localization features. Read More…

With the increased globalization of the economy, there is an obvious need to create mobile apps that handle multiple languages in a clean and extensible manner. This is known as localization (L10n) in the software development community, and various platforms deal with it in their own unique ways. We will look at how iOS manages L10n here, and the decisions that have to be made in order to stay on top of a dynamic situation.

There are several resources on iOS L10n available, both in official publications by Apple, and some articles and blog posts written by members of the development community:

  • Apple provides a home page for Internationalization (I18n), with links to several additional detailed sources, including WWDC videos.
  • There is an excellent tutorial on the MacRumors iPhone/iPad Programming Forum that goes into great detail on both how to convert your app to handle L10n and managing the app on an ongoing basis.
  • For apps being developed to target iOS 5, using pre-Xcode 4.5, Ray Wenderlich’s blog provides a good starting point with this blog post.

This article will take a high-level look at what needs to be done to fully localize an app.  Three follow-up articles will look at the nuts-and-bolts details of how to accomplish this through building an Xcode iOS app from scratch.  We’ll look at creating an app with storyboards, and the process of configuring the project to localize these storyboards.  Next, we’ll cover how to handle localization programmatically, if you find you have to manipulate text before displaying it. Finally, we’ll wrap the series up with a look at how to communicate with a web service and identify the language of the data you are expecting to download.

Read More…

Model-View-ViewModel (MVVM) is a client-side design pattern. It guides the structure and design of your code to help you achieve “Separation of Concerns.”  Implementing MVVM requires a bit of a mind-shift in the way you think about the functionality of your application. It has a significant learning curve and requires some additional upfront effort to get started on the right path. But the benefits are significant:

  • Your code is easier to understand, maintain and troubleshoot.
  • You are much more productive when you leverage the frameworks’ (WPF, Silverlight, XAML, WinRT) built-in features like Data Binding, Resource Dictionaries, Dependency Properties, Routed Events, Commands, etc.
  • You can test your app’s behavior “under-the-skin,” avoiding the pitfalls and cost of testing at the UI level.
  • Your ViewModels afford testability. You can have unit test coverage allowing “Test-Driven-Development” and “Automated Regressions.”
  • Decoupling the View from the ViewModel in the way enabled by MVVM allows designers and developers to work productively in harmony.

Read More…