The earthquake and ensuing tsunami which struck Japan on March 11th shocked the world. Thousands of people lost their homes, possessions and relatives. As a relatively small app developer, there isn’t much we could do the help the victims. At least not in financial terms.

Update: Apple does not allow us to create apps with the intent to donate the revenues. Therefore we’ve had to adjust our policy regarding this app. See the progress section below for a detailed description.

There is, however, one thing we can do: we make iPhone apps. And so we decided to use this skill to support the Japan rescue effort. On Monday March 14th, we held a brainstorm session about what we could build to raise money. Our boundaries were simple: the app would need to be interesting, needed to be designed and developed within a short period of time, and needed some link with the situation in Japan. All revenue – every cent – generated by the application would be directly transferred to the Dutch Red Cross Society, who will make sure the money is spent where it is needed the most.

App concept

The first choice we made was to create a game, not a utility, firstly because a relevant utility was hard to come up with, but also because people are more willing to pay for games, so it raises more money.

We set a deadline of one week, because the people of Japan need any help as soon as possible. One week of development and one week of review by Apple means we’ll be donating money to the Japanese Red Cross society soon enough to make a difference.

So the goal became to create a game and do so in one week. The last thing to decide was how to link the app to Japan, apart from the fund raising part. We chose to go for an old Nintendo-era 8-bit style of design, combined with a game-goal of rescuing people from the roofs of buildings.

After another hour of brainstorming, we finalized the game concept: the player would be in control of a rescue helicopter, flying above a city struck by a tidal wave. As the water level rises, people flee to the roofs of the city, hoping to escape the water. The goal is to save as many people as possible, before the water flushes away the city.

Good cause

We are aware this game touches on a very sensitive subject and borders on a bad sense of taste. Developing and publishing this game was not a decision taken lightly. We chose to go ahead in spite of potential controversy, because our intentions are good and we hope to provide an easy, entertaining way to allow people to support Japan. If this application offends you, we deeply apologize.

Gameplay Video

Progress

June 24th Our public statement regarding the name change:

Japan Rescue has been released under a new name: Chopper Rescue. The original Japan Rescue got rejected by Apple for two reasons:

- We are not allowed to mention anything about donations or what we’ll do with the proceeds.
- Any app that is defamatory, offensive, mean-spirited, or likely to place the targeted individual or group in harms way will be rejected.

In the meantime, it has been months since the tsunami struck and the national and international communities have already provided the help Japan needs. To avoid any trouble with Apple (we develop lots of apps, we don’t want to run any chance of making a bad impression on the review teams) we’ve decided not to donate the proceeds of the application to the Red Cross, as mentioned earlier. We have, however, lowered the price to $1.00.

We do understand this might feel like we’re breaking our earlier promise. The way we look at it, this app is no longer using the Japan disaster as a main source of (media) attention, but has just become another pixel art game. We’ve spent time developing the game and would now like to gain some revenue.

We sincerely hope you can understand this change.

Best,
Coding Dutchmen

June 23th Apple approved Chopper Rescue, which is now available in the App Store for $1.00
June 16th We’ve renamed the app to Chopper Rescue and removed any references to Japan and donations to the Red Cross.
April 6th We received a call from Apple, explaining they couldn’t approve the app for two reasons:

• Apps that are primarily designed to upset or disgust users will be rejected
• Apps that include the ability to make donations to recognized charitable organizations must be free

March 29th We received an e-mail from Apple stating review will take additional time:

Dear Coding Dutchmen,
We are currently reviewing an app that you submitted for inclusion on the App Store, and want to let you know that the review process will require additional time. We apologize for the delay and will provide you with an update on the status of your app as soon as possible.

March 28th Apple has notified us Japan Rescue is now in review.
March 24th There’s a discussion on Touch Arcade concerning the ethics of Japan Rescue.
March 23rd Received reply by Apple, stating they can’t expedite a review at this moment. Quote:

At this time we are experiencing high volumes in app submissions. While we are doing our best to honor all requests for expedited reviews, we cannot guarantee an expedited review at this time. We are working hard to process submissions as quickly as we can and in the most timely manner.

March 22nd Application uploaded to Apple. We sent an e-mail asking if they could review the app quickly. Full e-mail:

Dear Apple,
Today we’ve submitted the app Japan Rescue to the app store. We’ve created this app with the sole purpose of supporting the victims of the Japan earthquake victims. We intend to transfer 100% of the application revenue to the Red Cross society so they can help the Japanese people as effectively as possible.
We would appreciate it if you allow this app to pass review quickly, as it is meant to be an easy, entertaining method of supporting the tsunami victims. The faster this app will be available, the faster we will be able to help Japan.
Best,
Luc van Donkersgoed
Coding Dutchmen

March 18th First playable version complete
March 14th Concept and development started

Op 21 juni 2010 werd iOS 4.0 aan het publiek vrijgegeven. Deze nieuwe versie van Apple’s mobiele besturingssysteem bevatte een groot aantal vernieuwingen, waaronder multitasking, ondersteuning voor externe bluetooth toetsenborden, iAds en een lading aan kleinere veranderingen. Al deze wijzigingen, gecombineerd met het reclamekanon van Apple en het feit dat de update gratis via iTunes te verkrijgen is, scheppen de verwachting dat iedereen snel naar de nieuwste versie van iOS zou installeren. Maar gebeurt dit in de praktijk ook?

01 januari 2010 tot 21 juni 2010

Op 1 januari 2010 had 84.27% van de gebruikers iPhoneOS 3.1.2 geïnstalleerd. Op de tweede plaats stond iPhoneOS 3.1, met 6.65%. Op 2 februari – de dag waarop iPhoneOS 3.1.3 werd vrijgegeven – zagen we hier de eerste grote verschuivingen in: in vier dagen kreeg dit OS een aandeel van respectievelijk 0.81%, 5.59%, 11.31% en 27.27%. Het zou echter nog 20 dagen duren voordat iPhoneOS 3.1.3 de 50% voorbij zou gaan. De tweede verschuiving vond plaats in de week van 3 mei, toen de Spirit jailbreak werd uitgebracht. Deze software stond voor het eerst een untethered jailbreak van iPhoneOS 3.1.3 toe, wat resulteerde in een een groei van 61.35% op 1 mei tot 78.36% op 9 mei. Dit is tevens het hoogste punt dat deze versie bereikt heeft.

21 juni tot 26 juli

De release van iOS 4.0 lijkt in theorie niet te vergelijken met die van 3.1.3, omdat de feature list van iOS 4 zoveel groter is. Als we naar de grafieken kijken, blijkt er echter een zeer herkenbaar patroon te ontstaan: in de eerste vier dagen groeide het aantal gebruikers van iOS 4 respectievelijk naar 1.31%, 5.07%, 17.31% en 23.23%. Toen iOS geüpdate werd naar versie 4.0.1 was circa 58% van de gebruikers overgestapt op 4.0. Na deze laatste update is het percentage iOS 4 nog iets gegroeid, maar tot dusver ligt de piek op 63.15%.

Conclusie

In de onderstaande grafiek zijn alle metingen sinds 1 januari 2010 opgenomen. Klik op de afbeelding voor een grote versie (2700x960px). De dikkere blauwe en rode lijnen zijn de verschillende subversies van iPhoneOS 3.x en iOS 4.x gecombineerd, zodat de opkomst van iOS 4 ten opzichte van iPhoneOS 3 goed waar te nemen is.

Uit de grafiek blijkt dat iets meer dan 60% van de gebruikers over is naar iOS 4. Als we er vanuit gaan dat het acceptatietraject van versie 4 vergelijkbaar met versie 3 zal verlopen, zullen we nog een stijging van ongeveer 20% zien zodra iOS 4 in jailbreak-formaat beschikbaar komt. Een andere reden voor de langzame acceptatie van de nieuwe versie kunnen we zoeken in de trage werking van iOS 4 op modellen ouder dan de 3GS. Uit onze statistieken (zie grafiek hieronder) blijkt dat circa 20% van de gebruikers nog op een iPhone 3G werkt, terwijl al een tijd bekend is dat iOS 4 een merkbare vertraging op dat toestel teweeg brengt.

Over de metingen

