Smartphone-Apps als Schriftenlieferanten.

Disclaimer: Mein Anwalt hat geprüft und in folgendem Text keine potentiellen Rechtsverstöße festgestellt. Die folgenden Schritte zeigen keine Vorgänge, die durch Deassemblieren von kompilierten Dateien entstehen, ebenso wird kein Kopierschutz geknackt, sondern lediglich eine Datei in einem De-Zip-Programm geöffnet.

Der meines Erachtens nach notwendige, auch wenn völlig bescheuerte Disclaimer erklärt eigentlich schon alles – Gängige Smartphone-Apps (egal ob Android oder iOS) enthalten neben Programminhalten, Grafiken und multimedialen Inhalten meist auch Schriftdateien, in der Regel im TTF- oder OTF-Format. Zwar haben App-Dateien eine eigene Dateiendung (unter Android „.apk“ und unter iOS „.ipa“), allerdings sind diese Dateien nichts anderes als handelsübliche Zip-Dateien, also im Zip-Format komprimiert. Benennt man App-Dateien in ihrer Dateiendung auf „.zip“ um oder öffnet sie in einem besseren Komprimierungsprogramm wie 7-Zip, dann zeigt sich auf einen Schlag das gesamte Gut. Im Falle der SPIEGEL-Reader-App für iOS zum Beispiel mit folgendem Inhalt:

Font-Dateien in Apps

Das ist nicht weniger als die gesamten SPIEGEL-Schriftfamilien, die zum Beispiel bei MyFonts.com mehr als 220 Euro kosten. Schiebt man diese Dateien aus der gezippten App-Datei direkt in den eigenen Schriftenordner … aber das darf ich nicht weiter beschreiben, denn natürlich ist so eine Nutzung der in der App gelieferten Schriften nicht gestattet (andererseits müsste das ein Lizenzvertrag auch explizit untersagen). Das Spiel kann man so weiterführen, denn viele Apps nutzen nicht die an sich reichhaltige Auswahl an im Mobilbetriebssystem integrierten Schriften, sondern bringen ihre eigene Hausschrift in voller Pracht mit.

iOS macht es da sogar deutlich leichter als Android, denn wer sein iPhone/iPad mit iTunes sichert, hat ein komplettes Backup aller installierten Apps auf der Festplatte. Man schaue (unter Windows) in den Benutzerordner, dort unter

"Eigene Musik\iTunes\iTunes Media\Mobile Applications"

Unter Android ist es nicht ganz so einfach, denn dort lassen sich installierte Apps nur auf dem Smartphone/Tablet selbst heraussuchen und das auch nur bei einem gerooteten Gerät. Dort befinden sich die Apps in

"/data/app"

Da Android Apps auch direkt von hier aus startet, sollten Apps hier nicht direkt geöffnet werden, sondern an eine Stelle im Smartphone kopiert, wo man dann mit einem Dekomprimierprogramm gefahrlos hineinschauen kann. Meist befinden sich innerhalb der App-Datei die Schriftarten im „assets“-Ordner.

Sicherheitshalber nochmal der Hinweis: So dahergeholte Schriftdateien sind in der Regel nicht zur Nutzung außerhalb der jeweiligen App lizenziert. Ich habe das jetzt hier laut und deutlich gesagt. Ich liebe Schriftarten und kaufe offiziell die Schriften, die mir gefallen, um damit auch die Leute zu unterstützen, die sie erstellen. Allerdings könnten genau diese Leute auch mal die Verkäufer ihrer Schriften bitten, wenigstens doch bitte mal ihre Schriften mit entsprechenden Flags auszustatten, die eine Installation als normale Schriftdatei in Betriebssystemen untersagen. Das ist für gewiefte Leute zwar auch keine echte Hürde, ist aber wenigstens nicht ganz so einfältig. Am sinnvollsten wäre es, wenn ein App-Programmierer mit etwas Phantasie solche wertvollen Assets halbwegs gut codiert und vor einfacher Entnahme schützt.

Microsoft Office außerhalb von Windows – eine Revolution.

Einer der ersten Amtshandlungen des neuen Microsoft-Chefs Satya Nadella ist die Veröffentlichung von Microsoft Office für das iPad. Viele Betreiber von iPhone/iPad-spezifischen Websites haben dabei bemerkt, dass die Software ungewöhnlich durchdacht und stabil ist, fast schon „zu stabil“ für eine Software in ihrer Erstveröffentlichung. Und natürlich darf zu Recht mutgemaßt werden, dass Microsoft Office für das iPad nicht erst vor einigen Wochen zusammengestrickt wurde, sondern vermutlich Monate, wenn nicht Jahre alt ist und nur noch nicht veröffentlicht wurde.

Während für Apple deren Betriebssystem MacOS nichts anderes als der zentrale Baustein ist, völlig überteuerte und mit allen Tricks der Inkompatibilitätskunst versehene Hardware zu verkaufen, so ist für Microsoft deren Betriebssystem Windows das Kernstück zum Verkaufen von Microsoft Office. Microsoft Office läuft (mit Ausnahme von MacOS) nur auf Windows – es gab niemals eine Linux- oder Unix-Version und es gab auch niemals eine Version für mobile Betriebssysteme wie Android oder iOS (bis jetzt), auch nicht für vorherige und einst recht erfolgreiche Systeme wie Symbian oder PalmOS. Nicht weil es nicht funktionieren würde, Microsoft Office auch für andere Betriebssystem zu portieren, sondern weil Steve Ballmer und vorher Bill Gates niemals auch nur im entferntesten daran gedacht haben, die einstige Cashcow namens Microsoft Office auf „minderwertige“ Betriebssysteme zu verschachern. Microsoft Office gab es lange Jahre nur auf Microsoft Windows und im Geschäftsumfeld ist das eine relevante Kombination, denn hier hat Windows im Enterprise-Umfeld letztendlich mit unixoiden Wettbewerbern zu kämpfen.

Es blieb daher nur bei halbherzigen und recht arroganten Lippenbekenntnissen. Einer der ältesten solcher Bekenntnisse habe ich in meiner Sammlung von interessanten Palm-OS-Links, datiert auf den 20. Oktober 2000, von niemand anderem verkündet als von Steve Ballmer: „Microsoft goes Palm – vielleicht„, aus dem Heise-Newsticker. Wenn man damals bei Microsoft begriffen hätte, dass die Zukunft vieler Anwendungen nicht mehr auf dem Desktop, sondern in der Cloud liegt, hätte Microsoft gute Chancen gehabt, mit einem plattformweit verteilten Microsoft Office den IT-Markt am Desktop und auch in der mobilen Welt bis heute im Griff zu behalten und Google nicht ansatzweise zu so einem Imperium wachsen zu lassen, wie es heute dasteht.

