Minimum app requirements for the App Store and Google Play.

App Store (iOS) — minimum requirements

Apple operates a closed ecosystem. Anyone wishing to publish must go through a review process and a list of technical requirements that grows stricter every year. We walk through them below in order of practical relevance.

Account and toolchain

• Apple Developer Program — a paid annual subscription under an Apple ID, registered in the name of your organisation or as an individual. For businesses we recommend the organisation variant, as it lets you attach multiple team members to a single account.
• App Store Connect — the portal where you upload builds, complete metadata and submit apps for review. Access runs through your developer account.
• Xcode — Apple's IDE. For some years Apple has required builds to be made with the latest or one-version-back Xcode. A build made with an outdated Xcode will be rejected on upload.
• iOS SDK: the SDK version is tied to Xcode. Apple announces each autumn which minimum SDK becomes mandatory for new submissions from the following April.

Privacy and data

Since iOS 14.5, privacy requirements have been the biggest stumbling block at submission. Three mandatory components:

• App Privacy details: the so-called privacy nutrition labels. For each type of data (location, contacts, browsing history, financial, health), you must state whether you collect it, for what purpose, and whether it is linked to the user.
• App Tracking Transparency (ATT) — if your app uses tracking data for advertising or shares it with third parties, an ATT prompt is mandatory. The user must give explicit opt-in consent.
• Sign In with Apple — if you offer social login (Google, Facebook, etc.), Sign In with Apple must be offered alongside it on equal footing. Offering other providers without "Sign in with Apple" results in automatic rejection.

Security and networking

• ATS (App Transport Security) — all network traffic over HTTPS. Unencrypted HTTP is only permitted with an explicit exception in Info.plist and a sound justification.
• Code signing — every build is signed with a Distribution certificate from your developer account. Provisioning profiles determine which devices and which entitlements are permitted.
• App Sandbox & entitlements — access to the camera, microphone, location, contacts, photo library, push, HealthKit and so on must be requested explicitly as an entitlement and explained in the UX through the "purpose strings" (NSCameraUsageDescription etc.).

Review guidelines

Apple's App Review Guidelines are divided into five main sections: Safety, Performance, Business, Design and Legal. For around 90% of rejections, the cause falls into one of these categories — usually Performance (crashes during review) or Business (in-app purchase not handled through StoreKit). The full guidelines are on Apple's developer site and are updated a few times a year on average.

Distribution and testing

• TestFlight — Apple's beta distribution channel. Up to 100 internal testers (no review required) and up to 10,000 external testers (with a light beta review). Mandatory for serious betas.
• App size — Apple uses app thinning and asset catalogues to limit the download size per device. The upload binary can be large, but Apple generates smaller device-specific variants.
• Family Sharing — optional, but recommended for consumer apps: lets one purchase be shared within a family.

UX and accessibility

Accessibility is no longer a nice-to-have. Apple increasingly rejects apps that ignore VoiceOver entirely, particularly if they are used in the public sector or healthcare. Minimum standard: VoiceOver labels on all interactive elements, support for Dynamic Type (users can adjust text size), and correct contrast ratios. For more background on app choices early in the process, our app development service page is a good starting point.

Monetisation

Digital goods (subscriptions, in-app content, virtual currency) must go through StoreKit. Apple's commission on these is a fact you need to factor in. Physical goods and services may use external payment channels (Stripe, Mollie, iDEAL), but the separation between digital and physical must be crystal clear.

Google Play (Android) — minimum requirements

Google Play is technically more lenient than the App Store but now has a similarly dense set of policy requirements. The biggest pitfalls lie in the privacy policy and the data safety section — that is where most rejections occur.

Account and console

• Google Play Developer Account — a one-time registration fee and verification of your identity (mandatory for all new accounts since 2024).
• Play Console — Google's portal for publishing, releases, statistics and policy notifications.

SDK and API requirements

• Target SDK — Google requires new apps and updates to target an API level no more than two versions behind the latest Android release. The minimum target shifts each autumn. Don't underestimate this: even apps that have been on the store for a long time must keep up.
• minSdkVersion and compileSdkVersion — minSdk determines which older Android versions you still support, compileSdk which APIs you can call in code. For consumer apps we typically see minSdk 24 (Android 7) or higher.
• Android App Bundle (AAB) — since August 2021 the AAB is mandatory for new apps. Google no longer accepts standalone APKs. Google generates an optimised APK per device from your AAB.
• Play App Signing — Google hosts your upload key and signing key. Losing the upload key can be recovered through a reset flow, and the signing key itself remains safe.

