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…

For the last couple months, I’ve been working on a new mobile application for an AIS client. It is an iPad app, targeted for iOS 6. Although I am quite well-versed in many of the iOS standard libraries, there is always “further east” to go, and I’ve really stretched my wings with this project and explored some interesting UI features. One thing in particular that I dug really deeply into is Interface Builder and its new integration into Xcode 4.x. I’ll discuss more of that in a later post, as I explored some interesting features (and limitations).

What I’d like to discuss now is the use of static libraries in Xcode for a couple different reasons. First, I have several classes that I think will be helpful to the developer community (both here at AIS and beyond), and I will be building static libraries to share with any of my colleagues who want to use them in their iOS projects. Second, being able to import static libraries into an existing Xcode project can be a little involved, and I want to outline the process in a way that proves to be repeatable. And of course, the best way of learning is to teach, so I’m looking to solidify my understanding of the process by putting it out there for any of you to try it and punch holes in my logic. Read More…

I’m not going to try and convince you that mobile development is important – I hope you already recognize that it is! If you need further convincing, head on over to Allison Christman’s article – she gives you all the reasons you’ll need. However, while she mainly discussed mobile websites, I’d like to give an overview on mobile applications and their development methodologies. Should you build for the platform or the browser? Or both? What is the difference between a mobile website and a mobile application? What is a hybrid application? Knowing the strengths and weaknesses of each approach is vital when making the decision on how to best reach and serve your end-users. Read More…
The Microsoft Surface Pro, iPad 4, and the Nexus 10 are all great and revolutionary tablets, but which is better for the workplace? Ever since the release of the 1st generation iPad, businesses have made a slow and steady turn toward having tablets in their arsenal of technology, but why?

Once the future of portable PCs, today laptops can be considered big, heavy, expensive…and unless you are on the high-tech side of IT or a graphic designer, you are probably using your laptop primarily to check email, browse the web, VPN and use Microsoft Office. So why carry something around that is so bulky and needs its own carrying case when there are other options? In essence, laptops are too bulky, smart-phones are too small or restricting, and PC towers were not designed to be portable. This is where the tablet comes in.

The tablet PC, or simply tablet, has been around for some time but was revolutionized and made a modern household item when Apple introduced the iPad in 2010. Since then, the competition has worked furiously to catch up and make solid tablets that are great for both the consumer and the professional. In addition to the Nexus 7 and 10, the new Microsoft Surface Pro has quickly proven itself to be a strong alternative to the iPad 4. So which one is the best for the workplace? To start we will need to at look at the guts. Read More…

We recently started working on a new iOS project.  As part of this adventure, I asked the team if we could build a case study around XCode and TFSPreview.com. TFSPreview, if you’re not aware, is Microsoft’s Team Foundation Server 2012 as a service, hosted in Azure.

This isn’t your normal pairing.  Mac developers aren’t exactly flocking to the Microsoft stack and the Microsoft development tools haven’t exactly catered to the predominantly OSS community working on Macs.  In recent years, though, that has changed.  ASP.Net is now OSS, first class Azure tools ship for the Mac, even the Nodejs for Azure tutorials feature Chrome on a Mac.  It’s a brave new world out there!

Starting with this post and continuing over the next few months, I’m going to be sharing some of our experiences building iOS/XCode apps on TFSPreview using the cross-platform (yes, they used Java – who are these guys?!) git-tf plugin.

Read More…