Aber, sie haben es nicht gemacht, dazu waren Gates & Ballmer zu sehr verhaftet im Gedanken, dass die Cloud nur für spezialisierte Anwendungen sinnvoll sei und dass es genügend Bekloppte gibt, die ein hoffnungslos hinterherhinkendes Betriebssystem wie einst Windows Mobile und nun Windows Phone einzusetzen, nur weil es hier ein Microsoft Office gibt.

„Office 365“ sprengt als Abo-Software mit etwas Cloud-Funktionalität zwar seit einiger Zeit diesen Gedanken schon in der Ära Ballmer, aber letztendlich haben die Veteranen dennoch nie begriffen, wie der Markt der ehemaligen Handhelds und der heutigen Smartphones und Tablets wirklich funktioniert. Und deshalb bin ich mir auch relativ sicher, dass in den Tiefen der Microsoft-Laboratorien Microsoft Office ziemlich sicher für alle heutigen und jemals existierenden modernen Betriebssystemen existiert, es sich aber bisher niemand so recht getraut hat, der Gates-Ballmer-Phalanx endlich einmal vorzuschlagen, die alten Zöpfe beherzt abzuschneiden.

Microsoft Office für das iPad ist daher nichts anderes als eine Revolution und ein Eingeständnis dafür, dass man mindestens 15 Jahre lang den Markt ignoriert hat und glaubte, dass letztendlich doch alle Wege zu Microsoft führen. Die Erkenntnis, dass es wohl doch nicht so ist, kommt spät, vielleicht sogar nicht ganz zu spät, aber diese Revolution wird kaum das wieder zurückholen können, was in diesen 15 Jahren an Einfluss verlorengegangen ist.

Apple und der kommende Untergang auf dem Smartphone-Markt.

Die heutige Apple-Keynote habe ich nicht live verfolgt, sondern auf die Ergebnisse gewartet. Keynotes sind Geschmackssache, Apple-Keynotes habe ich zumindest mal so lange verfolgt, wie ich Apple-Aktien hatte. Die habe ich seit einer Weile nicht mehr und okay, ich will nicht schimpfen, der Gewinn beim Verkauf war beträchtlich.

Nach den ständigen Gerüchten der letzten Monate, dass Apple angeblich ein Billig-iPhone plane, um damit der Billigkonkurrenz mit Android-Betriebssystem Paroli zu bieten, horchte ich dann heute trotzdem genauer hin. Das iPhone 5C hätte das Potential, tatsächlich mit iOS und als billiges Gerät den Markt untenherum aufzurollen, in dem viele Hersteller mit Android tollen, teilweise auch mit recht emotionsarmen Geräten. Und vor allem hätte Apple die Chance, in Märkte hineinzukommen, die sich das metallene Original schlicht nicht leisten können.

Und was macht Apple? Sie verkacken es so, wie man es nur verkacken kann.

Denn: Der Plastikbomber in Form des iPhone 5C wird, so wie es derzeit aussieht, in allen Ausbaustufen (16 und 32 GB) gerade einmal 100 Euro billiger sein, als die des iPhone 5S, also dem iPhone-Flaggschiff. Und damit kostet das billigste iPhone 5C mit 16 GB Speicherausstattung immer noch knackige 599 Euro. Bei Google gibt es für 599 Euro das Google Nexus 4 (199 Euro) und das Google Nexus 7-Tablet (229 Euro) und man hat am Ende noch 171 Euro übrig.

Und selbst so Oberklasse-Gerätschaften wie das Samsung Galaxy S4 kosten derzeit etwas über 300 Euro. Will man es luxuriös, konkurriert der iPhone-Plastikbomber preislich zum Beispiel mit dem kommenden Android-Flagschiff Sony Xperia Z1, das ebenfalls in der 600-Euro-Klasse einsteigen wird, aber bei weitem besser ausgestattet ist.

Mit 599 Euro Einstiegspreis für das billigste iPhone hat Apple ein klares Statement gestellt. Das Segment der günstigen und mittelpreisigen Smartphones will man nicht betreten und diese Segmente weiterhin Android überlassen. Das schon jetzt über eine Milliarde aktivierte Geräte zählt und jeden Tag eine Million mehr. Dass iOS daran arbeitet, nächsten Monat die Hürde der 700 Millionen Aktivierungen zu reißen, ist da kein hoffnungsvolles Signal, sondern eine Kapitulation.

Synchronisation von Kontakten zwischen iPhone und Google Contacts via CardDAV.

Seit einiger Zeit gibt es im Funktionsumfang von normalen Google-Konten einen kleinen Einschnitt in Sachen Funktionsumfang. Dieser Einschnitt betrifft die Synchronisation von Daten zwischen dem Google Kalender und Adressbuch zu iPhone und/oder iPad. Konnte man nämlich Kalender und Adressbuch bei allen Konten bis dato per ActiveSync synchronisieren (dass unter iOS „Microsoft Exchange“ heißt und auf Seiten von Google „Google Sync“), so ist das seit 30. Januar 2013 nur noch für Google-Konten möglich, bei denen bis zu diesem Datum Google Sync mindestens einmal eingerichtet wurde. Mit allen Google-Konten, die nach dem 30. Januar 2013 mit iPhone/iPad Kontakte und Kalender synchronisieren sollen, ist dieser Weg nun versperrt.

Aber: Es gibt Alternativen. Und zwar sehr gute, weil nämlich mit offenen Protokollen.

Kalender synchronisieren

Dazu sei an dieser Stelle nicht viele Worte verloren, weil ich hierzu vor einiger Zeit schon mal einen sehr umfangreichen Artikel geschrieben habe, der den Installationsweg ausführlich beschreibt:

Aber jetzt: Kontakte synchronisieren via CardDAV

Das CardDAV-Protokoll gehört ebenfalls zur Familie der WebDAV-Protokolle und ist speziell auf die Synchronisation von Kontaktdatenbanken ausgerichtet. Die Synchronisationsmechanismen sind dabei ähnlich zu CalDAV bei Kalendersynchronisationen, grundsätzlich ist CardDAV aber ein eigenes und auch relativ neues Protokoll. So neu, dass es beim iPhone bzw. im iOS-Betriebssystem von Anfang an gar nicht im Funktionsumfang war. Erst ab iOS 5 wurde CardDAV standardmäßig in iOS implementiert und ist seitdem auch verfügbar. Die Einrichtung einer CardDAV-Verbindung zum eigenen Google-Konto ist dabei relativ simpel und auf keinen Fall schwerer, als bisher mit Google Sync.

