8. App Approved! (Now What?)

Written by Pietro Rea & Keegan Rush

So far, the chapters in this book have followed a narrative arc. You first learned how to upload a build to App Store Connect. You then mastered the art of code signing and provisioning. You learned how to distribute your build to internal and external testers using ad hoc distribution and TestFlight. And in the previous chapter, you learned how to prepare for App Review.

This chapter deals with what to do after you pass App Review. You might be wondering, is there anything left after Apple blesses your app for release? Wasn’t the whole point to get an app on the App Store?

Not only is there more to do, how you release and what you do after release can determine your success or failure. Think back to the app lifecycle diagram from Chapter 1, “The App Store”. This chapter covers what happens during the pre-release and post-release phases. The following diagram shows the app development cycle overview:

First, between the App Review and App Store phase, imagine a thin section called Pre-release for those who’ve opted to manually release, as the previous chapter recommended. The optional Pre-release phase is where you do your last-minute checks before releasing your app to the public.

At a minimum, you should have a release checklist that helps you click the Release button with confidence. The next section covers the best way to perform pre-release checks and what should go on your checklist.

Second, after uploading your app to the App Store and before a new Development cycle, there’s Analytics. This phase might sound like you can just kick back and wait for your numbers to come in. But in fact, Analytics might be the most challenging phase of all.

This is where your team answers the question “what should we do next?”, which informs the next app development cycle. Typically, product managers use the business context, resource constraints and customer feedback to create a road map.

Even though there’s no easy recipe for success, the second half of the chapter covers the different sources of feedback to monitor so you can make decisions with the best information available.

App Store Connect’s built-in tools for monitoring feedback only become useful after you’ve had an app in the App Store for some time. Therefore, you’ll look at the numbers for a real app called Math Ninja HD.

Smoke testing before release

Pre-release involves many small steps that must be done correctly. Here’s a classic oversight: Many apps depend on back-end systems. Sure, testing went smoothly in the pre-release staging environment, but did anyone remember to promote the app’s necessary changes to production?

If not, you suddenly have a situation where everyone who downloads your app from the App Store crashes on launch. As it turns out, you changed something so your app now expects data to come back in a new format, but is getting it in the old one. Whoops. That’s something you really want to catch before release.

In the previous chapter, you learned about the three version release options in App Store Connect: manual, automatic and automatic with a target date. When you choose the manual option, you get a window of time between approval and release in which you can perform last-minute checks. These are called smoke tests or sanity tests.

Creating a checklist gives you a systematic approach to minimize many common oversights.

Creating a checklist

Before diving into the checks to perform before release, take a detour to the world of medicine. Releasing an app is a complex and high-stakes endeavor, but no one would argue it’s more so than a life-or-death medical procedure. In his 2009 book, “The Checklist Manifesto: How to Get Things Right”, the surgeon, writer and public health researcher, Atul Gawande, writes about the need for checklists in increasingly complex fields like medicine and engineering.

His team developed the “safe surgery checklist” and applied it around the world. The results were staggeringly positive. Many lives were saved when surgeons followed simple documents spelling out every step they needed to take. If even surgeons who’ve trained for decades need checklists, developers can put them to good use, too.

What goes in your release checklist largely depends on your particular situation, but it’s important to have something to follow with every release.

You can go a step further and turn your release checklist into an internal-facing release page. In an organization with many teams and projects, a release page helps you communicate what the release included, when it was released to the public and any other internal documentation that might be relevant.

Release pages are helpful, even if your team only includes you. Whenever you have to remember what you did when, such as: “how long has this feature been on the App Store?”, you can refer back to your release pages instead of digging through App Store Connect or your Git commit history.

Appendix B has a sample release page, which includes a release checklist.

Using promo codes

Back in Chapter 3, “Submitting Your First App for Review”, you manually picked one build among many to send off to App Review. But what if you’d clicked the wrong radio button? App Review doesn’t know one build from the next, so you could unwittingly release the wrong build.

Fortunately, before releasing your app to the public, you have the option of using a promo code to download the approved build so you can double-check that everything is correct.

To request a promo code in App Store Connect, your app’s status must be Pre-Order Ready, Pending Developer Release or Ready for Sale. However, for a pre-release smoke test, the status will always be Pending Developer Release.

