Releasing a mobile app means two separate processes: Apple's, through App Store Connect with TestFlight for beta testing and App Review for every build, and Google's, through Play Console with internal, closed and open testing tracks before production. Open organisation developer accounts early, because verification takes time. Fill in the privacy disclosures accurately, and release each update gradually so you can stop a bad build. Over-the-air updates can change your JavaScript or web code between releases, but not native code, permissions or the app's purpose.
Developer accounts: organisation or personal
Both stores offer personal and organisation accounts. For a business app, use an organisation account: the store listing shows your company as the seller, access can be shared with staff and agencies through roles, and the app does not depend on one employee's personal login.
- Apple Developer Program: enrolment as an organisation requires a D-U-N-S Number for your legal entity, and the account is renewed yearly. Add developers as team members rather than sharing the Account Holder's Apple ID.
- Google Play Console: organisation accounts also require a D-U-N-S Number and go through identity and organisation verification. Registration is a one-time fee rather than yearly.
Get your D-U-N-S Number first; details that do not match your company registration stall verification. Distributing in the EU also requires declaring your trader status under the Digital Services Act in both consoles.
Review guidelines that catch business apps
Apple reviews every build, including updates. Google reviews new apps and updates too, usually with more automation. The rules that most often affect business and field apps:
- Minimum functionality (Apple guideline 4.2): an app must be more than a repackaged website.
- Sign-in for reviewers: if the app needs an account, give reviewers a working demo account or demo mode. An app that only lets approved employees sign in still needs a reviewer login.
- Account deletion: if users can create an account in the app, both stores require a way to delete it, and Google also asks for a web link to request deletion.
- Payments: unlocking digital features or content inside the app generally requires the store's in-app purchase system (Apple 3.1.1). Physical goods and services, such as a delivery or a field visit, use your normal payment gateway.
- Permissions: every permission you ask for, especially location and camera, needs a clear purpose string, and background location is scrutinised on both platforms.
Platform requirements also change every year. Since 28 April 2026, iOS apps uploaded to App Store Connect must be built with the iOS 26 SDK or later. On Google Play, new apps and app updates must target Android 16 (API level 36) from 31 August 2026, with extensions available to 1 November 2026. Plan an SDK upgrade into each year's maintenance.
Beta testing: TestFlight and Play testing tracks
TestFlight is Apple's beta channel. Up to 100 internal testers, who must have a role on your App Store Connect team, can install builds as soon as they are processed. Up to 10,000 external testers can be invited by email or public link, but a build must pass Beta App Review before external testers get it. Builds remain testable for 90 days.
Google Play has three testing tracks:
| Track | Who | Use it for |
|---|---|---|
| Internal testing | Up to 100 testers you name | Your team, quick checks of every build |
| Closed testing | Testers you invite by email list or Google Group | Pilot users, client acceptance, the new-account requirement below |
| Open testing | Anyone who opts in from the store listing | Public betas |
The testing requirement for new personal Play accounts
If your Play Console account is a personal account created after 13 November 2023, Google requires a closed test with at least 12 testers opted in continuously for at least 14 days before you can apply for production access. The application asks about your closed test, your app and your production readiness, and Google says review usually takes seven days or less. Organisation accounts are not subject to this requirement, which is one more reason to register as an organisation.
Privacy labels and the Data safety form
Both stores publish what your app collects, based on what you declare.
- Apple: the App Privacy section in App Store Connect records the data types collected, whether each is linked to the user, and whether it is used for tracking. Third-party SDKs that Apple lists as commonly used must ship privacy manifests, so keep SDKs current.
- Google: the Data safety form in Play Console covers data collected and shared, why, whether it is encrypted in transit, and whether users can request deletion. You also need a privacy policy URL.
Declarations must cover the SDKs inside your app, not just your own code: analytics, crash reporting, maps and push libraries all collect something. Update the forms when you add an SDK, and keep them consistent with your privacy policy and laws such as India's Digital Personal Data Protection Act or the GDPR.
Staged rollouts and phased releases
Never release an update to everyone at once. Both stores let you widen gradually:
- Apple phased release spreads automatic updates over seven days. You can pause it if something is wrong. Users can still update manually at any time, and new downloads get the new version straight away.
- Google Play staged rollout lets you choose the percentage of users who receive the update and raise it over time. You can halt a rollout so no further users receive that version.
Neither store has a true rollback. If a bad build reaches users, the fix is a new build with a higher version number, which goes through review again. So set up gradual rollout, crash reporting and server-side feature switches before the first release.
- Internal testers on TestFlight and Play internal testing for every build.
- A closed group of real users for significant releases.
- Production at a small percentage, watching crash rates and support tickets.
- Widen over several days, or halt and ship a fix.
Over-the-air updates and their limits
Tools such as Expo's EAS Update for React Native, live-update services for Capacitor and Shorebird for Flutter can push new JavaScript, web or Dart code to installed apps without a store release. They suit urgent fixes. The limits come from the stores' rules:
- Apple: guideline 2.5.2 bars downloading code that introduces or changes features or functionality. The Apple Developer Program License Agreement allows downloaded interpreted code only as long as it does not change the app's primary purpose, does not create a store for other code, and does not bypass the operating system's security. Fixes and small changes are fine; a new feature set should go through review.
- Google: the Device and Network Abuse policy bars downloading executable code such as dex, JAR or .so files from outside Google Play. Code running in an interpreter or virtual machine, such as JavaScript in a web view, is not covered by that restriction but must still comply with Play policies.
- Technical limits: an OTA update cannot change native code, add native libraries or plugins, add permissions or change the app icon. Each OTA bundle must match the native version it runs on, or the app can fail to start.
If you depend on Ionic's Appflow for Capacitor live updates or cloud builds, note that Ionic plans to sunset it on 31 December 2027.
If you distribute Android apps outside Google Play, for example to company devices, Google's Android developer verification applies on certified devices in Brazil, Indonesia, Singapore and Thailand from 30 September 2026, and globally in 2027.
Set up the accounts, tracks, privacy forms and rollout routine once and later releases become routine. If you would like help getting a first release through both stores, our mobile app development team does this regularly, and you can contact us to plan it. For the budget side, read what drives mobile app cost and timeline.
Questions we get asked
What is Google Play's 12 testers requirement?
Developers with a personal Google Play Console account created after 13 November 2023 must run a closed test with at least 12 testers who have stayed opted in for at least 14 consecutive days before applying for production access. Google then reviews the application, which it says usually takes seven days or less. Organisation accounts are not subject to this requirement, so businesses should register as an organisation.
How many testers can use TestFlight?
TestFlight allows up to 100 internal testers, who must be members of your App Store Connect team with a suitable role, and up to 10,000 external testers invited by email or public link. Internal testers get builds as soon as they are processed. External testers get a build only after it passes Beta App Review. Each build can be tested for 90 days after upload.
Can I update a mobile app without going through app review?
Partly. Over-the-air tools can update JavaScript, web or Dart code in installed apps without a store release, which suits bug fixes and small changes. They cannot change native code, add permissions or native libraries, or change the app's primary purpose. Apple's rules bar downloaded code that changes features or functionality, so significant new features should still be submitted for review.
Can I roll back a bad app release?
Not directly on either store. You can pause Apple's seven-day phased release or halt a Google Play staged rollout so no more users receive the version, but users who already updated keep it. The fix is a new build with a higher version number, reviewed again. Releasing gradually, monitoring crashes and keeping server-side feature switches limits the damage.