Even op een rij zetten:

• 3 augustus 2010 (16:03). Ik dien de update in. Zoals gewoonlijk krijg je direct een mailtje met de melding dat de status van je app verandert is naar ‘Waiting for review’. Ok, cool. De vorige keer duurde het ook een week.
• 10 augustus 2010 (18:55). Mailtje ontvangen: iemand van Apple is bezig met CamouTweet te reviewen. De vorige keer duurde dit ongeveer een uur dus ik verwacht me nog aan goed nieuws die avond. Helaas niks meer ontvangen.
• De app blijft nu een tijdje ‘In review’ staan. Lang. Ik besluit een mailtje te sturen waarom het zo lang duurt, maar meer dan een soort automatisch antwoord (knip- en plakwerk uit standaardteksten) krijg ik niet terug.
• 16 augustus 2010 17:42: Ik ontvang weer een mailtje van Apple. Deze maal met de melding dat de App niet werd goedgekeurd omwille van een fout tegen de zogeheten en sterk gevreesde ‘Human Interface Guidelines’.

De mail die me uitlegt wat er verkeerd is aan CamouTweet en waarom de update niet door kon gaan.

Voor alle duidelijkheid: die ‘fout’ was al aanwezig in versie 1.0. Aangezien ze geen probleem vormde voor de reviewer in de eerste versie moest ik ook geen moeite doen om ze in een kleinere update eruit te halen. Ik besloot me toe te leggen op meer dringende zaken.

Hoe komt het dan dat het zo lang moest duren om die kleine fout te melden? Hier is mijn hypothese.

De App Store reviewers, laat ik ze ‘het team’ noemen. Moet enorm veel apps reviewen in een zo kort mogelijke tijd. Het feit dat er een behoorlijke tijd zit tussen het ‘In review’ gaan en de eigenlijke feedback duidt volgens mij op 2 teams. Een reviewteam en een feedbackteam. Beide teams werken los van elkaar. Heb je geluk dat het reviewteam je app goedkeurd, dan komt die nooit in handen van een feedbackteam en kan het direct op de App Store gepost worden. Is dat echter niet het geval, dan wordt je app blijkbaar opnieuw in de wachtrij gezet van het feedbackteam. Vandaar dus de lange wachtperiode.

Ik moet eerlijk zeggen dat ik wel tevreden ben van de feedback en de mate waarin alles wordt beschreven. Er worden zelfs screenshots aangeleverd om alles te staven. Sterk, hier maken ze echt wel hun werk van. Maar als ik een suggestie mag doen aan Apple: maak een nieuwe status aan. Iets in de zin van: ‘Rejected, waiting for feedback’. Dan weet je tenminste waar je staat en hoef je niet een hele week nerveus rond te lopen…

De basis: Basic Authentication

Voor we naar OAuth kunnen gaan moeten we het even hebben over zijn eerder primitieve, doch nog steeds veelgebruikte, voorganger ‘Basic Authentication’ (BA). Die laatste onderscheid zich niet bepaalt op het vlak van veiligheid. Gebruikers van services zoals sociale netwerken gebruiken vaak standaard eenzelfde login (e-mailadres of gebruikersnaam) en een daarbij horend paswoord. BA komt eigenlijk neer op het ingeven van die gegevens, ze vervolgens al dan niet met een vorm van encryptie door te sturen naar een authenticatiedatabase die dan op zijn beurt een positief signaal geeft dat de gebruiker toegang krijgt tot de gegevens waar hij recht op heeft. Veilig tot op zekere hoogte, maar hoeveel keer komen de volgende situaties niet voor met zo’n service:

• Je wil gegevens overdragen van de ene service naar de andere (bijvoorbeeld contacten van Facebook importeren in LinkedIn)
• Je wil een derde-partij-app gebruiken die je toegang geeft tot een service (bijvoorbeeld TweetDeck voor Twitter)

