Zwischen Multitasking und iPad ging zunächst die knackigste Meldung zum Thema Phone OS 4.0 unter: dass Apple die Lizenzbedingungen in der Art ändert, dass Anwendungen in nativem "Objective-C, C/C++ oder JavaScript wie von WebKit ausgeführt" entwickelt sein müssen und dass jedwede Zwischenschicht verboten ist: "Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited".

Damit haben sie Blut ins Haifischbecken gekippt, das Web fing an zu toben. Völlig zu Recht, denn man muss sich die Bedeutung der Änderung vor Augen halten. Es ist verboten, eine Anwendung in beispielsweise Java zu programmieren und sie durch ein automatisiertes Verfahren in Objective-C zu übersetzen. Ein Analogon für dieses Vorgehen wäre Google Web Toolkit - GWT erlaubt es dem Programmierer, in Java zu entwickeln und in JavaScript zu übersetzen. Die Gründe für dieses Verfahren liegen auf der Hand - JavaScript ist recht grottig für grössere Programme, man nutzt die stärkere Sprache und ihre Vorteile.

Dass Apple dies verbietet, sagt für mich viel über die Qualität der Entwicklungsumgebungen von Apple aus und über den Alltag von iPhone-Entwicklung, denn etwas, das nicht gemacht wird, muss man nicht verbieten und es würde auch kein Entsetzen erzeugen. Ich vermute mal, dass sich die Entwicklerschaft geteilt hat: ein Teil hat nicht Objective-C, sondern Frameworks in anderen Sprachen verwendet, weil sie eine systemnahe Sprache wie Objective-C nicht sonderlich zugänglich finden. Das dürfte für die kleineren Anwendungen wie den xten Bejewelled-Klon zutreffen.
Der andere Teil sind grosse Firmen, die einerseits sehr viel Know-How und Bibliotheken in anderen Sprachen haben und die sich andererseits nicht festlegen wollen auf die Plattform iPhone. Es ergibt einfach keinen Sinn, grössere Summen in Apple Computer und Objective-C zu investieren, wenn man danach für eine immer noch relative Nische (vom iPhone abgesehen) programmiert. Es wurden in den vergangenen 15 Jahren grosse Anstrengungen hin zu plattformunabhängiger Programmierung unternommen und jetzt soll alles wieder von vorne losgehen.

Grundsätzlich ist Apples Strategie verständlich:
1. Apple will seine Plattform als solches fördern, in der Hoffnung, dass mehr Macs verkauft und eine breitere Basis für Objective-C-Entwickler entsteht, die dann exklusive Anwendungen für iPhone, iPad und OS X programmieren. Mit Abstraktionsschichten ist das iPhone halt nur eine Plattform unter vielen.
2. man will nicht auf etablierte Frameworks Rücksicht nehmen müssen. Das hat in der Vergangenheit immer wieder zu Problemen geführt, zugegeben - ein Hersteller ändert ein bestimmtes Feature ab und zieht danach den Zorn irgendeiner Gemeinde auf sich, weil etwas nicht mehr so funktioniert, wie sie es erwartet.

Andererseits ist sie auch recht riskant. Apple schlägt einerseits recht klar Adobe ins Gesicht, die mit der heute erscheinenden CS5 genau ein solches Framework mitliefert. Es ist schon extrem deutlich, wenn man einem langjährigen Partner am Freitag vorher ein Feature kaputt macht. Andererseits ist das Marktumfeld noch bei weitem nicht abgesichert genug für Apple, als dass sie sich derlei Spielchen gefahrlos erlauben könnten. Vor allem denke ich, dass sie gewaltig die Möglichkeit der Entwickler überschätzen, ihrer Vorstellung überhaupt Folge zu leisten. Denn wie gesagt, es gibt die einfacheren Entwickler, die eher den kreativ-bunten Teil der Apps erzeugen - diese Leute sind schlicht weder willens noch in der Lage, sich mit vielen Klammern und einer hardwarenahen Sprache auseinanderzusetzen. Damit möchte ich sie nicht abwerten, aber es wird nicht ohne Grund sein, dass relativ systemferne Ansätze wie Flash im letzten Jahrzehnt einen steilen Aufstieg hatten.
Professionelle Firmen hingegen sitzen auf Unmengen an bewährtem Code, den sie nicht gerne portieren werden auf eine Plattform, für die sie im Grunde gar nichts haben - keine Entwickler, keine Maschinen, keine Prozesse, keine Erfahrung. Und wenn wir über z. B. Navigationssysteme reden, eine der Killerapplikationen für mobile Plattformen, dann reden wir über hübsche Dinge wie "Algorithmen zur Kantengewichtung in azyklischen Graphen", die man auch nicht mal eben an einem Wochenende neu schreibt.

Letztendlich gehe ich sogar soweit, Apple in diesem Bereich die nötige Kompetenz abzusprechen. Abstraktionsschichten gehören zum Alltag des Programmierers wie Schleifen, Verzweigungen und Bedingungen. Ich habe mir beispielsweise mal eine objektorientierte Abstraktionsschicht für die GD-Bibliothek in PHP geschrieben. Oder eine Erweiterung für PDO, die es mir dann auch ermöglicht hat, recht einfach ein "falsches" PDO auf Grundlage der mysql-Funktionen zu programmieren, als ein Kunde kein PDO auf seinem Webspace hatte. Abstraktionsschichten sind im heutigen Programmieralltag schlichtweg eine Notwendigkeit geworden. Sicherlich wird oft übertrieben und man hat am Ende gefühlte 10.000 Schichten, die alle Performance kosten, das ändert aber nichts daran, dass Abstraktion an sich notwendig ist.

Nun noch ein Kommentar zu all jenen, die meinen, man müsse es ja nicht kaufen und nicht dafür entwickeln. Richtig, tue ich nicht, aus gutem Grund. Insofern könnte es mir egal sein. Es ist aber dennoch richtig, seinen Unmut darüber kundzutun, denn was Firmen tun, wird von anderen Firmen beobachtet. Und ich habe wenig Lust, dass sich dieser Ansatz weiter durchsetzt und wir irgendwann an den Punkt kommen, an dem erst mal ordentlich Kohle fällig ist und die Zustimmung zu Knebelverträgen, bevor man auch nur eine Zeile Code schreiben kann. Eine derartige Welt kann nicht im Interesse der Nutzer und Programmierer sein, insofern ist es richtig und wichtig, mit in den Aufschrei einzustimmen.

Kommentieren

Bitte beachten: Kommentare sind nicht sofort sichtbar, sondern werden erst nach einer kurzen Prüfung freigegeben, sofern keine rechtliche Beanstandung vorliegt.
Rechtlich bedenkliche Inhalte werden entweder entschärft oder nicht veröffentlicht.