Ein App-Store für Computer [Update]

Für ihre Macintosh-Computer hat Apple einen App-Store angekündigt. Für die Mobilgeräte iPod touch, iPhone und iPad existiert ein solcher seit längerem erfolgreich. Das neue MacOS X („Lion“) für Computer soll sich zahlreiche Technologien und Ideen bei iOS (dem System für die Mobilgeräte) ausborgen. Seit Jahren ist der iTunes Store auf Macintosh-Computern, Windows-Computern und auf Mobil-Geräten erfolgreich. Nicht ganz so erfolgreich, aber ordentlich läuft der Film- und TV-Store über iTunes. iTunes ist eines der beliebtesten Programme für Windows-Computer. All diese Vorausbemerkungen sind nötig, um zu verstehen, was als logischer Schritt folgt: Ein App-Store für Computer, und zwar nicht nur für Mac, sondern auch für Windows-Computer. Das argumentiert jedenfalls Daniel Eran Dilger (wie immer lesenswert!)

Historische Perspektive

Bereits in den 1990er Jahren gab es mit der „Yellow Box“ (mehr Historie) eine funktionierende Umgebung, um Programme auf verschiedenen Systemen und Architekturen laufen zu lassen. Das war ein anfangs relevanter Bestandteil der Migration des klassischen Mac-Systems zum NextStep-basierten MacOS X (seeehr verkürzt dargestellt). Hier genügt die Feststellung: Es gab bereits einmal eine funktionierende plattformübergreifende Entwicklungsumgebung, die aufgrund verschiedener Umstände jedoch nicht verbreitet wurde.

Mit Java, Flash, Adobe Air, .Net und anderen Umgebungen wurde seitdem mehrfach versucht,  plattformübergreifende Entwicklungsumgebung zu etablieren. Auch hier genügt die verkürzende Feststellung: Keine kann wirklich überzeugen. Vor allem fehlt bei allen das zugrundeliegende Wirtschaftskonzept bzw. die wirtschaftliche Motivation der konstanten Pflege. Das gleiche gilt für web-basierte Lösungen.

Ziel ist es, eine Umgebung zu haben:

• die auf möglichst vielen Computern problemlos läuft
• die modern und effizient zu programmieren ist
• die Sicherheitsstandards einhält
• die eine geschützte Umgebung darstellt (nicht nur in Hinblick auf Systemsicherheit, sondern auch mit Blick auf Raubkopien, ohne die Nutzer stärker einzuengen als unbedingt nötig)
• die gepflegt und gewartet wird, weil sie wirtschaftlich für das verantwortliche Unternehmen von Bedeutung ist.

Apple hat mit dem iTunes Store und dem App-Store bewiesen, dass die letzten beiden Bedingungen erfüllbar sind. Auch wenn die Stores keine relevanten eigenen Gewinne erwirtschaften, so stärken sie doch die anderen Angebote von Apple (iPod, iPhone) und generieren so indirekt Gewinn. Es ist also in Apples wirtschaftlichem Interesse, beide Stores in Schuss zu halten. Gleiches lässt sich von Java nicht sagen, denn Oracle (bzw. zuvor Sun) profitiert nicht spürbar unmittelbar davon. Auch Adobes Flash unterliegt nicht dem wirtschaftlichen Druck, da erstens keine Wahl besteht (wie bei einem Musik-Store) und zweitens stets argumentiert wird, es funktioniert doch alles super. Aus Mangel an Alternativen können die Nutzer eben nicht zu einem anderen Anbieter wechseln, während die Designer halbwegs zufrieden sind (eine unausgeglichene Situation, wenn als Ideal gilt, dass Anbieter und Nutzer gleichermaßen mit einem Angebot zufrieden sein sollten).

