Die Frage steht in vielen Erstgesprächen im Raum: Brauchen wir eine App? Dahinter steckt selten der Wunsch nach einem eigenen Programm, sondern ein konkretes Ziel - auf dem Telefon der Kundschaft sichtbar bleiben, Termine annehmen, Preise und Öffnungszeiten aktuell halten, Wiederkehrer schnell wieder hereinholen. Für genau diesen Zweck kann eine Website mehr, als die meisten Betriebe vermuten: Sie lässt sich auf den Startbildschirm legen, startet ohne Adressleiste, zeigt bei schwachem Netz schon etwas an und braucht keine Freigabe vor jeder Änderung. Dieser Beitrag zeigt, was dazugehört, welche Posten anfallen und wo eine native App trotzdem die passendere Antwort ist.
Woher die App-Frage kommt
Der Ausgangspunkt ist richtig beobachtet: Das Telefon ist das Hauptgerät. 92,4 Prozent (Eurostat) der Menschen in Deutschland, die in den letzten drei Monaten das Internet genutzt haben, taten das 2025 über ein Mobiltelefon.
Wer über Erreichbarkeit nachdenkt, denkt zu Recht zuerst an den kleinen Bildschirm. Der Schluss daraus fällt nur oft zu schnell aus: also eine App. Dabei ist die App eine von mehreren Antworten auf dieselbe Frage, und für die üblichen Aufgaben eines Betriebs - Anfrage, Termin, Preisliste, Anfahrt, Öffnungszeiten - in der Regel die aufwendigste.
Es hilft, die Frage einmal umzudrehen. Was soll auf dem Telefon passieren? In den meisten Fällen lautet die Antwort: Jemand sucht die Nummer, die Adresse oder die Öffnungszeiten, schickt eine Anfrage, bucht einen Termin oder schaut nach, was etwas kostet. Das sind Vorgänge von wenigen Sekunden bis wenigen Minuten, die sich selten wiederholen. Dafür installiert kaum jemand ein Programm. Die Hürde beginnt nicht beim Bedienen, sondern beim Herunterladen: Konto, Speicherplatz, Berechtigungen - und danach ein Symbol, das drei Wochen später ungenutzt in einem Ordner liegt. Wie sich diese Wege auf dem kleinen Bildschirm anfühlen sollten, steht ausführlich in Bedienbarkeit auf dem Handy.
Auf der Gegenseite steht der Aufwand, über den im Erstgespräch selten gesprochen wird. Eine native App bedeutet zwei Fassungen für zwei Plattformen, zwei Werkzeugketten, zwei Sätze Testgeräte. Jede Änderung - ein neuer Preis, ein geänderter Text, ein zusätzliches Formularfeld - durchläuft eine Prüfung, bevor sie bei der Kundschaft ankommt. Und weil die Website ohnehin bestehen bleibt, denn sie ist der Ort, den Suchmaschinen lesen und den man in eine Signatur schreibt, pflegt der Betrieb ab dem Tag der Veröffentlichung zwei Systeme statt eines. Was das für die Planung bedeutet, ordnet einmalige und laufende Kosten einer Website ein.
Die Frage hinter der Frage
Was die Website ohne Installation schon kann
Eine Website ist seit Jahren mehr als ein Dokument im Browser.
Drei Bausteine machen aus ihr etwas, das sich auf dem Telefon wie ein eigenes Programm anfühlt: eine kleine Beschreibungsdatei, das Manifest, ein Satz Symbole in mehreren Größen und ein Stück Code, das Inhalte für den nächsten Aufruf bereithält. Alle drei sind offene Standards, keine Zukäufe. Sie liegen in derselben Auslieferung wie die Seiten selbst und kosten keinen zweiten Betrieb.
Das Manifest ist eine JSON-Datei mit einer Handvoll Feldern. Die zuständige Spezifikation des W3C beschreibt ihren Zweck deutlich: „Using this metadata, user agents can provide developers with means to create user experiences that are more comparable to that of a native application“ (W3C). Übersetzt heißt das: Der Browser darf die Website beim Start behandeln wie ein installiertes Programm - eigenes Symbol, eigener Fenstertitel, eigener Einstiegspunkt. Der Betrieb liefert dafür Daten, keine Software.
- Anfrageformular mit Pflichtfeldern, Bestätigung und Weiterleitung an das richtige Postfach
- Terminwahl mit freien Zeitfenstern statt Rückrufschleife
- Öffnungszeiten, Notdienste und Betriebsferien, die sich an einer Stelle ändern lassen
- Karte, Anfahrt und Rufnummer als Tippziel, das direkt wählt
- Preis- und Leistungsübersichten, die ohne Aktualisierung eines Programms aktuell sind
- Dokumente zum Herunterladen: Anfahrtsskizze, Formulare, Datenblätter, Preisliste
{
"name": "[Betriebsname] - Maler und Lackierer",
"short_name": "[Kurzname]",
"start_url": "/?quelle=startbildschirm",
"scope": "/",
"display": "standalone",
"background_color": "#ffffff",
"theme_color": "#004d43",
"icons": [
{ "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" },
{ "src": "/icon-maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
]
}Der Symbolsatz ist der Teil, an dem es in der Praxis besonders oft hakt. Die Spezifikation begründet die Größenangaben so: „These sizes serve as hints for the user agent to determine a suitable icon to use in a particular context (e.g., on the home screen of a device)“ (W3C). In der Breite ist das angekommen: Symbole sind in 90 Prozent (Web Almanac) der ausgewerteten Manifeste auf dem Desktop und in 91 Prozent auf dem Telefon gesetzt, und rund 85 Prozent (Web Almanac) liefern die Kantenlänge 192 mal 192 Pixel mit. Wer sein Symbol nur als klassisches Favicon hinterlegt, bekommt auf dem Startbildschirm einen unscharfen Ausschnitt statt einer Kachel. Woher gute Symbole und Vorschaubilder kommen und wie sie zusammenspielen, behandelt Vorschaubild und Favicon beim Teilen.
Der Test dauert zwei Minuten
Die Kachel auf dem Startbildschirm
Verbreitet ist das noch nicht. Im Jahresbericht des Web Almanac heißt es für 2025: „In 2025, we can see that roughly one fifth of sites use service workers, and roughly one tenth use manifests“ (Web Almanac). Rund ein Zehntel (Web Almanac) der untersuchten Websites bringt also überhaupt eine Manifestdatei mit. Für einen Betrieb ist das eine gute Nachricht: Der Aufwand ist klein, der Unterschied auf dem Telefon der Kundschaft aber sofort sichtbar, weil die meisten anderen Seiten ihn nicht bieten.
Ein Feld entscheidet über den Eindruck: display. Steht dort standalone, startet die Website ohne Adressleiste und ohne Browserrahmen; die Spezifikation beschreibt den Modus als „Opens the web application to look and feel like a standalone native application“ (W3C). Das ist der Regelfall: 78 Prozent (Web Almanac) der ausgewerteten Manifeste setzen display auf standalone. Der Effekt ist unspektakulär und wirkt trotzdem - was in einem eigenen Fenster startet, fühlt sich nicht mehr nach Lesezeichen an.
/site.webmanifest Name, Kurzname, Symbole, Anzeigemodus, Startadresse
/icon-192.png 192 x 192 Kachel auf dem Startbildschirm
/icon-512.png 512 x 512 Startbild und Aufgabenumschalter
/icon-maskable-512.png 512 x 512 Fassung für runde und abgerundete Masken
/favicon.svg skaliert verlustfrei für den Tab im Browser
/sw.js hält Inhalte für den nächsten Aufruf bereitTabelle waagerecht wischen
| Aufgabe | Native App | Installierbare Website |
|---|---|---|
| Auf dem Startbildschirm sichtbar | Nach Installation aus einem Plattformladen | Nach zwei Tippern im Browsermenü |
| Zwei Plattformen bedienen | Zwei Fassungen, zwei Werkzeugketten | Eine Fassung, ein Stand |
| Preis oder Öffnungszeit ändern | Neue Fassung, Prüfung, Verteilung, Aktualisierung beim Nutzer | Änderung ist beim nächsten Aufruf da |
| In der Suche auffindbar | Der Ladeneintrag, nicht der Inhalt | Jede Seite einzeln auffindbar und verlinkbar |
| Einen Link weitergeben | Umweg über den Ladeneintrag | Adresse zeigt direkt auf den Inhalt |
| Zugriff auf Kamera, Standort, Dateien | Vollständig, nach Berechtigung | Weitgehend, nach Berechtigung im Browser |
| Hintergrundbetrieb und Sensorik | Möglich | Eingeschränkt |
Der dritte Baustein heißt Service Worker und ist der Grund, warum eine installierte Website auch bei schwachem Netz noch etwas anzeigt. Die Spezifikation nennt den Zweck direkt: „This specification also provides a fetch event, and a request and response store similar in design to the HTTP cache, which makes it easier to build offline-enabled web applications“ (W3C). Praktisch heißt das: Öffnungszeiten, Kontaktdaten und die zuletzt gelesene Seite liegen auf dem Gerät und erscheinen, bevor die Verbindung steht. Verbreitet ist die Technik deutlich stärker als das Manifest - 18,9 Prozent (Web Almanac) der untersuchten Websites setzen einen Service Worker ein. Wie stark sich schnelle Auslieferung insgesamt auswirkt, zeigt PageSpeed 100 durch statische Auslieferung.
Was „installiert“ hier bedeutet
Wo eine App die richtige Antwort ist
Diese Ehrlichkeit gehört dazu: Es gibt Fälle, in denen eine native App das passende Werkzeug ist, und sie lassen sich klar benennen.
Sie haben damit zu tun, dass etwas dauerhaft im Hintergrund läuft, tief auf die Gerätetechnik zugreift oder in einer Umgebung ohne Verbindung arbeiten muss - oder damit, dass die Anwendung selbst das Produkt ist und nicht die Werbung dafür.
Ein Argument fällt dabei regelmäßig weg, obwohl es im Gespräch als erstes kommt: die Benachrichtigung. Die Auswertung des Web Almanac beschreibt das Verhalten nüchtern: „Desktop notification acceptance is overwhelmingly ignored: 78% of them are disregarded, with a slightly lower but still meaningful 48% on mobile“ (Web Almanac). Erhoben ist das über die Berechtigungstelemetrie des Chrome-Browsers, und zwar für Adressen, auf denen ein Service Worker läuft: Für diese Gruppe nennt der Bericht auf dem Telefon 48 Prozent (Web Almanac) unbeachtete Anfragen. Wer eine App vor allem baut, um Nachrichten zuzustellen, baut auf einem Kanal, den ein großer Teil der Empfänger wegwischt. Für Terminerinnerungen sind Textnachricht und E-Mail in der Regel der verlässlichere Weg - wie eine Terminstrecke aussieht, die ohne Erinnerungsdruck auskommt, steht in Online-Terminbuchung für Betriebe.
Dauerbetrieb im Hintergrund
Ortung während einer Tour, Messreihen über Stunden, Aufzeichnung ohne offenes Fenster: Das gehört in ein Programm, das das Betriebssystem am Leben hält.
Tiefer Gerätezugriff
Nahfeldkommunikation, angeschlossene Messtechnik, Barcodescanner im Dauereinsatz, biometrische Freigaben: Hier reicht der Rahmen des Browsers häufig nicht aus.
Arbeit ohne Verbindung
Wenn Aufträge stundenlang ohne Netz erfasst und später abgeglichen werden, braucht es lokale Datenhaltung, die über einen Zwischenspeicher hinausgeht.
Die Anwendung ist das Produkt
Wenn Nutzung, Abo oder Kauf innerhalb des Programms stattfinden und der Plattformladen der gewünschte Vertriebsweg ist, führt an einer App kaum ein Weg vorbei.
Die Prüffrage ist einfach: Läuft der Nutzen der Anwendung weiter, wenn niemand hinschaut? Dann ist eine App plausibel. Passiert alles innerhalb eines Besuchs - anschauen, ausfüllen, absenden, weglegen -, dann trägt die Website. Bei den meisten Betrieben fällt die Antwort eindeutig aus, und dann ist die App kein Fortschritt, sondern ein zweites Projekt neben dem ersten. Wer statt einer App über ein Profil in einem sozialen Netzwerk nachdenkt, findet die Abwägung in eigene Website oder Profil im sozialen Netzwerk.
Eine App verlangt eine Entscheidung vor dem ersten Nutzen. Eine Kachel entsteht, nachdem der Nutzen schon da war.
Die Rechnung über drei Jahre
Belastbare Marktpreise für App-Entwicklung gibt es nicht in einer Form, die sich hier zitieren ließe - die Spannen reichen von Nebenjobarbeit bis Konzernbudget und sagen über ein einzelnes Vorhaben wenig.
Was sich dagegen sauber benennen lässt, sind die Posten, die anfallen, und ihre Wiederkehr. Daran entscheidet sich die Frage, nicht an einer Zahl aus einer Branchenumfrage.
Eine native App hat drei Kostenblöcke, die eine Website nicht hat: die zweite Plattformfassung, die Freigabe vor jeder Veröffentlichung und die Nachführung, wenn die Plattformen ihre Anforderungen ändern. Der dritte Block ist der unangenehme, weil er ohne Anlass aus dem eigenen Betrieb kommt: Eine App, die zwei Jahre nicht angefasst wird, verschwindet in der Regel irgendwann aus dem Plattformladen. Eine Website, die zwei Jahre nicht angefasst wird, bleibt erreichbar - inhaltlich veraltet vielleicht, aber online.
Tabelle waagerecht wischen
| Posten | Native App | Installierbare Website |
|---|---|---|
| Erstellung | Zwei Fassungen, je eigene Werkzeugkette | Eine Fassung, dieselbe wie die Website |
| Veröffentlichung | Konto beim Plattformbetreiber, Prüfung vor jeder Fassung | Auslieferung wie jede andere Änderung |
| Inhaltspflege | Über eine Schnittstelle, sonst neue Fassung | Im selben Redaktionsweg wie die Seiten |
| Plattformänderungen | Nachführen, sonst Rückzug aus dem Laden | Ältere Browserfassungen bleiben in der Regel bedienbar |
| Auffindbarkeit | Ladeneintrag, getrennt von der Website | Teil der bestehenden Sichtbarkeit |
| Ende der Nutzung | Deinstallation, Symbol verschwindet | Kachel wegziehen, Adresse bleibt |
Wer trotzdem beide Wege gehen möchte, sollte die Reihenfolge beachten: erst die Website so bauen, dass sie auf dem Telefon trägt, dann messen, was dort tatsächlich passiert - und erst danach entscheiden, ob eine App eine Lücke schließt, die sich benennen lässt. Die umgekehrte Reihenfolge führt zu einem Programm, für dessen Zweck hinterher die Begründung gesucht wird. Die grundsätzliche Wegentscheidung davor behandelt Baukasten, Agentur oder KI im Vergleich.
In sechs Schritten zur installierbaren Website
Der Weg ist kurz und lässt sich in einem Zug erledigen, wenn die Website ohnehin überarbeitet wird. Wichtig ist die Reihenfolge: Erst muss klar sein, welche Adresse beim Tippen auf die Kachel öffnen soll, dann kommen Symbol und Beschreibung, und ganz zum Schluss die Zwischenspeicherung.
- Startadresse festlegen: Nicht in jedem Fall ist die Startseite richtig. Bei einem Betrieb mit Terminvergabe ist oft die Terminseite der bessere Einstieg, bei einer Praxis die Seite mit Sprechzeiten und Notfallnummer.
- Symbolsatz anlegen: quadratisch in 192 und 512 Pixeln, dazu eine Fassung mit Rand für runde Masken. Das Motiv sollte in der kleinen Kachelgröße erkennbar bleiben - Wortmarken sind dort meist unlesbar.
- Manifest schreiben und einbinden: Sechs Felder reichen für den Anfang -
name,short_name,icons,display,start_url,scope. Der Kurzname sollte höchstens zwölf Zeichen haben, sonst kürzt das Gerät ihn ab. - Farben setzen:
theme_colorfärbt die Systemleiste,background_colorden Moment zwischen Tippen und erstem Inhalt. Beide sollten zur Website passen, sonst blitzt beim Start eine fremde Fläche auf. - Zwischenspeicher einrichten: ein schlanker Service Worker für Rahmenseite, Schriften und die zuletzt besuchten Seiten. Weniger ist hier besser, denn was zwischengespeichert wird, muss auch wieder erneuert werden.
- Auf echten Geräten prüfen: Ein älteres Telefon mit gedrosselter Verbindung sagt mehr aus als ein neues Gerät im Büro. Prüfen Sie Kachel, Kurzname, Startbild und den ersten Bildschirm nach dem Antippen.
Danach lohnt ein zweiter Blick auf die Seiten, die von der Kachel aus erreicht werden. Eine Startadresse, die auf eine überladene Startseite zeigt, verschenkt den Vorteil. Sinnvoll ist ein kurzer Einstieg mit den drei oder vier Handlungen, die auf dem Telefon zählen: anrufen, Termin, Anfrage, Anfahrt. Wie ein Formular gebaut ist, das dort nicht abbricht, steht in aus Besuchern Anfragen machen. Für Häuser mit zwei Zielgruppen, etwa Eigentümer und Mieter, lohnt zusätzlich der Blick in Hausverwaltung: Eigentümer und Mieter trennen.
Zwei Dinge, die man nicht nachträglich ändert
scope und die Startadresse gehören vor die Veröffentlichung festgelegt. Wer sie später verschiebt, bricht die Kacheln, die bereits auf Startbildschirmen liegen - sie zeigen dann auf eine Adresse, die es nicht mehr gibt. Und drängen Sie die Installation nicht auf: Ein Hinweisbalken, der beim ersten Besuch das halbe Bild verdeckt, kostet mehr Anfragen, als die Kachel einbringt.Woran Sie merken, dass es wirkt
Die Kachel ist kein Selbstzweck, und sie lässt sich messen. Weil die Startadresse frei wählbar ist, kann sie einen Zusatz tragen - im Beispiel oben ?quelle=startbildschirm.
Jeder Aufruf über die Kachel ist damit von einem Aufruf über die Suche unterscheidbar, ohne dass zusätzliche Daten über die Person erhoben werden. Sechs Werte lohnen den Blick.
- Aufrufe mit dem Startbildschirm-Zusatz je Woche: die Zahl der Menschen, die die Kachel tatsächlich benutzen
- Anteil der Wiederkehrer unter diesen Aufrufen im Vergleich zum übrigen Verkehr
- Zeit bis zum ersten sichtbaren Inhalt auf einer gedrosselten Verbindung, mit und ohne Zwischenspeicher
- Abgeschickte Anfragen und Terminbuchungen je hundert Aufrufe, getrennt nach Einstiegsweg
- Anteil der Aufrufe vom Telefon insgesamt: das Verhältnis, das die Prioritäten setzt
- Absprünge auf der Startadresse: zeigt, ob die Kachel auf die passende Seite führt
Zwei bis drei Monate Beobachtung genügen für ein Urteil. Bleibt der Anteil der Kachelaufrufe klein, ist das kein Argument gegen die Website - es heißt nur, dass die Kundschaft anders zu Ihnen kommt, meist über Suche und Kartendienst. Dann liegt der Hebel dort, und eine App hätte daran wenig geändert. Steigt der Anteil, hat der Betrieb einen Kanal ohne laufende Plattformkosten gewonnen. Wie sich Öffnungszeiten in beiden Fällen aktuell halten lassen, zeigt Öffnungszeiten und Erreichbarkeit aktuell halten.
Fünf Fehler, die die Kachel entwerten
Die Technik ist überschaubar, die Fehler wiederholen sich trotzdem. Alle fünf lassen sich in einer halben Stunde prüfen, und alle fünf fallen erst auf, wenn jemand die Kachel wirklich benutzt.
- Kurzname zu lang: Das Gerät schneidet ihn ab, und unter der Kachel steht eine Silbe. Zwölf Zeichen sind eine brauchbare Obergrenze.
- Symbol mit Schrift: Was auf dem Briefkopf funktioniert, ist in der Kachelgröße oft ein grauer Fleck. Auf die Bildmarke reduzieren oder einen einzelnen Buchstaben setzen.
- Startadresse auf der Startseite: Wer die Kachel antippt, will in der Regel eine Sache erledigen und nicht durch ein Menü navigieren.
- Zwischenspeicher ohne Ablauf: Veraltete Preise oder Öffnungszeiten, die sich hartnäckig halten, sind ärgerlicher als eine langsame Seite. Jede zwischengespeicherte Datei braucht eine Regel, wann sie erneuert wird.
- Installationsbanner beim ersten Besuch: Die Aufforderung kommt, bevor jemand weiß, ob die Seite hilft. Sie gehört an eine Stelle, an der der Nutzen schon sichtbar war.
Wer diese fünf Punkte abräumt, hat aus der Website ein Werkzeug gemacht, das auf dem Telefon der Kundschaft liegt - ohne zweites Projekt, ohne Freigabeschleife und ohne einen zweiten Ort, an dem Preise gepflegt werden müssen. Für Betriebe mit wiederkehrenden Anliegen ist das oft der ganze Unterschied: Serviceformulare für Bestandskunden zeigt, wie solche Wege aussehen, und wie eine Praxis Termine und Gebühren auf dem Telefon abbildet, steht in Tierarztpraxis: Termine und Gebühren.
display: standalone startet die Seite ohne Adressleiste in einem eigenen Fenster. Das ist der Regelfall: 78 Prozent (Web Almanac) der ausgewerteten Manifeste setzen genau diesen Wert. Die Kachel trägt Ihr Symbol, der Aufgabenumschalter zeigt Ihren Namen.?quelle=startbildschirm, und jeder Aufruf über die Kachel ist damit von anderen Zugängen unterscheidbar, ohne zusätzliche Daten über die Person. Nach zwei bis drei Monaten lässt sich sagen, ob der Weg genutzt wird. Barrierefreiheit gehört auf demselben Weg geprüft - der Rahmen dazu steht in barrierefreie Website nach BFSG.