This sections examines some common mobile app issues and offers tips and tricks to work around the problem.  For additional help, refer to the iOS Human Interface Guidelines on Apple's website.

Mobile app user interface (UI) design issues

When releasing a mobile app, it's important your users have a satisfying experience.  Below are some known issues surrounding the user experience that you should keep in mind when developing your mobile app.

Device limitations:

  • iPhone/iPod touch: Due the small screen size, visual design should be as simple, clean and streamlined as possible. Avoid navigation elements at the left/right edges of the screen for landscape apps.

Touch screen interface limitations:

  • Since there is no Flash rollover to provide visual and audio cues, it is important to provide clear text labels for all functions of the app.
  • Beware of overlapping hot zones! Nothing is more common and frustrating than accidental taps.
  • Beware of the fingernail! Fingernails do not conduct electricity and thus do not generate a response on a capacitive touch-screen. Each interactive element should ideally have a 40x40 pixel hot zone to fit a whole fingertip (not always practical, but again ideal).
  • Some users will press hard if they do not see the app responding instantly, thinking pressing will cause a response. This can be a big challenge in an app where you set a function to run onRelease instead of onTap. You may be tempted to use onRelease in an environment where you enable pinch and zoom, swiping, flicking or other movements that conflict with onTap. Think carefully about these competing challenges and the perception of responsiveness or lack thereof. For example, if you must go with onRelease, consider changing the state of an element (e.g., a button) when pressed.

Legibility:

  • Text should always be presented in a manner consistent with the changing contrast needs of a mobile device; dark sans-serif text on a light background is preferred for any long-form text.
  • It is far more important for a user to be able to read the text than to have a beautiful background.

Navigation:

  • Offer a clear, consistent way to return to the previous screen or main menu. Back arrows, tabs, and/or home icons are generally recommended.
  • For standard functions (e.g., turning sound on or off), we recommend making use of the device Settings panel.
  • Avoid deep menu systems.
  • Hide information not needed at a given point in time (a general usability principle, but especially key on the iPhone/iPod touch).

Testing:

  • User-test at every point in the process that you can. The more iterative you can make development, with real users testing at each interval, the better. By "real users" we mean people not involved in any way with development of the app and who are not familiar with the intended functionality and the things that may seem "obvious" to someone fluent with the project.

Technical issues and recommended resolutions

Device-specific functionality:

*Devices are constantly changing and evolving, this is just a sampling.

  • iPhone: Has camera (5-megapixel on iPhone 3GS and 4) and microphone and HD videocam (lower capabilities with older models)
  • iPod touch: New ones have HD video. Current install base has no microphone and pre-iOS 4 had no camera.
  • iPad: iPad 1 has camera and camera connector is an extra peripheral. All iPad 2s have both a front- and rear-facing camera. To look good on iPad, all graphical assets need to be higher resolution, which means you will either need two asset classes, or you will have very heavy, high-res images on the small-screen version and have to optimize file size and performance more carefully.
  • Non-Apple devices come in a bewildering array of screen size and configuration. It's impossible to support them all and so careful research is needed.

Performance:

  • Varies by device somewhat and by version. Older phones will naturally be less performant. Multi-tasking can also hit performance, so test your app with another app running in the background.

File Size:

  • Storage space ranges from 8 GB to 64 GB and iPhones and iPads will not be able to download an app over 20 MB file size over 3G network - only WiFi or syncing.

Tailoring to the device class:

  • Often you may wish to provide an app as a universal binary, if the intended functionality will work similarly on small screen and tablet-size screen.
  • However, if you see ROI in creating separate versions, think of the iPad as generally a more relaxed experience with more opportunities for content depth, richness, and use of two hands (often on a hard surface), whereas iPhone/iPod touch might (in SOME cases) be a shallower experience, with more snacking/hurry, more expectation of precise geo-awareness, and probably use of only one hand or two-thumbs without a hard surface underneath.

Build process:

  • This can be a complicated process, and should be done in close coordination with your PBS contact.
  • To get on PBS store, you will need to switch over to PBS' distribution certificate.
  • Many things can go wrong in final compiling and sometimes the process is not transparent, so leave approximately 6 weeks from final build before scheduling major promotions.
  • Expect two weeks of Apple review and leave extra time for possible rejection and resubmission if you are planning against a hard deadline