Mit der Cocoa-Umgebung erfüllt Apple die zweite und dritte Bedingung. Zusätzlich ist zu berücksichtigen, dass Cocoa als Programmiersprache Objective-C verwendet, die objektorientiert, modern und elegant ist (behaupten jedenfalls Programmierer). Durch sogenannte Fat-Binaries lassen sich verschiedene Rechner-Architekturen effizient unterstützen. Dabei wird der Programmcode in verschiedenen Versionen kompiliert (Übersetzung des für Menschen verständlichen Programmcodes in ausführbare Anweisungen). Der Nutzer enthält nur ein Programm, das aber mehrere Übersetzungen enthalten kann. Bei der Ausführung des Programms wird die Übersetzung verwendet, die die besten Ergebnisse auf dem jeweiligen Computer liefert. Damit kommt den Kompilern (den Übersetzern) eine große Bedeutung zu; hinter den Kulissen hat Apple vor kurzem den Kompiler ausgewechselt, sodass ihre eigenen Programme nun effektiver und besser laufen, ohne dass jemand etwas am Programmcode ändern musste. Das technische Know-how ist also vorhanden.

Wirtschaftliche Perspektive

Mit einem App-Store für den Mac würde die erste Bedingung lediglich mit Blick auf Mac-Computer erfüllt, der große Anteil der Windows-Computer bliebe außen vor. Ein solch beschränkter Markt hätte für den Musik-Store das Aus bedeutet. Das iPhone stellt mit seinen mehr als 30 Millionen Stück pro Jahr einen relevanten Markt dar, ebenso die iPods und iPads (aus dem Stand 4 Millionen im ersten Jahr, prognostizierte zehn Millionen im nächsten), sodass jedes Jahr etwa 50 Millionen iOS-Geräte verkauft werden, die auf den App-Store zugreifen können. Das ist ein großer Markt, der aufgrund der geringen Zersplitterung (im Gegensatz zu Android) eine attraktive Plattform für App-Entwickler bietet. Als der Musik-Store 2003 gestartet wurde, war nur der Zugang vom Computer aus möglich (inzwischen auch von iOS-Geräten). Pro Jahr verkauft Apple derzeit 4 Millionen Mac-Computer, damals zwischen zwei und drei. Der Markt wäre zu klein gewesen, um die Anbieter (Musik-Labels) zu überzeugen, deshalb wurde iTunes auch auf Windows angeboten, was den potenziellen Markt auf einen Schlag verzehnfachte. Allein aus den Erwägungen heraus, einen attraktiven Markt für die Entwickler anzubieten, kommt Apple langfristig nicht darum herum, Windows als Store-Plattform mit in Betracht zu ziehen.

Derzeit gibt es keinen großen Markt für plattformunabhängige Programme. Von wenigen Ausnahmen abgesehen gibt es Programme entweder für Macintosh oder für Windows. Adobe und Microsoft beispielsweise unterhalten eigene Abteilungen, um jeweils die Macintosh-Versionen zu erstellen. Die Mac-Plattform ist nur deshalb für zahlreiche Entwickler von wirtschaftlichem Interesse (also abgesehen von der Freude am Programmieren), weil die Quote von verkauften Programmen bei Macs deutlich höher ist als unter Windows-Nutzern; Mac-Nutzer sind tendenziell stärker bereit, für gute Programme etwas zu bezahlen. Dass auch Windows-Nutzer bereit sind, für Programme etwas zu bezahlen, beweist der App-Store, denn zahlreiche iPhone-Besitzer sind Windows-Nutzer. Außerdem ist es ein Unterschied, ob ein Programm 50 Euro oder 5 Euro kostet. Es ist also weniger die Frage des „Ob“ als vielmehr des „Wieviel“.

Mit dem Siegeszug von Smartphones, Tablets neben den Mobilrechnern in unterschiedlicher Ausstattung/Größe und Desktop-Rechnern wird die Computerlandschaft weiter zersplittert. Ein Store, der einerseits Raubkopien verhindert und andererseits aufgrund seiner Masse attraktiv ist, kann somit für Nutzer und Entwickler von Vorteil sein. Für die Nutzer werden die Programme günstiger, die Entwickler erhalten tatsächlich das Geld, wenn ihr Programm genutzt wird.

Nutzerperspektive