Der Startpunkt auf dem iPhone sind, wie immer, die Einstellungen und dort der Punkt “Mail, Kontakte, Kalender”. Hier geht es auf “Account hinzufügen …”. Der nächste Schirm zeigt die möglichen Synchronisationstechnologien dazu an:

iOS Synchronisationsauswahl

Alle DAV-Protokolle finden sich im letzten Menüpunkt, der etwas stillos unter dem Wort „Andere“ versteckt ist. Deshalb bitte hier drauf tippen, um zum nächsten Schirm zu kommen:

iOS Auswahl der DAV-Protokolle zur Synchronisation

Hier geht es nun richtig los, unter „Kontakte“ findet sich die Auswahlmöglichkeit zur Einrichtung eines CardDAV-Accounts. Bitte diesen Menüpunkt antippen und dann geht es schon darum, die eigenen Zugangsdaten zu hinterlegen:

iOS Einrichtung CardDAV

Die vorzunehmenden Einstellungen sind weitgehend selbsterklärend, deshalb nur im Schnelldurchlauf:

  • Account: Muss selbstverständlich aktiviert werden, hier lässt sich später aber dann auch vorübergehend die Synchronisation anhalten, falls das mal notwendig sein sollte.
  • Server: Ist die Gegenstelle, mit dem das iPhone-Gerät Verbindung zur Synchronisation aufnehmen soll. Das ist tatsächlich einfach nur „google.com“.
  • Benutzername: Das ist der Google-Kontoname, also im Normalfall die eigene Gmail- bzw. Googlemail-Adresse.
  • Kennwort: Selbsterklärend.
  • Beschreibung: Das ist eine Beschreibung, die frei gewählt werden kann. Bei mehreren konfigurierten Konten auf dem iOS-Gerät macht eine eindeutliche Beschreibung durchaus Sinn…

Wir gehen jetzt aber noch nicht zurück (und drücken natürlich auch nicht auf „Account löschen“), sondern wählen noch den Menüpunkt „Erweiterte Einstellungen“ für einen Kontrollblick aus. Der dortige Schirm sieht folgendermaßen aus:

iOS CardDAV Erweiterte Einstellungen

Hier geht es um die Verschlüsselung der CardDAV-Übertragung. SSL sollte hier aktiviert werden, der Standard-Port hierzu ist 443.

Nach dieser Überprüfung oben auf den Pfeil nach links „Google Contacts“ (oder wie auch immer die Beschreibung lautet) tippen, um zum vorherigen Schirm zurückzukommen. Dort dann nochmal auf den an der gleichen Stelle positionierten Pfeil tippen, der da lautet „Zurück“. Danach geht es nämlich nicht sofort zurück, sondern dann wird zunächst der Account geprüft. Hat alles seine Ordnung, erscheinen hinter allen Eingabefeldern kleine Häkchen und der Synchronisationsaccount ist erfolgreich eingerichtet.

Bitte dann einfach wieder zurück auf den Home-Bildschirm und mit einem Tippser auf die Kontakte-App gleich mal austesten, ob nun die ersten Adressen aus dem Google-Konto – sofern dort welche hinterlegt sind – eintrudeln.

Der Weg der Synchronisation

Ein spannendes Thema kommt an dieser Stelle: Hat man nämlich bisher Google Contacts nicht genutzt und sein Adressbuch ausschließlich auf dem iPhone gepflegt, dann passiert auch nichts. iOS synchronisiert ein lokales Adressbuch nicht ohne weiteres mit einem Adressbuch, das mit einem externen Dienst synchronisiert wird.

Damit also eventuell auf dem iPhone vorhandene Adressbestände ins Google-Contacts-Adressbuch kommen, müssen diese dorthin einmalig übertragen werden. Am einfachsten funktioniert das mit der iOS-App namens „My Contacts Backup“, die das Adressbuch auf iPhone/iPad als CSV-Datei exportieren kann. Diese kann man sich dann bequem per E-Mail an das eigene E-Mail-Postfach schicken lassen.

Hat man dann diese CSV-Datei, lässt sich diese auf der Website von Google Contacts unter https://www.google.com/contacts/ (ggf. zunächst anmelden) importieren. Auf der Hauptseite gibt es oben mittig angeordnet einen Button namens „Mehr“ und in diesem Untermenü dann den Menüpunkt „Importieren“. Dort dann einfach die oben generierte CSV-Datei importieren und schon nach einigen Augenblicken stehen die exportierten Adressen in Google Contacts zur Verfügung.

Hilfe! Alles doppelt!

Tatsächlich kann es zunächst passieren, dass nach der ersten Synchronisation im iOS-Adressbuch alle Kontakte doppelt auftauchen. Insbesondere dann, wenn wie im letzten Absatz der bisher lokal verwaltete Adressbestand in Google Contacts importiert wurde. iOS verwaltet alle Adressbücher strikt getrennt voneinander, also damit auch das lokale Adressbuch getrennt vom Adressbuch, das nun per CardDAV synchronisiert wird. Dass es hier mitunter dann Dubletten gibt, juckt iOS herzlich wenig.

Meine Empfehlung ist da ganz klar: Wer jetzt sein Adressbuch mit CardDAV synchronisiert und auch die lokalen Kontakte in Google Contacts importiert hat, auch nur noch mit diesem Adressbuch arbeiten und die lokalen Kontakte ersatzlos löschen. Sie gehen ja, wenn sie in Google Contacts importiert wurden, nicht verloren, sondern werden jetzt eben über die Google Cloud synchronisiert und das macht technisch gesehen keinen Nachteil aus. Denn der Zugriff auf einen synchronisierten Adressbestand ist selbst dann möglich, wenn das iOS-Gerät vorübergehend z.B. keine Verbindung haben sollte. Eine eventuell notwendige Synchronisierung erfolgt immer dann, wenn eine Netzverbindung besteht.

Also: Wenn es tatsächlich Dubletten in Ihrem Adressbestand gibt, dann ist die Vorgehensweise folgende (Bitte machen Sie dennoch unbedingt sicherheitshalber ein Backup mit der obig empfohlenen App):

  1. Schalten Sie vorübergehend die Synchronisation mit allen fernen Adressbüchern aus, sofern welche vorhanden und diese aktiv sind. Das können Sie bequem in den Einstellungen der einzelnen Adressbuchsynchronisationen tun, in dem sie den Schieber vorübergehend auf den „Off-Zustand“ schieben (siehe oben).
  2. Wenn Sie dann alle Adressbuchsynchronisationen ausgeschaltet haben, gehen Sie in die Kontakte-App und sehen hier dann logischerweise nur noch die Adressen, die tatsächlich lokal auf dem iOS-Gerät liegen. Wenn das dann tatsächlich die eine Hälfte der Dubletten ist, können Sie alle die lokalen Adressen hier getrost löschen.

