Lessons Learned: PMing an iOS Project

Published in

Product Labs

7 min readApr 11, 2016

You’re a product manager on your first iOS project! You’re thinking, I’ve PMed many web projects, what could be so different? Below is information I wish I knew before my first iOS project, along with some helpful resources to get you up to speed.

User flows + navigation design should be nailed down before development begins (or by Inception when the initial backlog is created). Changing the navigation affects the architecture, which can be very expensive. Because iOS is relatively new compared to web, there isn’t the same amount of tooling and support to make design changes easily.

Designers need to know Xcode in order to make design changes (vs HTML/CSS in web apps). If the designer does not know Xcode, they will need to provide high fidelity mocks + product spec docs to the developers instead. This means it’s extra important for design to stay ahead of development, especially for navigation elements that will affect the architecture. If you or the designer is unfamiliar with iOS, be sure to work closely with iOS developers to understand implementation costs.

Similar to a web app, where you need to determine which browser versions to support, for an iOS app, you need to determine both what iOS version and devices to support. Supporting multiple iOS versions can be very expensive. It is a big jump between supporting only iOS 9 to supporting both iOS 8 & 9. The jump is even bigger when you add iOS 7 into the mix. Make an informed decision when deciding what versions to support by looking at data:

Which iOS versions are people using to navigate to the company’s home page?
What is the current adoption rate of the newest iOS version?

You should lean on iOS developers to understand how difficult it would be to support multiple iOS verions. On my previous project, we only supported iOS 9+. Since iOS 9 is able to run on an iPhone 4s, we made sure the app functioned properly on all devices iPhone 4S and newer. Based on our target users and development time, we decided not to support the iPad. More on that below.

An iPhone app will work on an iPad (you will see a “2x” button in the corner). The app store on an iPad categorizes “iPad” and “iPhone” apps separately. Thus, if your app is only for “iPhone”, the iPad user has to explicitly search under “iPhone Only” apps in the app store. If they search for your app under “iPad Only” apps, it will not show up.

There is an option in Xcode to make your app “universal”, which means you can optimize the design for iPad and your app will show up as an “iPad” app in the app store. Keep in mind this requires separate assets and possibly additional development work if you want the UI to be different.

Acceptance criteria for iOS stories is longer. A user can interact with a touchscreen in more ways they can on a desktop/laptop. Thus, in an iOS story, you need to add more acceptance criteria for these additional interactions. For example:

What keyboard should appear when a user taps on an input field?
Are there limitations on what a user should be able to enter in on keyboard?
What happens when a user swipes left or right?

Another major difference is that you don’t have control over when a user sees app updates. Unless a user has “automatic app updates” turned on, they will have to manually update to the newest version of the app. This will bifurcate your user base between the old and new versions of the app. As time goes on and you release more and more versions of your app, you will have to decide between continuing to support the different versions or forcing all users to update to a minimum version. If the API introduces breaking changes for one of the supported app versions, you will have to force an update. Forcing app updates is something that should be used sparingly because it is very disruptive to users.

Unlike the internet in your office, mobile networks are very inconsistent. You have to take into account connectivity issues when designing your mobile app. For example, if your user is on the subway with no connectivity, how should the app behave? If your app needs to work offline, this needs to be built in from the beginning. Separate stories may be needed to elegantly handle various connectivity issues.

Designing for iOS

Respect the design patterns and standards of the platform. Taking them all into account means designing apps that are intuitive to use and play well with the rest of that platform’s ecosystem. Thus, a good place to start is with standard iOS patterns. If you discover through usability testing that a standard pattern needs to be changed, discuss with devs about how much effort it will be and reassess if it is worth it.

Design for a target screen size first, then make sure the design works for all other supported screen sizes. The designer should provide separate assets for both retina (2x) and plus (3x) sizes. As mentioned before, if you want your app to be an “iPad” app, this will require separate assets as well.

iOS allows you to create lots of cool animations to aid with usability and enhance the overall user experience of your app. Keep them in mind when you’re designing. For example, take a look at the Shimmer library.

Apple App Store Release process:

Ready to publish your app to the App Store? Be prepared to be at the mercy of Apple. Apple takes an average of 10 days to approve an app. Also note that Apple review is closed during certain holidays. Make sure you take this into account when planning release dates.

Here is a high level diagram of the differences between releasing a web app vs an iOS app:

The main difference is that for a web app, you deploy the WAR file to a specific environment. For an iOS app, when compiling the iOS code, you point it to a specific environment (e.g. Production). The iOS code (.ipa file) is then sent to Apple. If you only make changes to the back-end, you do not necessarily need to submit a new .ipa file. Releasing back-end code and iOS code should be treated as two separate releases.

TestFlight is Apple’s online service for over-the-air installation and testing of iOS mobile applications. You need it in order to submit your app to Apple for an app store review. Ideally, you will be able to push a build directly onto a device for acceptance/testing. However, if you have remote testers, you will have to leverage TestFlight so they can install the app onto their iPhone. An alternative to Testflight is the HockeyApp. It might be a better choice depending on your team setup and distribution. Talk to the developers as to which might work best for your team.

Tips:

Beginning of project:

Acquire devices: If devices need to be provisioned by security, be sure developers still have the ability to push a build directly onto the phone or else you will have to use TestFlight which will add significant delays. Also, make sure you have at least a few extra phones for user testing and demos.
Set up iTunes Connect account: Talk through the release process for the iOS app. This is especially important if this is the company’s first iOS app. Who can press the “release to app store” button? What sign offs are required? This could potentially add days/weeks to your release process.
Set up analytics tool: Recommend Mixpanel or Flurry

You can submit an “MAP” (Minimal Approvable Product) version of the app so that Apple can identify any major issues that need to be fixed immediately. This lowers the risk of delaying your first official release. When submitting an MAP, you should have enough functionality for the Apple approver to go through the entire workflow (happy path). Note that just because your app was approved once does not mean that your app will be approved the next time. The app might reviewed by a different person who follows a path the previous tester did not venture down. Always be prepared for your app to be rejected.

Before a big release, I find it helpful to have the entire team to do “mob usability testing.” This means having everyone download the version of the app you plan to release onto an iPhone and try to break the app. This not only catches new issues but also gives the team collective ownership of what you are shipping.

How to:

Set timer for 15 mins (depends on complexity of app). Everyone tests and writes down their findings on post-its. Keep findings to themselves.
After testing, open a blank Gsheet and go around the room and record everyone’s findings.
For each finding, determine the action item (e.g. design will investigate, create bug/story in backlog, test in next user interview)

Lastly, and probably the most practical tip, how do you project/record iPhone screen on your laptop? If using a Mac, you can plug your phone in and use Quicktime. Select “New Movie Recording” and select your iPhone from dropdown next to record button. On PC, you need to install a third-party tool like Reflector.

Resources:

Design Inspiration: Shows how other apps are handling similar design problems:

Lessons Learned: PMing an iOS Project

Table of Contents:

Written by Melanie Matsuo