How to Successfully Publish Your App on the App Store or Google Play

As someone who has released many apps starting in 2015 using frameworks such as Cordova and Ionic, and more recently using React Native and Expo, I have learned that the rules for publishing apps can change frequently and can sometimes be challenging to navigate. With that in mind, I want to provide a brief guide to help others navigate the process. While this guide may not cover every aspect of publishing an app, it does cover general tips and information that should be useful for anyone looking to release their app on the App Store or Google Play.

Metadata

Keywords, Description, Screenshots, App Name, Promo Videos

There are significant differences between Apple and Google when it comes to metadata. Apple is generally stricter than Google, so it is advisable to follow Apple's guidelines to ensure the best chances of success on both platforms. Here are some tips to keep in mind:

Keep your screenshots and promo videos separate for each platform. Mixing an Android device with an Apple device will result in metadata rejection from Apple. In the past, we had an app update rejected because a promo video included a brief illustration of a Samsung device. We had to re-render the video and replace the illustration with an iPhone to be accepted.
Avoid using trademarks in your description and mentioning other apps. It is okay to use them in keywords, as they are invisible, but do not use them elsewhere.
Do not use words like "beta," "alpha," "test," or release a version of your app with a version number like "0.1." Apple will label your app as "unfinished" and reject it. Using "beta" in screenshots will also result in rejection.
Do not show anything in your screenshots or videos that does not actually exist in your app. Your promo video must also always show the use of an iPhone (or a screen recording), or it will be rejected by Apple. While Google is more lenient in this regard, it is still advisable to follow these guidelines on both platforms.

Network, OTA, and App Size

If your app communicates with an API, make sure that it is reachable on native IPv6-only networks as well as IPv4 networks. We have had an app rejected in the past because it was not reachable on IPv6-only networks. To ensure that your domain is properly set up for IPv6, make sure it has AAAA DNS records for each endpoint and that they are correctly connected and reachable. While not all ISPs are designed for IPv6 yet, this will become increasingly important as we run out of IPv4 addresses.
OTA updates to your app are generally allowed as long as they do not significantly change the user experience, appearance, or core functionality of the app. Bug fixes and minor changes can be rolled out to users via OTA.
If your app is unnecessarily large due to the inclusion of very large videos or photos, it may be rejected. While this is not as strict a requirement as it used to be due to improved network speeds, it is still good practice to download and cache content such as photos and videos asynchronously to reduce the size of your app. In the past, this reduced the size of our app from 300MB to 20MB, but it was worth the effort to make the app more efficient.

App permissions

Only ask for permissions that you truly need for your app to function. Asking for every possible permission from the start will result in rejection.
On Apple platforms, you are only allowed to ask for permissions once. Any further requests must be made through the app's settings. In the past, some developers displayed their own permission dialog before the native dialog was loaded in order to avoid the detour through the app's settings. Recently, Apple has started rejecting apps that have a closable custom permission dialog, requiring developers to force the native dialog to be displayed instead.
Apple now requires more detailed explanations of why a permission is needed and how it adds value for the user in the permission text. In the past, short texts were sufficient, but we have had app updates rejected 3 times in November due to insufficient explanations. A sentence like "With access to the camera, you can record videos directly with our app. You can then immediately upload the video and share it with the community" was ultimately accepted.

{
    "NSCameraUsageDescription": "With access to the camera, you can record videos directly with our app. You can then immediately upload the video and share it with the community.",
    "NSMicrophoneUsageDescription": "With access to the microphone, you can record videos directly with our app, including sound. Without access to the microphone, your videos are mute.",
    "NSContactsUsageDescription": "Access to contacts is required so that we can check if your friends are already at X!",
    "NSPhotoLibraryAddUsageDescription": "Write permissions for the media library are necessary so you can save videos and drafts onto your device.",
    "NSPhotoLibraryUsageDescription": "With access to your photo library, you can share content with the community directly with our app. You can upload videos and pictures."
}

The rules for important push notifications (which can bypass Do Not Disturb mode), NFC, and Bluetooth are stricter and may require pre-approval. It is important to thoroughly research these topics to ensure compliance.

User Generated Content (UGC) and NSFW Content

Apps that contain user-generated content (UGC) are subject to stringent regulations. It is important to strictly adhere to the following rules:

You must have a privacy policy and terms and conditions in place.
You must clearly state that illegal content is prohibited and will be punished or prosecuted.
Each generated post must be reportable with a function that is easy to find and use (e.g. three dots next to the post). Provide options and categories for reporting, such as spam, pornography, copyright infringement, etc. Respond to every report within 24 hours. Google may conduct random checks to ensure compliance.
Users must be able to block other users and have the option to hide content from blocked users and prevent all forms of contact.
Each generated post must be "collapsible" and disappear immediately. You can either solve this locally or via your server with a block list.
Your app may contain explicit pornography or violence as long as it is not the core focus of the app. NSFW content must be behind a "block wall" (sensitive content) and may only be displayed with explicit approval. NSFW content may only be made available to registered users, and their date of birth must be verified. You may give registered users the option to display sensitive content without a block wall (provided the age is correct for the respective country and the setting has been explicitly activated, as on Twitter or Reddit). If your app allows NSFW content, you must allow it to be marked as such or use machine learning/artificial intelligence/moderation to detect such content. We generally recommend using computer vision for content analysis if manual moderation is not possible, as failure to do so can result in your app being removed from the stores. For example, Google removed our app from the stores for sexually depicting stick figures (no joke).

User Registrations

If your users can sign up using third party services such as Facebook, Twitter, or Github, you are required to offer "Sign up with Apple" as an option. It is unclear if you are required to offer "Sign up with Google" as well. (Note that this rule does not apply if you only offer registration with email or phone number.)
Since 2022, if your app offers registration or login, you are required to include a "delete account" function directly within the app.
Asking for too many sensitive fields during registration, such as religion or address, without a valid reason may result in rejection. Only request information that is necessary for the functioning of your app.

Further Considerations for Ensuring Your App's Approval

Here are a few additional suggestions you may want to consider:

Make sure your app is fully functional and bug-free before submitting it for review. Apps that crash or have other serious issues are more likely to be rejected.
Use clear and concise language in your app's description, and make sure it accurately reflects the content and functionality of the app.
Follow the design guidelines for each platform, as apps that do not adhere to the guidelines are more likely to be rejected.
Consider hiring a professional to translate your app's description and other text into different languages if you plan to release your app in multiple countries.
Be prepared to make changes to your app based on feedback from the review process. The review process is intended to improve the quality of apps, and being open to constructive feedback can help your app get approved more quickly.
Consider hiring a professional designer to create high-quality visuals for your app, including icons, screenshots, and other graphics. These can help your app stand out and increase its chances of being accepted.
Make sure you have properly tested your app on different devices and operating systems to ensure compatibility. Apps that do not work correctly on all supported devices are more likely to be rejected.
Consider using analytics tools to track user engagement and other important metrics. This can help you identify any issues with your app and make improvements before submitting it for review.

Notice

It is important to accurately fill out your app's age rating and ensure that your privacy practices comply with all relevant laws. Make sure you understand how the third-party services you use collect and use your users' data.

Please note that this article is incomplete and only covers the areas in which I have personal experience. There are many other rules related to data protection, gambling, and sensitive areas such as health, among others. This article is not a guarantee that your app will be approved. Familiarizing yourself with the store guidelines is crucial to avoid costly mistakes.

hirbod/app-release.md