Je app in de stores houden: de deadlines van 2026

Een app bouwen kost een paar maanden, een app in de stores houden kost elk jaar opnieuw aandacht. Apple en Google stellen jaarlijks nieuwe eisen aan wat je mag inleveren en wat er in de store mag blijven staan. In 2026 zijn er drie momenten die je als opdrachtgever of IT-beheerder moet kennen, met drie verschillende gevolgen als je ze mist.

Waarom een app nooit “af” is

Bij een website bepaal je zelf wanneer je iets vernieuwt. Bij een app zit er een partij tussen jou en je gebruiker: de store. Apple en Google bepalen met welke ontwikkeltools je moet bouwen, welke Android- of iOS-versie je app moet targeten en welke gegevens er over de uitgever bekend moeten zijn. Die eisen verschuiven elk jaar een stapje.

Het lastige is dat de gevolgen van niets doen niet altijd meteen zichtbaar zijn. Je app blijft vaak nog gewoon werken op de telefoons waar hij al staat, terwijl nieuwe gebruikers hem niet meer kunnen installeren. Als dat je marketing of je onboarding van nieuwe medewerkers raakt, merk je het pas als er iemand klaagt.

Drie gevolgen die je uit elkaar moet houden

Houd deze drie uitkomsten scherp uit elkaar, want ze vragen om een ander tempo van handelen:

• Je kunt geen update meer uploaden. De app blijft staan, maar je kunt geen bugfix, prijswijziging of nieuwe functie meer uitbrengen. Dit is het gevolg van de SDK- en target-API-eisen.
• Je app blijft staan, maar wordt onvindbaar voor een deel van de gebruikers. Bestaande gebruikers houden hun app; nieuwe toestellen krijgen hem niet meer aangeboden.
• Je app wordt verwijderd. De zwaarste variant, die Google koppelt aan het registreren en verifiëren van ontwikkelaars.

Google: registreer je apps en verifieer je ontwikkelaarsaccount

Google voert een verplichte ontwikkelaarsverificatie in. In de aankondiging van 18 juni 2026 schrijft Google, in een update van 15 juli 2026, dat Play-ontwikkelaars hun Play-apps moeten registreren in Play Console om aan Android developer verification en de bijgewerkte Play Console-vereisten te voldoen. 99% van de apps op Play is automatisch geregistreerd. Voor de rest geldt: controleer je Play Console Home-pagina en registreer de resterende apps uiterlijk 30 september 2026, om te voorkomen dat ze wereldwijd uit Google Play worden verwijderd.

Over de handhaving meldt TechRepublic dat die op 30 september 2026 begint, met een eerste fase in Brazilië, Indonesië, Singapore en Thailand. Daar installeren apps van geregistreerde ontwikkelaars gewoon door op gecertificeerde Android-toestellen; niet-geregistreerde apps vragen volgens Google om adb of de advanced flow. Volgens Google geldt de eis in die eerste fase voor zeven deelnemende winkels, waaronder Google Play, Galaxy Store, GetApps en HONOR App Market. Dat is het punt dat snel over het hoofd wordt gezien: verificatie gaat verder dan de Play Store alleen.

Wat er precies van jou als uitgever wordt gevraagd en welke landen wanneer volgen, staat op de officiële pagina’s van Google: Understanding Android developer verification en de handleiding Register on Google Play Console. Google beschrijft de uitrol naar alle ontwikkelaars ook in een blogpost van maart 2026. Lees die pagina’s zelf door voordat je iets aanlevert: dit is geen technische klus voor je ontwikkelaar, maar een administratieve actie van de eigenaar van het account, met bedrijfs- en identiteitsgegevens.

Wie moet dit doen?

De persoon of organisatie op wiens naam het ontwikkelaarsaccount staat. Laat je een app bouwen door een bureau? Zoek dan nu uit of de app onder jouw eigen Play Console-account staat of onder dat van het bureau. In het eerste geval moet jij actie ondernemen. In het tweede geval is het een goed moment om vast te leggen wie verantwoordelijk is voor verificatie en verlengingen — en of je het account eigenlijk niet zelf wil bezitten.

Google Play: Android 16 (API level 36) vanaf 31 augustus 2026

De tweede deadline gaat over het target API level: de Android-versie waarop je app zegt te zijn afgestemd. Volgens de Play Console Help geldt sinds 31 augustus 2026 dat nieuwe apps en app-updates Android 16 (API level 36) of hoger moeten targeten om bij Google Play ingediend te kunnen worden. Wear OS- en Android Automotive OS-apps moeten Android 15 (API level 35) of hoger targeten, Android TV- en Android XR-apps Android 14 (API level 34) of hoger.

Voor apps die al in de store staan, geldt een aparte regel. Die moeten Android 15 (API level 35) of hoger targeten om beschikbaar te blijven voor nieuwe gebruikers op toestellen die een hogere Android-versie draaien dan de app target. Apps die Android 14 (API level 34) of lager targeten, zijn alleen nog beschikbaar op toestellen met een Android-versie die gelijk is aan of lager dan het target API level van de app. Google beschrijft de eisen ook in de ontwikkelaarsdocumentatie over Google Play’s target API level requirement.

Red je de datum niet? Volgens een overzicht van Median kunnen ontwikkelaars uitstel aanvragen tot 1 november 2026 om aan de eisen te voldoen. Controleer de aanvraagprocedure en de actuele voorwaarden op de Play Console Help-pagina hierboven voordat je erop rekent.