As a side note, Apple created promo codes to let you give free copies of your app to customers and reviewers. You’re not technically using promo codes for their intended purpose, but there’s no harm in redeeming one for testing.

Generating a promo code

Here are the steps to generate a promo code on App Store Connect:

1. Log in to App Store Connect.

2. Click My Apps and select your app.

3. Click the Features tab.

4. In the sidebar, click Promo Codes.

5. The promo code management page opens with the Generate tab selected. Under the App Promo Codes section, enter 1 as the number of promo codes you want to generate.

6. Click Generate Code in the top-right corner.

7. A modal dialog appears. Check the checkbox to agree to Apple’s terms and conditions.
8. Click Generate Code and dismiss the modal.
9. Click View Code. A second dialog appears to reveal your promo code.

Copy your promo code and send it to yourself so you can access it on your iOS test device.

Redeeming your promo code

To redeem the promo code, open the App Store app on your iOS device. Sign in, if you haven’t already, and tap your profile photo on the top right. Then, tap Redeem Gift Card or Code.

See the image below:

Redeeming promo codes shares the same flow as redeeming physical gift cards. The App Store prompts you to redeem your gift card using your device’s camera.

Ignore this call to action. You can’t use your camera to redeem promo codes. Instead, tap Enter Code Manually.

Paste the promo code you’ve generated in App Store Connect. Tap Redeem in the top-right corner.

Once the App Store accepts your promo code, your test device begins to download your pre-release app.

Note: To prevent abuse, Apple made promo codes single-use. If you need to delete and reinstall the app to troubleshoot it, you’ll have to generate and redeem a new promo code.

Using a promo code to download your pre-release app gives you the exact binary your users will receive when they download your app from the App Store. Use this build to go through your pre-release checklist.

If you can’t get your hands on a promo code, the next best option is to run through your release checklist on the last TestFlight build for this version of your app. Of all build types, TestFlight builds are the most App Store-like. However, since you can use TestFlight to test multiple builds at once, you still run the risk of smoke testing the wrong build.

Once you’re happy with your approved build, open App Store Connect and release it to the public. Congratulations!

Monitoring your app

For the post-release phase, monitoring incoming feedback is one of the primary ways to figure out how you’re doing and what to do next.

Feedback can take many forms. Of course, you can receive direct customer feedback through support emails and App Store reviews. However, feedback can also be passive and less obvious. Passive feedback includes:

• Analytics about your app, like sessions and active users
• Crash reports
• Monitoring of your back-end systems

This is where you take on the role of a data scientist so you can make sense of the aggregate data.

App Analytics

Apple provides built-in analytics for all members of the Apple Developer Program. You don’t need to do anything to start using the built-in tools — all you need is an app on the App Store.

Log in to App Store Connect to see your app’s numbers. Instead of clicking My Apps, like you usually do, click App Analytics.

The next page shows a high-level analytics overview for every app in your account. Here’s what the numbers look like for Math Ninja HD:

The summary view defaults to the last 30 days, but you can change the date range. Here’s what each metric means:

• Impressions: The number of times Apple surfaced your app on the Featured, Categories, Top Charts or Search sections of the App Store. This number also includes product page views.
• Units: The number of times someone downloaded your app.
• Sales: The total amount billed to your users for purchasing Math Ninja HD or any of its In-App Purchases.
• Sessions: The number of times someone used your app for at least two seconds. Only users who agreed to share their data with third-party developers count towards this number.
• Crashes: The number of times your app crashed. Only users who opted-in count towards this number.

Click the summary row, which brings you to a more detailed summary page with more metrics.

See the image below:

Here’s what some of the new ones mean:

• Product Page Views: While Impressions gives you the number of times your app showed up anywhere in the App Store, Product Page Views only includes the times someone visited your App Store product page.
• Conversion Rate: Conversion rate represents the number of app downloads compared to the total unique impressions. Make sure to monitor your app’s conversion rate if you do any work to improve your App Store product page, like adding App Previews, fleshing out the description and so on.

On this page, you also see which regions of the world your users come from, as well as how they found you and which devices they used. You can click any tile on this page to get more granular information, apply filters and more.

