Deploying to stores
Say you've finished building your app and it's ready to be published to the stores. What are the steps you need to take in order to get this app to your end users?
1. Get a developer account
With Apple and Google you can sign up either as an Individual Developer or a Business. If signing up as a business you need to provide additional information to verify the organization's identity and legal entity status.
It is important to note that if you offer paid apps (via one-time purchase or in-app subscriptions) then your full legal address will be made public on the store page on both platforms. So if you're planning to charge for your apps, it might be worth registering as a company if possible.
For Android you need a Google Developer account. This comes with a one-time $25 fee. When signing up as an individual developer you need to prove your ID and address which will take a couple of days to go through.
For iOS you need to sign up for the Apple Developer program. This comes with an annual fee of $99.
2. Create the app
Now that you have an account, you'll be able to register the app on both stores.
3. Build the production app
For both iOS and Android, the build you submit to the stores is differently signed, more optimized version of your app that isn't directly installable on a device and can only be downloaded via the stores.
The development builds for Android are an .apk format, but the production build is an .aab - the Android App Bundle. Put simply, an debug APK includes all the files and binaries used to run the app on any Android device which means that it's quite large and there's a lot of code the is left unused. When you upload an AAB to Google Play, the store will generate a custom binary for each user based on their device's needs, resulting in a much smaller download size for the end user.
The iOS production app will be an .ipa format, signed with the Production provisioning profile and Distribution signing certificate.
4. Upload the production app
Next you'll want to upload the built bundle to the stores.
For Android, the first build must be uploaded manually via the Google Play console website by dragging and dropping it in the UI. Subsequent build can be done the same way, or with eas submit.
For iOS, the builds can be uploaded either via the Transporter app, eas submit or via Xcode.
5. Metadata
For both iOS and Android, there's quite a few forms to fill out: you'll need to declare what kind of user data you're tracking, what your app is used for, what countries it should be available in, is it free or paid etc. Then there's also promotional text like the app name, tagline, description and keywords.
6. Images
You'll also need to generate some promotional assets for your app, namely the "Screenshots" (they don't have to be actual screenshots, just an accurate representation of your app in the right file size), and in case of Android, a banner image and app icon.
Here's the list of the bare minimum you need to create in order to submit your app for review.
7. Testing
Both stores include a "testing" option which you can choose to use before submitting your app for review. This is meant for user acceptance testing, so the testing will be done on your actual production app.
On iOS this is TestFlight. In fact, all builds you upload to the App Store end up in TestFlight initially. TestFlight has an Internal and and External testing group. When you upload a build it becomes available to the Internal group and only users who are registered on your Apple developer account will have access. Anyone can be invited to the External group via email, or public link, but in order for your build to be available on the External group, it has to go through a small review process (it usually takes a couple of hours).
On Android you can have open, closed and internal test tracks. Anyone can be invited to the internal test track via their Google email, but it is limited to 100 users. For the closed track, users will be invited via email and in case of open testing, your app is available to the general public on Google Play, but with a "Pre-release" warning. Note that you don't have to go through all of these testing stages, you can promote from internal straight to production.
For Android apps created under personal accounts you will need a minimum of 20 testers who have been opted-in for at least the last 14 days before you can apply for production access. Business accounts do not need to do this.
8. Review
Finally, you submit your app for review. This is perhaps the most unusual part of the process compared to web development: both Apple and Google do both automated and manual checks on your app before it can be approved for production. These checks can take anywhere between a couple of hours to several days. The reviewer will check that your app is functional and complies with the store terms and conditions.
Your app may be rejected for various reasons (and iOS reviews tend to be more strict than Android), for example the first time I submitted the React Conf app on iOS it was rejected because the app includes native code to change the app icon, but the reviewer couldn’t find that feature. I replied to the reviewer, explaining how to access it via the quick action and the app was finally approved after a couple of hours. Your app would also get rejected if it crashes on launch, if the reviewer can’t log in, if your usage descriptions are not descriptive enough, and many other reasons.
If the reviewer finds something amiss, they will reject your app with an explanation, and the fix is usually to either reply to the reviewer to explain something they missed, or to fix the code in-app and re-submit a new version for review.