Privacy and data safety

• Privacy Policy URL — mandatory. It must be reachable on your own domain, written in clear language and with clear data categories. A placeholder or "coming soon" is an immediate rejection.
• Data Safety section — since 2022. You declare, per data type, whether you collect it, share it, and whether it is optional. A mismatch between the privacy policy and the data safety form is the single biggest cause of rejection on Google Play.
• Permissions — every permission requested must either be functionally justified or removed. Sensitive permissions (background location, SMS, call log, accessibility services) require a separate declaration within Play Console.

Content and audience

• Content rating (IARC) — a questionnaire that classifies your app per region (PEGI in Europe, ESRB in the US).
• Target audience and content — if your app is aimed at children, COPPA (US) and GDPR-K (EU) apply, along with Google's "Designed for Families" policy.

Recent Android features that affect the checklist

• Notification permission (Android 13+) — push notifications require a runtime permission. The flow must sit logically within onboarding.
• Foreground service types (Android 14+) — if you perform background work, you must explicitly declare why (location, media playback, dataSync, etc.).
• Photo Picker (Android 13+): Google recommends using the system Photo Picker instead of requesting broad photo permission.
• Play Integrity API: an anti-fraud check that verifies your app runs on a genuine, non-rooted device and that the binary has not been tampered with. For financial and healthcare apps, it is now effectively mandatory.

Common rejection reasons

Most first submissions are rejected, and almost always for the same reasons. Here is an overview of what we see coming up most often in practice.

iOS: top rejection reasons

• Weak metadata: screenshots that don't match the current app UI, titles or keywords that promise more than the app delivers, or marketing claims without substantiation.
• Copycat design: UI patterns that are too close to a well-known app (Apple refers to this as "minimum functionality" or "spam").
• Privacy policy gaps: privacy nutrition labels that don't match what the app actually does.
• Broken functionality during review: Apple's reviewer can't log in, a feature crashes, or a third-party API returns a 500. Always provide a working test account via "App Review Information".
• Missing ATT prompt: you collect advertising data without asking the user.
• Private APIs: use of undocumented Apple APIs. These are almost always detected automatically on upload.

Android: top rejection reasons

• Privacy policy mismatch: what the policy states does not cover what the app does.
• Undisclosed data collection: third-party SDKs (analytics, attribution, ads) that send data not listed in the Data Safety form.
• Sensitive permissions without use: you request SMS or accessibility access but don't visibly use it.
• Dark patterns: subscription traps, misleading UI, forced reviews.
• Misleading content or impersonation: a name, icon or description that resembles another well-known app or brand.

Pre-submission checklist

Our advice: work through this list over at least two sprints before you submit. Many teams underestimate that a good submission is a mini-project in its own right.

• Test on multiple devices: at least two iPhone generations and two Android manufacturers (Samsung and Pixel as a baseline, plus a Xiaomi or OnePlus for edge cases).
• Privacy policy live: on your own domain, with a date of last update.
• App Store screenshots: for every required device size. Apple requires screenshots for the largest iPhone and iPad. Google has its own set for phone, 7" tablet and 10" tablet.
• Description: a short description (80 characters) plus a full description (4,000 characters). Optimise for your most important search terms.
• Localisation: for EU markets, at least Dutch and English, often German and French. Translate not only the UI but also the store listing.
• Crash rate: below 0.5% for a healthy release. Firebase Crashlytics or a comparable tool is effectively indispensable.
• ANR rate (Android): "Application Not Responding" events also below 0.5%. Play Console monitors this and will downrank apps that exceed the threshold.
• App icon: in all required sizes (Apple generates them from a single high-resolution icon; Android expects explicit maskable icons).
• Splash screen: brief and functional. Apple rejects overly long splash screens.
• Onboarding flow: the first-launch experience. Avoid pushing permission requests on the first screens.
• Support email: working and monitored. A mailbox that goes unanswered is a rejection trigger.

Compliance overlays

Alongside store requirements, a layer of legislation and regulation applies that varies by market and sector. The relevant ones:

• EU Digital Services Act (DSA), in force since February 2024. Mainly relevant for apps with user-generated content or marketplace functionality: reporting mechanisms, transparency about moderation, and a point of contact for authorities.
• EU AI Act, being phased in. Apps with AI features must be transparent about what the AI does, which data it uses and what risks it carries. High-risk applications (healthcare, HR, credit) face stricter requirements.
• GDPR / AVG: data processing agreements with all SDK providers, a DPIA where sensitive data is involved, and user rights (access, erasure, data portability) properly handled within the app or via the web.
• COPPA: mandatory in the US for apps aimed at children under 13. In practice it is combined with Google's "Designed for Families" and Apple's "Made for Kids".
• NEN 7510 or HIPAA: for healthcare apps in the Netherlands and the US respectively. Requires a dedicated security framework and regular audits.

For a B2C launch with international ambitions, this list is one of the main reasons to involve a privacy lawyer early on. Apps aimed at business customers have their own set of requirements, which our B2B app development page covers in more depth. For consumer apps, the B2C variant is the right starting point.

Updates and maintenance after launch

Launch is not the end; it is the beginning. Do not underestimate the ongoing maintenance burden, as both Apple and Google force you to keep updating.

Target version cycle

Apple requires a new minimum target every autumn. Google does the same in August or September. Apps that do not keep pace either become invisible to new users in the store or are removed entirely after a few years of inactivity. Expect to update your app at least once a year just for the target version.

OS support strategy

How many older OS versions you support is a product decision with direct consequences for your cost base. Supporting two versions back is the industry standard; three is rarely done unless you have a large installed base. Going further back only makes sense if your audience has hard outliers (healthcare, government).

Security updates and library monitoring

Third-party libraries contain vulnerabilities. A good release cycle includes automated scans (Dependabot, Snyk, Renovate) and at least a quarterly update sprint in which you process critical updates. This belongs in the scope of any ongoing app maintenance relationship.

We explain what a new app realistically costs and which factors determine the rate in our guide to custom software costs. You can find an overview of all guides and knowledge base articles on the guides overview page.

Frequently Asked Questions

Can I publish an iOS app without a Mac?

Technically yes, but in practice it is not advisable. Xcode only runs on macOS, and all signing, archiving and upload steps run through it. Cloud build services (Codemagic, Bitrise, Xcode Cloud) run Macs in data centres under the hood and are a lifesaver for some teams, but local debugging still requires a Mac. For serious app work, a Mac is indispensable.

How long does Apple review take?

For a first submission we allow several days; for updates it is usually within 24 hours. Public holidays, major OS releases (September) or a reviewer query can extend that. Never schedule a launch for a fixed date without a buffer.

Write your own privacy policy or have it done?

For a simple app with little data collection you can start from a template and adapt it to your app, provided you genuinely understand what it says. For apps with user accounts, third-party SDKs or payment flows, a privacy lawyer (or a specialist service such as Iubenda) is worth the investment. The Data Safety form on Google Play and the Privacy Nutrition labels on iOS must match the policy exactly.

TestFlight versus internal testing on Google Play?

Functionally comparable: a closed beta environment for early testers. TestFlight is more polished and has a dedicated iOS app for testers. Google's internal and closed testing tracks work via an email link and the regular Play Store. For an initial launch, use both for at least two weeks of internal testing before expanding externally.

App Bundle (AAB) or APK?

New apps must upload an AAB. The APK still exists for distribution outside Google Play (sideloading, alternative stores) and for internal enterprise distribution. For Play Store publication you have no choice: the AAB is mandatory.

What should I do if Apple or Google rejects my app?

Read the rejection notice carefully and check which guideline or policy is cited. Nine out of ten rejections can be resolved quickly with an adjustment. Reply to the reviewer politely and professionally via App Store Connect or the Play Console. If you disagree, you can appeal: with Apple via the Resolution Center, with Google via an appeal form. In any case, expect a few rounds of correspondence.

How much do developer accounts cost?

Apple works with an annual subscription, Google with a one-off registration fee. Both amounts are negligible in relation to the total budget of an app project, so there is no reason to base your choice of platform on them.

How often should I update my app?

At least once a year for the target version. In practice, active apps release every two to four weeks: feature updates, bug fixes and security patches. For a supporting product app without much further development, a quarterly update rhythm is realistic.