Als je heel wat iOS-applicaties hebt ontwikkeld, weet je dat het niet zo eenvoudig is als “ontwikkel-publiceer in de App Store – laat gebruikers je app gebruiken”. Het “publiceren” gedeelte kan een paar minpuntjes hebben. Het is ons onlangs overkomen bij Moqod en ik kon niks anders doen dan het verhaal te delen over hoe het is verdergegaan en hoe we het hebben opgelost.
Onze opdrachtgever, Palladio Groep B.V., is een interim- en adviesbureau op het gebied van de besturing en beheersing van organisaties, programma’s en grote projecten. Ze werken samen met bedrijven waar ze adviesdiensten en tijdelijk beheer bieden: wat te implementeren, wat te verankeren en wat achter te laten. Iedereen in het proces moet veel leren, dus de behoefte aan de mobiele applicatie flink groeide.
Het team van Moqod ontwikkelde een applicatie voor het leren en certificeren van werknemers en hun klanten. Het geval van Palladio was klassiek voor B2B-apps: men moet een directe link sturen naar de klanten om de applicatie te downloaden zonder tussenkomst van derden, en zij zouden er onmiddellijk toegang toe hebben.
Het probleem begon toen een van Palladio’s klanten verzocht om de applicatie op de officiële marktplaatsen te krijgen vanwege hun interne veiligheidsvereisten. Google Play accepteerde de eerste versie meteen. De App Store was echter niet zo gastvrij.
Het uploaden van de applicatie maakte deel uit van mijn rol als projectmanager, dus stuurde ik de applicatie ter beoordeling naar de App Store. Verder zal ik de problemen beschrijven en aangeven hoe we ze hebben opgelost.
Het is B2B app, babe
Het doel van de app was niet om hem op een gewone manier te vinden in de AppStore, maar om direct verzonden te worden. De eerste en enige afbeelding was dus de screenshot van het inlogscherm. Voor de rest zou de beheerder de gebruiker de login- en wachtwoordinformatie verstrekken.
Na een paar dagen van uploaden van de app, heeft de App Store extra informatie bij ons aangevraagd om verder te gaan met de review van de app. Ze hadden de volgende antwoorden nodig:
- Wie is de doelgroep van de app?
- Hoe krijgen de gebruikers een account?
- Waar vindt de distributie van de applicatie plaats: binnen ons eigen bedrijf, binnen het bedrijf van één doelklant of onder bedrijven met meerdere doelklanten?
- In welke landen wordt de app verspreid?
- Als de applicatie alleen voor interne distributie is, hebben zowel interne als externe partners er dan toegang toe? Of is het exclusief voor interne medewerkers?
Als ik wilde dat ze de aanvraag bleven beoordelen, moest ik ze antwoorden geven, wat ik onmiddellijk deed:
- De doelgroep van de app zijn mensen die trainingen volgen bij Palladio Groep.
- Een cursusbegeleider maakt voor elke gebruiker een uniek account aan. De gebruiker krijgt dan een gegenereerd wachtwoord via e-mail.
- De applicatie wordt verspreid onder de klanten van Palladio Groep.
- De distributie van applicaties is beperkt tot alleen Nederland.
- De applicatie is bedoeld voor gebruik door Palladio Groep en haar partners.
Goede en duidelijke antwoorden toch?
Dezelfde dag, na ontvangst van de antwoorden, weigerde de App Store de eerste versie van de app.
De verklaring voor de afwijzing was de volgende:
De bedrijfsapplicatie is ontworpen voor een bepaald bedrijf en zijn klanten, maar niet voor algemene distributie in de App Store. Volgens het beleid van de App Store zijn B2B-apps op hun platform bedoeld voor gebruik door externe klanten over de hele wereld. Omdat onze applicatie niet bedoeld was voor algemene distributie, kon die niet beschikbaar worden gesteld in de App Store.
Ze volgden met generieke middelen om te beoordelen hoe de applicatie op een andere manier kon worden gedistribueerd of om de bestaande te herzien om hem beschikbaar te maken voor externe klanten over de hele wereld. Toen we het laatste deden, kregen we het advies om de App Store Review Guidelines en de Business App Distribution op de website van Apple te raadplegen.
Een van de opties in de App Store Review Guidelines was om de applicatie Mobile Device Management (punt 5.5. In de richtlijnen) diensten te laten aanbieden. In dit geval kan de app worden aangeboden door bedrijven en instellingen, met een duidelijke verklaring welke gebruikersgegevens worden verzameld voorafgaand aan acties. Onze klant heeft dit idee echter afgewezen vanwege hun beleid.
We besloten om aan de functionaliteiten te werken.
Afstemming
Ik heb aandachtig andere zaken met bedrijfsmodellen (punt 3.2.) en algemene richtlijnen (inleiding en voordat u deze indient) gelezen. Op dat moment besloot ik dat we onze applicatie binnen dit model konden passen.
We voegden de mogelijkheid toe om voor iedereen te registreren in de applicatie van Palladio Groep. Ze zouden daardoor toegang hebben tot een demoversie van de app, en dan konden ze een volledige cursus kopen. Om echte Palladio-cursussen te kopen, hoeven ze alleen maar contact op te nemen met Palladio Groep. Recente gebeurtenissen met de Fortnite-game geven aan dat het illegaal is om functionaliteit te kopen waarbij in-app-aankopen worden omzeild.
Registratie en authenticatie van een gebruiker is een van de eerste functies die je ontwikkelt wanneer je een applicatie voor een breed publiek bouwt. Het toevoegen van onze eigen vereisten aan de app na het inloggen was onze manier om de beperkingen te omzeilen.
Ik stelde deze oplossing voor aan onze klant en kreeg hun goedkeuring. We hebben een gebruikersverhaal ontworpen en als resultaat hebben we het volgende aan de applicatie toegevoegd:
- Mogelijkheid om te registreren in de app
- Het opnieuw instellen van wachtwoord
- Demo-quiz voor zelf-geregistreerde gebruikers
- Weergave van voorlopige quizresultaten
- Contactformulier (na de quiz) met één enkel veld en de opmerking: “De beheerder heeft toegang tot uw e-mailadres en uw naam. U kunt aanvullende contactgegevens toevoegen”
- Link naar privacybeleid
We hebben het volgende toegevoegd aan het admin-paneel:
- Een aparte pagina met zelf-geregistreerde gebruikers (standaardgroep)
- Mogelijkheid om de gebruikers van de standaardgroep naar de permanente groep te verplaatsen als de gebruiker zal deelnemen aan de echte cursus die door onze klant wordt aangeboden
- Standaardquiz voor standaardgebruikers
- Mogelijkheid om de e-mail met de contactpersoon via backend naar de beheerder te sturen
De nieuwe versie was goed om te gebruiken en we hebben die ter beoordeling naar de App Store gestuurd.
Het eerste antwoord dat ik binnen drie dagen ontving, was niet origineel. Het was net als het eerste antwoord – de applicatie is niet bedoeld voor algemene distributie.
Een mens achter het algoritme
Toen ik me realiseerde dat ze simpelweg hun oorspronkelijke reden voor afwijzing hadden gekopieerd van de eerste versie, besloot ik een grondiger uitleg te geven van wat er sindsdien is veranderd. Mensen die de applicaties voor de App Store beoordelen, zijn immers net zo menselijk als wij. Ik besloot ze niet te laten zien dat ik het onderzoek had gedaan.
Dezelfde dag schreef ik aan de App Store dat we volgens hun aanbevelingen het volgende hebben geïntegreerd:
- Registratie
- Het opnieuw instellen van wachtwoord
- Demofunctionaliteit om het app-doel te vertonen
Ik schreef dat deze functionaliteiten een breed publiek van de applicatie impliceren en hem beschikbaar maken voor alle gebruikers. Ik benadrukte dat ik geen enkele discrepantie vond in de App Store-beoordelingsrichtlijnen en in het bijzonder in punt 3.2. Als er ooit meer problemen in de app waren, vroeg ik om specifieke aanbevelingen om aan de richtlijnen te voldoen.
Mijn uitleg bleef enkele dagen onbeantwoord. Binnen een week besloot ik op “Appeal” te klikken en de situatie nog een keer hierin uiteen te zetten. De App Store antwoordde meteen en deze keer kreeg ik twee berichten. De eerste bevestigde dat ze de beoordeling van de aanvraag van de Palladio Groep zouden voortzetten met de nieuwe verstrekte informatie. De tweede verklaarde dat het beroep was ontvangen en werd beoordeeld. Oh, goed, het proces bleef tenminste doorgaan.
Aan mijn kant moest ik wachten op de beslissing. Ze zouden melden of het afwijzingsprobleem na de verbeteringen nog steeds geldig was of niet. Ze zouden ook communiceren over de nieuwe mogelijke problemen als die er waren.
Twee weken van volledige stilte zijn verstreken en ik besloot dat het tijd was voor een herinnering. Ik vroeg beleefd of de aanvraag nog in behandeling was of dat ze meer informatie van mijn kant nodig hadden. Diezelfde dag verscheen een heel eenvoudig antwoord, maar… ook, ik kreeg eindelijk de “happy mail”! Bingo!
Gelukkig einde
Het kostte ons bijna twee maanden en we kwamen eraan. Onze opdrachtgever, zijn klanten, App Store en Moqod kregen het resultaat waar we allemaal naar op zoek waren.
Het moraal van het verhaal?
- Beleid, richtlijnen en “how-to” zijn niet geschreven om de lezer te irriteren en ze over te slaan. Ze komen echt van pas als ze worden gebruikt!
- “Nee” is geen acceptabel antwoord als het om je bedrijf gaat.
- Hoe meer je gepassioneerd bent om een “ja” te krijgen, hoe meer de menselijke factor een rol speelt.
- Laat zien dat je het onderzoek hebt gedaan, wees redelijk.
- Neem nooit genoegen met een copy-pasted antwoord.
Conclusie
Met ervaring zul je steeds meer ideeën hebben om iets te laten werken, zolang je maar je onderzoek blijft doen en je ideeën test. Afwijzingen zijn ons eerder overkomen en zullen ongetwijfeld in de toekomst gebeuren. Wat ze ons hebben geleerd is dat er altijd een manier is om van een ‘nee’ een ‘ja’ te maken.
