Minimale app requirements voor App Store en Google Play.

App Store (iOS) — minimale requirements

Apple werkt met een gesloten ecosysteem. Wie wil publiceren, moet door een review-proces en een lijst van technische eisen heen die elk jaar strenger wordt. We lopen ze hieronder in volgorde van praktische relevantie langs.

Account en toolchain

• Apple Developer Program — een betaald jaar-abonnement op een Apple ID, op naam van uw organisatie of als individu. Voor bedrijven adviseren we de organisatie-variant: dan kunt u meerdere teamleden onder één account hangen.
• App Store Connect — de portal waar u builds upload, metadata invult en reviews indient. Toegang loopt via uw developer-account.
• Xcode — Apple's IDE. Apple eist sinds een paar jaar dat builds met de meest recente of één-versie-terug worden gemaakt. Een build op een verouderde Xcode wordt geweigerd bij upload.
• iOS SDK — de SDK-versie wordt aan Xcode gekoppeld. Apple kondigt elk najaar aan welke minimum-SDK vanaf april daarna verplicht is voor nieuwe submissions.

Privacy en data

Sinds iOS 14.5 zijn privacy-eisen het grootste struikelblok bij submission. Drie verplichte onderdelen:

• App Privacy details — de zogenaamde "privacy nutrition labels". U moet per type data (locatie, contacten, browse-historie, financieel, gezondheid) aangeven of u die verzamelt, waarvoor, en of het gekoppeld is aan de gebruiker.
• App Tracking Transparency (ATT) — als uw app tracking-data gebruikt voor advertenties of deelt met derden, is een ATT-prompt verplicht. De gebruiker moet expliciet opt-in geven.
• Sign In with Apple — als u social login aanbiedt (Google, Facebook, etc.), moet Sign In with Apple er gelijkwaardig naast staan. Geen "Sign in with Apple" terwijl andere providers er wel zijn = automatische rejection.

Security en networking

• ATS (App Transport Security) — alle netwerkverkeer over HTTPS. Onversleutelde HTTP wordt alleen toegestaan met expliciete exception in Info.plist en goede onderbouwing.
• Code-signing — elke build wordt ondertekend met een Distribution-certificate uit uw developer-account. Provisioning profiles regelen welke apparaten en welke entitlements zijn toegestaan.
• App Sandbox & entitlements — toegang tot camera, microfoon, locatie, contacten, photo library, push, HealthKit etc. moet expliciet als entitlement aangevraagd worden en in de UX uitgelegd worden in de "purpose strings" (NSCameraUsageDescription enzovoort).

Review-richtlijnen

Apple's App Review Guidelines zijn opgedeeld in vijf hoofdsecties: Safety, Performance, Business, Design en Legal. Voor 90% van de afkeuringen geldt dat ze in één van deze categorieën vallen — meestal Performance (crashes tijdens review) of Business (in-app purchase niet via StoreKit). De volledige guidelines staan op Apple's developer-site en worden gemiddeld een paar keer per jaar bijgewerkt.

Distributie en testen

• TestFlight — Apple's beta-distributiekanaal. Tot 100 interne testers (zonder review) en tot 10.000 externe testers (met een lichte beta-review). Verplicht voor serieuze betas.
• App-grootte — Apple gebruikt "app thinning" en asset catalogs om download-grootte per device te beperken. De upload-binary mag groot zijn, maar Apple genereert kleinere device-specifieke varianten.
• Family Sharing — optioneel maar voor consumenten-apps aangeraden: laat één aankoop binnen het gezin delen.

UX en toegankelijkheid

Accessibility is geen kers-op-de-taart meer. Apple keurt apps die VoiceOver volledig negeren steeds vaker af, zeker als ze ook in publieke sector of zorg gebruikt worden. Minimum-niveau: VoiceOver labels op alle interactieve elementen, ondersteuning voor Dynamic Type (gebruiker kan tekstgrootte instellen), en correcte contrast-ratios. Voor diepere achtergrond bij app-keuzes vroeg in het traject is onze app-ontwikkeling dienstpagina een goed startpunt.

Monetisatie

