676 Programmierer außer sich: Deine App ist nur eine Webseite
Am 9. Juli 2026 veröffentlichte der britische Programmierer Dan Q einen Beitrag, dessen Titel bereits nach Pulverdampf roch: 「Deine ‘App’ hätte eine Webseite sein können (also habe ich sie repariert)」. Der Artikel löste auf Hacker News eine erbitterte Diskussion unter 676 Programmierern aus – 420 Kommentare –, die das letzte Häutchen zwischen der App-Store-Ökonomie und dem offenen Web durchstieß.
Der Auslöser war ganz alltäglich. Dans Kind sollte bei einer Aufführung im Disneyland auftreten, und die Reisegesellschaft verlangte von den Eltern, eine App namens 「Travelbound」 zu installieren, um den Reiseplan einzusehen. Dan schaute sich die Größe der App an – 43 MB als Installationspaket, nach der Installation auf 124 MB aufgebläht. Als Programmierer mit über einem Jahrzehnt Erfahrung fand er das absurd: Ich will doch nur einen Zeitplan sehen, warum muss ich dafür eine App herunterladen, die größer ist als Super Mario?
Was er dann tat, war das, was Programmierer am besten können: Reverse Engineering.
Was steckt eigentlich in einer 124-MB-App?
▲ Das ist die besagte 124-MB-App Travelbound. Ihre Funktion besteht darin, eine Ansammlung von Text, Bildern und PDF-Links anzuzeigen. Quelle: Dan Qs persönlicher Blog.
Dan fing mit einem Sniffing-Tool den Netzwerkverkehr der App ab und stieß auf eine wahrhaft groteske Wahrheit: Alles, was diese App tut, ist, aus Benutzername und Passwort eine URL zusammenzubauen, Daten vom Server abzurufen und sie auf dem Bildschirm anzuzeigen.
Konkret sah die Logik hinter der App so aus:
https://travelbound.api.vamoos.com/api/itineraries/{Benutzername}-{Passwort}Der Server lieferte eine große Menge an JSON-formatierten Daten zurück – Reiselisten, Unterkunftsinfos, PDF-Download-Links, begleitende Bilder. Und diese Inhalte lagen bereits im HTML-Format vor. Mit anderen Worten: Die Serverseite der App produzierte bereits Webseiten, entschied sich aber, diese Webseiten in eine 124-MB-Hülle zu pressen, bevor sie sie dem Nutzer zeigte.
▲ Die abgefangenen Server-Rückgabedaten. Man sieht, dass die Reiseinformationen bereits im HTML-Format vorliegen. Quelle: Dan Qs persönlicher Blog.
Was aber füllte diese 124 MB, sodass ein im Kern 「Webseiten-Betrachter」 so aufgebläht wurde? Dan fand heraus, dass die App im Vergleich zu einer Webseite nur zwei zusätzliche Funktionen bot:
- Verfolgung deines Google-Kontos und Rückmeldung von Nutzungsdaten an die Reisegesellschaft
- Push-Werbung (offiziell 「Reiseinspiration」 genannt), die dich zum Kauf weiterer Reisen verführen soll
Dan drückte es noch direkter aus: Diese beiden Dinge seien 「Anti-Funktionen」 – für den Nutzer von hundertfachem Schaden ohne jeden Nutzen.
Von 124 MB auf 0,05 MB: Eine Webseite genügt
Dan verbrachte einen halben Tag damit, ein kleines Ruby-Skript zu schreiben, das in regelmäßigen Abständen die neuesten Daten vom Server holte und automatisch eine reine Webseiten-Version erzeugte. Das Ergebnis:
- App-Version: 124 MB (inklusive Tracking und Werbung)
- Webseiten-Version: 0,05 MB große HTML-Seite, dazu einige optionale Bilder (35 MB, die man aber auch weglassen kann)
Die Webseiten-Version ist passwortgeschützt und nutzt dasselbe Konto wie die Original-App. Sie hat keine aufwendige Oberfläche, lässt sich aber kopieren und einfügen, ausdrucken, auf dem Handy speichern und auf jedem beliebigen Gerät öffnen – genau das, was die Original-App eben nicht konnte.
▲ Die von Dan selbst erstellte Webseiten-Version. Sie entfernt Werbung und Tracking, behält aber alle Kerninformationen. Quelle: Dan Qs persönlicher Blog.
Dan schloss mit einer sezierenden Frage:
“Some apps really do need to be apps. Travelbound isn’t one of them. I can’t understand how we got to a place where software companies would rather make their own lives harder (and more expensive: getting on the App Store isn’t cheap!), just to deliver HTML content to fewer people, with fewer features.”
Warum sind wir hier gelandet? Die Apple-Ökonomie
Dans Verwirrung verbirgt ein größeres Problem: Warum verpacken Entwickler Dinge, die eine Webseite mühelos lösen könnte, zwangsläufig in eine App?
In der Diskussion der 676 Teilnehmer auf Hacker News traf der am höchsten bewertete Kommentar den Kern: Apple und Google haben Milliarden von Dollar darauf verwendet, das mentale Modell gewöhnlicher Menschen umzugestalten und ihnen einzupflanzen, dass 「etwas mit dem Handy tun = eine App benutzen」 bedeutet.
Betrachte nur: Wenn ein Durchschnittsmensch ein neues Handy in die Hand bekommt, was sieht er auf dem Startbildschirm? Reihen von App-Symbolen. Wie sucht er nach etwas? Er öffnet den 「App Store」. Wie nutzt er einen Dienst? 「Gibt es dafür eine App?」
Dieses 「App ist alles」-Verständnis ist nicht natürlich gewachsen. Es ist das Ergebnis von fünfzehn Jahren, in denen zwei Tech-Giganten mit echtem Geld darauf hingearbeitet haben.
Und der Motor dahinter ist Geld – genauer gesagt, jene berüchtigte 「Apple-Steuer」.
Die Apple-Steuer: Die 30-Prozent-Abgabe
Für jede über den Apple App Store verkaufte App oder digitale Inhalte behält Apple eine Provision von 15 bis 30 % ein. Im Jahr 2024 erwirtschaftete allein der App Store für Apple über 85 Milliarden Dollar (basierend auf Apples offiziellen Angaben und Finanzdaten, die im Rechtsstreit mit Epic Games öffentlich wurden). In der gesamten Internetbranche findet sich kaum ein zweites 「Mauttor」, das so profitabel ist.
Eine Webseite hingegen ist offen. Wer eine Webseite veröffentlicht, muss Apple kein Geld zahlen, muss Apples Prüfung nicht durchlaufen, und der Nutzer öffnet sie einfach im Browser. Existiert ein Dienst als Webseite, bekommt Apple keinen Cent davon.
Das erklärt, warum Apple auf iOS das Web-App bewusst 「unbrauchbar」 macht:
- Jeder Browser auf dem iPhone muss Apples eigene WebKit-Engine nutzen – selbst Chrome und Firefox sind auf dem iPhone nicht mehr als ein Safari mit anderer Haut. Im Juni 2026 veröffentlichten Microsoft-Ingenieure einen Benchmark-Bericht, dem zufolge Browser auf iOS mit der Chromium-Engine bis zu 28,6 % schneller laufen könnten als Safari.
- Web-Apps (PWA) können auf iOS weder Face ID nutzen, noch Daten im Hintergrund synchronisieren; Push-Benachrichtigungen sind stark eingeschränkt – genau das, was vielen Apps ihren Kernreiz gibt.
- Safari hinkt der Chrome-Unterstützung von Webstandards um Monate oder gar Jahre hinterher – will ein Entwickler neue Technik nutzen? Er muss warten, bis Apple nachzieht.
In Europa versucht der Digital Markets Act (DMA), diese Lage aufzubrechen, und verlangt von Apple, die Beschränkung der Browser-Engine zu lockern. Doch Apples Reaktion wurde von einem US-Richter als 「boshafte Compliance」 bezeichnet – die Firma änderte die Regeln scheinbar, errichtete aber in der Praxis eine Reihe technischer Hürden, die Konkurrenten den wirklichen Markteintritt erschwert.
Was ist die Endwirkung all dessen? Entwickler werden auf das App-Store-Schiff 「gezwungen」, und Nutzer werden zu Menschen 「verwöhnt」, die nur noch App-Symbole kennen.
Die andere Seite der Debatte: Manche Szenarien brauchen wirklich eine App
An dieser Stelle muss ich klarstellen: Dies ist kein Artikel über die 「Erbsünde der App」. In der HN-Diskussion wies ein beträchtlicher Teil der Entwickler auf Szenarien hin, in denen Apps der Webseite tatsächlich überlegen sind:
Ein Programmierer namens OkayPhysicist teilte seine Erfahrung: In seiner Firma gab es ein Tool für Spesenabrechnung und Dokumente, das er als mobile Webseiten-Version umsetzte. Das Ergebnis? Kollegen liefen ihm hinterher mit Fragen wie 「Wie bekomme ich die Website aufs Handy?」, 「Wie öffne ich die Website am Handy?」, 「Kann man das nicht als App machen?」
Das Problem liegt in der Gewohnheit. Für die meisten gewöhnlichen Nutzer ist 「App」 ein greifbares Konzept, während 「Webseite」 abstrakt wirkt. Es ihnen zuzumuten, eine URL in die Adresszeile des Browsers einzutippen, ist weniger natürlich, als sie auf ein buntes Symbol tippen zu lassen.
Auch ein anderer Entwickler brachte einen validen Punkt: Wenn du einen Dienst dutzende Male täglich nutzt, ist eine eigenständige native App tatsächlich bequemer als ständig im Browser hin- und herzuwechseln. WeChat, Alipay, Kartenapps – in diesen Hochfrequenz-Szenarien sind die Performance-Vorteile der App (schnellere Reaktion, flüssigere Animationen, Offline-Funktionen) real.
Es gibt zudem Szenarien, die Webtechnik derzeit kaum abdeckt:
- Hochleistungsspiele: benötigen GPU-Beschleunigung, komplexes 3D-Rendering
- AR/VR-Anwendungen: benötigen tiefen Zugriff auf Kamera und Sensoren
- Professionelle Audio-/Video-Bearbeitung: benötigt Echtzeitverarbeitung und Hardware-Codecs
- Dienste, die im Hintergrund dauerhaft laufen: etwa Sport-Tracking, Navigation
Das sind allesamt legitime Grenzen der Webtechnik. Ich behaupte nicht, dass alles eine Webseite werden sollte, aber ebenso wenig, dass alles einen Grund hat, eine App zu werden.
Das eigentliche Problem: Kein Technikstreit, sondern ein Machtkampf
Diese 「App vs. Web」-Debatte ist im Kern ein Machtkampf darum, wer bestimmt, welche Software du nutzen darfst.
In der Welt des offenen Webs veröffentlichst du einen Dienst mit einer einzigen URL, und der Browser ist dein 「App Store」. Niemand prüft deinen Inhalt, niemand zieht dir Einnahmen ab, niemand entscheidet, ob dein Produkt 「zugelassen」 wird.
In der Welt des App Store sind Apple und Google die Torwächter. Sie entscheiden, was die Prüfung besteht (500 Prüfer verwalten zwei Millionen Apps), sie entscheiden, wie viel Provision sie nehmen (15 bis 30 %), sie entscheiden, welche Handyfunktionen deine App nutzen darf. Nutzer erhalten gewiss einen gewissen 「Sicherheitsschutz」 – zumindest theoretisch wurden die Dinge im App Store geprüft –, zahlen dafür aber mit dem Verlust der Wahl.
Das ist der tiefere Grund, warum Dans Artikel 676 Menschen in Rage versetzte: Das ganze System ist so konstruiert – eine Webseite, die eigentlich 0,05 MB groß wäre, wird gewaltsam zu einer 124-MB-App gemacht. Die Reise-App an sich ist nicht schlecht, aber das System zwingt sie auf einen aufgeblähten Weg.
Epilog: Was ist deine Wahl?
Dans Geschichte hat ein warmes Ende. Er teilte seine selbstgebaute Webseiten-Version mit den anderen Eltern im Team, und alle entdeckten zum ersten Mal, dass man den Reiseplan auch ohne diese aufgeblähte App sehen konnte. Als seine Tochter auf der Disney-Bühne sang und tanzte, war auf seinem Handy ein 124-MB-Tracker weniger.
Für uns gewöhnliche Menschen ist die Lehre aus dieser Geschichte eigentlich simpel: Wenn dir das nächste Mal jemand sagt, du solltest eine App herunterladen, um etwas anzusehen, frag doch einmal: Könnte das nicht eine Webseite sein?
Denn oft lautet die Antwort: Ja.
Referenzlinks:
- Dan Q: Deine 「App」 hätte eine Webseite sein können (also habe ich sie repariert)
- Hacker News Diskussion: 676 Kommentare über App vs. Web
- Microsoft-Benchmark der Ingenieure: iOS-Browser wegen WebKit-Beschränkung 28,6 % langsamer
- Bericht über Apples WebKit-Beschränkungen und den EU-DMA-Streit
- PWA-Einschränkungen auf iOS und der aktuelle Safari-Support-Stand (Vollständiger Leitfaden 2026)
- Änderungen an Apples 30-Prozent-Provision: Auswirkungen des Epic-Games-Kartellrechtsstreits
- Kontroverse um das App-Store-Prüfsystem: 500 Prüfer und zwei Millionen Apps in der Realität
- Open-Web-Interessenverband: Apples wettbewerbswidrige Auswirkungen der Browser-Engine-Beschränkung