Und wie lege ich nun neue Kontakte an?

Das ist jetzt nämlich echter Komfort: Es ist egal, wo Sie neue Kontakte anlegen – ob nun im iPhone, auf dem iPad (falls es auch mit Google Contacts synchronisiert), auf der Website von Google Contacts oder mit einem anderen Programm oder Gerät, das mit Google Contacts synchronisiert – sie haben nur noch eine Adressdatenbank und das ist die bei Google Contacts.

Sie machen es jetzt also wie die Profis mit dem Adressbuch – in der Cloud. Und wenn Ihnen aus irgendeinem Grund das iPhone abhandenkommt (sie es von der Ferne aus natürlich sperren), ist Ihnen wenigstens nicht Ihr Adressbuch abhanden gekommen, denn das liegt eben nun in der Cloud.

iOS und Google Sync nur noch bis Ende Januar.

Da die Artikel zum Thema Google Sync und iPhone in meinem Blog die mit Abstand am häufigsten aufgerufenen Artikel sind, hier doch nochmal ein wichtiger Hinweis für alle, die zukünftig ihr iPhone oder iPod per Google Sync mit ihren Kalendern und Adressbüchern in ihrem Google-Account synchronisieren möchten. Denn Google Sync steht auf der Abschussliste bei Google und für viele Nutzer ist Google Sync ab 30. Januar 2013 nur noch Geschichte.

Google Sync und der technische Hintergrund

Das Ende von Google Sync ist relativ einfach zu erklären, wenn man sich anschaut, was dahintersteckt: Eine Synchronisierungstechnologie namens ActiveSync von Microsoft. Und dazu ist dann ein kleiner Exkurs recht interessant:

ActiveSync hat eine recht lange Geschichte und hat seine Wurzeln im Mobilbetriebssystem Windows Mobile und der Möglichkeit zur Synchronisieren von Smartphone-Inhalten mit Windows-Betriebssystemen ab Windows 95 und NT 4. Für diese Anforderung wurde ActiveSync entwickelt und das war schon zu den Zeiten, als Windows Mobile mit dem einst allmächtigen Betriebssystem PalmOS von US Robotics konkurrierte, revolutionär. Denn während Palm-Geräte im am PC angeschlossenen Zustand nur dann synchronisierten, wenn die Synchronisierung am Gerät oder an der Dockingstation (die „Cradle“) die Synchronisierung explizit der Knopfdruck gestartet wurde, erledigten Windows-Mobile-Gerätschaften die initiale Autorisierung direkt nach dem Anstecken an den PC und synchronisierten während der Verbindung permanent, selbstständig und zuverlässig. Wurde in Outlook ein neuer Termin eingetragen, erschien dieser Termin im gleichen Moment auch im angeschlossenen Windows-Mobile-Gerät. ActiveSync machte es möglich und nicht zuletzt diese Technologie war ein wichtiges Abgrenzungskriterium zur Palm-Welt.

Aufgebohrt wurde ActiveSync dann später, in dem das Protokoll als Basis für die Synchronisierung zwischen Windows-Mobile-Geräten und dem Microsoft-Exchange-Server diente und fortan Exchange ActiveSync hieß. Das Prinzip der Echtzeitsynchronisierung blieb, lediglich der Übertragungsweg und die Gegenstation änderte sich. Nicht mehr der Bürorechner auf dem Schreibtisch war das andere Ende, sondern der Exchange-Server des Unternehmens, der dann die zu synchronisierten Inhalte direkt mit dem Postfach des Nutzers synchronisierte.

Und obwohl ja Microsoft verschrieen ist als ein Unternehmen, das rücksichtslos seine eigenen Standards entwickelt und verbreitet – ActiveSync hatte schon sehr früh eine relativ offene Lizenzierungspolitik und konnte von Herstellern von Personal Digital Assistants, später dann Smartphones, aber auch Herstellern von Mailsystemen und Betreibern von Maildiensten (kostenpflichtig) lizenziert werden. Das hatte natürlich einen Hintergrund, denn neben den Einnahmen durch die Lizenzierung war durch den Einsatz von ActiveSync potentiell das jeweilige Produkt auch fähig zum Kontakt mit Windows-Mobile-Gerätschaften oder auf der anderen Seite mit dem Exchange-Server.

Und da ergaben sich dann die seltsamsten Allianzen. Während z.B. RIM mit dem Blackberry und dem dazugehörigen Protokoll sowohl Endgeräte als auch Synchronisierungssoftware mit dem Mailsystem aus einer Hand liefert, können z.B. iPhone und Android-Geräte per ActiveSync mit dem Exchange-Server synchronisieren. Vorteil: Diese Synchronisierung kostet den Nutzer nichts, während bei Blackberry lange Zeit der Synchronisierungsdienst Geld kostete und zwar nicht zu knapp. Dass also ActiveSync so zuverlässig funktioniert und für Hersteller von Smartphones recht freizügig lizenziert werden kann, ist mit einer der Gründe, warum Microsoft lange Zeit die eigene Mobilbetriebssystemstrategie hat schleifen lassen und es hat ihnen zumindest im Business-Bereich nicht sonderlich viel finanziellen Schaden beschert. Das Lehrgeld in der Smartphone-Jungsteinzeit haben tatsächlich andere bezahlt.

Google und ActiveSync

Auch Google gehört zu den ActiveSync-Lizenznehmern und das wiederum aufgrund einiger Umstände:

  1. Google benötigt ActiveSync im hauseigenen Mobilbetriebssystem Android, um Android-Handys mit der Exchange-Welt synchronisieren lassen zu können.
  2. Google muss seine eigenen Kalender- und Kontaktedienste mit Schnittstellen zu ActiveSync ausstatten, um Smartphones mit anderen Betriebssystemen als Android eine Synchronisierung zu ermöglichen. Dies gilt insbesondere für das iPhone, denn obwohl das iPhone direkt (ohne ActiveSync) mit Google Mail synchronisieren kann, wird ActiveSync wiederum zum Synchronisieren von Kalender und Kontakten benötigt, da das iPhone hier keine eigenen Schnittstellen zu den Google-Diensten hat (warum auch immer).

Punkt 2 muss man sich ob des Irrsinns auf der Zunge zergehen lassen – weil Apple und Google zu doof sind, iOS und Google-Dienste vollständig miteinander synchronisieren lassen zu können, muss ausgerechnet ein lizenzpflichtiges Microsoft-Protokoll den Lückenfüller machen.