Digitale goederen (abonnementen, in-app content, virtuele valuta) moeten via StoreKit. Apple's commissie daarop is een feit waar u rekening mee moet houden. Fysieke goederen en diensten mogen wel via externe betaalkanalen (Stripe, Mollie, iDEAL), maar de scheiding tussen digitaal en fysiek moet kraakhelder zijn.

Google Play (Android) — minimale requirements

Google Play is technisch toleranter dan de App Store maar heeft inmiddels een vergelijkbaar dichte set policy-eisen. De grootste valkuilen zitten in de privacy-policy en data safety section — daar wordt het meeste afgekeurd.

Account en console

• Google Play Developer Account — eenmalige aanmeldkosten en verificatie van uw identiteit (sinds 2024 verplicht voor alle nieuwe accounts).
• Play Console — Google's portal voor publicatie, releases, statistieken en policy-meldingen.

SDK- en API-eisen

• Target SDK — Google verplicht dat nieuwe apps en updates targeten op een API-level dat maximaal twee versies achterloopt op de meest recente Android-release. Het minimum-target schuift elk najaar op. Onderschat dit niet: zelfs apps die al lang in de store staan moeten meeschuiven.
• minSdkVersion en compileSdkVersion — minSdk bepaalt welke oude Android-versies u nog ondersteunt, compileSdk welke API's u in code kunt aanroepen. Voor consumenten-apps zien we doorgaans minSdk 24 (Android 7) of hoger.
• Android App Bundle (AAB) — sinds augustus 2021 is de AAB verplicht voor nieuwe apps. Losse APK's accepteert Google niet meer. Google genereert per device een geoptimaliseerde APK uit uw AAB.
• Play App Signing — Google host uw upload-key en signing-key. Verlies van de upload-key kan via een reset-flow, maar de signing-key zelf is daarmee veilig.

Privacy en data safety

• Privacy Policy URL — verplicht. Moet bereikbaar zijn op uw eigen domein, in begrijpelijke taal en met heldere data-categorieën. Een placeholder of "coming soon" is een directe rejection.
• Data Safety section — sinds 2022. U declareert per data-type of u het verzamelt, deelt, en of het optioneel is. Mismatch tussen privacy-policy en data-safety-formulier is de allergrootste rejection-bron op Google Play.
• Permissies — elke gevraagde permissie moet ofwel functioneel onderbouwd zijn ofwel verwijderd. Sensitieve permissies (locatie op de achtergrond, SMS, call log, accessibility services) vragen een aparte verklaring binnen Play Console.

Content en doelgroep

• Content rating (IARC) — een vragenlijst die uw app classificeert per regio (PEGI in Europa, ESRB in de VS).
• Target audience & content — als uw app op kinderen richt, gelden COPPA (VS) en GDPR-K (EU) plus Google's "Designed for Families" policy.

Recente Android-features die de checklist raken

• Notification permission (Android 13+) — push-notificaties vereisen een runtime-permissie. De flow moet logisch zitten in de onboarding.
• Foreground service types (Android 14+) — als u op de achtergrond werk doet, moet u expliciet declareren waarom (location, media-playback, dataSync, etc.).
• Photo Picker (Android 13+) — Google moedigt het gebruik van de system Photo Picker aan in plaats van een blanket photo-permission.
• Play Integrity API — anti-fraude check die verifieert dat uw app op een echt, niet-gerooted device draait en dat de binary niet is gemanipuleerd. Voor financiële en zorg-apps inmiddels feitelijk verplicht.

Veelvoorkomende rejection-redenen

De meeste eerste-submissions worden afgekeurd, en bijna altijd op dezelfde dingen. Een overzicht van wat we in praktijk het vaakst zien terugkomen.

iOS — top rejection-redenen

• Zwakke metadata — screenshots die niet matchen met de huidige app-UI, titel/keywords die meer beloven dan de app levert, of marketing-claims zonder onderbouwing.
• Copycat design — UI-patronen die te dicht bij een bekende app liggen (Apple noemt dit "minimum functionality" of "spam").
• Privacy-policy hiaten — privacy nutrition labels die niet kloppen met wat de app daadwerkelijk doet.
• Gebroken functionaliteit tijdens review — Apple's reviewer kan niet inloggen, een feature crasht, of een 3rd-party API geeft een 500. Lever altijd een werkend test-account aan via "App Review Information".
• Ontbrekende ATT-prompt — u verzamelt advertising-data zonder de gebruiker te vragen.
• Private API's — gebruik van niet-gedocumenteerde Apple-API's. Vrijwel altijd automatisch gedetecteerd bij upload.

