Softwarebureau · Delivery
Release van een mobiele app in de app stores
Krijg de app-update van een klant zonder verrassingen op het laatste moment door de storereview. De klant levert de listinggegevens en de accounttoegang via een openbare link, en er wordt niets ingediend tot de engineering lead de build en de klant de releasenotes heeft goedgekeurd.
- Doorlooptijd: 1 tot 2 weken
- Hoe vaak: Voor elke release in de app stores
- Stappen: 10 stappen
- AI-agents: 1 AI-agent
- Goedkeuringen: 1 goedkeuring
Gratis plan, geen creditcard nodig.
Wat er verandert met dit sjabloon
Zonder sjabloon
De app staat in het ontwikkelaarsaccount van het bureau, en verhuizen is later lastig.
Schermafbeeldingen, privacyantwoorden en teksten komen de dag vóór indiening binnen.
Een afwijzing komt pas boven als de klant vraagt waarom de update nog niet live is.
Releasenotes worden haastig geschreven door wie de build indient.
Met dit sjabloon
Vanaf de eerste release worden de eigen accounts van de klant gebruikt, met uw team uitgenodigd.
De klant deelt de listinggegevens en privacyantwoorden aan het begin via één link.
Een afwijzing blokkeert de uitvoering, met de reden, tot de verbeterde build opnieuw is ingediend.
Een AI-agent stelt ze op, de engineering lead corrigeert ze en de klant keurt ze goed.
Het sjabloon, stap voor stap
Bij elke stap staat wie hem uitvoert: iemand in uw team, een AI-agent of de klant via een openbare link. Een goedkeuring houdt alle volgende stappen vergrendeld tot ze is gegeven.
- Uitgevoerd door uw team
- Uitgevoerd door een AI-agent
- Uitgevoerd door de klant, via een openbare link
Begint wanneer
Een versie van de mobiele app van een klant is klaar voor release. De projectmanager start een uitvoering met de appnaam, de versie en de geplande releasedatum.
- 1
Plan de release en deel de link
Dag 1Projectmanager · Team
Spreek af wat er in de versie komt, vul de releasegegevens in en stuur de klant de openbare link met wat de stores van hem nodig hebben.
Checklist
- Inhoud van de release afgesproken
- Openbare link naar de klant gestuurd
In te vullen velden
- Appnaam (verplicht)
- Versie (verplicht)
- Geplande releasedatum (verplicht)
- 2
Klant levert storegegevens en accounttoegang
Dag 1 tot 3Product owner bij de klant · Openbare link
Via de openbare link bevestigt de klant dat de app onder zijn eigen ontwikkelaarsaccounts staat, nodigt hij het team daar uit en deelt hij wat de storevermeldingen nodig hebben.
Checklist
- Team uitgenodigd in het Apple-ontwikkelaarsaccount
- Team uitgenodigd in de Google Play Console
- Vragen over privacy en gegevensveiligheid beantwoord
In te vullen velden
- Functies om uit te lichten (verplicht)
- Link naar de privacyverklaring (verplicht)
- Supportadres (verplicht)
- Link naar nieuwe schermafbeeldingen
- 3
Bouw de releasekandidaat
Dag 2 tot 5App-developer · Team
Bouw de ondertekende releasekandidaat met de juiste versie- en buildnummers, en zet hem op de testtoestellen.
Checklist
- Versie- en buildnummer ingesteld
- Ondertekend met de certificaten van de klant
- Op de testtoestellen gezet
In te vullen velden
- Buildnummer (verplicht)
- Link naar de testbuild (verplicht)
- 4
Test op echte toestellen
Verborgen voor de openbare linkDag 4 tot 7QA-engineer · Team
Test de releasekandidaat op de ondersteunde toestellen en besturingssysteemversies, inclusief de update vanaf de versie die nu live staat.
Checklist
- Getest op het oudste ondersteunde besturingssysteem
- Update vanaf de liveversie getest
- Storerichtlijnen gecontroleerd
- Geen crash bij het opstarten
In te vullen velden
- Link naar het testrapport (verplicht)
- Bekende problemen
- 5
Stel de releasenotes voor de stores op
Dag 7Storenotesschrijver · AI-agent
De storenotesschrijver stelt de releasenotes voor beide stores op uit de functies die de klant wil uitlichten en de bekende problemen, binnen de lengtelimieten uit zijn instructies.
In te vullen velden
- Conceptreleasenotes (verplicht)
Gecontroleerd door: De engineering lead corrigeert de notes en keurt de build goed in stap 6.
- 6
Keur de build goed voor indiening
Dag 8Engineering lead · Team
Lees het testrapport en de bekende problemen, corrigeer de releasenotes, keur de build goed en mail de definitieve releasenotes naar de klant.
Checklist
- Testrapport gelezen
- Releasenotes gecorrigeerd
- Buildnummer klopt met de geteste build
Goedkeuring: De goedkeuring door de klant en de indiening bij de stores blijven vergrendeld tot de engineering lead de build goedkeurt.
- 7
Klant keurt releasenotes en datum goed
Dag 8 tot 9Product owner bij de klant · Openbare link
De klant leest de releasenotes die de engineering lead heeft gemaild, en legt via de openbare link zijn beslissing vast en de datum waarop de versie live mag.
In te vullen velden
- Beslissing (verplicht)
- Live op (verplicht)
- Wijzigingen in de tekst
- 8
Dien in voor storereview
Dag 9App-developer · Team
Dien de goedgekeurde build en releasenotes in bij beide stores, zet de release op handmatig of gefaseerd en noteer de datum van indiening.
Checklist
- Ingediend bij de App Store
- Ingediend bij Google Play
- Release op handmatig of gefaseerd gezet
In te vullen velden
- Ingediend op (verplicht)
- 9
Verwerk de uitkomst van de review
Dag 9 tot 12App-developer · Team
Noteer het resultaat van elke storereview. Wijst een store de build af, zet de uitvoering dan op geblokkeerd, noteer de reden en dien na de oplossing opnieuw in.
In te vullen velden
- Resultaat review App Store (verplicht)
- Resultaat review Google Play (verplicht)
- Reden van afwijzing
- 10
Breng uit en controleer of de versie live staat
Week 2Projectmanager · Team
Breng de versie uit op de afgesproken datum, controleer of hij uit beide stores te installeren is en laat het de klant weten.
Checklist
- Live in beide stores
- Installeert en opent vanuit de store
- Crashrapporten gecontroleerd na de release
- Klant geïnformeerd
In te vullen velden
- Live sinds (verplicht)
Klaar wanneer
De versie staat live in beide app stores onder de eigen ontwikkelaarsaccounts van de klant, en de release is vastgelegd in de uitvoering.
Pas het aan. Hernoem stappen, wijzig eigenaren en voeg checklistpunten, velden of goedkeuringen toe. Het sjabloon is een startpunt voor de manier waarop uw team werkt.
De AI-agents in dit sjabloon
Een agent werkt alleen aan zijn eigen stappen, en iemand in uw team controleert wat hij heeft gedaan. Alles wat een agent naar een gekoppelde app schrijft, wacht op goedkeuring tenzij u het toestaat.
Storenotesschrijver
Stelt de releasenotes voor beide app stores op uit wat er in deze versie is veranderd.
Wat hij doet
- Leest de functies die de klant wil uitlichten en de bekende problemen
- Schrijft korte releasenotes voor gebruikers
- Blijft binnen de lengtelimieten uit zijn instructies
- Rondt zijn stap af, zodat de engineering lead kan beoordelen
Gecontroleerd door: De engineering lead corrigeert de notes en keurt de build goed in stap 6.
Vragen die dit sjabloon beantwoordt
Publiceer onder de eigen ontwikkelaarsaccounts van de klant met uw team uitgenodigd, en dien alleen een geteste en goedgekeurde build in. In stap 2 nodigt de klant het team uit en beantwoordt hij de privacyvragen via de openbare link, en in stap 8 dient de app-developer de goedgekeurde build in.
Onder dat van de klant, zodat hij de app, de beoordelingen en de gebruikers houdt als u ooit uit elkaar gaat. Stap 2 vraagt de klant zijn eigen accounts te bevestigen en uw team uit te nodigen voordat de eerste build voor release wordt gemaakt.
Test op het oudste besturingssysteem dat u ondersteunt, test de update vanaf de liveversie en controleer de storerichtlijnen die tot afwijzing leiden. Stap 4 bevat die checklist voor de QA-engineer, met een link naar het testrapport.
Noteer de reden, los het op en dien opnieuw in, en informeer de klant in plaats van de releasedatum stilletjes te laten schuiven. In stap 9 zet de app-developer de uitvoering op geblokkeerd met de reden van afwijzing tot de verbeterde build opnieuw is ingediend.
Laat AI de releasenotes voor beide stores opstellen uit wat er in de versie is veranderd, en houd de goedkeuring van de build bij uw team. De storenotesschrijver stelt de tekst op in stap 5, en stap 6 is een goedkeuringscontrole waarin de engineering lead hem corrigeert en de build goedkeurt.
Dien vroeg in, zet de release op handmatig of gefaseerd, en breng hem uit op de datum die de klant heeft afgesproken. In stap 7 legt de klant de releasedatum vast, in stap 8 dient de app-developer in met een handmatige of gefaseerde release, en in stap 10 gaat de versie live.
Voer deze workflow uit in OKiDO
Richt de stappen, eigenaren en goedkeuringen één keer in en start daarna een uitvoering voor elke nieuwe zaak.