Die Anforderung war eigentlich ein Icon
Ein Team verlangte eine native App und beschrieb danach Login, Dashboard, Dokumentenupload und Benachrichtigungen. Keine dieser Anforderungen erklärte, warum native Software notwendig war. Gewünscht war ein Dienst, der dauerhaft wirkt, schnell öffnet und vom Homescreen erreichbar ist.
Der Unterschied ist wichtig. Native Entwicklung bringt getrennten Plattformcode, Store-Prüfung, koordinierte Releases und eine grössere Testfläche. Diese Kosten sind gerechtfertigt, wenn das Produkt Fähigkeiten braucht, die das Web nicht verlässlich liefern kann. Sie sind Verschwendung, wenn native nur als Synonym für ernsthaft dient.
Die erste Entscheidung lautet daher nicht Web oder native. Sie lautet URL, installierte Präsenz oder privilegierter Zugriff auf das Betriebssystem.
Was eine Web-App bereits ehrlich leisten kann
Für Kundenportale, Buchungssysteme, Marktplätze, Dashboards, interne Werkzeuge, Inhaltsprodukte und Abläufe zwischen Desktop und Mobilgerät ist eine Web-App meist der stärkste Anfang. Eine Codebasis erreicht sofort den Browser, Links öffnen den passenden Zustand und Updates warten nicht auf ein Store-Release.
Installation gehört nicht mehr ausschliesslich nativer Software. Die Web Application Manifest Spezifikation beschreibt Name, Icons, Startadresse, Darstellungsmodus und Geltungsbereich einer installierten Web-Erfahrung. Service Worker können Oberflächen zwischenspeichern und Offline-Arbeit ermöglichen. Schwankende Verbindung ist allein kein Grund für native.
Auch Push setzt nicht automatisch native voraus. Apple dokumentiert standardbasierten Web Push für Web-Apps auf dem Homescreen, mit Zustimmung und sichtbarer Benachrichtigung. Kamera, Mikrofon, Standort, Dateiupload und Teilen stehen ebenfalls im Web zur Verfügung, wenn Browserunterstützung und Berechtigungen zur Zielgruppe passen.
Die ehrliche Grenze ist Konsistenz. Eine Fähigkeit kann in einem Browser vorhanden und im nächsten eingeschränkt sein. Die konkrete Geräte- und Browsermatrix ist wichtiger als eine allgemeine API-Liste.
Was tatsächlich native verlangt
Native ist die ehrliche Antwort, wenn der Kernnutzen von privilegiertem, dauerhaftem oder plattformspezifischem Verhalten abhängt:
- Anhaltende Hintergrundarbeit. Muss Verarbeitung, Tracking oder Übertragung nach dem Schliessen der Oberfläche weiterlaufen, bieten native Plattformen eigene Frameworks für Planung und Ausführung. Apples Background Tasks Framework ist ein Beispiel.
- Erweiterungen des Betriebssystems. Widgets auf Home- und Sperrbildschirm, Live Activities, Controls, Watch-Komplikationen und Share Extensions liegen ausserhalb der Hauptanwendung. Apple stellt dafür Frameworks wie WidgetKit bereit.
- Tiefe Hardware- und Gesundheitsintegration. Dauerhafte Zubehörkommunikation, besondere Sensoren, HealthKit, Health Connect oder sichere Systemspeicher verlangen häufig native Berechtigungen und SDKs. Apple beschreibt HealthKit als App Capability, während Web Bluetooth eine Browser-API mit begrenzter Verfügbarkeit bleibt.
- An Geräte-Pipelines gebundene Leistung. Echtzeit-Audio, anspruchsvolle Kameraerfassung, fortgeschrittene Grafik oder lange Berechnung auf dem Gerät können vorhersehbaren Zugang zu nativen Medien- und GPU-Frameworks benötigen.
Authentifizierung, Abonnements, Animation, Karten, Push, ein Kameraknopf oder eine Offline-Ansicht reichen allein nicht als Begründung. Sie sind zu testende Fragen, keine fertigen Antworten.
Hybrid ist eine Produktentscheidung, kein Kompromiss
Manche Produkte brauchen breite Web-Auslieferung und einen kleinen Anteil nativer Fähigkeit. Die Web-Anwendung kann das Hauptprodukt bleiben, während eine native Shell Store-Vertrieb, sichere Zugangsdaten, Hintergrundaufgaben oder eine Hardwarebrücke ergänzt. Gemeinsame Web Views reduzieren doppelte Interfacearbeit. Native Module behandeln nur die Plattformgrenze.
Das passt, wenn die meisten Abläufe aus Formularen, Inhalten und Kontodaten bestehen, aber ein bestimmter mobiler Moment tieferen Zugriff braucht. Es passt weniger, wenn das gesamte Interaktionsmodell von nativer Navigation, kontinuierlichen Sensoren oder Plattformoberflächen abhängt. Eine Shell kann ein im Kern natives Produkt nicht verstecken.
Auch Hybrid hat einen Wartungsvertrag. Brücke, Store-Releases und Plattformmodule müssen getestet werden. Die Wahl braucht eine klare Grenze und darf nicht nur die Entscheidung vertagen.
Diese Woche von der schwierigsten Fähigkeit entscheiden
Den zentralen Nutzerweg ohne Technologienamen aufschreiben. Jeden Moment markieren, der offline, im Hintergrund, mit Hardware oder ausserhalb der Hauptoberfläche funktionieren muss. Danach jeden markierten Moment auf den tatsächlichen Browsern und Geräten der Zielgruppe testen.
Funktioniert die schwierigste Fähigkeit im Web verlässlich, zuerst die Web-App bauen und echte Nachfrage nach Installation messen. Scheitert nur eine schmale Fähigkeit, eine native Shell mit kleiner Brücke prüfen. Hängt das Produkt durchgehend von Hintergrundausführung, Systemerweiterungen oder privilegierten Gerätedaten ab, native wählen und dauerhafte Plattformverantwortung budgetieren.
Die ehrliche Antwort ist die günstigste Architektur, die die schwierigste Anforderung des Produkts garantieren kann. Alles andere benennt den Behälter, bevor sein Inhalt definiert ist.