Imagine this: It is 9 p.m. on a Thursday. After working significant overtime for the past few weeks, your development team finally created the first version of your application using React Native. The spirits in the office are high, and there is a mix of excitement and anticipation in the air. The marketing team's announcement is scheduled for the start of the week, and the investors are waiting on a demo next week. "We had better submit this to the app store then," the CTO announces.

Getting an app submitted to the app stores is a journey that can challenge even the most resilient teams. It's easy to assume that the process will be straightforward, but it often is not. It is an ecosystem with different rules and requirements for iOS and Android, rejections without clear explanations, and policies that need continual updating. Let's look at some of the gotchas that can occur at this point.

The different App Stores and their different rules

The Gotcha: Making the assumption that there are similarities between the requirements and processes of the Apple App Store and the Google Play Store.

You may think that the two stores share a similar process and requirements, but in reality, it is better to consider Apple and Google as two very different and independent experiences. You may even find that Apple may reject your application for something and require back-and-forth about the why; meanwhile, Google may approve it within hours, ultimately leaving you scratching your head. Although Apple has a reputation for being much stricter than Google, Google has become tougher in recent years. In 2015, Google moved closer to Apple, stating that human reviews would be conducted alongside the automated ones, and since then, both have conducted human and automated reviews. Given this, allowing adequate time for the submission process on both platforms is essential. 

When creating your app listing within the app stores, be mindful that this is not a five-minute endeavour. Both stores require different asset formats, testing setups, account details, and security configurations. 

Apple requires an app icon sized at 1024x1024 pixels in PNG format and screenshots for all supported device types. You must provide a privacy policy URL, copyright and contact details, and a D-U-N-S number is mandatory for organisation accounts. Additionally, tax and banking information must be linked to an enrolled Apple Developer account. From a development standpoint, you need to create certificates and provisioning profiles to sign and distribute your app. All app metadata and assets are managed through App Store Connect. More details on the requirements can be found here.

Conversely, Google requires a 512x512 px app icon, keystores for signing your app, and JSON service keys for Google API integrations. You must set up a payment profile if your app includes purchases and has access to the Google Play Console to manage your app listing. Developers must fill out several disclosures and declarations, including a data safety form, content rating questionnaire, and, if applicable, a COVID-19 declaration for health-related apps. Identity verification and business documentation are also required. Google also enforces SDK and API updates periodically, and developers will need to keep track of this to ensure they do not hold up a release. More information can be found here.

Timelines

The Gotcha: Assuming app stores stick to specific time frames.

Confidently assuming an app will be reviewed within 48 hours is a terrible mistake. Although the process has improved dramatically in recent years, waiting until a deadline is looming is not a good move.

The best approach is to at least double the timeline you are considering and then add some more time to it, taking public holidays into account. It is better to schedule your marketing around when you plan to release the approved app; don't work with the review submission dates. Wiser still, wait until the app is available for your customers to download.

Releasing a release candidate through app stores' non-public channels during development is a best practice which can help prevent delays. Both Apple TestFlight and Google Play’s internal test tracks help you identify any issues specific to the stores, such as build problems or privacy violations. At the same time, you can gather valuable user feedback.

Policies

The Gotcha: Discovering policy requirements too late in the process.

Apple and Google have extensive, ever-changing policy requirements, especially regarding data collection. If your app uses login, location, camera, or analytics, you must clearly declare how data is collected and used. Missing or misdeclaring this will almost certainly lead to rejection. Both platforms frequently introduce new policies without much notice, and noncompliance can delay future updates. Make sure you are clear on the guidelines early on in development and assign one of the team members the responsibility of managing the app store compliance.

Monetisation

The Gotcha: Finding out too late that the app you thought would be profitable is not.

You must use Apple or Google in-app purchases if your app sells digital products such as subscriptions or premium content. This results in Apple taking a commission of 15-30% of your revenue, depending on the size of your business. If you attempt to get users to pay another way, you can be banned from the app store. As a side note, ensure the platform fee is included in your pricing model from the beginning. For Apple, this is an annual fee of $99; for Google, it is a one-off fee of $25.

Restrictions of features

The Gotcha: Building features the app store does not like.

When designing the application, it's safer to assume that what you think is a clever use of device features might end up being restricted. The smartest approach is to remember that you don't have control over this, and placing all your value in certain types of functionality puts you in a vulnerable position.

You do not want to be in the situation where Apple restricts some hardware usage two days before you were going to submit your app to the app store.

The urgent bug fix

The Gotcha: You need to roll out an emergency bug fix, but the app store doesn't see 'urgent' in the same way that you do.

Imagine you have a security-critical bug fix you need to roll out. Your team fixes the code rapidly, and you breathe a sigh of relief. Numerous customer complaints, and 48 hours later, you are still waiting for the app to be reviewed.

This is a horrible situation to be in. Making sure your quality assurance processes are robust helps prevent this. Using phased rollouts also helps. In urgent cases, both Apple and Google allow developers to request expedited reviews, though these are granted at the platforms’ discretion. Make sure you have a crisis plan in place in case you need it.  

Post-launch considerations

Launching your app is just the beginning. Don't forget to consider:

  • Crash reporting
  • Feature flags
  • Support access

These elements are crucial for maintaining your app after launch. I also cannot underestimate how beneficial CI/CD platforms such as Codemagic or Bitrise can be in speeding up and stabilising the deployment process. Although some of these tools can seem expensive, broken deploys can consume hours of time.

The App Store page

The Gotcha: Getting rejected for your marketing materials.

Allow ample time for creating the app store listing and ideally involve marketing. This is the first impression your users will get of your product. Consider the copy and the quality of the screenshots, and remember that it is not just how it looks; this is your sales pitch to your potential customer. Engaging with the reviews left by customers can also boost retention and trust, which can result in better rankings.

Conclusion

There are so many app horror stories; every company or mobile developer has, at some point, been affected by these. The solution is not to leave things until the last minute, do not make assumptions, and remain open-minded that things may not always seem logical. Take some extra patience with you. It is sometimes hard to relay these issues to stakeholders.

If your team is not familiar with the process, do not be naive about the learning curve. Make sure you document the processes and keep them up to date.

Every app has gone through this journey, and yours will too—but maybe save the celebrations until you see the app ready to be downloaded.