Konstantin Filtschew WebLog

Der tägliche IT-Wahnsinn

Apples Entscheidung über das Ausschließen von intermediate languages technisch-rational betrachtet

Als erstes weise ich ganz klar darauf hin, dass ich weder bei Apple arbeite, noch Apple mich bezahlt, ich “Apple verrückt” bin oder mit Apple in Beziehung stehe. Ich versuche lediglich die Entscheidung von Apple bezüglich “intermediate languages” aus der technisch-rationalen Sicht zu betrachten.  Alle meine Überlegungen könnten total falsch sein, aber ich finde die Betrachtung von der anderen Seite durchaus wichtig.  Vor allem finde ich es sehr schade, dass kaum jemand die Entscheidung von Apple aus der anderen Sicht beleuchtet, sondern sich alle sofort über die neuen Regeln beschweren.

Dieser Blogeintrag handelt von dem folgenden Absatz aus den AGBs von dem Apple SDK für Iphone OS 4.0:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. 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).

Ich übersetze die wichtigsten Stellen frei ins Deutsche (keine Garantie für Richtigkeit): “Anwendungen dürfen nur  die dokumentierten APIs verwenden, wie es von Apple angedacht war und dürfen keine privaten APIs benutzen. Nur mit C, C++ und Objective-C  erstellte und gegen die dokumentierte APIs von Apple kompilierte Anwendungen sind zugelassen. Alle zwischenkompilierten Anwendungen, Kompatibilitätslayer oder Werkzeuge, die nicht direkt auf die dokumentierten APIs von Apple zugreifen, sind verboten und damit erstellte Programme werden nicht in den Apple Apps Store zugelassen”.

Diese Entscheidung hat erhebliche Auswirkungen für Entwickler, die nicht direkt für Apples Plattform gegen Apples dokumentierten APIs entwickeln. Vor allem wird diese Entscheidung auf  Adobes Flash CS5 zielen, das genau diese Möglichkeit für Flash Programme bietet. Mit der Adobe Flash CS5 soll es möglich sein, Flash-Anwendungen in Apples iPhone und iPad Anwendungen “umzuwandeln”. Ich möchte jetzt nicht auf Adobe, die Flash Technologie und den Krieg zwischen Adobe und Apple eingehen. Gründe für die Entscheidung gegen Flash habe ich bereits in einem älteren Artikel rational betrachtet: Fehlendes Multitasking und Flash sind ein missverstandenes Feature auf dem IPad!

Wir stellen uns jetzt mal vor, Apple würde die Entscheidung gegen “intermediate languages” nicht treffen und Adobes Flash CS5 erscheint auf dem Markt. Das wird vermutlich dazu führen, dass viele Entwickler ihre in Flash erstellten Programme mit den neuen Werkzeugen von Adobe in iPhone, iPod und iPod Anwendungen “umwandeln”. Dadurch wären jetzt viele Flash Anwendungen für den Apple Apps Store verfügbar.

Jetzt stellen wir uns mal vor, das wären 3 Millionen Anwendungen, die von Flash auf Apples Plattform umgewandelt werden. Diese Zahl habe ich jetzt mal frei aus der Luft gegriffen und das ist eigentlich nicht so wichtig. Wir können davon ausgehen, dass es nicht wenige Anwendungen sein werden und vermutlich Millionen wären. Vor allem werden viele Flash Spiele auf das iPhone und das iPad auf diese Weise portiert. Das könnte von der einen Seite Apple ganz gut gefallen. Steve Jobs könnte dann sagen: “Hey Google, wir hatten gestern 180.000 Anwendungen in unserem Apps Store und Heute haben wir 3.180.000. Versucht das mal mit Android aufzuholen!” Aber Apple hat sich anders entschieden und dafür habe ich versucht in den folgenden Absätzen rationale Gründe zu finden.

Ich möchte jetzt die 3 Millionen einfach auf andere Technologie “umgebogenen” Anwendungen betrachten, wenn auch nicht alle Aussagen für alle Anwendungen stimmen müssen. Fast alle alten Flash-Anwendungen wurden für die Mausbedienung entwickelt. Das führt dazu, dass die Schaltflächen (Knöpfe, etc.) in den Anwendungen nicht für Fingerbedienung ausgelegt sind. Dadurch werden kleine Elemente in den Anwendungen mit dem Finger nur mühsam oder kaum bedienbar sein. Alle mit Tastatur gesteuerten Anwendungen (z.B. Spiele) müssten auf dem Bildschirm ein visuelles Steuerkreuz oder was Ähnliches erhalten, mit dem die Anwendungen gesteuert werden. Ich gehe eigentlich 100%ig davon aus, dass diese Anwendungen sehr schlecht per Finger zu bedienen sein werden und nicht den Erwartungen der Nutzer für per Finger bedienbaren Geräte entsprechen werden. Dadurch erhält zwar Apple 3 Millionen zusätzliche Anwendungen in dem Apple Apps Store, aber sie werden den Wünschen und den Konzepten dieser Geräte auf keinen Fall gerecht werden. Ich rede hier ganz klar von Anwendungen, die nicht an die Konzepte der neuen Technologie angepasst wurden und nicht von neu entwickelten Anwendungen in “intermediate languages” für Apples Plattform. Eine Möglichkeit andere Programmiersprachen für neue Anwendungen zu nutzen sehe ich als sehr sinnvoll und benutze sie selber für die Java Virtual Machine (JVM).

