iPhone OS 4.0: Apple untersagt Nutzung von Crosscompilern, auch von Adobe Flash

Eine kleine Änderung im iPhone OS 4.0 SDK könnte für Adobes Packager für iPhone OS das Ende bedeuten: Anwendungen, die mit Crosscompilern erstellt wurden, sind laut den Nutzungsbestimmungen des SDK ab sofort verboten.

Mit dem Packager for iPhone hatte Adobe Ende letzten Jahres ein Tool für die Creative Suite 5 angekündigt, das es möglich macht, aus Flash-Anwendungen native iPhone-Apps herzustellen. Dies sollte den Flash-Entwicklern zu Gute kommen, die ihre Anwendungen auf diese Weise direkt für mehrere Plattformen bereitstellen können. Apple aber sieht Frameworks dieser Art nicht so gerne:

Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Apple

Adobe ist sich diesem Problem bewusst, wird vorerst aber nichts am Tool ändern. Den Entwicklern allerdings stinkt Apples Vorgehen ganz gewaltig. Da wäre zum einen Lee Brimelow, seines Zeichens „Plattform-Evangelist“ bei Adobe, der Apples Entscheidung als „Schlag ins Gesicht der Entwickler“ bezeichnet. „Was sie sagen ist, dass sie Anwendungen nicht auf ihrem Marketplace zulassen, nur weil sie auf einer bestimmten Sprache basieren. Es ist ein beunruhigender Schritt, der keine rationale Grundlage hat außer der tyrannischen Kontrolle der Entwickler – und was noch viel wichtiger ist: Der Nutzung der Entwickler als Bauernopfer im Kampf gegen Adobe.“ Brimelow wird Apples Produkte boykottieren, „bis es einen Führungswechsel gibt“.

Auch der Entwickler Greg Slepak wollte sich mit der Situation nicht zufrieden geben: In einer Mail an Steve Jobs fragte er nach den Beweggründen für das Verbot der Nutzung von Cross-Compilern. Als Antwort bekam er den Hinweis, sich John Grubers Aussagen zum Verbot einmal genauer anzuschauen. Dieser stellte heraus, dass die Gründe für die Ablehnung auch mit einem möglichen Kontrollverlust zu tun hat: Will man einen für alle gültigen Standard umsetzen, muss man Konkurrenzangebote wie Flash oder auch .NET außen vor halten.

Nimmt man mal den Fall, ein Entwickler würde eine Anwendung erstellen, die man mittels Crosscompiler auch auf andere Mobiltelefone bringen kann, gibt es keine Alleinstellungsmerkmal mehr und die Kunden haben keinen Grund, tatsächlich ein iPhone zu kaufen. Außerdem sind die Meta-Plattformen nicht in Apples Kontrollbereich. Wenn Apple eine neue Version seines iPhone OS mit neuen Funktionen veröffentlicht, müssen die Crosscompiler erst umgeschrieben werden. Dritthersteller müssen dann entsprechend lange warten, bis sie von den neuen Funktionen ebenfalls Gebrauch machen können. Die meisten Apps, die mit den Cross-Platform-Tools erstellt werden, sind laut Jobs zudem meistens qualitativ nicht besonders hochwertig, gerade im Fall von Flash könnte es zu einem Überschuss von wenig funktionalen Anwendungen sorgen (Beispiel: Baukasten-Apps).

Einen weiteren Grund führt der AppleInsider aus: Möglicherweise hängt der Schritt mit der gerade erst von Apple bekannt gegebenen Funktion des Multitasking im iPhone OS zusammen. Dafür sind recht umfangreiche neue APIs erforderlich. Das System selbst soll die Anwendungen verarbeiten und damit ein „Smart Multitasking“ bereitstellen.

Das Problem bei der Nutzung von Crosscompilern und der Nutzung von Runtimes: Der so entstandene Code verhält sich nicht so wie eine native C/C++/Objective-C-App. Somit kann sich das System nicht auf die Anwendung einstellen, andere Prozesse können nicht so einfach angehalten werden. Apple benötigt den Zugriff auf normal kompilierte Anwendungen, um alle Funktionen des neuen Systems anständig ans Laufen zu bekommen.

Mit der neuen Bestimmung schießt Apple nicht exklusiv nur auf Adobe, sondern auch auf Frameworks wie NimbleKit, oder MonoTouch, mit Hilfe dessen sich .NET-Anwendungen auf das iPhone portieren lassen. Die Anwendungen, die mit den jeweiligen Toolkits portiert werden, sind von außen nicht als Portierungen erkennbar. Alle nutzen sie Apples UIKit, nur der hinter der App steckende Code ist eben nicht mit Apples eigenen Entwicklertools erstellt worden. Und genau das wird ihnen jetzt zum Verhängnis. Apple kann die Regeln seines eigenen SDK selbstverständlich selbst bestimmen, und es es gibt durchaus einige nachvollziehbare Gründe, den externen Frameworks den Laufpass zu erteilen.

Apple sorgt mit den Beschränkungen unter anderem dafür, dass das Nutzungsgefühl nicht leidet: Sind die Apps nicht durchweg alle in der Lage, bestimmte Systembedingungen zu unterstützen, schadet dies dem Nutzer, unter anderem in Form niedriger Akkulaufzeiten und schlechter Userexperience. Mit Apples eigenen Tools wird eine maximale Performance sichergestellt – und das ist auch gut so. Apple hat als „Gatekeeper“ das gute Recht, zu entscheiden, was zugelassen ist und was nicht – wenn manche Entscheidungen mitunter auch unsinnig wirken.

Das gilt auch für die Entscheidung, Flash nicht auf iPhone, iPod touch und iPad haben zu wollen. Adobe wehrte sich in einer Beschwerde bei der US-Börsenaufsicht SEC gerade erst erneut vehement gegen die „Bedrohung durch iPhone und iPad“ und sieht seine Geschäfte in Gefahr.

Abgesehen von den systeminternen Gründen sind MonoTouch und Co meist recht simpel gestrickt und bieten für die damit entstehenden Apps keine echten Mehrwerte. Die Folge, die man bereits jetzt im App Store sieht: Eine Überschwemmung mit Anwendungen, die wenige Funktionen beinhalten.

Ähnliche Nachrichten