Deine PWA im App Store
PWA’s sind geil! Mittlerweile werden enorm viele native Funktionen unterstützt. So kann man die UX von Mobile-Webseiten schnell und einfach aufbessern. Doch einen Nachteil hat die Technologie: Die Nutzer:innen sind nicht darauf sensibilisiert. Ich habe deswegen versucht, eine PWA in den App Store zu bringen.
Für uns Entwickler:innen bringt diese Technologie viele Vorteile, die Nutzer:innen gehen dabei aber oftmals vergessen. Als ich meinen Eltern erzählte, dass ich eine eine PWA entwickelt habe, verstanden sie kein Wort. Selbst meine Freunde schauen mich fragend an, wenn dieser Begriff fällt.
Die Lösung dafür ist relativ simpel: Hybride Apps.
Mit einer Hybriden App wird eine Webseite durch einen Webview in eine native App umgewandelt. So ein Webview ist nicht sehr komplex. Er funktioniert wie ein Browser, aber ohne die Navigationsleiste. Du rufst also ganz einfach deine Mobile-optimierte Webseite in einer App auf.
Für wen lohnt es sich?
Hybride Apps sind nicht für alle App-Arten geeignet. Für Games eignen sie sich nicht besonders, da die Performance stark leidet. Hier kann es sich zu beginn lohnen, eine hybride App zu veröffentlichen, wenn das Game sowieso im Browser verfügbar ist. Langfristig wirst du hier aber eine native App entwickeln müssen.
Auch für einfache Webseiten lohnt sich eine App nicht. Nicht nur hybride Apps sind hier überflüssig. Auch native Apps, die einfach eine Webseite abbilden, machen nicht wirklich Sinn. Als Faustregel würde ich sagen: Wenn du dich einloggen kannst, lohnt es sich. Sonst nicht.
Make it feel native
Auch ein wichtiges Learning aus dem Ganzen: Eine App im App Store sollte ich anfühlen wie eine App. Burger-Menüs, externe Links oder ähnliche Elemente, die wir gerne auf Webseiten verwenden, haben darin nichts zu suchen.
Ich habe für beide Apps eine zweite Code-Base angelegt, die wirklich nur für Mobile optimiert wurden. Es reicht also nicht, einige Breakpoints in deine PWA einzubauen.
Selbstversuch – wie einfach ist es wirklich?
Ich habe versucht, selbst eine solche Hybride App in den Apple App Store und in den Google Play Store zu bringen.
Dazu habe ich zwei Varianten ausprobiert: Custom Code und WebViewGold. Da ich nicht zweimal die gleiche App in den Stores veröffentlichen konnte, habe ich auch zwei PWA’s gemacht. Zum einen onabudget.io, eine günstige Budget-App, und zum anderen ein Milchbüechli (MILKEE), eine Buchhaltungssoftware für Einzelfirmen.
Bei onabudget.io habe ich den Code selbständig geschrieben. Dafür dienten mir verschiedene Tutorials auf YouTube, wie zum Beispiel dieses hier.
Bei MILKEE habe ich WebViewGold verwendet. Dies ist ein vorgeschriebener Code, der verspricht, «out of the box ready» für den App Store zu sein.
Ich will hier nicht zu sehr ins Detail gehen, deswegen kommen wir auch schon zum Fazit.
Das Ergebnis
Zusammengefasst: Der Custom Code konnte ich in beiden Stores, also Apple App Store und Google Play Store veröffentlichen. Der Code von WebViewGold wurde in beiden Stores vermehrt zurückgewiesen.
Zeitaufwand
Ich habe keinerlei Erfahrungen in der App-Entwicklung. Deswegen schien mir WebViewGold zu beginn eine schlaue Lösung zu sein. Am Ende des Tages habe ich aber mehr Zeit damit verbracht, diesen Code anzupassen, als ich für meinen Custom Code hatte. Zudem kostet das ja noch 90 Franken. Für mich also kein guter Deal.
Kosten
Die Kosten für diesen Spass sind relativ hoch. Nebst den 90 Franken für WebViewGold benötigst du auch noch eine Mitgliedschaft im Apple Developer Programm für 109 Franken im Jahr. Der Google Play Store kostet einmalig 25 Franken für alle Apps.
(dbo)
Idee
Die Idee entstand aus einem vorherigen Digezz Projekt – MILKEE. Das Tool für die Milchbüechli Rechnung benötigte früher oder später eine App. Ich setzte zuerst eine mobile-optimierte PWA um, war aber nicht wirklich zufrieden damit. Die Nutzer:innen von MILKEE haben die PWA nicht aktiv verwendet. Ich wurde regelmässig gefragt, ob es denn eine App dazu gibt oder wann diese im App Store erscheinen wird. Aus diesem Grund entschied ich mich, tatsächlich eine App zu veröffentlichen.
Prozess
Ich habe mir anschliessend in die Materie eingelesen und bin dann zum Schluss gekommen, entweder eine Hybrid App oder eine React Native App zu erstellen. Ich entschied mich dann einfachheitshalber dafür, zuerst mal eine hybride App umzusetzen. Als ich mit dem Coden begann, fand ich dann per Zufall den Service WebViewGold. Es schien fast schon zu gut, um wahr zu sein. Deswegen packte ich noch eine alte Web-App aus, die ich mal entwickelte und versuchte beide Varianten – selbst geschriebener Code und WebViewGold.
Im verlaufe der Entwicklung merkte ich dann immer mehr, dass eine mobile optimierte Webseite keine gute App abgibt. Im Gegenteil, sie demotivierte einem mehr, sie zu verwenden. Aus diesem Grund schrieb ich dann zusätzlich zu meiner bestehenden Webapp für MILKEE noch eine zweite Webapp, die nur für Mobile optimiert ist. Grundsätzlich teilen sich die beiden Apps eine Code-Base. Jedoch wird beim Laden der Webapp geschaut, ob es sich um ein mobiles Gerät, also Tablet oder Mobiltelefon handelt und anschliessend wird der entsprechende Code geladen.
So konnte ich die Übersichtlichkeit meines Codes enorm steigern und die Usability für meine Mobile App optimieren, da sie nicht für beides, Desktop und Mobile funktionieren musste, sondern nur für mobile.
Letzten Endes hatte ich dann eine Version von MILKEE, mit der ich mich für den ersten Durchlauf zufriedengeben konnte. So versuchte ich dann, die beiden Apps im App Store zu veröffentlichen. Und siehe da: die selbst geschriebene App wurde im zweiten Durchlauf von Apple freigegeben. Bei WebViewGold hatte ich 8 Durchläufe und die App steckt noch immer im Reviewprozess fest.
Learnings
Ein Problem, das auftauchte, war das Abonnement. Wenn du eine App im App Store veröffentlichen willst, will Apple 35% von deinem Umsatz haben. Deswegen musste ich die Abo-Verwaltung von MILKEE auf der mobile optimierten Website, sprich in der App, verstecken. Dieses Learning hatte ich zum Glück früh genug. Ansonsten wäre das mit der Hybrid App nichts geworden. Denn In-App Käufe in einer Hybriden App funktionieren nicht.
Ein weiteres Learning das ich hatte: mobile optimierte Webseiten sind keine Apps!!!
Ich meine, grundsätzlich geht das schon. Aber die UX ist sehr verwerflich und es macht keinen Spass, die App so zu verwenden. Deswegen habe ich, wie bereits erwähnt, auch den gesamten Code für Mobile neu geschrieben und möglichst versucht, dieses Native-Feeling zu kreieren.
Das letzte Learning ist, dass Apps teuer sind. Ich meine, 109 Franken im Jahr, nur damit meine App heruntergeladen werden kann? Sehr viel… Zudem muss man jeden Februar an irgendeine Behörde in den USA einen Export Bericht schicken mit allen App-Downloads. Denn ein App-Download wird dort komischerweise als ein Exportgut gewertet.
Trotzdem hat es mir enormen Spass gemacht das alles auszuprobieren. Ich werde im nächsten Schritt den Webview-Code von onabudget.io auf MILKEE anpassen und dann das ursprüngliche Ziel meines Beitrags auch noch erreichen.