Zum Inhalt springen

Mobile App Commodity

Mittlerweile dürften alleine für die iOS-Plattform von Apple über eine Million Applikationen verfügbar sein. Es hat sich aber auch herumgesprochen, dass nur ganz wenige davon profitabel sind. Unmengen an trivialen me-too-Anwendungen und mehr oder weniger nutzlosen Werbeanwendungen fluten alle Appstores, ob bei Apple, Google oder Microsoft.

Jede Plattform hat ihre eigene technische Basis, die sich von herkömmlicher Anwendungsentwicklung (bspw. Mac OS, Java Swing/SWT, .NET) leicht bis dramatisch stark unterscheidet. Die Entwicklungsumgebung wird vom jeweiligen Betreiber vorgegeben, es gibt aber auch 3rd-Party-Umgebungen um native Apps zu entwickeln.

Je nach Unternehmensziel ergeben sich viele Optionen und Plattformen: Zahlungskräftige Kunden mit einer vergleichsweise homogenen Hardwareausstattung kann man vermutlich am einfachsten im Apple-Ökosystem finden, die große Masse an Nutzern vermutlich eher im Play Store bei Google’s Android.

Soll es sich bei der mobilen Anwendung um eine Ergänzung zu einer Desktop-Software oder eines Web-Services handeln oder gibt es einen losgelösten mobile Use-Case? Bei letzterem führt meines Erachtens nichts an einer nativen Entwicklung vorbei, bei den anderen Zielen kann man gerade zu Beginn versuchen die Aufwände überschaubar zu halten und auf Brückentechnologien setzen:

Wer es ganz billig mag, kann mit Phonegap bzw. Apache Cordova eine Anwendung in HTML, CSS und JavaScript zusammenschrauben. Die Experience wird nie die einer “nativen” Anwendung sein, dafür kann man mit beschränkten Technologiekenntnissen einen Prototypen recht einfach realisieren.

Einen Schritt weiter gehen Cross-Compiler-Lösungen: Hier kann, mit unterschiedlich starker Abstraktionsebenen, in einer bekannten Programmiersprache entwickelt werden. Dies wird dann zur Compile-Zeit in Bytecode übersetzt und kommt (je nach Framework-Abstraktionsschichten) einer nativen Performance sehr nahe bzw. ist identisch. Ich persönliche setze hier sehr gerne RubyMotion ein, denn ich habe hier das beste aus allen Welten: Ich kann den Editor meiner Wahl (vim) zusammen mit der Sprache meiner Wahl (Ruby) nutzen und bekomme “automagisch” die nativen Framework-Objekte und Methoden “übersetzt”. Ein reiches Ökosystem an Erweiterungsmodulen (gems) abstrahiert dies auf Wunsch noch weiter, erlaubt eine noch schneller Entwicklung, aber auch weniger Kontrolle (und eine geringere Laufzeitperformanz).

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Es gibt mittlerweile eine große Anzahl solcher Cross-Compiler-Lösungen auf unterschiedlichen technischen Grundlagen: Xamarin, Appcelerator Titanium, RoboVM, Flash

Als dritter Weg bleibt die native Entwicklung mit dem jeweils offiziellen SDK. Dies ist der zukunftssicherste Weg, weil nur eine Abhängigkeit zum jeweiligen Plattformbetreiber und keinem Dritten besteht. Aber es ist vermutlich auch der Weg mit dem größten Aufwand…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.