In het geval van BA zal die ene service, of die ene app je vragen om je credentials (gebruikersnaam en wachtwoord) en bijgevolg kan die onbeperkt gebruik maken van de privileges van je account. In het geval van Twitter: updates posten, retweeten, antwoorden, … In het geval van Facebook: vrienden toevoegen/verwijderen, status updaten, … Behoorlijk angstaanjagend als je dit ten volle begint te beseffen hoeveel macht zo’n service/app dan wel van je krijgt.

Maar wat is het alternatief dan? Uiteindelijk is en blijft de veiligheid van jouw gegevens afhankelijk, maar ook de verantwoordelijkheid, van grote services zoals Facebook, Twitter, … Om zo’n problemen te vermijden werd de hulp ingeroepen van een tot voor een aantal maanden een behoorlijk onbekende technologie: Open Authentication, kortweg OAuth.

OAuth, redder en bewaker van persoonlijke data

Het logo van OAuth, als je dit ziet zit je zeker veilig!

Zoals reeds vermeld heeft OAuth zijn succes voornamelijk te danken aan de opkomst van sociale netwerken zoals Facebook, Twitter, Youtube, … Vele sociale netwerken of andere services beginnen nu te switchen naar OAuth (Twitter schaft bijvoorbeeld vandaag BA af – OAuthalypse) en dat is een goede zaak. Voorheen werkten ze bijna allemaal met BA, voornamelijk ook omdat die het handigst en makkelijkst is om te implementeren in een API. Een goed hanteerbare API verzekert zowat je succes bij onafhankelijke developers en die heb je net nodig om je service bekend en populair te maken.

Waarom is OAuth nu zo veilig? Met BA geeft je je credentials aan een app en God alleen weet wat die app er allemaal mee gaat aanvangen. Stel nu dat zo’n app misbruik begint te maken van jouw credentials, wat is dan het enige wat je er tegen kan doen? Juist: je moet je paswoord en eventueel je gebruikersnaam van die service veranderen. In het ergste geval moet je zelfs je account stopzetten. OAuth verplicht de applicatie zich eerst te identificeren voordat hij kan gebruik maken van je data, zo kan je makkelijk de controle bewaren over wie al dan niet gebruik mag maken van jouw rechten op die service.

1. Eerst en vooral moet de ontwikkelaar van een derde-partij-app (de makers van Tweetdeck bijvoorbeeld) hun applicatie registreren bij de service (Twitter). Bij die registratie krijgt de app zogeheten ‘Consumer Credentials’, die bestaan uit een ‘Consumer Key’ en een ‘Consumer Secret’. Digitale nummerplaten zeg maar. Hierdoor kan een app geïdentificeerd worden bij een service.
2. Als de app voor de eerste keer wordt opgestart doet hij een ‘RequestToken’-procedure. Met andere woorden: de app vraagt aan de service een soort unieke sleutel die jouw gegevens met de digitale nummerplaat van de app zal verbinden.
3. Nu kom jij in het spel. Wanneer je een app opstart zal die je (eenmalig) vragen om je credentials in te vullen. Dit klinkt opnieuw wat verdacht en tegenstrijdig met wat hierboven staat maar toch, het is veilig.
4. De RequestToken wordt samen met je credentials doorgestuurd naar de service, meerbepaald naar de zogeheten ‘authorize_url’. Dit is een net gegenereerde pagina op het internet die gehost wordt door de service zelf. Met andere woorden: als je toegang geeft aan een app tot Twitter, dan moet je een pagina zien die onder www.twitter.com valt.
5. Op die pagina kiest de gebruiker of hij zijn toestemming verleent aan de app om gebruik te maken van je data/rechten (Allow or Deny principe).
6. Eenmaal de gebruiker op ‘Allow’ (of ‘Yes’ of elk ander positief antwoord) klikt wordt hij doorgestuurd naar de ‘CallBack_URL’. Die pagina waar je uiteindelijk belandt wisselt je RequestToken in voor een ‘AccesToken’.
7. De app die je toegang wou geven ontvangt die ‘AccesToken’ die eigenlijk niet meer is dan een unieke identificatie voor de relatie tussen een set ‘Consumer Credentials’ van de app, en de ‘User Credentials’ van jezelf. De AccesToken moet nu veilig worden opgeslagen ergens op je PC door de app zelf, meestal in een lokale database.