Android — top rejection-redenen

• Privacy-policy mismatch — wat in de policy staat dekt niet wat de app doet.
• Undisclosed data collection — third-party SDK's (analytics, attribution, ads) die data sturen die niet in de Data Safety form staat.
• Sensitieve permissies zonder gebruik — u vraagt SMS- of accessibility-toegang maar gebruikt het niet zichtbaar.
• Dark patterns — subscription-traps, misleidende UI, geforceerde reviews.
• Misleidende content of impersonatie — naam, icoon of beschrijving lijkt op een andere bekende app of merk.

Voor-submission checklist

Ons advies: doorloop deze lijst minimaal twee sprints voordat u submit. Veel teams onderschatten dat een goede submission een eigen mini-project is.

• Test op meerdere devices — minimaal twee iPhone-generaties en twee Android-fabrikanten (Samsung en Pixel als basis, plus een Xiaomi of OnePlus voor edge-cases).
• Privacy Policy live — op uw eigen domein, met datum van laatste wijziging.
• App store-screenshots — voor elke verplichte device-size. Apple eist screenshots voor de grootste iPhone en iPad. Google heeft een eigen set voor phone, 7" tablet en 10" tablet.
• Omschrijving — korte omschrijving (80 tekens) plus volledige omschrijving (4000 tekens). Optimaal voor uw belangrijkste zoektermen.
• Localization — voor EU-markten minimaal NL en EN, vaak DE en FR. Vertaal niet alleen de UI maar ook de store-listing.
• Crash-rate — onder de 0,5% voor een gezonde release. Firebase Crashlytics of een vergelijkbare tool is feitelijk onmisbaar.
• ANR-rate (Android) — "Application Not Responding" events ook onder de 0,5%. Play Console monitort dit en zal apps die boven de drempel zitten downranken.
• App-icon — in alle vereiste sizes (Apple genereert ze uit één hi-res; Android wil expliciete maskable icons).
• Splash-screen — kort en functioneel. Apple keurt overdreven lange splash-screens af.
• Onboarding-flow — first-launch experience. Zonder permissies pushen op de eerste schermen.
• Support-email — werkend en gemonitord. Een mailbox die niet beantwoord wordt is een rejection-trigger.

Compliance overlays

Naast de store-eisen geldt een laag van wet- en regelgeving die per markt en sector verschilt. De relevante:

• EU Digital Services Act (DSA) — sinds februari 2024 van kracht. Vooral relevant voor apps met user-generated content of marketplace-functionaliteit: meldingsmechanismen, transparantie over moderatie, contactpunt voor autoriteiten.
• EU AI Act — gefaseerd in werking. Apps met AI-features moeten transparant zijn over wat AI doet, welke data het gebruikt en welke risico's eraan kleven. Voor high-risk toepassingen (zorg, HR, krediet) gelden zwaardere eisen.
• GDPR / AVG — verwerkersovereenkomsten met alle SDK-leveranciers, een DPIA bij gevoelige data, gebruikersrechten (inzage, vergetelheid, dataportabiliteit) goed afgehandeld in de app of via web.
• COPPA — bij apps die zich op kinderen onder de 13 richten, verplicht in de VS. Combineert in praktijk met Google's "Designed for Families" en Apple's "Made for Kids".
• NEN 7510 of HIPAA — voor zorg-apps in respectievelijk Nederland en de VS. Verplicht een eigen security-framework en regelmatige audits.

Voor een B2C-launch met internationale ambities is dit lijstje één van de belangrijkste redenen om vroeg een privacy-jurist te betrekken. Apps die richting business klanten gaan hebben weer een eigen set eisen, daar gaat onze B2B app-ontwikkeling pagina dieper op in. Voor consumenten-apps is de B2C-variant de juiste startplek.

Updates en onderhoud na launch

De launch is niet het einde — het is het begin. Onderschat de doorlopende onderhoudslast niet, want zowel Apple als Google forceren mee-updaten.

Target-versie-cyclus