Wäre es nicht einfach großartig, wenn man sein Programm zur Fotoverwaltung auf iPad, MacBook und Windows-Computer gleichermaßen nutzen könnte? Wenn es Pages ebenfalls für alle drei Systeme gäbe? Wenn man nicht von zahlreichen verschiedenen Kopierschutzverfahren genervt würde? Wenn man nicht bei jeder Neu-Installation irgendwelche kruden Lizenzschlüssel für die zahlreichen Programme zusammensuchen bräuchte? Wenn man sein Lieblingsspiel überall (Mac, Windows, iOS-Geräte) spielen könnte? Wenn kein ständiger Wechsel zwischen verschiedenen Programmen nötig wäre, nur weil man den Rechner wechselt? So wie es für viele inzwischen selbstverständlich geworden ist, bei iTunes gekaufte Musik auf mehreren Geräten parallel zu nutzen?

Was spricht eigentlich dagegen? Die Machbarkeit ja wohl nicht, denn wenn bereits in den 1990ern eine Entwicklungsumgebung mehrere Computersysteme und -architekturen umfassen konnte, sollte das heutzutage ja erst recht möglich sein.

Der Aufwand spricht dagegen. Natürlich hat Java über die Jahre an Reife und Verbreitung und Relevanz gewonnen. Aber nur wenige „Normalnutzer“ würden es merken, wenn die Entwicklung eingestellt würde. Ist Oracle als neuer Java-Besitzer motiviert genug, die Plattform tatsächlich effektiv weiterzuentwickeln?

Apple-Perspektive

Was würde Apple gewinnen, wenn es eine eigene Cocoa-Umgebung für Mac- und Windows-Computer anböte? (nicht in Konkurrenz zu Java, sondern eher als moderne Erfüllung eines 1990er-Jahre-Versprechens)

• Verbreitung von Cocoa (moderne, effiziente Programmierung) und damit mehr Entwickler für MacOS X und iOS
• eine große Vielfalt von Programmen für Mac, iOS (naja, und Windows) = breitestmögliche Marktabdeckung für Anbieter/Programmierer und Nutzer
• Verbreitung des Mac-Feelings (oder wie immer das dann heißt) auch unter Windows-Nutzern
• eine Plattform, um Produktivitäts-Programme (iWork, FileMaker, FinalCut, etc.) versionsgleich auf Mac und Windows zu veröffentlichen (nie wieder „Ich kann deine Pages-Datei nicht öffnen“)
• effektive Verteilung von iTunes (evtl. sogar Aufsplittung ála iPad auf iTunes-, Store- und Video-App) und anderen eigenen Angeboten (wie Mobile Me), mit denen Geld verdient wird
• kleines Plus (der 30-Prozent-Anteil wirft keine relevanten Gewinne ab, sondern finanziert den Betrieb des Stores und die Abwicklung aller Geschäftsprozesse; Kasse durch Masse – wie eben auch die Entwickler, die nicht 80 Euro verlangen müssen, um die Raubkopien auszugleichen)
• positives Image bei Nutzern:
  • kleiner Preis für leistungsfähige Programme (durch die Prüfung eben nicht jeder Schrott)
  • das selbe Programm auf allen Geräten, die man besitzt
  • automatische Updates
  • „it just works“
• positives Image bei Entwicklern:
  • einmal programmieren – vielfach nutzen (in einer modernen Programmierumgebung)
  • kein eigener Vertrieb nötig (Logistik, Inkasso, Rechnungslegung laufen über Apple)
  • keine Raubkopien
  • gute Ergebnisse mit geringem Aufwand (keine zahllosen Testumgebungen, konsistente Erscheinung, Zugriff auf alle Standard-Ressourcen [Grafik, Sound, Touch, Multitasking, Multicore-Prozessoren, etc.], moderner Unterbau)
• letztlich: mehr Interesse und potenzielle Kunden für ihre Geräte und damit Stärkung der anderen Geschäftsfelder/Angebote

Steam hat es mit seiner Spieleplattform vorgemacht, und Apple könnte das gleiche für Apps allgemein vorschweben. Sie würden in jeder Hinsicht profitieren – bei vergleichsweise geringem Aufwand. Die Nutzer können dabei nur gewinnen.

Konkurrenzperspektive