Telkens je de derde-partij-app zal opstarten zal die zich eerst bekend maken aan de service door zijn ‘Consumer Credentials’ door te sturen, direct gevolgd door de ‘AccesToken’ en een ‘ServerRequest’. Dat laatste is een vraag aan een server om ‘iets’ te doen (tweeten, een status updaten, een foto posten, … wat de service-API ook maar toelaat).

Zoals je merkt is het dus voor de applicatie op geen enkel punt nodig om je credentials op te slaan. Toch kan hij dat doen, maar de sterkte van OAuth zit hem net in stap 5. Elke service die OAuth gebruikt, zal zijn gebruikers ook een soort authorisatiepagina (zoals die van Twitter) geven. Een pagina waarop alle rechten die je verleent aan applicaties opgesomd staan. Op die pagina kan je die rechten, indien je dat wil, intrekken en zo vermijden dat een programma nog iets doet met je credentials zonder dat je daarvoor nog je eigen credentials hoeft te veranderen. Eenmaal je de rechten verwijdert, verwijder je eigenlijk de AccessToken. Als die onbestaande is, dan zal elk ServerRequest op een fout uitdraaien.

De nobele onbekende

OAuth klinkt misschien niet echt sexy voor de gewone gebruiker van dingen zoals Twitter, Facebook, … maar is meer aanwezig dan je maar denkt. Uiteindelijk hoeft enkel de developer en de aanbieder van de service hiervan wakker te liggen. Het enige wat telt voor de gebruiker is dat zijn gegevens veilig zijn, en dat zou ook de eerste zorg moeten zijn van veel services op internet die nu nog geen OAuth gebruiken. OAuth is voor velen de nobele onbekende die je veilig houdt op het Internet zonder dat je het beseft. Een goede bewaarengel als je wil.

Meer info over OAuth vind je hier.

En zo gebeurde het ook met de (kleine) update naar iOS 4.0.2. Het gaat om een fix voor de PDF-exploit die jailbreaken mogelijk maakte, dus eigenlijk geen ingrijpende veranderingen zou je denken. Dat bleek het ook niet, maar toen ik even later in de winkel iets wou opzoeken bleek mijn internetverbinding het niet meer te doen. Dit is hoe ik het opgelost heb.

Het probleem

Telkens ik een dataverbinding wil starten zegt de iPhone me ‘Kan geen verbinding maken. Er is geen internetverbinding actief’. Dit deed me denken aan de tijd toen ik nog met een gewone prepaid-kaart rondliep in mijn iPhone. Toen kreeg ik ook telkens die melding toen een programma probeerde over 3G (of Edge) te verbinden. Vreemd, zou de optie ‘Data’ verdwenen zijn uit mijn abonnement?

De oplossing

Uiteindelijk kan je hier zelf bitterweinig aan doen. Het probleem ligt hem vooral in een corrupte APN op je iPhone. Bellen naar de klantendienst van Mobistar dan maar. In alle eerlijkheid: ze steken ver uit boven de alledaagse standaardbeleefdheid van de doordeweekse helpdeskmedewerker. Zeker een kwartier lang heb ik iemand aan de lijn gehad die actief oplossingen aan het zoeken was. Dus dank u wel Mobistar. Voor alle duidelijkheid, ik word er niet voor betaald om dit te zeggen!

Misschien is het wel handig om even mee te geven dat je moet kiezen voor optie 4, hulp bij iPhone. Daarna kies je voor optie 1 ‘Technische vragen’.

Hoe raakte het dan uiteindelijk opgelost? Wel, Mobistar heeft een soort van ‘Reset-mogelijkheid’ voor APN’s die je zelf kan gebruiken. Op je iPhone ga je naar ‘Instellingen’ > ‘Algemeen’ > ‘Netwerk’ > ‘Mobiel Datanetwerk’. In alle waarschijnlijkheid zie je bij APN staan ‘iphone.mobistar’ zonder gebruikersnaam of wachtwoord.

De APN instellingen van Mobistar