Note: The App Analytics section in App Store Connect focuses on visitor and usage information. It’s primarily geared toward making product improvements.

If you’re looking for more robust sales and financial reporting, head to the Sales and Trends section in App Store Connect.

Built-in versus third-party analytics

When it comes to analytics, third-party tools can only tell you what happens after someone downloads and opens your app. If you want to know anything before that, such as App Store impressions, the built-in tools are your only option.

Although third-party tools can’t give you all the data you might be interested in, they fill gaps that Apple doesn’t cover. In particular, there are two ways third-party tools can help:

1. App-specific metrics: If you want to know how many people reached level two in Math Ninja HD, you’re out of luck without third-party tools. App Store Connect can’t tell you anything specific to your app. For this, you need custom analytics.
2. Data from all your users: Apple only reports session and crash reports from users who agreed to share information with third-party developers. If you want data from all users, you need custom analytics.

If you decide to use a third-party analytics tool, make sure its data collection and data retention policies align with the App Store Review Guidelines and all applicable laws.

When you submit an app for review, you’ll need to provide information about your app’s privacy practices, including the practices of third-party partners whose code you use. For more information on required privacy disclosures, refer to Apple’s documentation: https://apple.co/3stPWkE.

Crash reports

Crash reports are another important source of feedback. An app crashes when something unexpected occurs, usually because of a flaw in the source code.

Crashes are a fact of life — every app crashes from time to time. Each time a crash occurs, the operating system ejects the unlucky user out of your app, regardless of what they were doing at the time.

Although getting thrown out of an app is frustrating, most people won’t report the crash or even complain. It’s up to you to monitor crashes as they happen so you can fix the root cause promptly. Fortunately, Apple makes this easier with built-in tools in App Store Connect.

Note: Chapter 6, “TestFlight”, covered collecting crash reports from beta testers. The process is similar, though not identical, for App Store builds. You can skip this section if you have a good handle on TestFlight.

To see crash report information, click the Crashes tile on the metrics summary page. On the next page, you can filter crashes by app version, device type and OS version.

The graph only reports the number of crashes that occurred on a particular day. Do note that the crashes recorded are from users who have opted in to share analytics with developers. App Store Connect doesn’t give you any other details, technical or otherwise.

Knowing that a crash occurred is the easy part. The more challenging part is reproducing, diagnosing and fixing the crash. To do so, open Xcode to see a crash report’s technical details. Log in to Xcode using an Apple ID with access to the crashing app.

Next, press Shift-Option-Command-O to open Xcode’s Organizer. You might remember the Organizer from previous chapters, where you had to archive and upload builds. You can also use the Organizer to browse through a released app’s crash reports.

On the top left, click the drop-down icon and select your app. In the sidebar, under Reports, click Crashes. Xcode then begins to download recent crash reports.

Every crash report has a stack trace, which is a detailed description of what your app was doing moments before it crashed. Here’s part of the stack trace from the previous screenshot:

Thread 0 Crashed:
0  mathninja             0x0000000104967a90 0x104118000 + 8714896
1  mathninja             0x0000000104967a74 0x104118000 + 8714868
2  mathninja             0x0000000104a449b0 0x104118000 + 9619888
3  mathninja             0x0000000104a446a4 0x104118000 + 9619108

A stack trace is essential to the debugging process as it often has clues about why the crash occurred. This particular stack trace has memory addresses (e.g 0x0000000104967a90) instead of human-friendly pointers into the code, which a developer could more easily understand.

To make this stack trace more helpful, you’d have to symbolicate it. To read more about crash reports, including how to symbolicate them, refer to Apple’s documentation: https://apple.co/3kpzVJE.

If you have access to the source code, you can also open the crash report inside its corresponding Xcode project. To do so, click Open in Project… and select the Xcode project that corresponds to your app. This links you directly to the line of code where your app crashed.

Like App Analytics, there’s no shortage of third-party tools to help you monitor crashes. The trade-offs are similar as well. If you use a third-party tool, you’ll have access to crash reports from all users instead of just those that opted-in. However, now you have to worry about implementation, privacy and data sharing.

Ratings and reviews

Ratings and reviews are another important source of post-release information. Users can rate your app on a scale from 1 to 5 stars and can also write a detailed review of your app for others to read.