Apple verplicht elk najaar een nieuwe minimum-target. Google idem in augustus/september. Apps die niet meeschuiven worden ofwel onzichtbaar in de store voor nieuwe gebruikers, ofwel volledig verwijderd na een paar jaar inactiviteit. Reken erop dat u uw app minimaal eens per jaar moet updaten alleen voor de target-versie.

OS-support strategie

Hoeveel oude OS-versies u ondersteunt is een productbeslissing met directe gevolgen voor uw kostenbasis. Twee versies terug is industrie-standaard; drie versies wordt zelden gedaan tenzij u een grote installed base hebt. Verder terug: alleen als uw doelgroep harde uitschieters heeft (zorg, overheid).

Security-updates en library-monitoring

Third-party libraries hebben kwetsbaarheden. Een goede release-cyclus betrekt automatische scans (Dependabot, Snyk, Renovate) plus een minimaal-kwartaalse update-sprint waarin u kritische updates verwerkt. Dit hoort in de scope van iedere lopende app-onderhoud-relatie.

Wat een nieuwe app realistisch kost en welke factoren het tarief bepalen leggen we uit in onze gids over maatwerk software kosten. Een overzicht van alle gidsen en kennisbankartikelen vindt u op de gids-overzichtspagina.

Veelgestelde vragen

Kan ik een iOS-app publiceren zonder Mac?

Technisch wel, in de praktijk niet aan te raden. Xcode draait alleen op macOS, en alle ondertekening-, archive- en upload-stappen lopen daar doorheen. Cloud-build-diensten (Codemagic, Bitrise, Xcode Cloud) draaien onder de motorkap Macs in datacenters en zijn voor sommige teams een uitkomst, maar lokaal debuggen blijft een Mac vereisen. Voor serieus app-werk is een Mac onmisbaar.

Hoe lang duurt de Apple-review?

Voor een eerste submission rekenen we op meerdere dagen, voor updates meestal binnen 24 uur. Bij feestdagen, grote OS-releases (september) of als de reviewer een vraag heeft, kan dat uitlopen. Plan launches nooit op een vaste datum zonder buffer.

Privacy-policy zelf schrijven of laten doen?

Voor een eenvoudige app met weinig dataverzameling kunt u prima met een template starten en die op uw app aanpassen — mits u inhoudelijk begrijpt wat er staat. Voor apps met gebruikersaccounts, third-party SDK's of betaalflows is een privacy-jurist (of een gespecialiseerde service zoals Iubenda) de moeite waard. De Data Safety form op Play en de Privacy Nutrition labels op iOS moeten exact matchen met de policy.

TestFlight versus internal testing op Google Play?

Functioneel vergelijkbaar: een afgesloten beta-omgeving voor early testers. TestFlight is gepolijster en heeft een aparte iOS-app voor testers. Google's interne en gesloten testtracks werken via een mailing-link en de gewone Play Store. Voor een eerste launch: gebruik beide voor minstens twee weken intern testen voordat u extern uitbreidt.

App Bundle (AAB) of APK?

Nieuwe apps moeten een AAB uploaden. De APK bestaat nog wel voor distributie buiten Google Play (sideloading, alternatieve stores) en voor interne enterprise-distributie. Voor Play Store-publicatie heeft u geen keuze: AAB is verplicht.

Wat doe ik als Apple of Google mijn app afkeurt?

Lees de rejection-notitie zorgvuldig door en kijk welke guideline of policy genoemd wordt. Negen van de tien rejections zijn met een aanpassing snel op te lossen. Beantwoord de reviewer beleefd en zakelijk via App Store Connect of Play Console. Als u het oneens bent, kunt u in beroep gaan — bij Apple via Resolution Center, bij Google via een appeal-formulier. Verwacht in elk geval een paar correspondentie-rondes.

Wat kosten developer-accounts?

Apple werkt met een jaarlijks abonnement, Google met eenmalige aanmeldkosten. Beide bedragen zijn in verhouding tot het totale budget van een app-traject verwaarloosbaar — geen reden om de keuze tussen platformen daarop te baseren.

Hoe vaak moet ik mijn app updaten?

Minimaal jaarlijks voor de target-versie. In de praktijk doen actieve apps elke twee tot vier weken een release: feature-updates, bug-fixes en security-patches. Voor een ondersteunende productapp zonder veel doorontwikkeling is een kwartaal-update-ritme realistisch.