Verander de APN naar ‘mworld.be‘. Dit is de oude APN van Mobistar. Ja, je leest het goed, de oude. Maar die is zo geconfigureerd dat hij de nieuwe instellingen automatisch gaat downloaden en installeren zodat je opnieuw verbinding krijgt.

Belangrijk! Schakel je iPhone nu volledig uit. Niet in vliegtuigmodus, niet enkel data uitzetten, neen, volledig uit.

Eenmaal je de iPhone opnieuw hebt opgezet kan je al even proberen om verbinding te maken. In alle waarschijnlijkheid zal dit niet lukken maar je moet eerst opnieuw een verbinding proberen te maken zodat Mobistar je de juiste instellingen kan doorsturen. Geef je  iPhone een rusttijd van een aantal minuten. Zet hem opnieuw volledig uit, en opnieuw volledig aan. Normaal werkt de dataverbinding nu opnieuw.

Voor de volledigheid zie je hier nog eens de instellingen die onder ‘Mobiel datanetwerk’ zouden moeten verschijnen.

De APN instellingen van Mobistar

De MMS instellingen van Mobistar

Dit is geen officiële fix van Mobistar zelf. Het was een experiment die (misschien toevallig) goed gelukt was door en mij verteld door iemand op de helpdesk zelf. Ik weet niet of zij zelf iets veranderd hebben aan de instellingen op mijn iPhone, of aan mijn abonnement, tijdens het gesprek. In elk geval kan je ze gratis bereiken, vertel hen deze oplossing en ze zullen ongetwijfeld weten waarover je het hebt.

Veel succes!

iTunes Connect (iTC)

Toen ik de eerste keer mijn App instuurde was er eigenlijk geen enkel vuiltje aan de lucht. Akkoord iTunes Connect (het managementssysteem achter de App Store) vraagt een heleboel gegevens over je App. SKU-nummers, versienummers, screenshots, icoontjes in bepaalde resoluties, … Het lijkt allemaal wat overdreven, maar uiteindelijk is het voor het beste, want de App Store is nu eenmaal op en top verzorgd. En dan begint de miserie, want zo mag ik het wel noemen…

De binary die je moet inzenden, het feitelijke programma dus, moet aan extreem scherpe voorwaarden voldoen. Niet alleen moet je er opnieuw een heel speciaal certificaat voor ophalen (geen zorgen, dat zit in je inschrijvingsgeld vervat), maar de build moet 100% perfect zijn verlopen. Je mag met andere woorden geen enkele waarschuwing krijgen door je compiler (het programma die de eigenlijk App bouwt) op het is al zover: iTunes Connect weigert de App. Mijn fout lag hier dat het icoon voor de App zelf geen 57×57 pixels was, het was er 100×100. Aanpassen en opnieuw preppen dus…

Zo moet de compiler zijn resultaat tonen: alles ok.

Ik vind persoonlijk dat Apple een slechte zaak doet aan het niet integreren van iTunes Connect binnenin XCode, de developertool om Apps mee te maken. Slecht een zeer klein venster van XCode, de Organiser,  is in staat zich te verbinden met iTC en dat alleen maar om de certificaten op te halen die je toelaten om een App werkelijk op een iDevice (iPhone, iPod, iPad) te testen. Een mogelijkheid om direct te kunnen uploaden naar iTC ontbreekt, net als de mogelijkheid om je details in te vullen of screenshots aan te leveren. Nog iets wat zou mogen verbeteren is het icoonsysteem. Apple vraagt je nu om zo’n 8 verschillende stuks, mocht je enkel de grootste mogen leveren en XCode zou alles zelf verkleinen, aanpassen en plaatsen waar het moet zou dat al een heel groot verschil maken.

Het Approval Proces

Ongetwijfeld het meest gehate proces onder de Apple-ontwikkelaars. Eenmaal je App ingestuurd begint een al dan niet lange periode van onzekerheid en in het duister tasten over hoe je App de review van een Apple-ingenieur zal doorstaan. Laat me duidelijk zijn: je staat compleet machteloos. Je ziet niet de hoeveelste je bent in de rij wachtende Apps die nog moeten gereviewd worden, en als je ook maar één verandering wil aanbrengen aan de binary zelf val je opnieuw naar onder in de mand.