Sinds de zomer van 2009 registreert Coding Dutchmen het gebruik van haar applicaties. We slaan hierbij anoniem gebruiksgegevens op, waaronder het type iPhone, de versie van het OS en de gebruikte versie van onze apps. Het platform waarmee we deze gegevens registreren lijkt op Flurry of Google Analytics, maar is helemaal in-house ontwikkeld, waardoor we meer vrijheid hebben in toepassing en optimalisatie. De lijst van apps waar we onze statistieken mee opbouwen bevat onder andere FML en Rabo Cycling, waardoor we een zeer gevarieerde groep gebruikers hebben. Verdeeld over alle apps hebben we sinds begin 2010 meer dan 2 miljoen meetpunten kunnen registreren, welke we in dit artikel gebruiken om de opkomst van iOS4 te beschrijven.

Rabo Cycling is de meest uitgebreide sport-app van de Rabobank. De applicatie bevat een grote hoeveelheid gegevens, welke via een aantal verschillende kanalen naar de iPhone gebracht worden. Dit artikel werpt een blik op de technieken die bij het ontwikkelen van de backend van een iPhone-app gebruikt worden.

Interaction design

De Rabobank gaf ons de opdracht om een wielren-applicatie voor alle wedstrijden in de UCI Wereldkalender te ontwikkelen. Van deze wedstrijden moest zoveel mogelijk informatie getoond worden, waaronder klassementen, ploegenlijsten, etappebeschrijvingen en hoogtekaarten, terwijl de app vanzelfsprekend snel en gebruiksvriendelijk moest blijven.

De belangrijkste functionaliteit – the unique selling point - van de eerdere wielren-apps iTour en iSport was het live volgen van de renners tijdens een etappe. Deze functionaliteit moest daarom ook in de nieuwe app een prominente plaats innemen.

Op basis van bovenstaande uitgangspunten hebben we een interactieontwerp gemaakt. Dit design beschrijft welke schermen de applicatie bevat en hoe een gebruiker tussen deze schermen kan navigeren. In het schema is te zien hoe de applicatie uit twee niveaus bestaat: de main tabbar bevat overkoepelende infomatie als nieuws, video’s, algemene informatie en een overzicht van te downloaden evenementen, de event tabbar bevat een aantal schermen met evenement-specifieke informatie.

In de live tab wilden we niet veel veranderen; in iTour en iSport was de voortgang van de renners snel en duidelijk te herkennen en gebruikers waren erg tevreden over de werking. Het design van de tab hebben we wel op de schop genomen, omdat het oude ontwerp niet meer aan onze kwaliteitsstandaarden voldeed en überhaupt niet goed in de nieuwe applicatie paste. Zie het screenshot hiernaast voor een vergelijking tussen de oude Rabo iTour en het nieuwe Rabo Cycling.

Nieuws en video

In de applicatie worden de nieuwsberichten en video’s van rabosport.nl getoond. De nieuwsberichten worden uit het RSS-kanaal met wielreninformatie gehaald. RSS-feeds voldoen aan de XML-standaard, waardoor de berichten makkelijk op de iPhone geparsed kunnen worden. Tijdens de Tour de France 2009 bleek echter wel dat sommige onderdelen van de feed zonder aankondiging kunnen veranderen: destijds schakelde de partij die rabosport.nl onderhoudt over naar een nieuw dateformat, met als gevolg dat onze applicatie crashte zodra de feed geparsed werd. In de nieuwste Cycling app worden deze variaties afgevangen, waardoor een nieuwsbericht eventueel niet getoond wordt, maar de app in ieder geval gebruikt kan worden.

De video’s worden uit een andere RSS-feed gehaald, direct van YouTube. Technisch is er daarom weinig verschil tussen het downloaden van nieuws en video’s, hoewel de inhoud van de twee feeds op verschillende manieren in de app getoond worden.

Evenementen

De kern van de applicatie draait natuurlijk om de verschillende soorten wielrenwedstrijden, welke wij samenvatten onder de noemer evenementen. Deze evenementen zijn in twee types te onderscheiden:

• De meerdaagse wedstijden, bestaande uit een aantal etappes. De bekendste hiervan zijn de Tour de France, de Giro d’Italia en de Vuelta a España.
• De eendagskoersen zoals de Waalse Pijl en Luik-Bastenaken-Luik.

