Een app bouwen is een hele kunst. Vooral omdat je wilt dat  die nuttig in gebruik is, prettig werkt en oogt en bovenal veilig is. Maar dan ben je er nog niet, want de grootste uitdaging is vervolgens om de app aan te kunnen bieden in de App store, weten wij inmiddels uit eigen ervaring. Graag neem ik je mee in dit avontuur en de lessons learned die het ons heeft gebracht.

Begin juli waren we functioneel gezien klaar om live te gaan. We hebben gelijktijdig onze Vakpaspoort app aangeboden aan de Google Play Store en de App Store. Binnen enkele dagen stond de app in de Google Play Store, maar kregen we van Apple een  afwijzing . Dit voldeed dan weer wel aan de vooringenomen beelden die ik had bij Google en Apple. Voor beide reacties valt overigens wat te zeggen. Google laat echt niet alles zomaar binnen en is bijvoorbeeld wel streng op alles wat met veiligheid te maken heeft. Apple is dat ook, maar is ook extra alert op alles wat de usability (‘gebruikersvriendelijkheid’) in hun ogen aantast. Dat is bewonderenswaardig , maar heeft als risico willekeur in zich.

De reden van de eerste afwijzing was goed  te begrijpen. Van Currence (merkeigenaar van iDEAL, iDIN, Incassomachtigen en Acceptgiro) moesten we  voor het gebruik van iDIN om een identiteit vast te stellen, vanuit de app naar een externe browser gaan. Vanuit veiligheidsperspectief een begrijpelijk standpunt. Van Apple moesten we vanuit usability juist in de app blijven en een in-app browser aanroepen.

We hebben uiteindelijk twee routes bewandeld om het op te lossen:

1.    We hebben bij Currence aangekaart dat hun richtlijnen strijdig zijn met de richtlijnen van Apple en gevraagd mee te werken aan een oplossing. Zij hebben ons hier erg goed bij geholpen.

2.    Verder hebben we er alles aan gedaan om te voldoen aan de eisen van Apple en bij hen het verzoek neergelegd om in dit geval toch de externe browser oplossing te accepteren.

Na veel inhoudelijke onderbouwingen, filmpjes hoe we iDIN in onze app gebruiken, ondersteunende teksten van Currence en vooral meerdere afwijzingen, heeft Apple onze oplossing en daarmee onze app uiteindelijk geaccepteerd. Het is ons overigens nog steeds niet helemaal duidelijk waarom ze hier dit keer wel toe besloten.

Uit onze analyse op dit acceptatietraject valt het volgende op:

• Apple denkt serieus na en mee over de kwaliteit voor de gebruiker van apps en gaat daar heel ver in.
• Een onderbouwing met een goede storyline, uitgeschreven discussies en ondersteunende filmpjes en screenshots, helpen zeker.
• En het belangrijkste  volg de guidelines van Apple letterlijk en tot in detail op!.

Aangezien het zomerperiode was maakte ik dit hele avontuur mee via Whatsapp vanaf mijn vakantieadres.  Ik wil het ICT team en Synobsys die zo hard hebben gewerkt aan de acceptatie dan ook enorm bedanken voor hun inzet en vooral voor hun geduld om onze Vakpaspoort app geaccepteerd te krijgen.

Voor de liefhebber hebben we een lessons learned gemaakt voor toekomstig gebruik (zie hieronder). Heb je zelf ervaring met het brengen van apps naar de stores, deel ze met ons. Ondanks dat we op dit gebied inmiddels een stuk deskundiger zijn, vermoed ik dat we nog veel van elkaar  kunnen leren.

Marcel van Lieshout

In deze lessons learned geven we onze belangrijkste lessen weer bij het brengen van een app naar de App Store. Op het internet zijn genoeg handleidingen wat je allemaal moet doen om een app aan te bieden aan de app store. Dus als je wilt weten hoe je een developer account moet aanmaken, zie google. Ook bij Apple zelf vind je veel informatie: https://developer.apple.com.

Als het gaat om de vereisten van de app zelf, verwijzen we naar de App Store Review Guidelines van Apple: https://developer.apple.com/app-store/review/guidelines/

Onze eigen lessen:

• De app store review guidelines geven géén uitsluitsel over dat het aanroepen van een externe browser vanuit een app al dan niet verboden is. Het lijkt dus met volledige willekeur te zijn gebeurd dat onze app op dat punt is afgekeurd. In het bericht vanuit Apple van de afkeuring werd gesproken over dat de app het hoofdstuk 4-Design niet zou volgen, maar dat is dus nooit hard (concreet) gemaakt. Dat brengt ons tot de les om deze guidelines nog meer ter harte te willen nemen tijdens het ontwikkelen van de app. Al weet je nooit wanneer deze guidelines wijzigen en waarin dan.
• Omdat we gebruik maken van iDIN heeft Apple géén review van de daadwerkelijke app kunnen doen (omdat ze geen iDIN-login kunnen/willen doen). Daartoe is ons gevraagd een filmpje te maken van de functionaliteit van de app. Daarbij hebben we geleerd:
  o  Gebruik géén simulator maar altijd een daadwerkelijke capture vanaf je mobiele device (anders accepteert Apple het alsnog niet).
  o  Dat het filmpje gemaakt moet worden binnen de productie-omgeving, wat inhoudt dat er aan onze backend-zijde ook een certificaat gekoppeld moet zijn aan de betreffende Vakpaspoort-gebruiker, zodat alle functionaliteit van de app getoond kan worden in het filmpje. Het voelde overigens niet heel goed dat we daarvoor de daadwerkelijke productie-omgeving hebben moeten inzetten.
  o  Iedere volgende major update (nieuwe build) verwacht ik dat er een nieuw filmpje gemaakt moet worden t.b.v. het tonen van de nieuwe functionaliteit en daar geldt bovenstaande dus opnieuw.
• Bovenstaand proces heeft (naar onze mening) erg lang geduurd (ruim drie weken doorlooptijd), daar moeten we bij major updates dus ook rekening mee blijven houden. We verwachten, hopen en gaan ervan uit dat het een volgende keer, gezien de lessons learned, een stuk sneller moet kunnen.
• Toen eenmaal tóch de app goedgekeurd werd, heeft Apple geen enkele terugkoppeling gedaan waarom ze deze beslissing alsnog genomen hebben. Daarmee hebben we nog steeds geen zekerheid naar de toekomst (qua approval van Apple van toekomstige major versies).
• Een goede samenwerking met de ontwikkelaar, in ons geval Synobsys, en er bovenop zitten, is essentieel.
• Vraag hulp van mensen met ervaring en expertise bij het in de app store krijgen van een app.

Succes met het aanbieden van jullie eigen app.

CRT Team