De percentages die Apple nu en dan eens vrijgeeft

Over de wachttijden is Apple zeer vaag. De enige maatstaf die je kan hanteren om te oordelen of je al dan niet snel bediend werd staat te lezen in hun documentatie van het proces zelf. Helaas worden deze cijfers niet al te vaak geüpdated dus kan je ze niet echt onder ‘betrouwbaar’ klasseren.

Na een week wachten komt uiteindelijk een beetje nieuws binnen: ‘Your application has changed state’. Ok, cool! Nu blijkt de App ‘In Review’ te zijn. Met andere woorden, iemand is werkelijk bezig met die zelfgeschreven hebt te bekijken, te beoordelen, … Het voelt bijna als een examen. Maar toen, na iets minder dan een uur opnieuw een mailtje: ‘Your application has changed state’… Nu is het alles of niks, ‘Rejected’ of ‘Preparing for App Store’. We weten dus allemaal hoe het met die eerste versie afliep.

Daar sta je dan, in de App Store, fier als een gieter. Vandaag ben je een echte Apple-ontwikkelaar zeg je tegen jezelf. Onmiddelijk begint de queeste opnieuw, op zoek naar bugs, verbeteringen en hoe je die in je App zal krijgen. Na een week ben je klaar met een betere versie, een waar je echt fier op kan zijn, en een die de oude doet smelten als sneeuw voor de zon. Je kent iTC al, je weet hoe grillig de compiler werkt en uiteindelijk, vol zelfvertrouwen, zend je de update naar iTC en dan is het wachten…

Een week…

Acht dagen…

Op de negende dag krijg je een mail: ‘Your application changed state’. Cool, binnen een uur is het weer puur geluk! Niks is minder waar. Sindsdien (en we schrijven meer dan 60 uur later) heb ik niks meer gehoord van de update. Na meer dan 48 uur toch eens een ongerust mailtje gestuurd naar het supportadres van het Approval Proces zelf (jawel, het bestaat!), maar buiten een antwoord van meneer Robot heb ik ook nog niks mogen ontvangen.

Het mailtje die ik van Apple kreeg, na al 3 dagen geleden

Om maar te zeggen… het kan lang wachten zijn. Nerveus word je er van. En dan schrijf je deze blogpost. Meer nieuws volgt!

De afbeelding in de banner van deze post behoort toe aan Cristiano Betta

Wel, dat is dus net niet gebeurd. In mijn onredelijk lange vakantieperiode heb ik alles eens netjes op een rij gezet. Wat wil ik gaan doen met de blog, is het nog wel de moeite om hem open te houden naast Twitter, Youtube, Vimeo, Facebook, LinkedIn, Gowalla en consoorten? Ik denk van wel. Het is stoutmoedig, maar ik ben er van overtuigd dat ik na zo lang stilliggen de nodige inspiratie en kennis heb opgedaan om deze blog regelmatig te kunnen aanvullen. De denkwijze die er achter zit is wel veranderd. Ik heb alles wat er ooit op stond verwijderd. Niet weggegooid, gewoon niet meer beschikbaar gesteld voor het collectieve geheugen van de wereld. Wat er nu zal opkomen zijn dingen over mijn alledaags werk, stukken die ik handig vind, dingen die ik leuk vind om te delen met iedereen, … Je snapt het wel.

Ik ben blij dat ik deze nieuwe weg heb kunnen kiezen, en het oude pad links kan laten liggen. Ik hoop dat jullie het ook zullen kunnen appreciëren. Mijn onverantwoord lange vakantie duurt nog enkele weken en van die tijd zal ik gebruik maken om alles hier werkende te krijgen. Zoals je merkt zijn nog niet alle pagina’s in orde qua stijl, gebruiksgemak, vindbaarheid, … en kan je ook nog niet reageren. Strategisch misschien niet de beste keuze om dat even achterwege te laten maar ik waag het er op. In de komende weken zal de boel wel goed gaan draaien en dan zie ik wel aan mijn statistieken wat jullie er van vinden. Tot de volgende!

Martijn