Apple: sinds 28 april 2026 bouwen met de SDK’s van versie 26

Apple werkt met minimale SDK-eisen: de versie van de ontwikkelkit waarmee je build gemaakt is. In de aankondiging op developer.apple.com staat dat apps en games die vanaf 28 april 2026 naar App Store Connect worden geüpload, moeten zijn gebouwd met de iOS 26 & iPadOS 26 SDK of later. Voor tvOS geldt de tvOS 26 SDK of later, voor visionOS de visionOS 26 SDK of later en voor watchOS de watchOS 26 SDK of later. Apple houdt de actuele lijst bij op de pagina Upcoming requirements.

In de praktijk betekent dit dat je builds met Xcode 26 of later gemaakt moeten worden, zoals ook Expo beschrijft. Voor jou als opdrachtgever is dat vooral een planningspunt: de ontwikkelomgeving, de buildservers en eventuele CI-pipelines moeten mee, en dat kost tijd los van de functionaliteit die je wilde toevoegen.

Belangrijke nuance: bouwen met een nieuwe SDK is niet hetzelfde als je app alleen op nieuwe iPhones laten werken. De SDK bepaalt welke API’s je kunt gebruiken; welke iOS-versies je app ondersteunt, stel je in met het deployment target. Je kunt dus met de iOS 26 SDK bouwen en toch oudere iOS-versies blijven ondersteunen.

Wat dit betekent voor je planning en budget

De praktische conclusie is simpel: reken op minstens één onderhoudsronde per jaar, gekoppeld aan deze storedeadlines. Dat is geen extra service, maar de prijs van in de store staan. Een paar keuzes die daarbij helpen:

• Plan onderhoud vóór de deadline, niet erna. Een update die met haast door de review moet, geeft meer druk en risico dan een geplande ronde.
• Leg vast wie de accounts bezit. Play Console en App Store Connect horen op naam van jouw organisatie te staan, met jouw ontwikkelaar als beheerder.
• Combineer verplicht werk met gewenst werk. Als de app toch open moet voor een nieuwe SDK, is dat het moment voor die kleine verbeteringen van je lijstje.
• Houd de officiële kanalen in de gaten. De Play Console Help-pagina en Apple’s Upcoming requirements zijn leidend; blogs en samenvattingen kunnen verouderd zijn.

Bij app-ontwikkeling neem ik dit onderhoud mee in de afspraken, zodat je niet elk jaar opnieuw hoeft te onderhandelen over werk dat toch moet gebeuren. Staat je app er al en wil je alleen dat iemand de deadlines bijhoudt? Dat kan ook via onderhoud en support. Dezelfde ritmes gelden voor mijn eigen apps Deskside en BamBuddy, te vinden in het portfolio. Zulke verplichte deadlines zijn trouwens niet uniek voor apps: ook op het web loopt zoiets, zoals ik eerder beschreef bij de European Accessibility Act.

Checklist voor deze week

1. Log in op Play Console en open de Home-pagina. Staan al je apps als geregistreerd? Zo niet: registreer ze en volg de stappen voor verificatie.
2. Controleer op wiens naam Play Console en App Store Connect staan, en wie de contactgegevens en betaalprofielen beheert.
3. Vraag je ontwikkelaar welk target API level je Android-app nu heeft: 36, 35, of lager. Bepaal op basis daarvan of je een update kunt uploaden en voor wie je app nog installeerbaar is.
4. Vraag met welke Xcode- en SDK-versie de laatste iOS-build is gemaakt. Is dat nog niet versie 26, dan kun je vandaag geen nieuwe build inleveren.
5. Zet één onderhoudsronde per jaar in je begroting en agenda, ruim voor de zomer.
6. Twijfel je of iets op jouw situatie van toepassing is? Plan een gratis kennismaking van een half uur en neem je storegegevens mee.

De kern: een app die stilstaat, glijdt langzaam uit de store. Eén korte controle per jaar scheelt je een spoedklus op het verkeerde moment.

Veelgestelde vragen

Wordt mijn app direct verwijderd als ik niets doe?

Dat hangt van de eis af. Bij de SDK- en target-API-eisen kun je vooral geen updates meer uploaden en wordt je app voor een deel van de nieuwe gebruikers niet meer installeerbaar. Verwijdering wereldwijd koppelt Google aan apps die niet in Play Console geregistreerd zijn; die moesten uiterlijk 30 september 2026 geregistreerd zijn.

Moet ik ook verifiëren als ik mijn app niet via Google Play verspreid?

Volgens Google start de eis op 30 september 2026 bij zeven deelnemende winkels in Brazilië, Indonesië, Singapore en Thailand, met wereldwijde uitbreiding in 2027; apps die je buiten Play verspreidt, kun je ook in Play Console registreren. Check je eigen situatie op de officiële pagina van Google over Android developer verification.

Werkt mijn app nog op oudere iPhones als er met de iOS 26 SDK gebouwd wordt?

Ja, dat kan. De SDK bepaalt welke API's beschikbaar zijn; welke iOS-versies je app ondersteunt, stel je in met het deployment target. Je ontwikkelaar kan dat per app instellen.

Hoe vaak moet ik onderhoud inplannen?

Reken op minstens één ronde per jaar, gekoppeld aan de storedeadlines van Apple en Google. Doe dat bij voorkeur ruim voor de deadline, zodat een verplichte update niet samenvalt met een drukke periode.