• Die Sache mit dem Flash & dem iPhone und dem Zeug

    by  • 29. April 2010 • Apple • 23 Comments

    Wir hatten bei mobileMacs eine lange Diskussion drüber, in den Kommentaren wurde eine Menge drüber geredet, und selbst Steve Jobs hat sich inzwischen öffentlich dazu geäußert:Flash auf dem iPhone.

    Dennoch gibt es vermutlich noch ein wenig was zu dem Thema zu sagen.

    Nun bin ich selbst kein Fan von Flash: wann immer ich einen Browser nutze, installiere ich als erstes einen Flash Blocker, und als es für Chrome keinen gab, habe ich kurzerhand selbst einen geschrieben. Auch aus Entwicklerperspektive hat mir Flash nie sonderlich viel Spaß gemacht. Das Flash Programm als Entwicklungsplattform ist langsam, die API ist schlecht dokumentiert, der Debugger ist zum davonlaufen und die Fehler der Sprache und API haben mich diverse Haare und Stunden meines Lebens gekostet.

    Auf einem Mobiltelefon wird die Sache nur noch schlimmer: das langsame Flash würde den Prozessor noch mehr belasten und den Akku noch schneller leersaugen. Und unnütz wäre es noch dazu: da vermutlich nur unglaublich wenige Flash-Filme auf kleine Displays und Bedienung mit dem Finger angepasst würden, könnte man sie nicht sinnvoll nutzen.

    Es spricht also wirklich nichts dafür Flash auf meinem iPhone haben zu wollen.

    Oder vielleicht doch?

    Es gibt nämlich nicht nur das Flash im Browser. Mit Flash CS5 wollte Adobe ein Tool herausbringen, mit dem sich in Flash native Apps für das iPhone entwickeln lassen. Die damit erstellten Apps verhalten sich weitgehend so, wie es auch in Cocoa geschriebene Apps tun würden, sie ließen sich auf Touch Bedienung optimieren und wären für die meisten Anwender nicht von einem nativen App zu unterscheiden. Tausende von Flash Entwickler könnten noch heute mit der Entwicklung von Flash Apps beginnen, ohne eine neue Sprache oder neue Werkzeuge erlernen zu müssen. Ob diese Apps den Prozessor stark auslasten würden wäre relativ wurscht: es ist davon auszugehen, dass in Flash eher Spiele und Spielzeuge programmiert worden wären, und auch die nativen iPhone Spiele zeichnen sich nicht durch akkuschonendes Verhalten aus.

    Auch das von Steve Jobs vorgetragene Argument, dass eine Plattform wie Flash die Möglichkeiten des Entwicklers zu sehr einschränken würde, halte ich für vorgeschoben: schließlich sollte es doch im ermessen des Entwicklers liegen, ob er mit den Einschränkungen einer bestimmten Plattform klarkommt oder nicht.

    Der eigentliche Grund für den Ausschluss von Flash und Co liegt ganz woanders: ich glaube, Apple will schlicht verhindern, dass man gleichzeitig fürs iPhone und ein anderes OS entwickeln kann. Plattformunabhängige Entwicklung auf dem iPhone soll nicht möglich sein.

    Denn plattformunabhängige Toolkits würden Apple nicht helfen: im Augenblick kann es sich eh niemand leisten das iPhone außenvor zu lassen. Lieber verzichten Entwickler auf eine Android oder WebOS Version ihres Apps als auf die iPhone Version. Flash & Co.  würden also nicht wirklich Apple oder seinen Kunden schaden, sondern eher den anderen Mobiltelefonen nutzen, weil für sie mehr Krümel vom großen Appstore Kuchen abfallen würden.

    Apples Aussperren von plattformunabhängigen Toolkits ist also mitnichten ein technische Entscheidung, sondern eine rein wirtschaftliche: es geht darum, die Konkurrenz klein zu halten.

    Und wenn Apple aus meiner Sicht als Kunde eines ganz dringend braucht, dann ist es stärkere Konkurrenz.

    23 Responses to Die Sache mit dem Flash & dem iPhone und dem Zeug

    1. Max
      29. April 2010 at 18:17

      „Die damit erstellten Apps verhalten sich weitgehend so, wie es auch in Cocoa geschriebene Apps tun würden …“
      Bitte? Diese Apps fühlen sich ganz anders an. Die ganzen tollen Kleinigkeiten an die Apple gedacht hat fehlen: Buttonfläche wird größer nach dem touchDown-Event um nur ein Beispiel zu nennen. Man merkt schnell, dass diese App nicht direkt mit CocoaTouch-Elementen gebaut wurde.

      „Apple will schlicht verhindern, dass man gleichzeitig fürs iPhone und ein anderes OS entwickeln kann.“
      Also ein portabler C/C++ Kern und eine gute native UI darauf. Da habe ich meine Plattformunabhängigkeit und verliere nicht meine Usability in einer gruseligen Middleware. Für den User muss sich eine Anwendung nativ anfühlen. Die Entwickler müssen halt für iPhoneOS, Android usw je eine GUI machen. Die User wechseln nicht permanent zwischen den mobilen Plattformen, die wollen Konsistenz.

      „Und wenn Apple aus meiner Sicht als Kunde eines ganz dringend braucht, dann ist es stärkere Konkurrenz.“
      Ja

    2. Max Winde
      29. April 2010 at 18:22

      Die wesentliche Entwicklung läuft nun mal gegen die API, zumindest bei Apps wie sie z.B. mit Flash entwickelt werden. Der portable C/C++ Kern wäre da praktisch null.

    3. paierschiff
      29. April 2010 at 19:34

      im grunde bin ich müde bezüglich dieser diskussion. ich verstehe max, habe auch gewaltige probleme mit flash, hätte aber nichts gegen ein cross-plattform-toolkit.
      aber es ist eigentlich ganz einfach. es passt genau zu apples politik. es passt du der ipod/iphone-itunes-bindung (inklusive erschwerung für die dritt-software), zur öffentlichkeitspolitik, zum appstore, zur eigenen arroganz, ….
      und wer glaubt apple durch „kritik“ zu größeren änderungen bewegen zu können, der hat sich vermutlich die falsche firma ausgesucht.

      vielleicht ist es sogar sinnlos die energie an apple zu verschwenden, vielleicht ist es sinnvoller die energie in die „alternativen“ zu stecken. einfach weil sich apple vermutlich „nur“ anpassen wird, wenn ihnen die kunden wegrennen. und da müssen die konkurrenten vorallem bezüglich usability nachholen, was sie ja aber teilweise machen.
      mit palm & hp wird es alternativen geben und auch win mobile7 sieht ganz vielversprechend aus. android ist von der verbreitung ebenso ganz gut dabei, taugt aber von der bedienbarkeit nicht ganz so…
      und auch auf dem desktop werden die alterantiven besser. mit win7 gibt es deutlich weniger punkte um vom ms auf osx zu wechseln, die web-distributionen (jolicloud, chromeos, …) werden zukünftig noch interessanter und auch linux auf dem desktop bewegt sich -gerade mit ubuntu- deutlich voran. das synkt seit der neusten version auch wieder mit dem iphone/neuestem ipod, gibt sich mühe bei der usability (man schaue sich nur die menuleiste an, die sehr osx-like aussieht), und es soll sogar das menu der programme in die menuleiste kommen (wenn auch erstmal nur bei der netbook-variante..) -die paketverwaltung ist mit dem software-center deutlich einfacher geworden, ebenso gibt es die mobile-me alternative ubuntu one und den ubuntu one music store.. das geht jedenfalls alles in die richtige richtung und das wird apple auch zum handeln bewegen. zumindest früher oder später.

      liebe grüße,
      das papierschiff

    4. Oliver
      29. April 2010 at 20:08

      Flash würde die Dynamik in der Entwicklung von iPhone OS bremsen. Neue Features des OS würden würden von vielen (Flash) Entwicklern nicht, oder nur spät, implementiert werden können. Das schadet ganz klar der Innovationsfähigkeit der Plattform. Apple müsste zudem Rücksicht auf die Lauffähigkeit eben dieser Apps nehmen, will man die Kunden nicht verprellen, denn die kaufen bei Apple und nicht bei Adobe. Flash rauszuhalten ist m.E. die absolute richtige Entscheidung.

      ZUr Konkurrenz: Das iPhone OS wird massive Konkurrenz durch Android bekommen, das steht doch ausser Frage – man muss sich nur die steigenden Marktanteile von Android ansehen. Diese Konkurrenz ist sehr ernst zu nehmen und natürlich auch zu begrüßen. Aber um dieser Konkurrenz auch auf lange Sicht gewachsen zu sein muss sich Apple seine Innovationsfähigkeit bewahren. Ansonsten wird das iPhone OS und die zugehörige Hardwareplattform den identischen Weg gehen, wie damals der Mac und das Mac OS.

    5. Kay
      29. April 2010 at 20:19

      @Oliver: Das ist doch Quatsch (sorry). Welche nativen Apps reizen den wirklich die neusten Features aus? Schon mit iPhone OS 4.0 wird es deutlich schwieriger. Nutzt man die letzten Features, läuft ein Programm womöglich nicht mehr auf den älteren iPhones und iPod Touch. Gerade der Marktanteil von iPod Touches der 1. und 2. Generation ist noch sehr groß.
      Und wenn ein Flash-Entwickler das unbedingt will, muss er halt doch zu xcode wechseln.

    6. Nick
      29. April 2010 at 23:06

      Max: Ich stimme zu – es geht Ihnen um etwas ganz anderes … Das ganze Kindergarten-Geplänkel der ‚Big-Player‘ lässt sich einfach runterbrechen auf:

      a) Sagt einfach, was ihr wollt und sagt uns die wahren Gründe dafür.
      b) Beide Seiten tun dies nicht – das bietet sehr viel Spielraum für Interpretationen und Unsicherheit (für Entwickler) – scheint so gewollt zu sein. Mich nervt es persönlich inzwischen.

      Auf beiden Seiten (Apple/Adobe) kann man viele Unstimmigkeiten erkennen. Ich behaupte, dass es auf Adobe’s Seite dennoch deutlich weniger Unstimmigkeiten in Ihren Äußerungen gibt.

      Wahllos herausgenommende Beispiele:
      Adobe sagt: Flash ist weitgehend offen. Das ist natürlich nicht so.
      Apple sagt: Flash ist für PCs konzipiert mit Maus (rollOver/rollOut) und passt so gar nicht zu TouchDisplays. Wenn schon jeder Flashentwickler seine Anwendungen, Webseiten, etc. für Touchdisplays umschreiben muss, dann können sie doch gleich Technologien der Zukunft (HTML5,JavaScript, CSS) lernen und anwenden <= ein schlechter Witz in jeder Beziehung: Ich schreibe mir in Anwendung X eine neue Klasse, überschreibe ein paar Methoden, deaktivere damit jeden Listener der auf rollOver und rollOut reagiert und 'that's it!'.

    7. Oliver
      29. April 2010 at 21:44

      @ Kay
      Warum sollte Apple Ressourcen einsetzen (und das müssten sie), um die Lauffähigkeit von cross compilierten Apps zu gewährleisten?
      Wenn sie Flash zulassen, haben sie binnen kürzester Zeit genau so viele Flash-, wie Native Apps auf der Plattform. Adobe wäre ein zentraler Faktor betreffend der Weiterentwicklung des iPhone OS. Das will Apple nicht, weil es zum einen Ressourcen bindet und zum anderen die Weiterentwicklung des OS ausbremst.
      Daneben spielen sicherlich auch wirtschaftliche Fragen eine wichtige Rolle. Warum sollte Apple die Konkurrenz (in erster Linie Android) am Erfolg des App Stores partizipieren (Stichwort cross compile) lassen? Apple hat momentan ein sehr gutes Standing im Bereich Mobile, aber Marktführer sind sie nicht. Die Konkurrenz hat geschlafen, aber sie ist aufgewacht. Google hat alle Möglichkeiten dem iPhone OS mindestens Paroli zu bieten. Das einzige, was Apple dem entgegenzusetzen hat ist ein technologischer Vorsprung durch den frühen Markteintritt (der ist fast weg), den App Store (Google Market wächst) und eben eine hohe Innovationskraft. Und die gibt man nicht aus der Hand – vor allem nicht für Dinge, von denen sich die Welt mittelfristig verabschiedet. Flash im Sinne des Formats wird nicht mehr benötigt. Überleben können wird Flash nur als das, was es ursprünglich einmal war: als Authoring Tool. Diesmal für offene Standards / Formate.

    8. 29. April 2010 at 21:50

      Interessant. Vor allem aus der Perspetive des zweitseitigen Marktes und dem Multihoming, wie es Marcel Weiss dargestellt hat.

      http://www.neunetz.com/2010/04/13/zweiseitige-maerkte-multihoming-bei-internetplattformen/

      Apple versucht Multihoming für die Plattform zu unterbinden, damit die Programmierer exklusiv auf der Plattform gebunden werden, was wiederum deren relative Attraktivität für den Endnutzer erhöht.

    9. 29. April 2010 at 21:59

      Ich glaube, das Argument mit dem Cross-Entwickeln ist viel zu kompliziert gedacht. Viel wichtiger ist doch, dass Apple von Flash-Apps nicht mehr seine App-Store-Prozente einsammeln kann.

    10. Max Winde
      29. April 2010 at 22:01

      Klar könnten sie das. Die Flash Apps wären ja genauso durch den Store gegangen wie jedes andere App auch.

    11. Nick
      30. April 2010 at 11:46

      @dotPax: Du lässt Dich als User entmündigen und möchtest das gerne auch unterstützen?

      Technisch wäre es gar kein Problem einen Optionsschalter Use Flash: No/Yes zu integrieren. Damit wäre dann die Diskussion tatsächlich beendet.

    12. Pingback: F.A.Z.-Community

    13. Oliver
      30. April 2010 at 10:21
    14. 30. April 2010 at 11:00

      Als ich fand die Diskussion bei mobileMacs schon anstrengend und sehe es genauso wie Tim. Ich als Endanwender will im Appstore nicht irgend ne Anwendung bezahlen, um dann festzustellen, das Flash meinen Akku leer saugt und sich die auf den ersten Blick womöglich nativ aussehenden Buttons nicht wie erwartet verhalten.
      Und das Argument, das Apple Crossplattform-Entwicklung nicht zulässt verstehe ich auch nicht. Es gibt keinen besseren mobilen Browser als Safari.

      Und Adobe verstehe ich überhaupt nicht. Die hängen sich so in den Kampf um Flash rein und verpassen die Zukunft. Ich dachte die verdienen ihr Geld mit Authering-Software. Wo ist die Entwicklungsumgebung für geile HTML5/JS Apps?

      Flash is dead. Und das ist gut so. Ende der Diskussion!

    15. Max Winde
      30. April 2010 at 11:03

      Niemand zwingt dich Apps zu kaufen, nur weil sie im Store angeboten werden.

    16. Oliver
      30. April 2010 at 14:48

      Kein Flash auf der Wii
      Kein Flash auf der Xbox
      Kein Flash auf der PSP

      hmmm?

    17. Max Winde
      30. April 2010 at 15:39

      Auf der Wii gibt es Flash. Und alles drei sind sicherlich keine Geräte mit denen man surfen möchte.

    18. Lethian
      30. April 2010 at 18:50

      Was mich als Privatperson gähnend kalt lässt, macht mich als Webentwickler nachdenklich.

      Unterwegs das iPhone, daheim das iPad. Dieser Gedanke scheint ja bisher relativ gut aufzugehen, zumindest was das iPhone angeht, was die Verkaufszahlen des Gerätes unterstreichen.

      Nun sind diese xx-Millionen Besitzer nicht in der Lage unterwegs auf Flash-Sites zuzugreifen. Das stinkt Adobe – würde mir auch – insbesondere wenn ich Tage/Monate/Jahre in die Einarbeitung in Flash investiert hätte.

      Mit wachsendem Marktanteil an nicht-flash-unterstützenden Produkten sollte demnach auch der „Bedarf“ an Flash-Sites weiterhin sinken.

      Die Leidtragenden sind im Endeffekt nur leider die Kunden denen keine Ausweichseite zur Präsentation im Netz entwickelt / ausgezeichnet wurde und somit widerum mögliche Kunden verlieren, bzw denen das Konzept Flash-Site nicht von grundauf aus dem Kopf argumentiert wurde.

      stay accessible and valid…

    19. Michael Schmid
      5. Mai 2010 at 08:44

      Also ich glaub hier wird auch viel missverstanden (vielleicht auch von mir).

      Der Adobe-Crosscompiler für Flash erzeugt doch keine Flash-App, sondern schreibt diese in Cocoa um bzw. setzt unter die Flash-App eine Übersetzerschicht. Für das iPhone selbst sieht diese App wie eine native Cocoa App aus.

      Aus Flash selbst fällt hinten dann eine App raus, die in den App-Store eingereicht werden kann/könnte.

      Insofern dürften (je nach Qualität des Crosscompilers) technisch gesehen (Akkuverbrauch, Geschwindigkeit) doch kaum Unterschiede feststellbar sein?

      Auch über Flash liegt es weiterhin an der „Qualität“ des Entwicklers, wie gut die App wird. Es würde sicherlich auch hervorragende Flash-Compilierte Apps gegeben, genauso wie es grottenschlechte Cocoa-Apps gibt…

      Das Problem wird eher sein, wie gut Adobe die Flash-Befehle letztendlich übersetzt und wie schnell Änderungen/Ergänzungen aber auch Löschungen im SDK Einzug in den Compiler halten…

      Michael

    20. Ron
      5. Mai 2010 at 08:50

      Huhu,

      seht euch mal

      http://www.appcelerator.com/

      an.

      Beste Grüße aus Nürnberg

    21. Max Winde
      6. Mai 2010 at 14:31

      Im Wesentlichen hast du recht, passt schon.

      Das einzige, was du vergisst ist, dass Flash fürs iPhone eben kein Zugriff auf die gesamte Cocoa API erlauben würde.

    22. Nick
      17. Mai 2010 at 21:41

      … was Apps im Zweifelsfall nicht unbedingt schlechter gemacht hätte.

      Fakt ist, dass Adobe sich von dem IPhone Packager offiziell verabschiedet – auch wenn er noch in Flash CS5 integriert ist. Sie werden keine Sekunde mehr in eine Weiterentwicklung des Packagers investieren.

    23. Pingback: Managing CTRL-Verlust II – Plattformneutralität als Politik | ctrl+verlust

    Kommentar verfassen