An anderer Stelle habe ich bereits darüber nachgedacht (und andere auch): Wenn es Apple gut geht, muss Microsoft nicht verlieren. Microsoft sieht das natürlich anders. Denn Microsoft befindet sich in einem künstlichen Monopol, einem Monopol über Computer, das durch Verträge abgesichert ist, nicht durch Kaufentscheidungen. Egal ob ich einen Computer von Dell, HP, Samsung, Sony, Toshiba, Medion etc. kaufe, ich erhalte stets Windows dazu. Das ist keine wirkliche Freiheit.

Natürlich könnte ich Windows wegwerfen und Linux installieren, aber dafür gibts keinen wirklichen Support (bei Microsoft könnte ich zumindest theoretisch anrufen). Für die „normalen Nutzer“ ist Linux bislang keine Alternative (zumal ihnen alle Technikredakteure zwar einerseits von Linux’ Offenheit vorschwärmen, dann aber doch nur wieder erklären, wie sie mit Windows-Programmen ihre Ziele erreichen können).

Microsoft ist sicherlich alles andere als erfreut, wenn plötzlich auf ihrem Windows-System ein Shop aufsetzt:

• der beweist, wie einfach und funktional Software sein kann (Stichwort Usability und Konsistenz; Microsoft ist nicht einmal innerhalb der eigenen Programmpalette einheitlich)
• der Nutzer und Entwickler gleichermaßen anspricht (Vielfalt, Preisgestaltung, einfache Nutzung)
• der Geld verdient (für Betreiber ein wenig, für Entwickler viel; für Kunden vergleichsweise niedrige Kosten)
• der plattformunabhängig ist (warum braucht man dann eigentlich noch Windows? – die gleiche Furcht vor Geräteneutralität wie in den 1990ern vor Java und Internetbrowsern)
• der Nutzern, Entwicklern und Administratoren eine konsistente, leicht einzurichtende, einfach zu wartende, simpel zu nutzende, effektiv mit anderen Geräten kombinierbare Umgebung liefert
• der den Store gegenüber den Kunden und Entwicklern nicht als Geschäftsmodell versteht, sondern als Angebot für „eine einfachere Computwelt“

Der App-Store bezieht sich nicht auf Programmpaketmonster wie die Adobe Creative Suite oder hardwareintensive und auf mehreren DVDs ausgelieferte Spiele. Sondern er dient zum Vertrieb von nützlichen kleinen Programmen, Spielen, Tools.

Die Gefahren

Natürlich würden mit einem solchen Store sofort die Gesänge anbrechen, dass das Abendland seinem Untergang entgegensteuere, wenn Apples geschlossenes System auch auf die freien Windows-Computer käme. Sämtliche Grundannahmen solcher Befürchtungen sind falsch. Weder bedeutet ein solcher Store das Ende des Abendlandes noch sind Apples Systeme so geschlossen wie immer behauptet wird noch ist Windows so frei wie es behauptet wird. Die Frage ist: Warum verwende ich ein Apple-Produkt? Weil ich mich dafür entschieden habe. Warum verwende ich ein Microsoft-Produkt (jedenfalls im Bereich der Software)? Weil ich keine echte Wahl hatte.

Kritischer ist die Frage, wie Kartellbehörden in den USA und in der EU auf eine solche Plattform reagieren. Der Unterschied zu dem Microsoft-Monopol ist, dass Apple die Welt nicht als Geschäft definiert, dafür steckt noch zu viel Hippie-Geist in dem Unternehmen. Natürlich will man geschäftlich erfolgreich sein, aber das muss ja nicht zulasten von anderen gehen. Apple zwingt niemanden zu irgendwelchen Geschäften, Apple verführt bzw. überzeugt mit seinen Produkten. Der Music- und Film-Store sind immerhin auch noch geöffnet – trotz weltweiter Marktführerschaft.

Ein App-Store (auch für Windows) macht allerdings keine großen Investitionen nötig. Die Entwicklungsarbeit der Software-Plattform kann „nebenbei“ erfolgen. Naja, das wäre etwas flapsig, aber es ist kein so Mega-Unterfangen wie beispielsweise Adobe mit einer neuen Version ihrer Creative Suite, sondern noch überschaubar. Außerdem bestehen mit Safari, iTunes und QuickTime schon Grundlagen, auf denen man aufbauen kann. Insbesondere Safari wurde von einigen Auguren bei der Ankündigung 2007 als Vorbote von großen Dingen angesehen.

