Werkt uw app over drie jaar nog?

Op de dag van de lancering gaat alles goed: u hebt uw app zien draaien. Hij staat in de stores, de eerste gebruikers downloaden hem, alles reageert. De vraag die er echt toe doet, komt die dag niet op.

Die komt veel later — op de ochtend dat iemand u schrijft dat er iets niet meer werkt. Daartussen zijn drie jaar verstreken waarin u niets hebt aangeraakt.

Uw app is geen komma veranderd. De wereld eromheen wel. Daar zit de paradox: een app kan ophouden te werken zonder dat er binnenin ook maar één regel is bewogen.

Vier bewegingen, in hoofdzaak. De stores scherpen hun regels aan: privacyverklaringen, minimumversies, herziene rechtenbeleid. Besturingssystemen laten onderweg functies vallen en maken andere geleidelijk verplicht. Sommige dingen hebben een houdbaarheidsdatum: certificaten en sommige servicegegevens verlopen — het SSL-certificaat van een domein, bijvoorbeeld. En de data stapelen zich op, tot wat ooit direct was traag wordt.

Pierre-Laurent heeft de gedetailleerde inventarisatie van wat er stilletjes achteruitgaat geschreven, inclusief het storebeleid en de termijnen. Ik ga dat hier niet overdoen. Wat mij in dit artikel interesseert, is de vraag daarna: als u dat allemaal weet — wie doet het dan?

Zeggen dat een platform «het onderhoud regelt» is zo vaag dat het hol wordt. Het echte mechanisme past in één zin: het probleem wordt één keer opgelost, op platformniveau, en elke app erft die oplossing bij zijn volgende build.

Wanneer een nieuwe privacyvereiste van kracht wordt, zijn het niet duizenden appmakers die ieder voor zich de documentatie van Apple lezen. Het is één team, één keer, dat de engine bijwerkt die de apps bouwt. Wanneer een systeem een functie laat vallen, wordt de component die hem gebruikte één keer herschreven, op diezelfde plek. U hebt niets gelezen, niets gemigreerd, niets beslist.

Het is de moeite waard om het alternatief te benoemen, want daarin ligt het hele argument om op een platform te bouwen in plaats van uw eigen code te onderhouden. Als u de broncode van de app zelf moet onderhouden — geschreven door een ontwikkelaar die u hebt ingehuurd, of in één middag uit een prompt gegenereerd — dan beschrijft diezelfde zin uw middag. U moet zelf opmerken dat de regel is veranderd, begrijpen wat die vraagt, de code aanpassen, opnieuw bouwen, opnieuw indienen. Niemand deed het één keer voor iedereen: het gebeurt één keer voor u, en opnieuw voor de volgende verandering, en die daarna. Een app maken is opvallend goedkoop geworden, en dat is echt goed nieuws. Een app actueel houden is geen millimeter opgeschoven. Pierre-Laurent heeft dat gat uitvoerig beschreven.

Eén punt van eerlijkheid, omdat het telt: die waakzaamheid vangt alleen op wat iemand heeft zien aankomen. De regels lezen voordat ze gelden, een component herschrijven voordat het wegvallen ervan een storing wordt — dat is een vak dat continu wordt uitgeoefend, geen automatische garantie.

Alles hierboven geldt voor een levende app, een app die af en toe opnieuw wordt gepubliceerd. Maar de echte zorg ligt elders, en niemand verwoordt hem: ik heb mijn app twee jaar laten liggen. Is hij verloren?

Nee. En de reden zit in de manier waarop het werk zich opstapelt: de oplossingen wachten op uw app, ze rennen er niet achteraan. Een app die niemand aanraakt, herstelt zichzelf 's nachts niet — terwijl hij slaapt, komt er niets bij hem binnen. Maar in die twee jaar is elke regelwijziging en elke door iOS of Android losgelaten functie één keer afgehandeld, stroomopwaarts, voor alle apps op het platform. Dat werk is niet verdampt omdat die van u stil was. Het ligt er, opgestapeld, en het wacht.

Het gevolg is heel concreet: als u terugkomt, haalt u geen twee jaar met de hand in. U bouwt opnieuw, en uw app komt eruit op de norm van de wereld van vandaag, niet die van de wereld waarin hij is ontstaan. Bijkomen is geen project, het is een build. U hoeft niet te weten wat erin zat.

