Jorg Nieuws 25 mei 2009, 22:52

Leestijd: 7 minuten

iPhone-evolutie (en hoe voorkom je het Android-probleem)

Het Android systeem zal uiteindelijk gebruikt worden op tientallen verschillende telefoons, iets wat mogelijk voor ongemakken kan zorgen bij ontwikkelaars. Wat gebeurt er als Apple afwijkende iPhone-modellen wil introduceren? Kan het bedrijf dan baat hebben van de iPod nano?

Een van de redenen dat de iPhone zo goed werkt ligt in het feit dat, geheel in Apple-traditie, zowel de hardware als de software door dezelfde firma zijn ontwikkeld. Op die manier waren de hardware-engineers volledig op de hoogte van hoe de software zou werken, en wisten de software-engineers alle ins en outs van de hardware. Gezamenlijk konden zij er zo dus alles uithalen wat er in zat. Het was dan ook een beproefd recept. Kijk maar naar de Mac om te zien hoe een naadloos geintegreerd pakketje van hardware en software een boel problemen kan voorkomen die in de PC wereld zo gewoon zijn, waar alle combinaties van fabrikanten, types, versies en componenten leiden tot ontelbare hardwarecombinaties, die allemaal met dezelfde software moeten werken.

Naast voordelen voor de eindgebruiker is een geintegreerd hardware/software platform ook ideaal voor ontwikkelaars. Precies weten op welk apparaat jouw software wordt gebruikt geeft een ontwikkelaar veel van dezelfde voordelen: hij of zij kan het maximale uit de hardware halen zonder het risico te lopen dat iets niet, of niet hetzelfde, werkt op een ander type apparaat. Je kent de eigenschappen van het appraat en hoeft niet te raden welke features er mogelijkerwijs aanwezig zijn, of erger nog: welke er ontbreken en hoe je met zulke gevallen om moet gaan.

Ontwikkelen voor Android

Laten we eens een kijkje nemen bij het Android platform. Android is een goed ontworpen besturingssysteem, gebaseerd op een robuuste en capabele Linux kernel. Tot zo ver niets aan de hand. Echter, in tegenstelling tot de iPhone is Adroid geen gecombineerd hardware/software platform. Het is een software platform dat door een fabrikant van telefoontoestellen kan worden toegepast. En in tegenstelling tot de iPhone zijn alle fabrikanten van Android-telefoons elkaars directe concurrenten. Dat betekent dat zij, omwille van hun concurrentiepositie, hun toestellen van elkaar moeten onderscheiden. Dit zal snel leiden tot verschillende Adroid-modellen, met en zonder toetsenbord, met en zonder multi-touch capacitieve touchscreens, met verschillende schermafmetingen en verschillende beeldschermresoluties.

Dit maakt het ontwikkelen voor Android veel ingewikkelder. Je zult namelijk met al deze verschillende hardware configuraties rekening moeten houden. En heel waarschijnlijk houdt het in dat huidige software voor toekomstige modellen drastisch moet worden aangepast. Laten we als voorbeeld eens het toetsenbord nemen. De eerste Android telefoon, de HTC G1, heeft een uitschuifbaar hardware toetsenbord, en tot aan de komst van de laatste Android-software (1.5 Cupcake) was er geen on-screen keyboard. Als er een Android-telefoon zou komen zonder fysiek toetsenbord, dan zou er een on-screen toetsenbord moeten worden gebruikt. Maar applicaties die uitgingen van de specificaties van de G1 hielden hier geen rekening mee, en hebben dus ook geen plek voor een toetsenbord ingeruimd in de user interface.

De zaken worden nog complexer als er toestellen op de markt komen met verschillende schermafmetingen en pixelresoluties. Sommige applicaties passen dan niet meer zondermeer op het scherm. Wanneer je de pixelresolutie gelijk zou houden maar het scherm zou verkleinen, dan worden de schermelementen voor gebruikershandelingen te klein.

Ik ga ervan uit dat Google hier een oplossing voor gaat bieden in de SDK, maar hoe dan ook: een ontwikkelaar moet vanaf dat moment rekening houden met alle mogelijke toesteluitvoeringen. Een simpele oplossing zou zijn dat je alleen nog maar ontwikkelt voor een beperkte, maar universeel aanwezige feature-set, maar dat resulteert in programma’s die niet maximaal gebruik maken van de mogelijkheden van de hardware. Vergelijk dit maar met de universele Java “games” die op vrijwel alle eenvoudige telefoons te gebruiken zijn. Het is geen toeval dat de Android SDK is gebaseerd op Java, want hiermee kun je gemakkelijk programmeercode porten tussen platforms zonder vast te zitten aan een bepaalde processor-architectuur of hardware capaciteiten.

Verschillende iPhone-modellen

