TestFlight om iOS app versies te distribueren

Het ontwikkelen van een app stopt niet wanneer app versie 1.0 live is gegaan. Een goede app heeft namelijk op reguliere basis app updates nodig. Dit kunnen nieuwe functies zijn of bugs die moeten worden aangepakt. Het blijft belangrijk om de app verder te ontwikkelen en nieuwe app updates te testen, voordat deze beschikbaar worden in de app stores. Dit kan voor een uitdaging zorgen, omdat deze app updates moeten worden gedistribueerd naar testers zonder dat bestaande gebruikers hier last van hebben.

TestFlight kan hierbij helpen om nieuwe app versies extern en zelfs intern te distribueren. Deze aanpak kan in het begin voor problemen zorgen aangezien het noodzakelijk is om een aantal review processen te doorgaan. Door handigheid te krijgen met TestFlight zal dit zorgen dat je eenvoudig nieuwe app versies kunt verspreiden. In dit artikel zullen we kijken hoe je TestFlight in jouw voordeel kunt gebruiken.

Drie verschillende manieren om iOS apps te installeren

Als voorstanders van een app: bug vrij te versturen, data integriteit en on-device testing ontwikkelen wij drie verschillende manieren om een iOS app te installeren. Op deze manier kun je app versies blijven testen zonder App Store gebruikers te hinderen. Er is opzettelijk geen interactie tussen deze drie verschillende versies. Ondanks dat dit zorgt voor meer werk in het begin heeft het de volgende voordelen. Je kunt nieuwe updates verspreiden naar app beta testers, je hebt een app die beschikbaar is in de App Store en je kunt door blijven ontwikkelen aan een andere app versie. Dit kan allemaal tegelijkertijd.

De drie verschillende soorten app versies die ten alle tijden beschikbaar zijn, zijn de volgende:

• App Store: Deze versie is beschikbaar voor de eindgebruikers van de app die in de App Store zelf te vinden is.
• Beta: Een versie van de app beschikbaar voor beta testers die nieuwe functies of opgeloste bugs bevat. Deze versie is niet beschikbaar voor de eindgebruiker.
• Interim: Dit is ook een versie die niet beschikbaar is voor de eindgebruikers. Deze versie wordt door het team gebruikt om nieuwe functies of bugs op te lossen, voordat app beta testers deze versie kunnen gaan testen.

Drie soorten apps nader toegelicht

Beta versies zullen als eerste worden geïnstalleerd met TestFlight en zullen vervolgens worden geplaatst in de App Store om de huidige live app versie te vervangen. Interim versies worden voornamelijk gebruikt door: QA, ontwikkelaars en andere teamleden om toegang te krijgen tot de nieuwe app versie en het werk te analyseren. Aangezien deze versies worden gebruikt voor het nieuwe werk zijn we vaak afhankelijk van Beta door Crashlytics om deze app versie te distribueren. Houd hierbij rekening dat voordat we de v1.0 app versie lanceren in de App Store we als eerste beginnen met de interim versie. Vervolgens verder gaan met de beta versie en als laatste wordt de nieuwe app versie gelanceerd in de App Store.

Als de app een backend heeft dan zal elke app installatie gericht zijn op een van de verschillende database omgevingen: ontwikkeling, staging en productie. De ontwikkeling database wordt voornamelijk gebruikt voor interim versies en staging voor beta versies van de app. Productie is alleen voor de live app zelf. Deze opzet is belangrijk voor data integriteit en om live App Store gebruikers niet lastig te hoeven vallen. Bijvoorbeeld, een app beta versie kan nieuwe functies bevatten die het data model van de app veranderen waardoor de app voor live gebruikers kan crashen.

Hoe TestFlight distributie voor iOS App’s makkelijker maakt

Voor oktober 2015 werd er veel gebruik gemaak van HockeyKit om non-App Store versies te distribueren. Hockeykit en vergelijkbare tools vereisen dat handmatig een collectie en input van elke gebruiker’s  UDID wordt verzameld om testers de app te laten installeren. Aangezien veel testers niet weten waar zij hun UDID’s kunnen vinden kostte het veel tijd om uit te leggen waar testers deze informatie konden vinden. Als vervolgens deze informatie verzameld was moesten de UDID’s handmatig worden ingevoerd in Apple’s Developer Portal.

Wanneer een nieuwe versie op de server was geplaatst moesten klanten gemaild worden dat de app klaar was. Vervolgens moest er aangegeven worden wat er precies getest moest worden. Klanten zouden vervolgens zelf een notificatie sturen naar hun testers.

