Mythen der iPhone-Entwicklung

Die richtige Hardware
Entwickler benötigen für ein iPhone-Spiel Intel-basierte Mac OSX Rechner mit OSX 10.5+. Ich empfehle allerdings OSX 10.6/Snow Leopard, da allein der »Static Analyzer« die minimalen Upgradekosten wert ist. Entscheidend sind auch die Varianten der iPhone-/iPod-Hardware. In der Apple Knowledge Base finden Sie Informationen zu den jeweiligen Plattformunterschieden (siehe Kasten »Nützliche Links«). Hier eine kurze Aufstellung:


iPod Touch

• Erste Generation: Prozessor und Speicher identisch mit iPhone und iPhone 3G
• Zweite Generation: Prozessor schneller als iPhone und iPhone 3G, Speicher identisch mit iPhone und iPhone 3G
• Dritte Generation / Ende 2009: Prozessor und Speicher identisch mit iPhone 3GS, 3D-Grafikchip identisch mit iPhone 3GS

iPhone

• iPhone: langsamster Prozessor und geringster Speicher
• iPhone 3G: identischer Prozessor und Speicher wie iPhone
• iPhone 3GS: Schnellerer Prozessor und mehr Speicher, besserer Grafikchip

Für das Performance-Testing eignen sich die erste Generation des iPod Touch, das iPhone sowie das iPhone 3G gleichermaßen gut. Die zweite Generation des iPod Touch hat einen minimal schnelleren Prozessor, darüber sollten Sie sich bewusst sein, wenn Sie mit ihm testen. Das iPhone 3GS sowie die dritte Generation des Touch stehen auf derselben Stufe und sind signifikant schneller als die anderen Geräte. Sie werden zudem mit zusätzlichen 128 MB Speicher ausgeliefert.
Obwohl es sehr verlockend sein mag, auf der stärksten Plattform zu entwickeln, ist dies eine schlechte Idee. Das iPhone 3G ist im Handel weiterhin im Neuzustand erhältlich und der noch verfügbare iPod Touch mit dem geringsten Speicher gehört der zweiten Generation an. Zielt Ihr Spiel allein auf die neuesten Plattformen ab, schließen Sie damit auch die mehr als 50 Millionen bereits gekauften Geräte aus. 
Sie sollten auch darauf achten, sich nicht nur auf das iPhone zu konzentrieren und Kunden des iPod Touch auszuschließen -- dies gilt natürlich nur, falls Ihr Spiel keine iPhone-spezifische Funktion voraussetzt. Es ist wichtig zu wissen, dass der iPod Touch einen signifikanten Anteil am Markt hält, er macht in etwa die Hälfte der verfügbaren Hardware für Ihr Spiel aus. Je nach App können iPod Touch-Nutzer rund 75% der Spielerschaft ausmachen (Abbildung 2).

Programmierung
Das iPhone SDK von Apple ist dafür ausgelegt, dass Entwickler Xcode nutzen, Apples Compiler und Programmier Toolset. Es ist zwar auch möglich, die Verwendung von Xcode zu vermeiden, darauf einzugehen würde aber den Rahmen dieses Artikels sprengen. 
Die meisten iPhone-Beispiele von Apple und anderen Quellen sind in »Objective-C« geschrieben, einem Erweiterungsset der C-Sprache, basierend auf »Smalltalk«. Möchten Sie also Objective-C lernen, finden Sie Code-Beispiele oder Tutorials direkt bei Apple. Und da Objective-C eine Erweiterung von C ist, können Sie C-Code auch einfach in denselben Source Files und sogar Funktionen schreiben.
Die Xcode-Umgebung geht auch relativ problemlos mit C++ um, obwohl dies nicht ganz so einfach funktioniert wie einfaches C. Hinzu kommt, dass es sehr viel weniger Beispiele zu C++ gibt, von denen Sie lernen könnten.
Der beim SDK mitgelieferte iPhone Simulator ist extrem nützlich für die Entwicklung (Abbildung 3). Er emuliert die meisten Aspekte des iPhone-Betriebssystems nahezu perfekt. In den letzten 18 Monaten habe ich nur äußerst selten erlebt, dass der Simulator etwas anders verarbeitet hat als die »eigentliche« Hardware, mal abgesehen von spezifischen Einschränkungen. So basieren Prozessorgeschwindigkeit und Speicher des Simulators auf dem jeweiligen Rechner, auf dem er läuft. Daher ist er für Performance-Tests nutzlos. Zudem fehlt im Simulator eine Eingabemöglichkeit für den Beschleunigungssensor -- einige 3rd-Party Bibliotheken versuchen sich aber an einer Lösung dieses Problems.
Ebenfalls problematisch ist die Multi-Touch-Fähigkeit des Simulators, so werden etwa nur zwei Berührungen gleichzeitig als Eingabe zugelassen. Für die meisten Funktionalitäten und die Kernlogik Ihres Spiels wird der Simulator aber mit der Hardware des Endkunden identische Ergebnisse liefern, Deploy- und Testzeiten fallen gegenüber »echter« Hardware signifikant kürzer aus.
Unterm Strich bietet der Simulator äußerst kurze Review- und Testzeiten, mit nur geringem Risiko von Inkompatibilitäten der eigentlichen Hardware.