Publishing an app to the App Store and Google Play means opening developer accounts in your company's name, preparing the store listing and privacy disclosures, running the build through a test track and passing each store's review. Without a plan, these steps can delay a launch by weeks; the most common hold-ups include crashing or incomplete builds and missing privacy information.
Key takeaways
- Open the developer accounts under your own company, not your software supplier; whoever holds the account effectively owns the app in the store.
- Apple reviewed more than 7.7 million submissions in 2024 and rejected over 1.9 million; 400,000 submissions were turned down for privacy violations.
- Personal Google Play accounts created after 13 November 2023 must run a closed test with at least 12 testers for 14 consecutive days before going live.
- Get the privacy policy, data disclosures and a reviewer login ready before you worry about screenshots.
- Publishing is not a one-off job; target version rules and policy changes mean the app needs regular maintenance.
Why does getting into the stores take longer than expected?
Plenty of businesses treat "the app is ready" as the launch date. The stores, however, also check content, privacy and the user experience, and every rejection means another round of fixes.
The scale is considerable. According to Apple's May 2025 announcement, App Review looked at more than 7.7 million submissions in 2024 and turned down over 1.9 million for failing its standards on security, reliability and user experience; 400,000 of those were rejected for privacy violations. Apple's App Review page adds that, on average, over 40 percent of unresolved issues relate to guideline 2.1, App Completeness, which covers crashes, placeholder content and incomplete information.
On Android, testing is usually what sets the pace. The Google Play Console help centre states that personal developer accounts created after 13 November 2023 need at least 12 testers opted in to a closed test for 14 consecutive days before they can apply for production access. Leave that out of the plan and the launch slips by a fortnight on its own.
Which accounts and documents do you need before submitting?
The first decision is whose name the accounts are in. Organisation accounts on both the Apple Developer Program and Google Play Console ask for a D-U-N-S number, and if you do not have one the application and verification take longer. If the account belongs to your software supplier, taking the app back when the relationship ends becomes awkward; we explain how to cover this in the contract in software contracts and source code.
Once the accounts exist, give your developers their own logins with limited roles rather than sharing the company password. You will also need:
- A privacy policy: published at a public URL and matching exactly what the app collects.
- Data disclosures: the App Privacy section on Apple and the Data safety form on Google Play.
- A reviewer account: working credentials so the review team can get past any login screen.
- Store assets: app icon, screenshots in the required device sizes, short and full descriptions and a support contact.
If the app processes personal data of people in Turkey, the privacy notice must also meet KVKK transparency duties, and GDPR applies to users in the EU. To keep notice and consent separate, see KVKK explicit consent vs privacy notice.
How do the App Store and Google Play processes differ?
Both stores do the same job, but their rules and timelines differ. The table sets out what a business team needs to plan around.
| Area | App Store (Apple) | Google Play |
|---|---|---|
| Account | Apple Developer Program, annual membership | Google Play Console, one-off registration fee |
| Organisation account | D-U-N-S number required | D-U-N-S number required |
| Test track | TestFlight (internal and external testing) | Internal, closed and open testing tracks |
| Mandatory testing | None | 12 testers for 14 days on new personal accounts |
| Review time | Half of submissions within 24 hours, 90 percent within 48 hours | Varies; can be longer for new accounts |
| Privacy disclosure | App Privacy labels | Data safety form |
| Technical rule | Build with current Xcode and iOS SDK | Target Android 16 (API 36) from 31 August 2026 |
The Android target requirement is set out on Google Play's target API level page, and apps granted an extension have until 1 November 2026. It applies to updates as well as new apps. An app that has not been touched for years may therefore need a technical upgrade before you can ship even a small fix.
Your technology choice matters here too; we compare native code with a shared codebase in native vs cross-platform apps.
What are the steps to publish an app, in order?
Done in the right order, releasing to both stores is a predictable job of a few weeks. We recommend this sequence for a business app.
- Set up the accounts: obtain a D-U-N-S number, open Apple and Google organisation accounts in the company's name and give the development team role-based access.
- Fix the app's identity: decide the app name, bundle ID and application ID, and keep the signing keys in a vault the company controls.
- Prepare the privacy file: list every piece of data the app collects, publish the privacy policy and complete App Privacy and Data safety from that list.
- Open a test track: use TestFlight on iOS and a closed test on Android, and give real users a simple way to report bugs.
- Write the store listing: description, keywords, screenshots and support contact, with screenshots that show the app as it really is.
- Submit for review: include the reviewer account and notes, explaining any features that depend on hardware or internal systems.
- Roll out in stages: after approval, use a staged rollout to a small group first, watch the crash reports and then release to everyone.
A narrow first release also lowers the risk at review. We cover the idea of shipping a version that does the core job and growing it from feedback in what is an MVP.
What are the most common reasons for rejection?
Most rejections are predictable and can be checked before you submit. Apple's figures show the largest share comes from incomplete or unstable apps; business apps add one more classic: the reviewer cannot get in.
| Rejection reason | What it looks like | How to avoid it |
|---|---|---|
| App completeness | Crashes, blank screens, "coming soon" menus | Test the final build end to end on real devices |
| No access | Missing or expired reviewer account | Provide a fixed, dedicated review login |
| Privacy mismatch | Undeclared data collection, permissions without a reason | Give users a clear reason for every permission |
| No account deletion | Users can sign up in the app but cannot delete their account | Offer an in-app route to delete the account |
| Misleading listing | Screenshots do not match the app | Take images from the current build |
For an app used only by your own staff, the reviewer may have no way to reach your internal servers. A demo environment running on sample data removes most of the back-and-forth. Where the app talks to your ERP or other systems, the API layer needs a test environment as well; we explain the basics in API integration explained.
Should an internal-only app go into the public store?
Not every business app belongs in the public store. Apple allows custom apps distributed privately to specific organisations through Apple Business Manager, and Google offers private apps through managed Google Play. These routes have their own account and release steps (custom apps on Apple still go through App Review), but the app does not appear in public search.
The audience decides. If dealers, customers or field teams outside the company will use the app, a public listing is usually the practical choice. For a warehouse or service app installed only on company devices, private distribution combined with device management gives you more control.
What carries on after launch?
Going live is the start of running the app. Annual iOS and Android releases, target version rules and policy changes all mean regular updates. An app that is left alone first misbehaves on new devices and can eventually stop being offered to new users.
Build a maintenance routine into the release plan: who watches crash reports, who answers store warnings and how often updates ship. Our guide to a software maintenance and support agreement shows how to put this in writing. For the yearly running costs, work through the items in mobile app development cost.
How does Digital Bridge help with publishing?
Through our business mobile app development service, Digital Bridge builds native iOS apps in Swift and Android apps in Kotlin. We also handle App Store and Google Play publishing and version updates, and we recommend opening the developer accounts in your company's name so ownership stays with you.
In field sales, service, warehouse and dealer ordering apps, the real work is usually what sits behind the screen. The app keeps working without a connection, syncs when it is back online and writes records straight into your ERP or web system through the API integration layer. You can see how mobile fits alongside web panels and other business software on our software solutions page.
What is the next step towards getting your app live?
Start with three questions: whose name are the developer accounts in, does the privacy disclosure match the app's real data flows, and is the Google Play closed test in the timeline? The answers tell you roughly how many weeks you are from launch. More software guides are collected on the software topic page.
If your app is built but stuck at the store stage, or you are planning a new one from scratch, have a look at our mobile app development page. To agree scope and timings together, get in touch via the contact page or call us on +90 850 346 41 09.