Drei Formen auf demselben Telefon
„Wir brauchen eine App“ bedeutet drei völlig verschiedene Dinge. Der Unterschied entscheidet über Kosten, Zeit und Abhängigkeit — nicht über das, was der Nutzer sieht.
Auf einem Telefon sehen alle drei Formen fast gleich aus. Ein Symbol, ein Vollbild, eine Bedienung mit dem Daumen. Der Unterschied liegt nicht in dem, was der Nutzer sieht, sondern darin, wer beteiligt ist, bevor er es sehen darf. Klicken Sie sich durch.
Das ist genau die Anwendung aus Kurs 1, aufgerufen auf einem Telefon statt auf einem Rechner. Sie ist responsiv gebaut, sie sieht anständig aus, sie funktioniert.
Niemand steht zwischen Ihnen und Ihren Nutzern. Sie ändern etwas, Sie veröffentlichen, alle sehen es — in derselben Minute. Kein Konto, keine Gebühr, keine Prüfung, kein Wartezimmer.
Technisch ist es dieselbe Anwendung. Es kommen drei Dateien dazu, mehr nicht: eine Beschreibung (wie sie heißt, welches Symbol, welche Farbe), ein kleines Programm, das Dateien zwischenspeichert, und ein Symbolbild.
Dann bietet das Gerät an, sie „zum Startbildschirm hinzuzufügen“. Danach hat sie ein Symbol wie jede App, startet ohne Browserleiste und läuft — je nach Gerät mehr oder weniger gut — auch ohne Netz.
Ein eigenes Programm, gebaut für das jeweilige Betriebssystem, unterschrieben mit Ihrem Schlüssel, geprüft von Apple beziehungsweise Google, installiert aus deren Store.
Sie kann alles, was das Gerät kann: Kamera im laufenden Vorgang, Bluetooth, NFC, Arbeit im Hintergrund, Push-Nachrichten, echte Datenhaltung auf dem Gerät.
Der Preis ist nicht die Programmierung. Der Preis sind zwei Entwicklerkonten, zwei Signaturverfahren, zwei Prüfstellen, die Nein sagen dürfen, und eine Aktualisierungslogik für Geräte, auf denen eine alte Fassung liegt.
Der eine Satz, an dem sich alles entscheidet
Braucht Ihre Anwendung etwas, das nur ein installiertes Programm auf dem Gerät kann? Wenn nein, ist jede Minute, die Sie in Store-Konten stecken, eine Minute, die dem Nutzen nicht zugutekommt. Wenn ja, ist der Rest dieses Kurses Ihr Weg.
WarumWarum die Grenze zwischen Web und nativ seit Jahren wandert
Alles, was eine native App kann und ein Browser nicht, ist eine Erlaubnisfrage, keine Fähigkeitsfrage. Die Technik dafür ist im Browser vorhanden oder wäre leicht zu bauen; die Gerätehersteller geben sie nur schrittweise frei, weil jede Freigabe auch eine Angriffsfläche öffnet.
Daraus folgt die Bewegungsrichtung: Es wird mehr möglich, nicht weniger. Push-Nachrichten auf iOS kamen 2023, dauerhafter Speicher auf Anforderung 2024. Bluetooth und Dateisystemzugriff gibt es in Chrome seit Jahren, in Safari nicht.
Für ein Vorhaben heißt das zweierlei. Erstens: Wer heute knapp an der Grenze liegt, sollte warten statt bauen. Zweitens: Wer drei der vier Gründe erfüllt, wird nie zurückwandern — bei dem geht es nicht um eine fehlende Erlaubnis, sondern um die Bauart des Vorhabens.
TiefeDer Sonderfall, den beide Seiten verschweigen: die App als Rahmen um eine Webseite
Es gibt Werkzeuge, die eine native Hülle um eine bestehende Website legen. Das Ergebnis liegt im Store, hat ein Symbol und kostet fast keine Entwicklung.
Es ist fast immer die falsche Antwort, und zwar aus zwei unabhängigen Gründen. Erstens prüft Apple ausdrücklich darauf: Eine App, die nichts kann, was der Browser nicht auch könnte, wird nach Regel 4.2 abgelehnt. Zweitens erbt sie alle Nachteile beider Welten — die Store-Pflichten der nativen App und die Grenzen des Browsers.
Es gibt eine Ausnahme, und sie ist eng: wenn die Hülle etwas Eigenes beisteuert, das der Browser nicht kann — eine Offline-Ablage, eine Kamera im Vorgang, eine Push-Nachricht. Dann ist es aber keine Hülle mehr, sondern eine App mit Web-Anteilen, und die Rechnung aus Station 07 gilt wieder vollständig.