Siehe auch das folgende Beispiel im Youtube Video (ein gutes Beispiel für Neukonzipierung):

oder Farmville direkt über Flash auf dem Nexus One (ich nenne es “Scrollmeisterschaft”):

Jetzt betrachten wir das Einreichen der 3 Millionen Anwendungen für die Anwendungsprüfer bei Apple. Auf ein Mal müssen zusätzliche Millionen von eingereichten Anwendungen untersucht werden. Das wird vermutlich dazu führen, dass Apple zusätzliche Kapazitäten für das Prüfen der Anwendungen aufbringen muss. Bei der Anzahl der Anwendungen inklusive der erneuten Einreichungen und Updates werden dafür Personal und Kosten notwendig sein. Das ganze wird notwendig sein, um die Flut meist ungeeigneter, von Flash umgewandelter Anwendungen abzuwehren. Von ungeeignet rede ich immer von Anwendungen, die nicht für die Bedienung über ein berührungsempfindlichen Bildschrim für das bestimmte Gerät entwickelt wurden.

Wer mir an dieser Stelle nicht glaubt, dass Anwendungen für spezielle Geräte angepasst oder neu entwickelt werden müssen, der möge die geschichtliche Entwicklung des Microsoft Tablet-PC anschauen. Der Hauptgrund für das Scheitern war der fehlende Wunsch die Software (in dem Fall MS Windows und MS Office) für die neuen Geräte und Bedienkonzepte anzupassen. Der Artikel bei Techcrunch beschreibt es sehr gut: Lost: If Microsofties Can’t Live Together, Microsoft May Die Alone.

Viele Entwickler schreiben ihre Anwendungen, die ehemals für das iPhone entwickelt wurden, für das Apple iPad neu. Das hat vor allem mit dem größeren Bildschirm und sich dadurch ergebenden neuen Möglichkeiten der Interaktion mit dem Benutzer zu tun. Natürlich werden auch die iPhone Programme auf dem iPad funktionieren, aber sie werden die Möglichkeiten des größeren Bildschirms, der höheren Auflösung und sich dadurch ergebenden Möglichkeiten der Interaktion nicht nutzen können. Das können wir auch aus der PC-Technologie ableiten. Wer schon mal einen Mac und einen PC benutzt hat, wird vermutlich erkennen, dass die Bedienkonzepte trotz der Tastatur, Maus und des fast gleichen Bildschirms sich deutlich zwischen Microsoft und Apple unterscheiden. Viele für den Apple Mac entwickelten Programme wurden an die Bedienkonzepte des Macs angepasst, was man leider von vielen Windows Anwendungen nicht behaupten kann. Auf der MS Windows Plattform herrscht ein buntes Durcheinander an Bedienkonzepten und Aussehen der Anwendungen. Im Endeffekt ärgern sich die Benutzer, dass sich die Software nicht “Windows gewohnt” bedienen lässt. Dadurch sinkt der Gesamteindruck für die ganze MS Windows Plattform und das will Apple auf gar keinen Fall für ihre gelobten Geräte. Die Apps für das IPhone und IPad sind genau die Bereicherung für die Benutzer auf Basis sehr gut von Apple abgestimmter Technologie, API und Bedienung der iPods, iPhones und jetzt iPads.

Ich fasse das noch einmal zusammen. Die Überflutung des Apples Apps Store mit schlecht bedienbaren Anwendungen, wird den  Gesamteindruck Apples Plattform trüben. Der Aufwand für die Prüfung der Applikationen wird vermutlich immens steigen und die Benutzer werden sich ärgern, dass sie die Anwendungen schlecht bis gar nicht bedienen können. Das wird Einfluss auf die iPhone, iPod und iPad Plattformen und den bis jetzt sehr positiven Eindruck haben. Der negative Eindruck wird sich vermutlich auch auf die Verkaufszahlen auswirken. ENDE!