Zoals gezegd spelen deze zaken momenteel niet bij de iPhone. Zowel de originele iPhone als de iPhone 3G zijn gebaseerd op hetzelfde hardware/software platform, en naar verwachting zal het aanstaande nieuwe iPhone-model dat deze zomer verschijnt hier niet of nauwelijks van afwijken. Op dit moment is er dus nog niets aan de hand. De vraag is: Wat gebeurt er als Apple zijn iPhone productlijn wat meer wil differentiëren? En dan vooral wanneer Apple een versie met een kleiner scherm zou willen maken, bijvoorbeeld in een “candy bar” of “clam shell” uitvoering. Dit zou de huidige beeldscherm-afmeting/pixel-resolutie verhouding doorbreken, en resulteren in dezelfde problemen als hierboven genoemd.

Sommige mensen zullen stellen dat Apple nooit het huidige iPhone-platform zal “breken” door andere formfactors te introduceren, omdat Apple niet geinteresseerd zou zijn in dit segment van de markt (vergelijkbaar met de Mac, waar Apple ook geen speler is in het budget- tot mid-price segment). Ik denk echter dat Apple een andere strategie voor ogen heeft met de iPhone. Niet alleen is de markt voor mobiele telefoons vele malen groter dan die voor personal computers, maar het is ook veel eenvoudiger om een nieuw platform te lanceren op dit moment in vergelijking met de computermarkt, die immers al veel meer is uitgekristalliseerd. Nieuwe iPhone formfactors zijn in dat licht bezien dus een logische stap, en misschien beter vergelijkbaar met de iPod, waar Apple een product heeft in elk prijs-segment, oplopend van de goodkoopste Shuffle, tot de iPod touch van ruim 400 euro.

Vroeg of laat zal ook Apple tegen dit probleem aanlopen: bestaande software werkt niet (goed) op andere ontwerpen. Ervan uitgaande dat het ook bijr deze nieuwe, kleinere iPhones mogelijk zal zijn om er software voor te ontwikkelen, zal Apple de mogelijkheden hiertoe moeten opnemen in de ontwikkel SDK. Apple heeft echter een groot voordeel tenopzichte van “open” platforms als Android: het kan het aantal hardware-varianten beperken.

iPhone- en iPod nano-platform combineren

En ik denk dat ze dit op een slimme manier kunnen doen. Als we aannemen dat de opvolger van de huidige iPod nano ook gebaseerd zal zijn op OS X (zoals de iPhone en iPod touch), waarom zou je het platform voor dit apparaat dat niet samenvoegen met die van een kleinere iPhone? Het beeldscherm van een kleine iPhone zal qua afmetingen immers ongeveer gelijk zijn aan dat van de iPod nano. Net zoals de iPod touch ervoor zorgt dat de doelgroep voor iPhone-applicaties veel groter is, zou hetzelfde kunnen gebruiken met een enkel platform voor iPod nano en kleine iPhone.

Natuurlijk moet Apple dan nog steeds bedenken of zo’n apparaat met een klein scherm nog steeds bediend moet worden met een touchscreen, en of de beroemde click-wheel moet blijven bestaan en misschien op een of andere manier mee kan worden genomen naar die nieuwe iPhone. Maar als de belangrijkste kenmerken, zoals beeldverhouding, resolutie, invoermethodes en hardwareplatform hetzelfde blijven, vergroot Apple het bereik van het nieuwe iPhone-platform aanzienlijk.

Ik denk dat twee configuraties nog wel behapbaar zijn voor ontwikkelaars, helemaal als Apple de grondvesten van beide platforms hetzelfde houdt als in de huidige iPhone. Bovendien is het zo dat beide platforms waarschijnlijk ieder een ander publiek bedienen, met mogelijk andere behoeftes en verwachtingen van applicaties. Dit is een aanzienlijk betere uitganssituatie dan het vooruitzicht op tientallen verschillende hardwareconfiguraties, zoals momenteel het geval is bij Android.

Steve Jobs maakte een interessante opmerking tijdens de telefonische toelichting op de kwartaalcijfers op 21 november vorig jaar: “As software becomes the differentiating technology of this product category, people find that a hundred [hardware] variations presented to software developers is not very enticing, and most companies in this phone business do not have much experience in a software platform business. So we’re extremely comfortable with our product strategy going forward, and we approach it as a software platform company, which is pretty different than most of our competition.”

Voor de duidelijkheid, ik verwacht niet op korte termijn een kleinere iPhone, noch een op OS X gebaseeerde iPod. Maar ik zou er niet van opkijken als we volgend jaar tijdens de WWDC getuigen zijn van de introductie van het nieuwe platform. En wie weet, zien we dan niet alleen een kleine versie, maar ook een grote broer verschijnen in de vorm van een langverwachte tablet.