TestFlight heeft een aantal uitdagingen van HockeyKit en vergelijkbare tools versimpeld. De grootste uitdaging hiervan is de UDID’s. Om nieuwe testers uit te nodigen hoef je alleen nog maar hun e-mailadres in te voeren. TestFlight stuurt vervolgens een notificatie naar de gebruiker om aan jouw app mee te kunnen werken. Daarnaast worden testers op de hoogte gehouden wanneer een nieuwe versie klaar is en wat er getest moet worden. Dit gebeurt allemaal in de TestFligt app zelf. In de “What to Test” sectie van de tool kunnen we alle informatie kwijt. Hier kunnen we vertellen hoe feedback kan worden gestuurd, welke items nieuw zijn, geüpdatet zijn of waaraan wordt gewerkt voor de volgende app versie.

Interne testers

Ons grootste probleem met TestFlight is het review proces en hoe deze voor vertraging kan zorgen bij het testen. Gelukkig hebben we dit kunnen overkomen door de volgende twee manieren. De eerste manier is met TestFlight’s interne testers. Deze gebruikers zijn onderdeel van het iTunes Connect team. Wanneer een app versie klaar is voor intern testen gaat deze direct naar de testers. Op het moment dat deze testers klaar zijn, hoeft de app versie niet meer goedgekeurd te worden door Apple.

Wanneer je klaar bent om jouw app te testen bij een groter publiek, zoals de beta versie, dan moet je gebruik maken van “External Testing” in TestFlight. External testing moet echter wel worden bekeken door Apple voor goedkeuring. Houd er rekening mee dat dit niet hetzelfde review proces is dat Apple heeft voor de App Store. Het duurt vaak 2 tot 3 werkdagen voordat de app is goedgekeurd en je de app versie kan doorsturen naar jouw externe testers. Het komt voor dat het in minder dan 12 uur getest is.

Hoelang duurt een review?

Met de tijd die nodig is om nieuwe versies te testen is de tweede manier om de tijd die voor review nodig is te begrijpen. Het distribueren van beta app versies heeft vaak twee tot drie dagen review nodig, voordat deze kan worden vrijgegeven. Bij externe beta builds hoeft de app niet nogmaals bekeken te worden door Apple als er geen grote veranderingen zijn doorgevoerd. Met deze kennis in gedachten melden we een app versie aan voor review die de belangrijkste functies van een app bevat. Vervolgens geven we met een nieuwe versie aan dat er geen grote veranderingen zijn doorgevoerd sinds de vorige aanmelding. Hierdoor kan de nieuwe beta versie gelijk worden verspreid naar de externe testers.

Continuous integration met iOS versie distributie

Onze continuous integration (CI) setup helpt ons met de strategie voor het distribueren van verschillende app versies. Het helpt het proces voor verschillende versies van een app installatie vrijwel automatisch te laten verlopen. Met onze aanpak kan elk teamlid makkelijk de app installeren zonder gebruik te hoeven maken van de Xcode. Onze ontwerpers kunnen de laatste app versie gebruiken waar we mee bezig zijn en een ontwerp of UX audit uitvoeren.

Wanneer code gepusht wordt tegen specifieke branches dan zorgt onze CI voor de creatie van een van de drie verschillende app installaties. Dit kan zijn interim (Ad Hoc), beta of de App Store versie. Er kan gebruik gemaakt worden van Fastlane en Beta door Crashlytics bij dit proces. Na elke commitment wordt een versie gecreëerd en is vervolgens beschikbaar om te downloaden. Er is zelfs een Slack integratie notificatie voor als een app versie mislukt.

Naarmate we de verschillende interim versies bekijken en tickets worden geaccepteerd updaten we de app versie in Xcode. Deze zal relevant werk doorsturen naar een specifieke branch, zoals beta. In dit geval creëert de CI de beta versie voor ons. Wij pakken de versie die wordt gehost op GitHub release en zetten het op TestFlight om extern getest te kunnen worden. Dit proces blijft doorgaan totdat de app klaar is voor de App Store. Al het werk wordt dan samengevoegd in de master branch.

Conclusie

Het proces om verschillende app installaties van dezelfde app te maken en gebruik te maken van Testflight is erg handig voor het distribueren van de app versies. Voornamelijk helpt dit het product, QA, beta app testen en het ontwerp. Testers hoeven niet geïnformeerd te worden omtrent hun UDID’s. Er hoeven minder technische mensen getraind te worden hoe ze code kunnen verkrijgen. Daarnaast wordt er minder tijd verspild om op verschillende app versies te wachten en dat maakt het veel ontwikkelen van een app veel makkelijker. Daarnaast is het mogelijk op toestellen te testen en continu te blijven werken aan bugs of nieuwe functies zonder de App Store gebruikers lastig te vallen. Ondanks dat het langer duurt om alles bij elkaar te verzamelen is dit proces simpel te beheren en de tijd meer dan waard.