The app is finished, the screenshots are ready, the build goes to the App Store, and two days later a rejection arrives: the reviewer could not get past the login screen because nobody supplied a demo account. Google Play is different but just as frustrating. A newly created personal developer account only gets access to production after a closed test with at least twelve people. In both stores, code is only part of the job.
This article walks through the process at the level a client needs, from technology choice and design guidelines to back end, privacy, store release, purchase rules and maintenance. If you are not yet sure you need an app at all, read our piece on mobile apps versus mobile-friendly websites first.
The whole process: stages and deliverables
The table shows the stages of a typical business app heading for both stores. Durations vary too much to list; what matters is that every stage ends with something concrete in your hands.
| Stage | What happens | Deliverable |
|---|---|---|
| Discovery | Target users, core flows, device features, integrations and revenue model are pinned down | Scope document, prioritised backlog, technology recommendation |
| Design | Flows, wireframes and an interface that follows both platforms' guidelines | Clickable prototype, design system, accessibility notes |
| Architecture and back end | API, data model, authentication and notification infrastructure are set up | API documentation, test and production environments |
| Development | The app is built in sprints, with a test build after each one | TestFlight and Google Play internal test builds |
| Testing and beta | Testing on real devices, closed beta, bug fixing | Test report, beta feedback, store-ready build |
| Store preparation | Store copy, screenshots, privacy disclosures, age rating | App Store Connect and Play Console listings |
| Release | Review, phased rollout, close monitoring of the first days | Live version in the stores, monitoring dashboards |
| Maintenance | Bug fixes, OS compatibility, new releases | Release notes, regular maintenance report |
Native or cross-platform?
With native development, the iOS app is written in Swift (usually with SwiftUI) and the Android app in Kotlin (with Jetpack Compose), separately. You get every new platform feature on day one, and the interface behaves exactly like the platform. The price is two codebases and often two sets of specialists.
Cross-platform development produces both apps from one codebase. The two most common options:
- Flutter: built by Google, written in Dart, drawing its interface with its own rendering engine. The app can look identical on both platforms; making it feel native on each takes extra effort.
- React Native, started by Meta, written in JavaScript or TypeScript and using the platform's own interface components. The "New Architecture" has been the default since version 0.76, and the React Native docs recommend starting new projects with a framework such as Expo. For a team that already uses React on the web, the learning curve is short.
A third route is gaining ground: Kotlin Multiplatform, where business logic is shared and the interface can stay native on each platform. JetBrains declared iOS support in Compose Multiplatform stable in May 2025.
For most business apps (ordering, booking, loyalty, field service, content) cross-platform is a sensible and economical choice. Native comes into its own when an app works close to the hardware: heavy camera and image processing, constant communication with Bluetooth devices, high-performance graphics. One caveat: even with cross-platform, features such as home-screen widgets, Apple Watch or Live Activities need some Swift and Kotlin. Ask whose job that is in the proposal.
Design: platform guidelines and the store's eye
Apple's Human Interface Guidelines (HIG) and Google's Material Design 3 describe the behaviour each platform's users expect. This is muscle memory, not taste. On Android, the system back gesture has to work consistently on every screen; iOS users expect to swipe from the left edge to go back. Tab bars, alerts and share sheets also differ between the two.
Both design languages were refreshed recently. Apple changed the look of iOS 26 with the Liquid Glass design language introduced in 2025, and Google extended Material 3 with its "Expressive" update. Respecting those languages while keeping your brand colours and typeface is what stops an app looking like a repackaged website.
That phrase is deliberate: guideline 4.2 of Apple's App Review Guidelines turns down apps that do not go beyond a repackaged website.
Accessibility is part of design too. Apple recommends touch targets of at least 44 by 44 points, Material at least 48 by 48 dp. Screens must not fall apart when users enlarge text (Dynamic Type on iOS), VoiceOver and TalkBack must be able to announce what every button does, and dark mode should be designed in from the start. If you sell to consumers in the EU, the European Accessibility Act has applied to e-commerce services, apps included, since June 2025.
Back end, APIs and notifications
Behind the app your users see runs a back end for authentication, data, payments, notifications and an admin panel. That can be your own API or a service such as Firebase or Supabase. Ready-made services speed up the start, but they tie your data model and cost structure to their rules.
Mobile has one reality the web does not: old versions live in the field for months, because some users switch automatic updates off. Design the API with versioning, keep supporting older app versions for a while, and build in a forced-update mechanism that can say "this version is no longer supported, please update" from the very first release.
Sign-in has a store rule of its own. Apple's guideline 4.8 says that apps offering a third-party login such as Google or Facebook for the primary account must also offer an equivalent option that limits data collection to name and email address and lets users keep their email private. Sign in with Apple meets that requirement. If you only use your own account system, the rule does not apply.
Notifications
On iOS, push notifications travel through the Apple Push Notification service (APNs); on Android, usually through Firebase Cloud Messaging (FCM), which can also deliver to iOS via APNs. Both platforms require the user's permission. Since Android 13 (API level 33), notifications depend on a runtime permission called POST_NOTIFICATIONS, and for newly installed apps they stay off until the user grants it.
So ask at the moment the benefit is obvious, not on first launch. "Shall we tell you when your order has been dispatched?" earns far more yeses than a system dialog that pops up as the app opens. Plan frequency, topics and which screen each notification opens (deep links) from the start. Huawei devices sold without Google services need AppGallery and Huawei's own push service, which is a separate work item.
Privacy: labels, the Data safety form and account deletion
Both stores ask you to show users what data the app collects. At Apple, this is the App Privacy section in App Store Connect, which appears on the product page as privacy labels. Google Play's counterpart is the Data safety form in Play Console. In both, you declare not only what your own code collects but also what your analytics, advertising, crash reporting and payment SDKs collect.
Apple also requires a privacy manifest from apps that use certain system APIs and from commonly used third-party SDKs, with each SDK carrying its own manifest. If you track users across other companies' apps and websites, you need App Tracking Transparency permission as well.
Account deletion is a shared requirement. If users can create an account in the app, Apple wants them to be able to delete it from within the app. Google Play additionally asks, in the Data safety form, for a web link where users can request deletion of their account and data without reinstalling the app.
Finally, age ratings. Apple overhauled its age categories in 2025: 12+ and 17+ were dropped and 13+, 16+ and 18+ were added, and the new age rating questions in App Store Connect have to be answered. Google Play uses the IARC questionnaire. Both stores have separate, strict rules for apps aimed at children, and in the UK the ICO's Children's code applies to services likely to be used by children.
Store release: App Store and Google Play
Developer accounts
Open the accounts in your company's name, not the agency's. Enrolling in the Apple Developer Program as an organisation requires a legal entity, a website on a domain that matches your organisation, and a D-U-N-S number; Google Play also asks new organisation accounts for a D-U-N-S number. Obtaining the number or updating registration details can take time, so do it when development starts, not in launch week.
App Store
Test builds go out through TestFlight: up to 100 internal testers and 10,000 external testers, with each build available for 90 days. The first build sent to external testers goes through a short review.
Apple says it reviews at least half of all submissions in under 24 hours and 90 per cent in under 48 hours; incomplete submissions take longer or are rejected. According to Apple, more than 40 per cent of unresolved issues relate to guideline 2.1, app completeness: crashing screens, placeholder content, broken links, login screens without a demo account. Putting a working demo account and the necessary notes in the App Review Information section is the cheapest precaution there is.
After approval, you can release updates in phases. Apple's phased release runs over seven days, reaching 1, 2, 5, 10, 20, 50 and finally 100 per cent of users with automatic updates enabled, and can be paused for up to 30 days in total. And since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 and the iOS 26 SDK. Apple raises this bar every year.
Google Play
Play Console has four tracks: internal testing, closed testing, open testing and production. Personal developer accounts created after 13 November 2023 face an extra step: before production, they must run a closed test with at least 12 testers who have stayed opted in for at least 14 consecutive days, and then apply for production access from the dashboard. Google says this review usually takes seven days or less. Organisation accounts are exempt but go through the D-U-N-S process instead, so plan around your account type.
Google's target API level requirement also rises each year. From 31 August 2026, new apps and updates must target Android 16 (API level 36). You can roll out updates in stages and halt a rollout if you spot a problem; staged rollouts work only for updates, not the first release. Play Console's pre-launch report also runs your app on real devices before release, and it is often your first crash list.
In-app purchases and store rules
If your revenue model is selling something digital inside the app, store rules become part of your business model. Under Apple's guideline 3.1.1, opening up features or content within the app (subscriptions, premium content, in-game currency) requires in-app purchase. Physical goods and services consumed outside the app work the other way round: a parcel delivery or a hairdresser's appointment is paid by card or Apple Pay, not through in-app purchase. Google Play's payments policy likewise centres on Google Play Billing for digital goods.
The rules differ by region. On the US storefront, following a 2025 court ruling, Apple allows apps to show buttons and links to external purchase options. In the European Union, the Digital Markets Act opened up alternative app marketplaces, web distribution and alternative payment or link-out options, and Google runs alternative billing and external offers programmes for the European Economic Area. Each option comes with its own contract and commission terms, and they have changed several times in the past two years. If you sell into Europe, read both stores' current EU terms before deciding and review them with your legal adviser.
Three technical points are easy to miss. Add a "restore purchases" button for restorable purchases; Apple's guidelines spell this out. Validate purchases on your server rather than on the device, using the App Store Server API and the Google Play Developer API. And track the subscription lifecycle (renewal, cancellation, refund, billing problems) through the stores' server notifications; tools such as RevenueCat can take on part of this work.
Release management, crash reporting, analytics and maintenance
Release management
Every release carries two numbers: the version users see (2.4.0, say) and the build number the store expects to increase with every upload. A steady rhythm, such as a release every two weeks, is safer than rare, large releases. Hiding unfinished features behind feature flags decouples the release schedule from feature work.
Teams using React Native and Expo can ship fixes to the JavaScript layer over the air (OTA) without waiting for store review. It is a useful tool with a clear limit: Apple's guideline 2.5.2 does not allow apps to download and run code that changes their features or functionality. Bug fixes, yes; new screens and features go through a store release.
Crash reporting and analytics
Set up a crash reporting tool such as Firebase Crashlytics or Sentry before launch, not after. Google Play's Android vitals dashboard also acts as a referee. If the user-perceived crash rate exceeds 1.09 per cent overall, the ANR rate (app not responding) exceeds 0.47 per cent, or either rate goes above 8 per cent on any single phone model, Google may reduce the app's visibility in the store. On iOS, the Xcode Organizer provides crash and energy reports.
The most common analytics mistake is starting with "let's measure everything". Write a short measurement plan first. Do users finish registration? How many steps to the first order? Where do they give up? Remember that analytics SDKs may need consent from users in the UK and EU.
Maintenance and OS updates
Apple announces each new iOS version at WWDC in June, and it usually ships in September. Google also releases a new Android version every year and raises its target API requirement. So a live app needs at least one compatibility update a year even if you add nothing new: building with the new SDK, changed permission models, removed APIs, new screen sizes.
Put this in the maintenance agreement explicitly. Who tests against the betas over the summer? How often are libraries updated? Who keeps track when store policies change? Apps left untouched for years break on new devices first, then lose visibility in the stores.
Where to start
- Write down on one page which job the app does for its users, and how often.
- Open Apple and Google developer accounts in your company's name and start the D-U-N-S process now.
- Choose the technology with an eye on who will maintain the code in five years.
- Have the design follow both platforms' guidelines and test the clickable prototype with real users.
- Version the API and put the forced-update mechanism into the first release.
- Build an SDK inventory and prepare privacy labels, the Data safety form and your privacy notice from it.
- If you publish through a personal Google Play account, schedule the 14-day closed test.
- Set up crash reporting and the measurement plan before launch.
- Agree a maintenance contract that covers yearly OS compatibility before you go live.
At AYTE Digital we take mobile apps from discovery through store release to ongoing maintenance, and we open accounts and source code repositories in the client's name. If you are at the start, we can walk through your idea stage by stage and work out which technology and release timeline suit you.