Und weil genau das Kostenthema der ActiveSync-Lizenzierung für die (kostenlos nutzbaren) Google-Dienste eine Rolle spielen dürfte, ist ActiveSync nun wohl bei der Synchronisierung der Google-Accounts auf der Abschussliste. Immerhin gibt es aber einige begrenzende Ausnahmen für das Ende:

  • Wird ein Google-Account bis zum 30. Januar 2013 noch mit ActiveSync synchronisiert, bleibt diese Möglichkeit für diesen Account auch darüber hinaus noch erhalten. Das Ende gilt also ab 30. Januar 2013 nur für bis dato noch nicht per ActiveSync synchronisierende Google-Accounts. Inwiefern es bis zu diesem Datum tatsächlich aktiv genutzt werden muss oder ob die Nutzung irgendwann in der Vergangenheit schon ausreicht, wird sich zeigen.
  • Ebenfalls nicht betroffen von dem Ende sind Google-Accounts, die innerhalb der inzwischen auch kostenpflichtigen Google Apps angelegt sind. Google-Apps-Accounts werden also auch weiterhin per ActiveSync synchronisieren können und wer da noch das Glück hatte, in der vergangenen Kostenlos-Zeit einen Google-Apps-Account einzurichten, lebt immer noch komplett kostenlos.

Die kostenlosen Protokollalternativen zum Synchronisieren

Google beendet das Synchronisieren mit ActiveSync vor allem auch deshalb, weil es inzwischen kostenlose Protokolle zum Synchronisieren gibt, die auch hinreichend zuverlässig sind. Für das Synchronisieren von Kalender ist dies das CalDAV-Protokoll und für das Synchronisieren von Kontakten das CardDAV-Protokoll. Beide Protokolle sind (inzwischen offizielle) IETF-Standards und im Falle von CardDAV eine beschwerliche Geburt hinter sich.

Das ist auch einigermaßen nachvollziehbar, denn ein einheitlicher, herstellerübergreifender Standard liegt zunächst einmal nicht im Interesse der Hersteller von eigenen, proprietären Protokollen und da lange Zeit die Motivation an echten freien Protokollen fehlte, dauerte es auch dementsprechend, bis beide Protokolle jeweils die Hürden genommen hatten, um als IETF-Standard zu gelten – zumal alle involvierten Hersteller innerhalb der IETF auch an der Standardisierung beteiligt waren. Das Wort „Sabotage“ will niemand in den Mund nehmen, aber IETF-Standardisierung ist mitunter auch interessant für Beobachter, die sich für Rudelbildungen im Tierreich interessieren.

Was zu tun ist … Empfehlungen

Also, grundsätzlich: ActiveSync muss niemand unbedingt einsetzen, der auch CalDAV und CardDAV einsetzen kann. Beide Protokolle sind gleichwertig funktional, wenn es um die Synchronisierung von Kalender- und Kontaktdatenbanken geht. Selbstverständlich ist ActiveSync deutlich mächtiger, allerdings richten sich viele Funktionen von ActiveSync vornehmlich an Unternehmen, die z.B. in einer Exchange-Infrastruktur alle Arten von Clients – vom Windows-Rechner mit Outlook bis zum iPhone – synchronisieren und zentral verwalten müssen.

Innerhalb von Google-Diensten ist ActiveSync bzw. der eigene Name „Google Sync“ immer als bisher mehr oder weniger notwendige Alternative zu verstehen. Es besteht also kein Grund zur Panik und auch nicht zu übermäßiger Hektik in Sachen Synchronisierungen zum Google-Konto einrichten. Wer bis zum 30. Januar 2013 Google Sync bzw. ActiveSync nicht einsetzt, wird es auch danach nicht vermissen, den selbst das iPhone, die Ausgeburt an Apple-Scheuklappentum in Sachen offenen Standards, unterstützt CalDAV und CardDAV

Zu erledigende Aufgaben für Besim

Das inzwischen gewachsene Sammelsurium an Blog-Artikeln, die sich mit der Synchronisierung zwischen Google-Konto und iPhone beschäftigen, aktualisieren. Die Artikel, die Google Sync erklären, werden mit Hinweisen darauf versehen, dass Google Sync nicht mehr bei allen Arten Google-Accounts funktioniert, der Artikel zu CalDAV so überarbeitet, dass es wieder als Empfehlung gilt und ein Artikel zu CardDAV neu geschrieben, das ich bisher großflächig ausklammerte, weil die CardDAV-Unterstützung von Google vor zwei Jahren, als ich das erste und bis dato letzte Mal in dieser Konstellation mit CardDAV experimentierte, schlicht unmöglich war.

Manchmal hilft die wohltuende Wirkung der Zeit doch, dass Hersteller sich ihren Möglichkeiten zur Interoperabilität bewusst werden.

Obama 2012 – Der Wandel von der App zur Web-App.

Eigentlich sollte dieser Artikel eine Fragestellung erörtern. Nämlich die, ob es in einem Wahlkampf sinnvoll ist, eine eigene Smartphone-App zu haben oder ob man lieber auf eine Web-App setzt, also eine Website, die funktional und optisch auf Smartphones so aussieht, als ob sie eine App wäre. Die Wahlkampf-Website so eine Web-App-fähige Website, die in einem responsive Webdesign erstellt ist und deren Ansicht sich der Bildschirmgröße des anzeigenden Gerätes anpasst.

Begonnen wurde die Obama-2012-Kampagne 2011 auch mit einer eigenen App für Smartphones, genauer gesagt für das iOS-Betriebssystem von iPhone und iPad. Als ich nun darüber bloggen wollte, stellte sich heraus, dass diese App schon seit längerer Zeit nicht mehr zur Verfügung steht. Und der Grund dazu ist herzlich einfach: Es gibt keine Notwendigkeit dafür.

Historische Ansichten in die Obama-2012-App.

Die Obama-2012-App als besonderes Highlight zu bezeichnen, wäre vermessen. Vom Prinzip her ist das Konzept das eines betriebseigenen Kiosks und keine der Inhalte, die in dieser App abgerufen werden können, sind wirklich exklusiv, da sie auch auf der Wahlkampf-Website zu finden sind. Die Startseite der App verweist schon auf alle Bereiche in der App:

„Latest News“ führt auf einen Nachrichtenbereich, der exakt dieselben Nachrichten enthält, wie auf dem offiziellen Wahlkampf-Weblog. Mit einem Tippser auf eine Nachricht lässt sich diese dann lesen:

Die Rubrik „Photos & Videos“ stellt auf einem Bildschirm eine Übersicht über Bilder und Videos im Wahlkampf zusammen:

Während die Videos recht anschaubar sind, sind die Fotos reine Makulator und eigentlich unansehnlich, weil völlig pixelig. Zudem fehlt jegliche Sortierung, so dass diese Bilderwand nicht viel mehr als Show ist:

Interessanter, aber auch nicht wirklich weltbewegend neu ist die Rubrik „Events“, die, wenn man der App in den Einstellungen den aktuellen Standort in Form des US-ZIP-Codes spendiert hat, passend zum aktuellen Ort die nächsten Events anzeigt. In meinem Beispiel wohnte ich z.B. im beschaulichen Honolulu auf Hawaii. Mit einem Tippser auf die Stecknadel lassen sich nähere Informationen zum jeweiligen Event anzeigen:

Dinge, die gegen und für eine App sprechen.

Tatsächlich war es eine gute Entscheidung, diese App nicht wirklich in den Wahlkampf mitzunehmen und schon nach wenigen Monaten einzustampfen, bevor wirklich Befürworter und Wähler mit dieser App enttäuscht werden könnten. Denn der Mehrwert gegenüber einer mobil gut erreichbaren Seite ist nahe Null. Mit einer Ausnahme, weshalb diese App vermutlich einst auch entwickelt wurde: Der Push-Service von iOS, der für die Verteilung der Nachrichten eingesetzt wurde. Mit dem Push-Service wurde wohl die Idee verfolgt, bei Neuigkeiten direkt über den Push-Service den Besitzer des iOS-Gerätes zu informieren.

Rein faktisch gesehen ist das aber nicht notwendig, weil neue Nachrichten im Wahlkampf-Weblog auch über die Twitter-Kanäle von Barack Obama angekündigt werden und hier mit vielen Twitter-Clients und dem Konfigurieren von bestimmten Regeln ein Push-Service einsetzen lässt. Oder auch über Facebook oder über gutes, altes Syndizieren via RSS-Feed.

Dass bei Barack Obama dennoch nicht auf ein Home-Symbol verzichtet werden muss, lässt sich anschaulich beobachten, wenn die Wahlkampf-Website mit Safari unter iOS (iPad und iPhone) aufgerufen wird. Tippt man dort (iOS 6) auf das Weiterleiten-Symbol, erscheint folgendes Menü und da ist der mittlere Button genau die gewünschte Ansage:

Bei solchen Apps darf man einen Punkt nicht verheimlichen: Wo App draufsteht, ist meist nicht viel mehr drin, als ein Webbrowser. Das gilt auch für die einstige Obama-2012-App und für viele andere Apps für SmartPhones, die lediglich aus Prestigegründen in Form einer App daherkommen, hinter den Kulissen aber die meisten Inhalte online aus dem Web beziehen.

Eine Web-App bzw. ein Widget ist die einzig konsequente Antwort für solche Informationsdienste, da so mit gängigen Technologien wie HTML 5, JavaScript und dem Document Object Model (DOM) ein wirklich plattformübergreifendes Angebot geschaffen werden kann, das auf allen gängigen Smartphone-Umgebungen von Hause aus läuft.

Mitt Romney geht App.

Das Team um Mitt Romney fährt nach wie vor eine App-Strategie und ist sogar mit zwei eigenen Apps im iOS-AppStore vertreten:

Die App „Romney-Ryan“.

Diese App ist die offizielle App und stellt sich wohl als Antwort auf die einstige „Obama-2012-App“ dar. Und leidet genau unter den Krankheiten, die funktionsarme Apps von Hause aus haben – außer Prestige liefert die Apps nur Inhalte, die auf der Wahlkampf-Website von Mitt Romney sowieso zu finden sind:

Die Frage, warum das Team Romney auf Apps setzt, hat wohl mehrere Gründe und zeigt sehr schön, dass auch beim Verständnis in Sachen Mobile Computing das Team Romney nicht ansatzweise die gängigen Möglichkeiten ausschöpft:

  • Eine App gilt als schick und modern, während eine Website als „zu normal“ gilt – zumindest bei Menschen, die Smartphones und Mobile Computing vornehmlich als Statussymbol ansehen und weniger für echte Kommunikation. Das Herunterladen einer App aus dem AppStore und das Erscheinen eines eigenen App-Symbols auf dem iPhone-Home-Bildschirm ist nun einmal auch eine Art von Marketing.
  • Zur Informationsvermittlung sind zwar Web-Apps gegenüber echten Apps weitgehend ebenbürtig, allerdings nur bei kommunikativen Anwendungen. Spiele und Anwendungen, die auf besondere Hardware eines Smartphones setzen wie z.B. die Kamera sind (derzeit zumindest) nur als App realisierbar. So hat ausgerechnet die ansonsten sinnfreie „With Mitt“-App durchaus ihre Berechtigung, weil die Kamera- und Bildbearbeitungsfunktion derzeit nur in einer App zu realisieren ist.

Die Nachteile der App-Strategie finden sich im Team Romney auch gleich und zwar alle zusammen:

  • Die Wahlkampf-Website ist nicht mit einem responsive Webdesign erstellt und kennt nur eine Bildschirmgröße. Für mobile Webbrowser ist daher eine Weiche im HTML-Code eingebaut, die diese dann auf einen Server namens m.mittromney.com“ schickt, auf der explizit eine mobile Website gehostet wird, die allerdings reichlich umständlich zu bedienen ist.
  • Eine App funktioniert natürlich nur auf der Plattform, für die sie entwickelt wurde. Im Falle der Romney-Apps gibt es nur Versionen für iOS-Betriebssysteme und z.B. nicht für Android. Zwar können andere Betriebssysteme über dort installierte Webbrowser dennoch auf die mobilen Websites zugreifen, allerdings ist eine App-Strategie, die nur auf einzelne Plattformen zielt, eben nur eine unvollständige App-Strategie.

Die App „With Romney“.

Diese App ist nicht sonderlich ernstgemeint (hoffentlich zumindest!) und dient zur Erzeugung von „Unterstützerplakaten“ aus eigenen Fotos. So kann der iPhone-Besitzer oder auch das zum Besitzer korrespondierende Haustier seine innige Zuneigung zu Mitt Romney mitteilen:

Ob so eine Nonsens-App, die sehr an die Idee mit dem „Hope“-Plakaten im Wahlkampf von Barack Obama im Jahr 2008 erinnert, tatsächlich neue Wählerschichten erschließt, darf bezweifelt werden. Eine eh schon schlechte Smartphone-Strategie wird dadurch jedenfalls nicht automatisch besser.


Alle Teile meines Dossiers zu Obama 2012 unter dem Stichwort „Obama 2012“.