Ich spreche nicht davon, dass im Frühjahr ein solcher App-Store für Windows eröffnet wird, aber für 2012 könnte das realistisch sein. Das setzt natürlich voraus, dass Apple die gleichen Denkmuster verfolgt, die Daniel Eran Dilger ihnen unterstellt (und ich ebenso). Mir fallen jedenfalls nur Argumente dafür ein. Das einzige Gegenargument, das Gewicht haben könnte: Apple hat nicht so viele personelle Ressourcen wie Microsoft. Die Apple-Programmierer haben schon genügend damit zu tun, regelmäßig MacOS-X-Versionen, iOS-Versionen, iWork-Programme, iLife-Programme, Pro-Apps zu entwickeln.

Langfristig könnte aber so ein Store genau das erleichtern: das Programmieren leistungsfähiger Programme und deren Vertrieb. Eben weil er eine einheitliche Basis legt, sozusagen noch stärker vom Betriebssystem abstrahiert. Damit wäre die Pflege all der verschiedenen Programme für Apple sogar noch leichter, und sie könnten sich zusätzliche Nutzerschichten erschließen (die für die Programme auch bezahlen). Für die iLife-Programme kann die Store-Plattform ja eine tatsächliche oder künstliche Sperre enthalten, die sie nur auf Macintosh-Rechnern laufen lässt, sodass die nötige Distanz zwischen Windows und Mac bestehen bleibt :-)

Ein wenig Technik im Hintergrund

Die folgende Darstellung ist stark vereinfacht und soll lediglich die grundsätzlichen Abhängigkeiten und Zusammenspiele verdeutlichen.

Was wäre nötig, damit ein App-Store auf Windows überhaupt funktioniert? Dazu ist es sinnvoll, sich anzuschauen, wie die App-Stores für iOS und MacOS funktionieren.

Eine App ist eine Sammlung von Programmanweisungen und Ressourcen. Zu den Ressourcen gehören Bilder, Ton- und Video-Elemente, Sprachdateien (um ein Programm potenziell in verschiedenen Sprachen anzubieten) und anderer Schnickschnack. Eben die Elemente, die die Interaktion mit dem User erleichtern, verschönern, verbessern. Der eigentliche Programmcode besteht aus Anweisungen, wie Eingaben umzusetzen sind.

Bereits beim klassischen MacOS in den 1980er Jahren befand sich ein Programm in einem Dauerwartezustand. Es wartete auf Ereignisse: eine abgelaufene Zeit, eine gedrückte Taste, eine Mausbewegung, eine Datei-Aktion etc. Das Programm legte fest, wie auf solche Ereignisse zu reagieren ist. Beispielsweise gibt es zahlreiche Ereignisse in einem Texteditor: Der Nutzer kann Buchstaben oder andere Zeichen eingeben – diese erscheinen an der Position des Cursors in der eingestellten Schriftvariante. Der Nutzer kann einen Menüeintrag oder ein Steuer-Element (Schaltfläche) anklicken – der angewählte Befehl wird ausgeführt bzw. die Einstellung vorgenommen. Der Nutzer kann einen Textbereich markieren, einen Befehl via Tastenkürzel auslösen, etc. Manche Ereignisse lassen das Programm aktiv werden, andere werden vom System ausgeführt, beispielsweise wenn der Nutzer das Fenster verschiebt, denn dabei werden keine programmspezifischen Anweisungen benötigt.

Es gibt somit zwei Arten von Ereignissen bzw. zwei Instanzen, die sich darum kümmern, sie umzusetzen: das Programm (Dokumentinhalte) und das System (Dateiinhalte und Fensterumgebung). Für beide gelten die drei gleichen Anforderungen: Die Ereignisse müssen umgehend (ohne unnötige Verzögerung), nicht-zerstörend (Warnhinweis, Rückgängig-Funktion) und konsistent (gleiche Aktion führt zu gleichem Ergebnis, ähnliches Aussehen bedeutet ähnliche Funktionalität) umgesetzt werden.