Afgezien van de aanwezigheid van etappes behandelen we de twee types gelijk: ze bevatten klassementen, teams, renners en eventueel live-data. Om de bovenstaande types verder gelijk te trekken creëren we bovendien een ‘fictieve’ etappe bij de eendagskoersen, welke gebruikt wordt om de lengte en cols van de koers te tonen. In de afbeelding is het linker screenshot een voorbeeld van een evenement met meerdere etappes, het rechter screenshot een voorbeeld van een eendagsevenement.

Een evenement bevat dus klassementen, teams, renners en etappes. Deze verschillende objecten worden op de iPhone als entities opgeslagen in een Core Data-structuur. Naast de definitie van de entities – bijvoorbeeld dat een renner uit een id, naam, nationaliteit, foto en rugnummer bestaat – wordt in deze structuur ook de onderlinge samenhang van de objecten vastgelegd. In het schema hiernaast is deze samenhang versimpeld weergegeven.

Core Data kan vanaf MacOSX Tiger (10.4) gebruikt worden bij de ontwikkeling van applicaties voor Mac, sinds iPhoneOS 3.0 is het ook beschikbaar voor de iPhone. Core Data wordt door Apple beschreven als een “schema-driven object graph management and persistence framework”, wat zich laat vertalen tot een framework waarmee schematisch de verhoudingen tussen objecten vastgelegd en opgeslagen kunnen worden. Voor complexe applicaties als Rabo Cycling is dit framework een geweldige feature en de belangrijkste reden dat onze applicaties iPhoneOS 2.x niet meer ondersteunen. Het alternatief voor Core Data is om het opslaan van alle gedownloade data zelf te ontwerpen en onderhouden, wat uitermate complex en foutgevoelig is. In Rabo iTour (welke we ontwikkelden voordat iPhoneOS 3.0 uitkwam) was het cachen van gegevens in het filesystem van de iPhone de voornaamste reden van vastlopers en crashes.

Bestandsstructuur en versioning

In Rabo Cycling kunnen op een willekeurig moment 30 tot 40 evenementen getoond worden. Een groot deel van deze evenementen bevat lijsten met klassementen, renners en etappes. Vanwege deze grote hoeveelheid data konden we de gebruiker niet alle data in één keer laten downloaden, zoals bij Rabo Hockey wel kon. In plaats daarvan geven we in Rabo Cycling een lijst van evenementen weer en laten we de gebruiker kiezen welke hij hiervan wil downloaden.

De algemene informatie, klassementen, teams, etappes en live-data van een een evenement worden in verschillende bestanden op onze servers opgeslagen. Deze files verwijzen in een boomstructuur naar elkaar, beginnend met de overkoepelende events.json en eindigend met de klassementen, etappes en teams. In de bovenste laag – events.json – staat een lijst met beschikbare evenementen. Per evenement wordt in dit bestand enkel een id, de start- en einddatum en titel meegegeven, zodat deze informatie in de app getoond kan worden, ook als de gebruiker een evenement nog niet gedownload heeft.

Zodra een gebruiker een evenement selecteert wordt – op basis van het eventID – de juiste event.json gedownload. In deze file staat niet veel direct bruikbare informatie; er wordt enkel verwezen naar de standings, teams en stages van het evenement. De reden om deze verwijzingen in één file op te nemen zit in versioning – bij het genereren van iedere file wordt een versienummer opgeslagen, waarmee de app kan controleren of hij de gegevens in de file al heeft.

Bestandsgeneratie

Iedere vijf minuten wordt door de server gekeken of er nieuwe wielrengegevens beschikbaar zijn. Deze controle wordt gedaan door een vrij uitgebreid compare script dat de inhoud van bestaande JSON’s regel voor regel vergelijkt met de gegevens in de database. Indien er een verschil gevonden wordt zal  alleen de file die de verouderde data bevat vervangen worden, zodat de iPhone app enkel die data hoeft te downloaden. Ter illustratie: als er nieuwe uitslagen van een etappe in de Giro beschikbaar zijn, wordt dit door het compare script gevonden. Vervolgens wordt de betreffende etappe opnieuw gegenereerd en wordt het versienummer van de etappe in event.json opgehoogd. Daarna wordt ook het versienummer van de Giro in de overkoepelende events.json verhoogd, zodat de app weet dat hij de event.json opnieuw moet downloaden.