Ich gehe davon aus, dass ich durchaus viele negative Kommentare zu diesem Blogeintrag bekomme. Ich werde sie alle freischalten, so lange sie auf sachlichen Aussagen basieren. Mit diesem Artikel wollte ich einen Blick aus einer anderen Sicht auf das Thema zeigen und ich hoffe, dass es mir gelungen ist. Ich betrachte die Entscheidung von Apple, “intermediate languages” auszuschließen, neutral und möchte mich weder Apples Entscheidung, noch den Gegnern anschließen. Meine Überlegungen könnten total falsch sein, aber sie könnten auch genau die Gründe für diese Entscheidung von Apple treffen. Nicht ohne Grund habe ich mich auf Adobe und die Flash Technologie bezogen, weil die Entscheidung von Apple aus rationalen oder politischen Gründen vermutlich auf das Erscheinen Adobes Flash CS5 und dessen Fähigkeiten Apple Apps zu erzeugen, bezog. Ich bin auch kein Gegner von Adobe, aber das Thema zielt ziemlich sicher auf Adobe ab.

Weitere konstruktive Berichte zu dem Thema:

3 Reaktionen zu “Apples Entscheidung über das Ausschließen von intermediate languages technisch-rational betrachtet”

  1. Anonymous

    Guten Morgen Herr Flitschew,

    Heute früh zum Kaffee stolperte ich über Ihren Aufsatz “Apples Entscheidung über das Ausschließen von intermediate languages technisch-rational betrachtet”.

    Die darin dargestellte Problematik wird seit vielen Jahren in leicht veränderter Form im Markt beobachtet. Hier ist die Marktstruktur das Moment was eine zutreffende Einschätzung nicht gerade einfach macht.

    Wenn es sich um Closed Source Software (CSS) auf proprietärem Gerät wie dem Apple Telefon geht, bleibt es inhaltlich wie technisch beschaut spannend.

    Intermediate Code gibt es seit es die Programmiersprache Pascal (1971, Niklaus Wirth) gibt. Mit JAVA wurde 1995 von SUN dieser Ansatz erneut öffentlich und somit
    interessant für uns alle. Für Anwender, für Entwicklerinnen, Informatiker wie API-Designerinnen und Vieltelefonierer gleichermaßen.

    Wissen Sie ob es Offene Standards auch in der Mobiltelefonie in ansprechendem robustem Gerät gibt?

    Fragt

    Anonymous

  2. Konstantin Filtschew

    Hallo,

    ich verstehe Ihre Frage nicht ganz. Falls die Antwort nicht ausreichend ist, so stellen Sie sie bitte noch einmal.

    Sun hat die Java Virtual Machine unter einer Open Source Lizenz veröffentlicht. Die Entwicklung wird zwar noch immer fast ausschließlich von Sun (jetzt Oracle) bestimmt, aber es ist defakto Open Source.

    Auf den Android Telefonen läuft das Open Source Betriebssystem Android von Google. Dieses basiert auf einem für Mobiltelefone angepassten Linux Kernel und der Dalvik Virtual Machine, welche mit Android als Open Source veröffentlicht wurde. Die Entwicklung wird hier allerdings wiederrum von Google und einem Konsortium geprägt.

    Die Android Geräte der neueren Generation mit Android 2.1 und 2.2 sind meiner Meinung nach entsprechend robust, schnell und zuverlässig. Ich benutze Android seit dem ersten Android Mobiltelefon (HTC G1) und bin noch immer mehr als begeistert.

    Gruß, Konstantin

  3. Anonymous

    Hallo Herr Flitschew,

    nein – Sie haben mich schon recht verstanden.
    Für mich ist es so, dass Standards immer dann überzeugen wenn dise offen angelegt sind und auch so gehalten werden. Bleiben sie offen, möchte ich nicht über Multi-Level-Mix-Marketing und ähnliche Schwellen „gehoben“ werden.
    Das nervt nur und dient der Sache nicht. Der Entwicklung robuster Geräte in funktionalem Design.

    Wann sollte man irgendwelchen API-Styleguides folgen, wenn nicht wegen der drei grossen Fs? Form-Follows-Function!
    Es ist doch so, dass wer erst einmal Eintrittgeld für Styleguides zahlt, zahlt meist auch ein zweites und drittes mal.
    Was übertragen auf Apple-Styleguides bedeutet: Es wird gezahlt auch wenn es nicht einmal (mehr) erforderlich ist..

    Vor diesem Hintergrund steht meine Frage nach offenen Standards in Hard- und Software des Mobilfunk Markt.
    Openmoko?

    Danke und Viele Grüße,
    Anonymous
    :-)

Einen Kommentar schreiben

Copyright © 2014 by: Konstantin Filtschew WebLog • Template by: BlogPimp Lizenz: Creative Commons BY-NC-SA.