Moet u uw app updaten voor elke nieuwe iOS of Android?

U kent dat lichte ongemak. De keynote haalt de krantenkoppen, uw telefoon werkt zichzelf 's nachts bij, en de ochtend erna schiet een gedachte door uw hoofd: en mijn app? Werkt die nog? Had ik iets moeten voorbereiden?

Het instinct is niet verkeerd. Er verandert wel degelijk iets: uw app rust op honderden functies die het systeem levert — een kaart tonen, een notificatie versturen, een toestemming vragen — en juist die ondergrond is zonet bewogen. De vraag is dus niet «gebeurt er iets?» — er gebeurt iets. De vraag is: wiens werk is het?

Twee bewegingen, bijna altijd.

Functies stoppen. Niet met een knal: een functie die uw app gebruikte, is simpelweg niet meer beschikbaar, en wat erop steunde reageert niet meer. Niets «crasht» op het scherm; iets gebeurt gewoon niet meer. Het is de sluipendste storing die er bestaat, omdat ze geen zichtbaar spoor achterlaat.

Andere worden verplicht. Het systeem introduceert een nieuwe manier van werken — veiliger, privacyvriendelijker — en maakt die geleidelijk onontkoombaar. Niet van de ene dag op de andere: er wordt een deadline gesteld, soms maanden vooruit, en die komt er altijd.

Het punt dat tegelijk geruststelt en verontrust: de meeste van deze bewegingen worden vooraf aangekondigd. Apple en Google publiceren wat gaat stoppen en wat verplicht gaat worden, ruim voordat het ingaat. Alles is leesbaar — op voorwaarde dat iemand leest. En het ritme pauzeert nooit: twee systemen, elk één grote versie per jaar, aanpassingen tussendoor.

Hier verandert een platform de aard van het probleem.

Die aankondigingen leest iemand — voordat ze ingaan, want dat is zijn vak. Wanneer een functie op de nominatie staat te verdwijnen, wordt de component die haar gebruikt één keer herschreven, in de engine die de apps bouwt. Wanneer een vereiste verplicht wordt, wordt ze op diezelfde plek geïntegreerd, één keer. En elke app op het platform erft die aanpassingen bij zijn volgende build — de uwe net als alle andere.

Wat u niet hebt gedaan, verdient het om opgesomd te worden, want dat is het product: u hebt de release notes niet gelezen. U hebt niet uitgezocht welke van de getroffen functies uw app gebruikte. U hebt de oude manier niet tegen de nieuwe afgewogen. U wist niet eens dat er iets te beslissen viel.

Eén eerlijke kanttekening, omdat ze telt: deze waakzaamheid is geen allriskverzekering. Ze vangt alleen op wat aangekondigd of opgemerkt is — het is doorlopend werk, door mensen gedaan, geen magische garantie. Maar precies daarom is ze waardevol: ze bestaat, ze stopt nooit, en ze is niet uw last.

Het contrapunt is de moeite waard, want het geeft de maat aan. Als u zelf de broncode van uw app moet onderhouden — geschreven door een leverancier, of in een middag gegenereerd uit een prompt —, ziet september er heel anders uit. U moet lezen wat er verandert, tussen honderden aankondigingen vinden wat u aangaat, de code aanpassen, opnieuw bouwen, opnieuw indienen. Daarna hetzelfde voor Android. Daarna volgend jaar weer. Of u nu iets nieuws te publiceren hebt of niet: de afspraak wordt gezet door de besturingssystemen, niet door uw agenda.

Die jaarlijkse afspraak bestaat ook op een platform — hij ligt alleen aan onze kant. Dat is het hele verschil tussen een probleem bezitten en van de oplossing ervan profiteren.

De artikelen in deze serie eindigen gewoonlijk met de lijst van wat niemand in uw plaats kan doen — de volledige kaart staat in het eerste artikel. Voor de evoluties van iOS en Android heeft die lijst één bijzonderheid: ze is leeg.

Geen beslissing te nemen, geen deadline te volgen, geen instelling aan te raken. Van alle krachten die door de jaren heen op een app wegen, is dit de enige waarbij uw aandeel in het werk nul is — en precies daarom bestaat dit artikel: zodat u weet dat u deze ene vraag niet meer hoeft te stellen.

Het enige gebaar dat het uwe blijft, is wat het altijd was: beslissen wanneer u een update publiceert. De aanpassingen liggen klaar en wachten — uw app neemt ze mee bij zijn volgende build, of u nu om die reden publiceert of om een andere.

Het voordeel past in één beeld: de keynote wordt weer een show. U kunt ernaar kijken uit nieuwsgierigheid, blij worden van een nieuwigheid, of hem volledig negeren — geen van de drie keuzes heeft gevolgen voor uw app. De maand waarin het hele mobiele ecosysteem de adem inhoudt, is voor u een maand als alle andere.

Voor wie nieuwsgierig is naar de mechaniek: ik heb vanuit de techniek beschreven wat drie jaar systeemevoluties werkelijk met een app doen — en het weinig spectaculaire werk dat ze opvangt.

En als u nog geen app hebt: bouw hem dan op een plek waar september nooit uw probleem zal zijn — mijn app maken met GoodBarber.

Kan een functie die mijn app gebruikt van de ene dag op de andere stoppen?

Zelden. De meeste verwijderingen worden vooraf aangekondigd door Apple en Google, met een deadline — en dat is wat de waakzaamheid mogelijk maakt: die aankondigingen lezen voordat ze ingaan, en de getroffen component stroomopwaarts vervangen, voor alle apps op het platform. Het scenario «op een ochtend stopt alles zonder waarschuwing» is precies wat dit werk moet voorkomen.

Wat gebeurt er met mijn app op de dag dat een nieuwe iOS of Android uitkomt?

Aan uw kant: niets te doen. Een nieuw systeem verwijdert uw app niet en wist niets. De aanpassingen die het vraagt, worden voorbereid in de engine die de apps bouwt, en de uwe neemt ze mee bij zijn volgende build — of die nu hierdoor wordt ingegeven of door een gewone routine-update.

Kan mijn app meerdere iOS-versies «achterlopen»?

Dat kan, als hij lange tijd niet opnieuw is gebouwd — en het is geen doodlopende weg. De engine bleef ondertussen bij: bij de volgende build komt uw app aangepast aan het huidige systeem naar buiten, hoeveel versies er ook zijn verstreken. Bijbenen kost niet naar rato van de achterstand.

Kan een nieuwe Android-versie iets verplicht maken voor mijn app?

Ja — het is zelfs de meest voorkomende beweging: een nieuwe vereiste, vaak rond veiligheid of privacy, wordt geleidelijk onontkoombaar, met een deadline. Op een platform wordt die vereiste één keer geïntegreerd, stroomopwaarts, voor alle apps; de uwe voldoet eraan bij zijn volgende build, zonder dat u ooit van haar bestaan hoefde te weten.