Alle sportinformatie – van hockey, de Olympische Spelen en wielrennen – wordt geleverd door Infostrada Sports. Zij kunnen hun gegevens in verschillende vormen leveren: als een iframe op een website, als uploads in XML-formaat of als database-replicatie. Tijdens de Tour de France 2009 hebben we met de XML-uploads gewerkt, maar hiermee bleken we geen optimale snelheid, betrouwbaarheid en flexibiliteit te kunnen garanderen. We hebben er daarom in december 2009 voor gekozen om een dedicated Microsoft SQL server in gebruik te nemen, waarmee we vrijwel realtime de live-updates naar de iPhone kunnen verzenden.

De MSSQL-database wordt dus continu gevuld en bijgewerkt door Infostrada. Naast deze server hebben we een uit de kluiten gewassen webserver geplaatst die de gegevens met PHP en SQL uitleest. Zoals eerder beschreven doen we dit periodiek: drie keer per minuut voor live, een keer per vijf minuten voor actuele evenementen en één keer per dag voor afgelopen evenementen. Ieder script wordt twee keer gestart: eerst om de files in het Nederlands te genereren, daarna om het nog een keer in het Engels te doen.

Tweetalige apps

Rabo Cycling, Rabo Hockey en Rabo Sport kunnen zowel in het Nederlands als in het Engels weergegeven worden, afhankelijk van de taal waarin de telefoon ingesteld is. Ook de sportdata wordt aan deze voorkeur aangepast: de Wereldkampioenschappen heten in het Engels vanzelfsprekend World Championships, het algemeen klassement heet general classification, enzovoorts.

We bereiken dit door van de telefoon de preferred language op te vragen en deze bij het downloaden van de JSON’s mee te sturen in de URL. De afkortingen die voor deze talen gebruikt worden voldoen echter niet aan een vaste structuur, zo kwamen we tot nu toe de volgende codes tegen: ‘ar’, ‘da’, ‘de’, ‘en’, ‘es’, ‘fi’, ‘fr’, ‘he’, ‘it’, ‘ja’, ‘ko’, ‘nb’, ‘nl’, ‘pl’, ‘pt’, ‘pt-PT’, ‘ro’, ‘ru’, ‘sk’, ‘sv’, ‘zh-Hans’ en ‘zh-Hant’. Om ervoor te zorgen dat alle niet-Nederlandstalige apparaten de Engelse JSON’s downloaden laten we een .htaccess script met regular expressions alle onbekende codes verwijzen naar de map met Engelse bestanden (image credit: xkcd.com).

Live

De live voortgang van de etappes heeft een aantal overeenkomsten met de ‘statische’ data in de app: het wordt geleverd door Infostrada, het komt van onze servers en het wordt periodiek gegenereerd. Het gebruikt echter geen versioning, omdat de gegevens in principe altijd out of date zijn. Ook ligt de frequentie van het genereren veel hoger; waar de statische data maximaal twaalf keer per uur gemaakt wordt, gebeurt dit drie keer per minuut voor de live data.

Er zijn drie verschillende soorten etappes in de wielersport: de wegrace, de individuele tijdrit (ITT) en de teamtijdrit (TTT). Deze drie types worden elk op een eigen manier getoond, maar we hebben de live JSON zo ontworpen dat alle gegevens via hetzelfde platform verzonden kunnen worden. Hiertoe kijken we bij het genereren van de live data naar het type van de etappe en voeren we op basis hiervan het juiste script uit. Aan de iPhone-kant wordt dezelfde afweging gemaakt.

We kunnen de verschillende soorten etappes via hetzelfde platform verzenden doordat de structuur van de data voor een groot deel overeen komt: in een wegrace rijden één of meer groepen met daarin renners, bij een ITT eindigen de renners achter elkaar, waarna ze in de groep ‘gefinishte renners’ geplaatst kunnen worden. Een TTT is vrijwel gelijk aan een ITT, alleen wordt de groep ‘gefinishte renners’ vervangen door de groep ‘gefinishte teams’.

Datacenter

Om de snelheid en betrouwbaarheid van de verbinding tussen onze servers en de rest van de wereld te garanderen huren we een 19″-rack in het datacenter van TransIP in Amsterdam. In dit datacenter zijn we verzekerd van een stabiele 100MBps internetlijn en redundante stroomvoorzieningen. Bovendien hebben we de mogelijkheid om snel servers bij te kunnen plaatsen, mocht dit nodig zijn.

