Stuff to implement before you launch on App Store

A collection of small-ish things that can make a difference.

Published: April 28, 2022
See books

Having launched a few of my apps and another bunch of client ones, I thought I would try to come up with a list of more minor things worth adding before your app goes live for the first time.


Having a prominent way for the users to get in touch with you may be the difference between hearing about an important issue and getting a one-star rating.

With the option to change the default email client on iOS, this is now much easier. You can use mailto URL and let the system handle it.

Make sure to also display the email address in the UI either when mailto cannot be opened or just at all times.

It is also good to add the version number to the email, so you know in which versions the issue is happening.

See for more info: How to send email using default email app [my blog]

Crash reporting

Sadly the crash reports we get from Xcode aren’t sufficient, and this doesn’t look likely to change anytime soon.

I am massive fan of Sentry - they have an excellent web app, and the reports mostly tell you where the problem is. Unless your app crashes a lot, the free plan should be enough.

A popular free alternative is Firebase Crashlytics. Assuming you don’t mind adding Google SDK to your project.

Review prompt

App ratings matter a huge deal. Especially when you have a brand new app. I recommend implementing basic logic that shows the SKStoreReviewController after the user completes an action inside your app.

iOS automatically limits how often this prompt can be shown. It should be a maximum of three times a year and once for a version of the app.

See for more info: Requesting App Store Reviews [Apple]

Save first installed version

This only applies if you are monetizing your or have monetization plans for the future.

On the first launch, fetch the current version of the app and save it to Keychain. This way, it will be persisted for the user even after reinstall.

If you decide to lock more portions of the app in future updates, you can apply this to only new users and don’t risk backslash from your existing users.

Taking away stuff from your existing users probably never goes well.

Kill switch

Another optional item. If there is a risk of bugs that could severely impact your business, you should have the means to let users know that they need to update it from the App Store to continue using the app.

Kill switch doesn’t have to be too fancy. You can have just some simple JSON available somewhere from which the app gets a minimal supported version on each launch.

If the current version is lower than the supported ones, you can display a full screen telling the user to update.


This one depends on the complexity of your app. If you have something that requires setup or specific permissions, then onboarding makes a lot of sense.

Similarly, for FAQ. If users might run into issues, you can anticipate, adding FAQ can help save you from bad ratings and support emails.

For FAQ, you can check out Supporter by Jordi Bruin.

Other considerations

Check out this Twitter thread for more items.

Filip Němeček profile photo


Filip Němeček

iOS blogger and developer with interest in Python/Django. Want to see most recent projects? 👀

iOS blogger and developer with interest in Python/Django. Want to see most recent projects? 👀