Für Standardfunktionen hält das System (im klassischen MacOS die Toolbox) effektive Routinen bereit: Fenstergestaltung und -manipulation, Texteingabe und -darstellung, Grafikdarstellung und -manipulation, Maus-/Tastatur-/Touch-Eingabe, Zwischenablage, Menü, Multimedia, Netzwerk, Datenbank, Drucken, Datenträgerzugriff, etc. Statt also ein Menü zu programmieren, war im Programm lediglich definiert, welche Menüeinträge vorhanden waren. Das konkrete Menü gestaltete dann das System beim Programmstart, indem es die Menü-Definition auslies.

In MacOS X haben einige Core-Bestandteile (v.a. für Bilder, Filme und Sound) die Funktionen übernommen. Da diese nah am Systemkernel programmiert sind, arbeiten sie effektiv und mit einer erstaunlich niedrigen Verzögerung. Ebenso wie der Mauszeiger, der eben stets reagiert, unabhängig vom Beschäftigungsgrad des Computers. Für beispielsweise die Farb- oder Textauswahl gibt es systemweit eine einheitliche Palette, auf die jedes Programm zugreifen kann. Indem Standard- oder häufig benutzte Funktionen in solche Frameworks ausgelagert sind, können sich die Programmierer auf das Wesentliche konzentrieren: ihr jeweiliges Programm. Das ist alles kein Zauberwerk, sondern schlicht effektive Verteilung. Ein weiterer Vorteil: Hält sich der Programmierer an den Aufruf der Systemfunktionen, profitiert sein Programm davon, wenn Apple eine Funktion verbessert, beispielsweise bei der Schriftgestaltung weitere Effekte ermöglicht. Ohne eine Zeile Code zu ändern, steht auch dem eigentlich schon älteren Programm automatisch diese verbesserte Funktionalität zur Verfügung.

Da ein Macintosh-Computer über mehr Leistung verfügt als ein iOS-Gerät, besitzt er auch leistungsfähigere Frameworks. Für iOS wurden die Frameworks überarbeitet, verschlankt und auf Effektivität getrimmt. Es sind dennoch immer noch über tausend API (Application Programming Interface, Schnittstelle für Programme) vorhanden, auf die App-Programmierer zurückgreifen können. Fehlt ein Framework bzw. wird eine Funktionalität benötigt, die nicht im System enthalten ist, kann ein Programm seine eigenen Frameworks mitbringen, diese können auch Systemframeworks im Programm ersetzen (so wie Adobe beispielsweise eine eigene Farbauswahl anbietet).

Gehen wir mal theoretisch vor: Texteingabe über Tastatur wird auf dem Bildschirm angezeigt.

1. Tastatureingabe
2. Auswertung des Programms
3. Aufruf der Systemroutinen zur Darstellung von Zeichen
4. Aktualisierung des Fensterinhalts durch das Programm
5. Integrierung des aktualisierten Fensterinhalts in den Desktop
6. Änderung der Bildschirmdarstellung
7. Anweisung an die Grafikkarte, auf dem Bildschirm die neue Darstellung anzuzeigen.

Das Programm muss von den sieben Punkten nur zwei tun: Die Eingabe korrekt entgegennehmen (2) und diese Eingabe verarbeiten (4). Alles andere erledigen die Systemroutinen bzw. Frameworks. Eine App würde also in einem unsichtbaren Programm (eben der Store-Umgebung) laufen, die sicherstellt, dass die App das darunterliegende System nicht beeinträchtigen kann (Sicherheit) und zur Ausführung der App auf die Funktionen des Systems zurückgreifen (nebenbei würde das Store-Programm auch sicherstellen, dass nur legale Apps ausgeführt werden können).

Die Frameworks der Store-Umgebung würden auf dem Mac denen des MacOS X sehr ähneln, sodass die Apps über den Store problemlos an die korrekten Frameworks weitervermittelt werden können. Die App würde also beispielsweise das Text-auf-den-Monitor-schreib-Framework aufrufen, das wiederum auf dem Mac den Aufruf einfach an das Framework des MacOS durchreicht, wo der Aufruf bearbeitet wird (eben die Texteingabe in einem bestimmten Bereich anbieten). Unter Windows würde das selbe Store-Framework die Funktionen an Windows-APIs weiterreichen, sodass mit Windows-Schnittstellen dann die benötigte Funktion bereitgestellt wird (eben in einem bestimmten Bereich Texteingabe ermöglichen). Windows würde dann über seine Schnittstellen (Grafiktreiber) eben den Monitor anweisen, den geänderten Text korrekt anzuzeigen. Da MacOS (und dessen Frameworks) im Bereich der 3D-Darstellung auf OpenGL basieren, kann an dieser Stelle sogar recht hardwarenah gearbeitet werden, denn OpenGL-Anweisungen muss der Store nicht umformulieren, um sie an Windows (bzw. dessen Grafiktreiber) weiterzureichen.