Dat is precies wat niet gebeurt wanneer u de broncode zelf onderhoudt. Er heeft zich niets voor u opgestapeld terwijl hij sliep. Twee jaar aan veranderingen blijven twee jaar aan veranderingen, wachtend tot iemand — u, of iemand die u betaalt — ze stuk voor stuk doorneemt voordat de app weer naar buiten kan.

Dit is het echte antwoord op de vraag in de titel, en het past in twee kolommen.

Aan onze kant: de engine die de apps bouwt, permanent actueel gehouden. Het lezen van de storeregels voordat ze gelden. Het herschrijven van componenten voordat het wegvallen ervan een storing wordt. De keten die uw notificaties bezorgt. Het SSL-certificaat van uw domein, vóór elke deadline vernieuwd. Niets daarvan vraagt u om een beslissing, of zelfs maar om ervan te weten.

Aan uw kant, en niemand kan het in uw plaats doen:

• Uw Apple- en Google-ontwikkelaarsaccounts. Ze staan op uw naam — dat is wat de app van u maakt — en ze moeten worden verlengd. Een verlopen account haalt de app uit de stores, hoe goed de inhoud ook is.
• De verklaringen die uw content en uw omgang met data beschrijven. Ze gaan over uw activiteit, niet over de onze: wij kunnen ze voorbereiden op basis van de functies die u daadwerkelijk hebt aangezet, maar niet in uw plaats bepalen wat u met de gegevens van uw gebruikers doet.
• De handeling van het versturen van de update. Elke nieuwe versie gaat door de beoordeling van de stores: het platform maakt alles klaar, u geeft het startsein. Als juist dat u zwaar valt, is GoodBarber Takes Care de optie waarbij wij de updates in uw plaats bij de stores indienen.

Het lijstje is kort. Dat is met opzet — en elk van die regels verdient een eigen artikel. Dat is wat deze serie gaat doen.

Het echte voordeel is niet technisch, het is tijd. De uren die u niet besteedt aan het lezen van Apples release notes, aan uitzoeken wat een privacyverklaring is of aan achterhalen waarom een certificaat is verlopen, besteedt u aan uw content, uw publiek, uw activiteit.

Het is een voordeel dat zich moeilijk laat aanprijzen, omdat het niet zichtbaar is: als het werkt, gebeurt er niets. Geen enkele demo kan het bewijzen; alleen de tijd bevestigt het. Dat is wat het platform sinds 2011 onopvallend doet.

Als het technische detail u interesseert: ik heb elders, vanuit de techniek, beschreven wat er in drie jaar werkelijk stukgaat.

De eenvoudigste manier om te zien hoe een app eruitziet die op deze mechaniek is gebouwd, is uw eigen app beginnen: mijn app maken met GoodBarber.

Werkt mijn app over drie jaar nog?

Een app die strikt onaangeroerd blijft, raakt uiteindelijk achter op zijn omgeving, en dat geldt overal. Het verschil zit in wat bijkomen kost: op een platform dat de veranderingen opvangt, zijn de oplossingen al gemaakt en wachten ze op uw app. Hem weer bij de tijd brengen is een herbouw, geen project.

Ik heb mijn app twee jaar laten liggen. Is hij verloren?

Nee. Terwijl een app slaapt komt er niets bij hem binnen, maar al het werk dat ondertussen op platformniveau is gedaan, wacht op hem: bij de volgende herbouw komt hij eruit op de huidige norm. Dat is precies het verschil met een app waarvan u de broncode zelf moet onderhouden, waar zich niets voor u heeft opgestapeld.

Wie is waarvoor verantwoordelijk, het platform of ik?

Het platform neemt op zich wat alle apps gemeen hebben: de engine die ze bouwt, het voldoen aan de storeregels, het vervangen van losgelaten componenten en de notificatie-infrastructuur. U houdt uw Apple- en Google-ontwikkelaarsaccounts, de verklaringen die uw content beschrijven en de beslissing om updates te publiceren.

Zijn technische vaardigheden nodig om een app jarenlang draaiende te houden?

Nee, en dat is nu juist het punt: het deel dat ze vraagt, wordt één keer stroomopwaarts gedaan, voor alle apps. Wat aan uw kant blijft is administratief en redactioneel — accounts verlengen, uw content beschrijven, kiezen wanneer u publiceert — geen code.

Waarom is mijn app trager dan bij de lancering?

Meestal is er niets stuk: het volume is veranderd. Wat bij een kleine catalogus direct ging, kost meer werk als die jarenlang is gegroeid. Het is de enige van de vier bewegingen die uit uw eigen succes voortkomt en niet van buiten — en het onderwerp van een volgend artikel in deze serie.