Die mobile Halbherzigkeit von Apple Safari in Sachen FTP.

Ich habe mehr oder weniger aus Jux und Dollerei gerade einmal probiert, ob der Mobile Safari, der Webbrowser auf iOS-Gerätschaften, FTP beherrscht. Und tatsächlich, ich war sehr gut beraten, die ansonsten eigentlich schon prädestine, museale Ausstattung des Mobile Safari nicht in einer Wette dazu zu nutzen, eine Gegenwette abzuschließen. Denn tatsächlich beherrscht der Mobile Safari FTP. Allerdings, und da bleibt sich Apple treu, so bescheuert schlecht, dass es doch schon wieder alle Vorurteile erfüllt.

Als Webbrowser FTP zu können, ist leichter gesagt, als getan. Denn im Gegensatz zum Web ist FTP vor allem eine Geschichte, die für gewöhnlich passwortgeschützt passiert. Hier mal mein Setup:

Meine Fritzbox hat einen angeschlossenen USB-Stick, das ich als Speicherlaufwerk einsetze. Mit der VPN-Funktionalität der Fritzbox habe ich auf diese Weise eine ziemlich praktische Home-Cloud, die ich aus dem Internet problemlos erreichen kann – per VPN und innerhalb meines LAN dann per SMB („Windows Netzwerk) oder auch per FTP. Im Webbrowser gebe ich für diesen Zugriff einfach ein:

ftp://fritz.box/

Normale Webbrowser probieren den FTP-Zugriff und bekommen dann von meiner Fritzbox die Rückmeldung, dass der FTP-Zugriff nicht anonym erfolgen kann, sondern Zugangsdaten erforderlich ist. Normale Webbrowser kennen dieses Verhalten und fordern den Benutzer mit einem Passworteingabefeld auf, Zugangsdaten einzugeben, mit denen dann der FTP-Zugriff nochmals durchgeführt werden kann, nun eben mit Authentifizierung.

Für Apple scheint dies völlig neu zu sein. Denn gebe ich einfach die obige Adresse ein, fragt mich der Mobile Safari nicht etwa nach Zugangsdaten, sondern lässt mich im Regen stehen:

Keine Zugriffsrechte
Sie haben nicht die erforderlichen Zugriffsrechte, um „/“ anzuzeigen.

Darauf wäre ich gar nicht gekommen.

Allerdings sind wir ja nicht vollkommen blöd, sondern wissen ja, wie das URL-Schema funktioniert. Und das URL-Schema hat feste Regeln, wie man neben einer Adresse auch Zugangsdaten übermittelt:

ftp://benutzername:passwort@fritz.box

Und siehe da: So funktioniert das sogar im Mobile Safari, danach bin ich auf meinem Speicherlaufwerk und kann Dateien herunterladen.

Eine ganze Reihe von Nachteilen gibt es, allesamt Mobile-Safari-Schwächen:

  • Es wird nur FTP unterstützt, nicht die verschlüsselte Variante SFTP. Das ist freilich nur ein „weiches“ Problem, denn SFTP unterstützen auch andere Webbrowser nicht. Damit ist der FTP-Zugriff per Webbrowser immer eine Geschichte, die man, wenn es um sensible Daten geht, nur mit einer zusätzlichen Transportverschlüsselung machen sollte. Da der FTP-Zugriff zu meiner Homecloud nur innerhalb meines LAN funktioniert und ich vom Internet aus zwangsläufig ein VPN nach Hause benötige, ein in diesem Szenario vernachlässigbares Problem.
  • Mobile Safari kennt zwar das URL-Schema und die Art und Weise, wie in diesem Schema Zugangsdaten übermittelt werden, allerdings ist die Umsetzung halbherzig. Denn den obigen URL mit integriertem Passwort kann ich so nicht als Lesezeichen hinterlegen, sondern würde gern folgendes als URL verwenden:ftp://benutzername@fritz.boxMit diesem URL können nämlich alle anderen, FTP-fähigen Webbrowser etwas anfangen und fragen nur noch das Passwort ab, das für den Zugriff notwendig ist. Mobile Safari kann mit diesem URL nichts anfangen.
  • Sehr, sehr wichtig: Mobile Safari führt, so wie jeder andere Webbrowser auch, einen URL-Verlauf, in dem alle aufgerufenen URL der letzten Zeit gespeichert werden. Leider speichert Mobile Safari hierbei auch Adressen, in denen sich Benutzernamen und/oder Passwörter befinden. Um das zu verschmerzen, gibt es zwei Möglichkeiten. Das so genannte „private Surfen“ in den Safari-Einstellungen aktivieren oder an der gleichen Stelle den Verlauf löschen. Ist leider relativ umständlich, weil beide Dinge nicht direkt im Mobile Safari vorgenommen werden können, aber leider nicht unwichtig, wenn man sensible Zugangsdaten nicht im Verlauf herumspazieren möchte.

Nun gut, immerhin kann Mobile Safari FTP-Zugriff so auch mit Zugangsdaten, wenn auch auf eine ziemlich vorsintflutliche Weise. Schön sehen die Dateiauflistungen auch nicht aus, aber technisch funktioniert es und ich kann Inhalte aus meiner Homecloud auf iPhone/iPad herunterladen.

Google Tasks auf iOS und Android.

Einer der Dinge, die mich  von Anfang an in Apples Mobilbetriebssystem iOS und auch in Android gestört haben, war eine fehlende ToDo-Verwaltung. Es ist mir unverständlich, wie man ansonsten alle PIM-Anwendungen wie Kalender, Kontakte, Notizzettel integrieren kann, dann aber eine simple ToDo-Verwaltung außen vor lässt.

Das Ergebnis auf beiden Plattformen ist dementsprechend desolat: Es blühen die Todo-Anwendungen von Drittanbietern und sie blühen in der Regel mehr schlecht als recht. Die eine Gruppe an solchen Apps macht es mit der Verwaltung entweder zu einfach oder viel zu kompliziert, die meisten Apps synchronisieren mit keinem gängigen Dienst und die wenigsten Apps sind kostenlos und im Gegenzug dafür sogar richtig unverschämt teuer. ToDo-Verwalten für 5 oder gar mehr Euro?