Van 9 september tot 11 september hebben wij een paar dagen buiten onze normale habitat geleefd. We verlieten ons kantoor in Lunetten en trokken met tassen vol mac’s, monitoren, toetsenborden en muizen naar het verre Amsterdam, waar we ons drie dagen lang genesteld hebben op het kantoor van Booreiland.

Wie zijn Booreiland?

Booreiland is een designstudio in Amsterdam Noord met wortels in de wereld van geprinte media, ervaring in de wereld van webdesign en een liefde voor de koppeling tussen het web en de “echte” wereld. De drijvende krachten achter Booreiland zijn Menno en Wimer.

Booreiland ontwikkelt websites, huisstijlen en metaproducten (kruisbestuivingen tussen het web en fysieke producten). In deze producten gaan betrouwbaarheid en intuïtief gebruik hand in hand met onconventionele ontwerpen. Een geweldig voorbeeld hiervan is Okimok, hun op fotostreams gebaseerde sociale platform.

Hoe kennen wij Booreiland?

Een van de eerste dingen die we als Coding Dutchmen deden, was het geven van een presentatie over onze visie op branding en marketing door middel van iPhone apps. Deze presentatie hielden wij samen met Sense Studios op een bijeenkomst van 212Amsterdam, in Felix Meritis.

Een andere spreker op dit mini-congres was Menno Huisman van Booreiland. Hij sprak over Okimok, zijn blik op social networking en de kruising tussen de fysieke wereld en de digitale wereld.

Op de borrel na onze presentaties hebben we nog even staan praten met de jongens van Booreiland, en zo hebben we elkaar leren kennen.

Waarom zijn wij bij Booreiland?

Een paar maanden na onze presentaties bij 212 belde Booreiland ons op (we hebben tussendoor wel contact gehouden, maar niet intensief), met de vraag of we eens om tafel konden gaan zitten en te kijken of we aan een aantal projecten zouden kunnen samenwerken. Zij hadden namelijk wel een iPhone-product (Okimok), maar ondertussen geen iPhone-programmeur meer in huis, dus daar konden wij een gat vullen. Aan de andere kant kunnen wij regelmatig de diensten van designers als Booreiland gebruiken, dus leek het ons een briljant plan om de relatie tussen onze bedrijven wat aan te trekken.

Zo gezegd, zo gedaan, en eind juni zaten we met z’n drieën bij Booreiland aan tafel. We hebben het toen vooral over Okimok gehad, en tijdens dit gesprek kwam duidelijk naar voren dat wij graag mee wilden werken aan de verdere ontwikkeling van het platform. Het was echter midden in de zomer, dus concrete plannen stelden we even uit tot iedereen zijn vakantie had gehad. Aan het eind van de zomer hebben we een datum vastgesteld, en op 9 september was het zover: de kickoff van het eerste Okicamp!

Wat hebben we gedaan bij Booreiland?

We hebben hard gewerkt om Okimok te verbeteren! Met een volledig herschreven iPhone-app, nieuwe functies op de website en een gloednieuwe api hebben we een paar flinke stappen gezet in de groei van het platform. Niet alleen op de korte termijn, maar vooral met zicht op nog veel meer verbeteringen in het komende jaar. De nieuwe iPhone-app zal binnenkort te downloaden zijn op de App Store.

De paar dagen dat we bij Booreiland zaten hebben we het onwijs naar ons zin gehad en zijn we erachter gekomen dat Coding Dutchmen en Booreiland erg goed op elkaar aansluiten. Het waren maar drie dagen – in totaal 24 uur – maar de creativiteit en productiviteit die we samen genereerden maakten het tot een zeer lonende periode.

Op de gebieden van ontwikkeling, ontwerp en marketing, maar ook in humor, karakter en muzieksmaak hebben we een partner en geestverwant gevonden. We kijken uit naar de volgende Okicamp en naar alle andere projecten die we als Boring Dutchmen gaan bedenken, ontwikkelen en ontwerpen!

Het Okimok-team:

Van links naar rechts: Wimer Hazenberg, Jurjen Helmus, Okimok, Jasper Gremmen, Luc van Donkersgoed, Jeroen Faijdherbe, Bob Vork, Menno Huisman