1 · Adresse öffnen
Die App läuft zuerst wie eine Website im Browser. MDN
Leistung · Website & Technik
Wir bauen individuelle Web-Anwendungen: Anwendungen, die über eine Adresse im Browser laufen — auf Handy, Tablet und Rechner, aus einer gemeinsamen Codebasis. MDN Kein App Store, keine getrennte Fassung je Gerät. Was so eine Anwendung kann und wo ihre Grenzen liegen, steht auf dieser Seite.
Eine ist eine Anwendung, die mit Web-Technik gebaut ist und im Browser läuft — auf Handy, Tablet und Rechner aus derselben Codebasis. MDN
Browser-App
Eine Browser-App ist eine Anwendung, die im Browser läuft und mit Web-Technik gebaut ist. Sie ist über eine Adresse erreichbar, ohne App Store. Lässt sie sich installieren und offline nutzen, spricht man von einer Progressive Web App.
Lässt sie sich zusätzlich installieren und auch ohne Netz nutzen, spricht man von einer . MDN Technisch bleibt sie in jedem Fall eine Website und braucht einen Browser, der sie ausführt. MDN Wie die Oberfläche aussieht und sich bedient, entsteht wie beim Webdesign.
Progressive Web App
Eine Progressive Web App ist eine Anwendung, die mit Web-Technik gebaut ist und sich wie eine installierte App verhält. Sie läuft auf vielen Geräten aus einer Codebasis, lässt sich installieren und kann auch ohne Netz arbeiten.
Eine Website besuchst du. Eine App hast du.
Was bleibt wie bei einer Website: Die App ist über eine Adresse erreichbar, per Link teilbar und von Suchmaschinen auffindbar. MDN Was dazukommt, sobald sie installiert ist: ein eigenes Symbol auf dem Startbildschirm, ein eigenes Fenster, auffindbar in der Gerätesuche — und auf Wunsch Betrieb ohne Netz. MDN Dass die App gefunden wird, ist dieselbe Arbeit wie bei jeder Website: SEO.
Du öffnest ihre Adresse im Browser und installierst sie von dort — ein App Store ist dafür nicht nötig.
Die App läuft zuerst wie eine Website im Browser. MDN
Chrome, Edge und Samsung Internet bieten das selbst an. Auf dem iPhone geht es über das Teilen-Menü („Zum Home-Bildschirm“), seit iOS 16.4 auch in Chrome, Edge und Firefox; am Mac über Safari „Zum Dock hinzufügen“. MDN
Danach: eigenes Symbol, eigenes Fenster, auffindbar in der Gerätesuche — ohne Installationsdatei. W3C
Neue Versionen kommen über das Web, ohne erneute Prüfung durch einen Store. web.dev
Eine kleine Steuerdatei — das — mit Name, Symbolen und Startadresse, und eine Auslieferung über HTTPS ().
Web App Manifest
Ein Web App Manifest ist eine kleine Textdatei im JSON-Format, die dem Browser Name, Symbole und Startadresse einer Web-App mitteilt. Erst damit bieten Browser wie Chrome die Installation an.
Sicherer Kontext
Ein sicherer Kontext ist eine Umgebung im Browser, die bestimmte Anforderungen an Verschlüsselung und Echtheit erfüllt, in der Praxis eine Seite über HTTPS. Viele leistungsfähige Funktionen, etwa Service Worker, gibt es nur dort.
{
"name": "Beispiel-App",
"short_name": "Beispiel",
"start_url": "/",
"display": "standalone",
"icons": [
{
"src": "/icons/192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "/icons/512.png",
"sizes": "512x512",
"type": "image/png"
}
]
}
<link rel="manifest" href="/manifest.webmanifest">
Jede Seite verweist auf dieses Manifest. Chromium-Browser verlangen mindestens Name, Symbole in 192 und 512 Pixeln, eine Startadresse und einen Anzeigemodus. MDN Ein ist für die reine Installation nicht nötig — aber für den Betrieb ohne Netz, dazu gleich. MDN
Service Worker
Ein Service Worker ist ein Skript, das der Browser getrennt von der Seite ausführt und das zwischen App und Netz vermittelt. Er kann Dateien zwischenspeichern, damit eine App ohne Verbindung startet, und ist Grundlage für Push-Nachrichten.
Ja, wenn sie dafür gebaut ist: Ein legt die nötigen Dateien im Browser ab und liefert sie aus, wenn das Netz fehlt.
Cache
Ein Cache ist ein Zwischenspeicher im Browser, in dem eine Web-App Dateien ablegt. Fehlt das Netz, kann sie diese Dateien von dort laden.
Service Worker
Ein Service Worker ist ein Skript, das der Browser getrennt von der Seite ausführt und das zwischen App und Netz vermittelt. Er kann Dateien zwischenspeichern, damit eine App ohne Verbindung startet, und ist Grundlage für Push-Nachrichten.
1 · App-Oberfläche
Das, was der Nutzer sieht und bedient.
2 · Service Worker
Sitzt als Vermittler zwischen App, Browser und Netz; fängt Anfragen ab. web.dev
3 · Cache und Netz
Der im Browser hält Dateien bereit; ist Netz da, kommt es vom Server. WebKit (Apple)
Zwei Wege sind möglich: zuerst aus dem Cache (schnell, kann aber veraltet sein) oder zuerst aus dem Netz (aktuell, der Cache nur als Ersatz). Welcher passt, hängt von der App ab. WebKit (Apple) Grenze: Was im Hintergrund passiert, entscheidet der Browser mit — er darf den Service Worker beenden und regelt, wie oft eine App im Hintergrund aktualisiert. WebKit (Apple)
Eine Browser-App passt, wenn du mit einer Lösung viele Geräte erreichen und ohne Store-Freigabe aktualisieren willst; eine App aus dem Store, wenn sie tief ins Betriebssystem eingreifen oder Funktionen nutzen muss, die nicht jeder Browser bietet.
Entwicklung: eine Codebasis für alle Plattformen. Verteilung: über eine Adresse, per Link, über Suchmaschinen — Store möglich, nicht nötig. Updates: neue Version liegt auf dem Server, keine Store-Prüfung. Gerätefunktionen: viele, aber nicht jede in jedem Browser. MDN web.dev Gesetzestext
Entwicklung: je Betriebssystem, mit dem Werkzeug des Herstellers. Verteilung: meist über den Store des Herstellers. Updates: neu verpacken, signieren, prüfen lassen, neu installieren. Gerätefunktionen: volle Einbindung ins System, etwa Kamera oder GPS. MDN web.dev
trendgo baut keine . Wer eine braucht, bekommt von uns eine ehrliche Einschätzung — aber kein Projekt und keine Vermittlung an Dritte.
Native App
Eine native App ist eine Anwendung, die für ein bestimmtes Betriebssystem wie iOS oder Android mit dem Werkzeug des Herstellers entwickelt wird. Sie wird meist über dessen App Store verbreitet.
Sie kann nicht in jedem Browser alles, sie ist kein sicherer Langzeitspeicher auf dem Gerät, und sie ersetzt kein großes Softwareprojekt.
„Eine Browser-App kann alles, was eine Store-App kann.“
Manche Gerätefunktionen fehlen in verbreiteten Browsern — Web-Bluetooth etwa gilt als experimentell und ist nicht . Gute Apps prüfen das und bieten einen Ersatzweg. Gesetzestext
„Installieren geht überall gleich.“
Auf dem iPhone gibt es keinen Installationshinweis der App, nur das Teilen-Menü. Firefox am Rechner installiert keine Web-Apps per Manifest. Android ohne Google-Dienste legt nur eine Verknüpfung an. W3C
„Was offline gespeichert ist, bleibt für immer.“
Browser dürfen gespeicherte Daten bei Platzmangel löschen. Safari löscht per Skript angelegte Daten nicht installierter Seiten nach sieben Tagen ohne Nutzung. Bundesamt für Justiz
„Eine kleine Browser-App ersetzt eine große Software.“
Tut sie nicht — und das ist auch nicht unser Anspruch. Wichtige Daten gehören auf einen Server mit Datensicherung, nicht nur in den Browser.
Baseline
Baseline ist eine Kennzeichnung für Web-Funktionen, die in allen wichtigen Browsern laufen: Chrome, Edge, Firefox und Safari, am Rechner und auf dem Handy. Was nicht Baseline ist, funktioniert in mindestens einem davon nicht.
Daraus folgt eine einfache Regel: je wichtiger die Daten, desto weniger dürfen sie allein im Browser liegen.
Individuelle Web-Anwendungen rund um die Website, in überschaubarem Rahmen. Vier Bausteine, und eine klare Grenze.
Zum Beispiel haben wir eine Anwendung für Zeiterfassung, Personalplanung und Abrechnung gebaut — für einen Kunden, als reine Web-App im Browser, auf echten Geräten getestet.
Ein Redaktionssystem, mit dem Inhalte selbst gepflegt werden — klassisch oder als Headless-Setup.
Sichere Auth- und Form-Flows: Login-Bereiche und Formularstrecken, sauber umgesetzt.
Schnittstellen zu Newsletter-Diensten — nicht zu CRM- oder Shop-Systemen.
Was wir nicht machen: keine nativen Apps, keine Online-Shops, keine großen Softwareprojekte und kein Hosting. Den Betrieb richten wir ein, laufen tut die Anwendung beim Kunden — der Hostingvertrag läuft über ihn. Eine laufende Wartung der App gehört nicht dazu; für Websites bieten wir Wartung dagegen als eigene Leistung an.
Kläre vorher, wer die App auf welchen Geräten nutzt, welche Daten sie verarbeitet und wer sie später betreibt.
Vier Punkte helfen dabei:
Geräte und Browser. Davon hängt ab, wie sich die App installieren lässt und welche Funktionen zur Verfügung stehen. W3C
Gerätefunktionen. Braucht die App etwas Besonderes — Kamera, Standort, Bluetooth —, prüfen wir vorher, ob alle nötigen Browser das können. Gesetzestext
Personenbezogene Daten. Verarbeitet die App solche Daten, muss der Datenschutz schon bei der Planung mitgedacht werden, nicht erst im Betrieb. Gesetzestext Können Verbraucher über die App etwas buchen oder kaufen, kann das gelten — außer für Kleinstunternehmen; der Prüfweg steht beim Webdesign. Bundesamt für Justiz
BFSG
Das BFSG (Barrierefreiheitsstärkungsgesetz) ist ein Bundesgesetz, das bestimmte Produkte und Dienstleistungen für Verbraucher zur Barrierefreiheit verpflichtet. Es setzt eine EU-Richtlinie um und gilt seit dem 28. Juni 2025. Websites betrifft es vor allem, wenn Verbraucher darüber Verträge abschließen, etwa im Online-Shop oder bei der Terminbuchung.
Betrieb nach dem Start. Wo die App läuft und wer sie betreibt, legen wir vorab fest. Wie ein Projekt Schritt für Schritt abläuft, steht auf der Seite zu unseren Leistungen.
Erzähl uns, was sie können soll und wer sie nutzen wird. Im kostenlosen Erstgespräch klären wir, ob eine Browser-App der richtige Weg ist — und was sie dafür braucht.
Nur eine Seite für eine einzelne Aktion? Landingpages