Schematisch vereinfacht sieht der Ablauf etwa so aus:

Der Store funktioniert etwa wie ein eigenes Programm auf dem Computer. Die Apps wären dann sozusagen mächtige Dokumente, so wie ein Word-Dokument VBA-Programmroutinen enthalten kann oder eine Website ja stellenweise auch komplexe Anweisungen enthält, die von den einzelnen Multimedia-, Grafik- und Eingabe-Systemkomponenten zu verarbeiten sind.

Diese Überlegungen zu einem App-Store auch für Windows setzen voraus, dass Microsoft fair spielt und nicht wie in den 1990ern (bei QuickTime) versucht, den Store zu behindern.

Für iOS gibt es – wie gesagt – bereits eine funktionierende Kollektion von Frameworks. Ebenso auf dem MacOS. Mit Safari für Windows (und auch mit iTunes, QuickTime, Bonjour) hat Apple zahlreiche grundlegende Frameworks oder Funktionen bereits auf Windows portiert. Sie müssen also nicht bei Null anfangen.

Die Infrastruktur besitzt Apple mit dem iTunes Store und dem App-Store. Dank beiden verfügt Apple auch über genügend Erfahrung und Glaubwürdigkeit. Die technische Machbarkeit sehe ich ebenfalls nicht als das große Hindernis. Die Hauptfrage ist demnach nur noch die Motivation. Reichtümer sind mit einem solchen App-Store für Computer nicht zu verdienen. Auf dem Mac passt er gut ins Gesamtkonzept, warum also für Windows den Aufwand, Programmierer für Cocoa zu begeistern?

• Cocoa-Programmierer schreiben auch für Mac
• gute Mac-Software erhält einen breiteren Markt (den von Windows)
• Windows-Software ist auch auf dem Mac verfügbar
• die Grenzen zwischen den Systemen werden durchlässiger
• der Store, wenn er gut funktioniert, macht quasi Werbung für die Mac-Plattform (wie iTunes, iPod, iPad, iPhone)

So ein Store wird niemals als alleiniges Mittel zur Software-Verteilung dienen können. Denn direkt installierte Programme sparen sich den Umweg über die beschränkteren Store-Frameworks, können also mehr Funktionen anbieten und mehr Leistung ausschöpfen. Außerdem möchte sich wohl niemand ein mehrere Gigabyte großes Programmpaket über einen Online-Store herunterladen – dafür wurde schließlich die DVD erfunden (oder auch USB-Sticks). Im Fall einer Neu-Installation müssten auch jedes Mal sämtliche Apps wieder heruntergeladen werden (ohne erneut zu bezahlen). Ab einer gewissen finanziellen Größenordnung bevorzugen Kunden auch, etwas Handfestes ins Regal stellen zu können (am liebsten einen Datenträger in einer schicken Pappbox, in der auch gleich noch ein Handbuch steckt).

Als weiterer positiver Store-Effekt würde sich erweisen, dass App-Anbieter anders rechnen. Sie entwickeln eine App, die auf Mac und Windows gleichermaßen läuft. Es gibt keine Raubkopien. Also muss nicht eine verkaufte Lizenz fünf bis zehn illegale Nutzungen kompensieren, also muss ein Programm (oder eine App) nicht mehr für 50 Euro angeboten werden, sondern kann zehn Euro kosten. Außerdem entfallen die Kosten für Werbung, Bereitstellung der Downloads, Online-Shop, Versand etc. Viele Apps (Spiele, Arbeitsprogramme etc.) für das iOS überraschen mit günstigen Preisen, wie man sie von anderen Plattformen nicht einmal im Ansatz gewohnt ist.