Ratings and reviews both end up on your App Store product page to help potential customers decide if they want to try your app. Beyond their obvious benefits to end-users, ratings and reviews also give you useful qualitative data about your app.

Note: Motivated users will find the right place on your App Store product page to leave a rating or review. However, Apple also provides an API, SKStoreReviewController (https://apple.co/388PW1N), which lets you programmatically request reviews from your users as they’re using your app.

To see your ratings and reviews, return to App Store Connect’s top-level menu. From here, click My Apps, then select your app.

In the sidebar, under General, click Ratings and Reviews. Here, you can see your app’s aggregate star rating by territory. In this case, 4.3 out of 5 for Math Ninja HD in the United States. Not bad!

Below your app’s rating information, you can also read individual reviews. You can filter them by the version or the number of stars. You can also apply filters like Most Recent or Most Critical. For example, here’s a glowing review of Math Ninja HD:

Users can only review your app once, but they’re allowed to change their minds and edit their reviews at any time. For example, the user from the previous screenshot might love Math Ninja HD for the first two versions. But if they have a problem with version 3.0, they can change their previously glowing review to complain about the new release.

Apple also lets you reply to reviews. You can use this feature to provide lightweight customer service or to ask for more information. You can also edit your reply or delete it at any time.

One of the most rewarding experiences you can have as an app publisher is to see negative reviews turn into positive ones after proactively addressing their problems.

Maintaining your app

Monitoring your app after release can help you figure out what to do in the short term, such as addressing a critical bug fix, as well as in the medium term, like adding a new feature. But what about the long term?

Apple provides no fancy tools in App Store Connect to help you decide which direction to take. What you do with your app over time is entirely up to you.

As you look into the future, watch out for two forces that may prompt you to release new versions of your app. These both come from Apple, so they apply to every third-party developer.

Minimum ongoing maintenance

Don’t expect your app to work for years and years without any work from you. The platform you built it on changes too quickly for that. Apple releases new hardware every year, as well as new versions of their operating systems and SDKs.

Practically speaking, this means you need to retest your app whenever Apple releases software or hardware that affects your user base. At a minimum, rebuild your app with the latest version of the SDK, test on new hardware and fix anything that doesn’t work anymore.

Apple typically releases beta versions of new software in June and officially releases them in September. Most developers use the intervening time to test and update their apps. As a word of warning, be sure not to fall too far behind on maintenance. From time to time, Apple purges apps from the App Store that don’t work anymore or look abandoned.

New technologies and opportunities

With every new hardware and software release, Apple brings forth new technologies and capabilities that third-party developers (that’s you!) can take advantage of. Here are a few notable examples from the past decade:

• Push notifications, iOS 3
• App multitasking, iOS 4
• Touch ID, iOS 8
• Augmented Reality, iOS 11

Some of the older technologies, like push notifications, are commonplace today, but there was a time when they were brand new. It was up to app developers to adopt them.

Unlike maintenance work, adopting new platform capabilities isn’t required. No one is going to remove your app from the App Store if you don’t integrate with Apple’s latest frameworks. It’s up to you to pick the capabilities that fit your app and release app updates that take advantage of them.

If this sounds interesting, then you must pay attention to platform changes. Apple holds a yearly Worldwide Developers Conference, commonly known as WWDC (“dub-dub”) around June, where they announce new platform capabilities and improvements to existing ones.

Attending WWDC in person is one of the most exciting things about being a developer on Apple’s platforms. If you can’t get a ticket to attend in person, you can always watch the videos on Apple’s developer site: https://apple.co/3bIhhsv. Videos from previous years are also available.

Key points

• Use the window of time between approval and release to perform sanity checks and smoke tests. This only works if you picked the manual version release option.
• Create a release checklist that includes everything you need to do before you go live.
• Generate and redeem a promo code to download a pre-release version of your app. Use it for your sanity checks and smoke tests.
• Monitoring feedback is an excellent way to figure out how your app should evolve over time.
• App Store Connect has built-in tools to monitor analytics, crash reports, ratings and reviews. There are also third-party tools that can help.
• At a minimum, release app updates to take care of basic app maintenance. You can also release changes that take advantage of the new platform capabilities Apple ships every year.