Meine private und geschäftliche ToDo-Verwaltung läuft unter Google Tasks, das von Google bis vor kurzem noch ziemlich stiefmütterlich behandelt wurde, inzwischen aber sogar eine offizielle API hat. Wenn man mit dem Umstand lebt, dass Google Tasks kein eigenes Webinterface hat und derzeit nur via Google Mail oder über ein Widget in iGoogle bedienbar ist, kann man damit ganz gut leben. Seine Klasse spielt Google Tasks schon allein dadurch aus, dass es extrem simpel ist und die Verschachtelung von Aufgaben einfach dadurch realisiert, in dem Aufgaben einfach „unter“ bestehende Aufgaben geschoben werden und mit frei definierbaren Aufgabenkategorien gearbeitet werden kann. An umfangreiche Priorisierungen hat man einfach keinen Gedanken verschwendet, das realisiert man einfach durch das Verschieben von Aufgaben nach oben oder nach unten oder vergibt Aufgaben einen festen Fälligkeitstermin. So einfach kann es gehen.

Wenn man Google Tasks mit einer iOS- oder Android-App synchronisieren will, fällt glücklicherweise der größte Teil der ToDo-Apps gleich durchs Raster – die meisten nutzen Google Tasks nicht zum synchronisieren. Das macht die Auswahl dann auch gleich leichter. Gelandet bin ich dann bei zwei Apps namens „GoTasks“. Witzigerweise heißt nämlich die beste App für die Synchronisierung von Google Tasks für iOS genauso wie die App für Android, obwohl beide Apps miteinander nichts zu tun haben und jede App von einem anderen Programmierer gepflegt wird, die dann wiederum aber beides Russen sind. Zufälle.

Beide Apps kosten nichts, beide sind werbefrei, beide funktionieren sowohl auf Smartphones, als auch auf Tablets und beide funktionieren zuverlässig, auch mit Google-Apps-Konten:

Einen kleinen Wermutstropfen gibt es lediglich für GoTasks für Android: Offenbar lässt sich die App nicht auf allen Android-Gerätschaften finden. Auf meinem Samsung Galaxy S2 mit Android 2.3.4 ist es nicht auffindbar und im Web-Market wird angezeigt, dass mein Gerät nicht kompatibel sei. Es funktioniert aber, wenn man die App schon vorher installiert hat, sie ist also soweit kompatibel. Falls jemand mit Android die App nicht findet, bitte einfach mal kurz melden.

Warum es egal ist, ob Android oder iOS mainstream oder premium sind.

Da sind wir wieder, bei der immer gleichen Sau, die regelmäßig durchs Dorf getrieben wird und sich um das Thema dreht, ob nun Android oder iOS das bessere Betriebssystem ist. Aktuell sind wir bei der unglaublichen Feststellung von „Digital-Pionier“ Christoph Kappes im D&W-Magazin, der sinniert, dass Android „mainstream“ sei und iOS „premium“. Wollte ich mir eine Antwort sehr einfach machen, würde ich einfach mit einem Link auf einen x-beliebigen Handyshop antworten, denn diese Feststellung lässt sich dort schon allein mit den Preisen für iOS- bzw. Android-Gerätschaften darlegen. Mal so am Rande: Die Säue, die man durchs Dorf treibt und Aufregung verursachen, waren auch mal besser.

Anyway: Die Frage, ob ein Premiumprodukt, das das bessere ist, auch tatsächlich funktioniert, ist eine, die nichts, aber auch wirklich nichts mit Qualität zu tun hat. Gerade in der Unterhaltungselektronik überlebt selten das beste System, sondern allenfalls das, was die meiste Marktdurchdringung gewinnt. Solche Marktdurchdringungen werden dabei auf verschiedenste Weisen erkauft, in der Regel durch knallharte Subventionierungen. Entweder ist das Produkt gänzlich kostenlos oder es wird ordentlich günstig verscherbelt. Es wird aber gepusht und das ist das zentrale Kennzeichen.

iOS kann man allein schon dadurch zu einem Premium-Produkt zählen, dass es nur ein Hersteller für seine Geräte verbaut und der diese Monokultur auch kräftig ausnutzt. So kräftig, dass iOS bzw. iPhone und iPad letztendlich nur für einen verhältnismäßig kleinen Kreis von weltweiten Nutzern erschwinglich ist. In den meisten Staaten dieser Erde wird der Otto Normalverbraucher sich ein iOS-Gerät schlicht nicht leisten können, weil es zum einen keine „Billigversionen“ von iPhone und iPad gibt und Apple auch überhaupt kein Interesse daran hat, zumindest so lange die Märkte in der „Ersten Welt“ nicht gesättigt sind. Android geht den Weg über die Breite, baut also, schematisch gesehen, ein Framework, das dann Hersteller für ihre eigene Hardware adaptieren können, mit all den damit verbundenen Vor- und Nachteilen.

Ironischerweise erheblich unwichtig ist die Frage, ob nun Android oder iOS das bessere Betriebssystem ist. Grundsätzlich haben beide Betriebssysteme einen relativ hohen Grad an Benutzerfreundlichkeit erreicht und es geht in der Entwicklung von zukünftigen Versionen weitgehend nur noch um Detailfragen und um Kompatibilität zur Hardware, was Android naturgemäß vor deutlich höhere Hürden stellt, als iOS. Was Android mit diversen Bedienelementen wettmacht, die iOS (noch) nicht hat, macht iOS wiederum mit weitgehender Idiotensicherheit wieder wett und umgekehrt. Das wichtigste Ziel der Attraktivität ihrer Betriebssysteme haben beide erreicht: Eine verhältnismäßig große Softwarevielfalt in Sachen Apps.

Das wird erheblich deutlicher, wenn man sich mal die Mühen macht, die echten Kriegsschauplätze in Sachen Mobilbetriebssysteme anzuschauen, nämlich jenseits des angeblichen Kampfes zwischen Android und iOS. WebOS/Palm hat sich durch die (in meinen Augen krasse) Abkehr Hewlett-Packards von der Consumerelektronik erledigt, RIM kämpft mit seinem extrem abgeschirmten und in Consumerbereich quasi kaum sinnvoll nutzbaren Blackberry um jeden Kunden. Microsoft versucht mit Windows Mobile mit extremem Aufwand, an alte Zeiten anzuknüpfen und kann relativ bequem Blackberry-Anwender abschöpfen, die mit Windows Mobile zur „Mutterplattform“ in Sachen Exchange- bzw. Active-Sync-Synchronisierung kommen. Was dann noch hinter Blackberry und Windows Mobile kommt, hat ganz schlechte Karten und kaum über homöopathisch wirkende Reichweiten kommen.

Den vielbesungenen Krieg der Mobilbetriebssysteme Android und iOS – ich bin mal so frei und behaupte, dass das vor allem ein Krieg ist, der bei den Kleingeistern dieser Welt, die schon damit überfordert sind, zwischen App, Webapp und Widget zu unterscheiden, am stärksten gekämpft wird. Und diesen Krieg, den interessiert, mit Verlaub, kein Schwein.