Apple zwingt niemanden, einen solchen Shop zu nutzen … aber es ist schon verdammt verführerisch.

Nachtrag (14.01.2011)

Bei den obigen Überlegungen war ich davon ausgegangen, dass der Mac-AppStore ebenso wie der iOS-AppStore nicht die komplette Funktionalität des Betriebssystems zur Verfügung stellt, sondern dass auch auf dem Mac quasi mächtigere iOS-Apps möglich sind, die Programme wie Graphic Converter, iPhoto oder iMovie ermöglichen. Angesichts des begrenzteren Funktionsumfangs wäre es auch realistisch gewesen, eine Windows-Umgebung für diese Apps zu entwickeln.

Nun hat Apple aber den Store etwas anders aufgezogen: Jedes Programm, das auf einem Mac laufen kann, ist Store-tauglich. Als Kopierschutz prüft das Programm, ob es sich auf dem korrekten Rechner befindet (verkürzt gesagt). Diese Prüfung ist in jedem Programm enthalten, und je nachdem wie sorgfältig die programmiert wurde, desto aufwändiger ist ein Programm auf einem Fremdcomputer nutzbar. Werden alle von Apple empfohlenen Schutzmaßnahmen einprogrammiert, läuft ein Programm auf einem anderen Computer nicht, jedenfalls nicht, solange dort nicht der Kauf-Account ebenfalls eingerichtet wurde.

In meiner obigen Vision würde der Store eine Art Sandkasten bilden, in dem die Programme laufen. So wie Steam ein Sandkasten für Spiele ist, der gleichermaßen auf Windows und Mac läuft. Allerdings unterscheidet Steam zwischen Mac- und Windows-Spielen.

Da sich der Store also offenbar um vollwertige Programme kümmert, deren Leistungsfähigkeit und Möglichkeiten durch nichts beschränkt werden (weil sie eben nicht in einem Sandkasten oder einer Laufzeitumgebung laufen), ist ein Windows-AppStore von Apple eher unwahrscheinlich. Denn dazu würden sie ihr gesamtes System (bzw. die Systemaufrufe der Programme) auf Windows umsetzen müssen. Abgesehen von dem Aufwand besteht für Apple kein Interesse daran, seine Apps auch unter Windows anzubieten. Denn Apple verdient weniger daran, dass beispielsweise iPhoto, Aperture oder iWork auch auf Windows laufen als an den eigenen Rechnern.

Somit ergeben sich vier Möglichkeiten für die Zukunft:

1. Apple setzt tatsächlich einen Store für Windows um und verstärkt damit seine Position als Softwarehersteller und -vertreiber. – eher unwahrscheinlich
2. Apple schafft eine Laufzeitumgebung (Sandkasten) für Windows, die es ermöglicht, zahlreiche Programme laufen zu lassen (wie oben geschildert), aber eben mit einem begrenzten Funktionsumfang. – möglich, aber auch nicht wahrscheinlich.
3. Apple schafft eine Art Doppelstore (wie Steam) für Mac- und Windows-Apps. – auch nicht wahrscheinlich, denn an Windows-Apps verdient Apple nicht genug.
4. Apple sieht den MacStore als Mac-exklusiv an und stärkt damit die Entwicklung für die Mac-Plattform, indem Programmierer vom Vertrieb entlastet werden. Haben es die Programmierer einfacher, nicht nur zu programmieren (das ist ja schon so), sondern ihre Programme auch unaufwändig anzubieten/zu vertreiben (und damit Geld zu verdienen), wächst das Angebot an Mac-Software, was letztlich die Plattform stärkt. Wenn Kunden Programme einfacher kaufen, installieren und updaten können, ist das sicherlich auch von Vorteil. – die derzeit wohl wahrscheinlichste Entwicklung.

Der Mac-AppStore ist in seiner jetzigen Form gar keine so dramatisch aufregende Sache. Aber ebenso wie der iOS-AppStore könnte er die Plattform für Entwickler und Nutzer noch attraktiver machen. Die tatsächliche Relevanz steckt also weniger in der Store-Software als vielmehr in der Plattform. (mehr dazu)