- Apple bietet Kundinnen und Kunden sichere Geräte mit geringem Verwaltungsaufwand, kommt aber erfahrungsgemäß zu dem Schluss, dass es gegenüber einzelnen Entwicklern nicht dasselbe Maß an gegenseitiger Abhängigkeit schafft
- Der Dark-/Light-Mode-Bug in der Google-Suche dient als Beispiel dafür, dass Unannehmlichkeiten ohne Einfluss auf den Umsatz lange liegen bleiben können – eher als für mangelnde technische Kompetenz
- Apples zentraler Wert liegt weniger im App-Ökosystem als in Computern und Geräten, die Nutzer ohne gesonderte Verwaltung verwenden können; iPhones oder iPads seien auch ohne Apps kaufenswert
- Die 2016 erhoffte Apple Music API hat auch acht Jahre später noch Bugs und Zugriffsbeschränkungen, und selbst für einfaches Ausprobieren ist ein Entwicklerkonto für 100 US-Dollar pro Jahr nötig
- Die Webplattform, die keinem einzelnen Unternehmen gehört, ist unvollkommen und fragil, bleibt aber eine realistische Option für Entwickler, die weniger an die Zero-Sum-Strukturen bestimmter Unternehmen gebunden sein wollen
Apple ist stark für Kunden, aber nicht von Entwicklern abhängig
- Im Mittelpunkt steht die Einschätzung, dass Apple einzelnen Kundinnen und Kunden zwar klaren Wert bietet, aber nur schwache strukturelle Gründe hat, sich auf gleiche Weise um einzelne Entwickler zu kümmern
- Die Abhängigkeit verläuft als
Developer -> Apple,Apple -> Consumer; eine umgekehrte Abhängigkeit von Apple hin zu einzelnen Entwicklern gebe es kaum - Selbst wenn alle Entwickler die Entwicklung für Apple-Plattformen einstellen würden, könnte Apple im Großen und Ganzen überleben, weil Apples zentrales Wertversprechen nicht von einzelnen Entwicklern abhängt
- Zusammenarbeit mit „Partnern“ unter Unternehmensentwicklern kann nötig sein, ist aber eine andere Frage als die Abhängigkeit von einzelnen Entwicklern
- Manche multinationale Konzerne machen Entwickler zum Kern ihrer Strategie, Apple gehöre jedoch nicht zu diesem Typ
- Nachdem diese Unterscheidung akzeptiert war, ließen sich die Sympathie für Apple-Produkte und der Wunsch, für Apple zu entwickeln, voneinander trennen
Google-Beispiel: Bugs ohne Umsatzeffekt können lange bestehen bleiben
- Die Google-Suche hat in Umgebungen, in denen das System dynamisch zwischen Light und Dark Mode wechselt, ein Problem, bei dem die erste Suchergebnisseite im jeweils entgegengesetzten Theme angezeigt wird
- Nachts ist das gesamte System dunkel, doch die erste Ergebnisseite erscheint hell und schmerzt in den Augen
- Morgens, nachdem der Laptop wieder in den Light Mode gewechselt ist, erscheinen die Suchergebnisse auf schwer lesbarem schwarzem Hintergrund
- Dieser Bug besteht seit Jahren, und es sei unwahrscheinlich, dass er behoben wird, sofern er nicht zufällig im Zuge einer größeren Überarbeitung verschwindet
- Als Ursache wird nicht fehlende Fähigkeit Googles gesehen, sondern dass er keinen Einfluss auf den Umsatz hat
- Wer alternative Suchmaschinen wie DDG nutzt, ist bereits gegangen, während die überwältigende Mehrheit an Google gebunden ist
- DDG stellt seine Datenschutzfreundlichkeit heraus, doch der tatsächliche Nutzungsgrund liege in der einfachen UX, die an das frühe Google erinnert, guten und präzisen Suchergebnissen sowie unaufdringlicher Werbung
- Google mache Nutzer nicht zum spieltheoretischen Ziel; auch nutzerfeindliche Interaktionen, die entstehen, wenn man Google-Produkte verwenden muss, werden als Ergebnis dieser Struktur verstanden
Apples Kernwert: sichere Computer ohne Verwaltungsaufwand
- Um 2009 herum fiel bei der Auswahl eines Familiencomputers die Einschätzung, dass Windows damals sicherheitstechnisch zu schwach und Linux auf kontinuierlichen technischen Support angewiesen war
- Am Ende wurde ein Computer mit OpenBSD, Firefox und einfachen Spielen eingerichtet; dafür gab es Sicherheit, Privatsphäre und geringen Supportaufwand, aber die Nutzbarkeit war stark eingeschränkt
- Nachdem bei einer iOS-App-Firma ein Arbeits-Mac genutzt wurde, entstand das Urteil: „Das ist der Computer, den ich für meine Mutter wollte“
- Es wurde Geld für ein MacBook gespart, und mit der Zeit wechselte der von der Familie genutzte Formfaktor vom Laptop zum iPad, doch derselbe Kernwert wurde weiterhin erfüllt
- Selbst ein iPhone ohne Apps wäre für die eigene Nutzung möglicherweise ein Kauf; für die Familie sei es fast sicher ein Gerät, das gekauft würde
- Im Geschäftsmodell von Apple sind Entwickler kein zwingender Bestandteil; es ist in Ordnung, wenn Entwickler zufrieden sind, aber die Struktur erfordert nicht, dass sie zufrieden sein müssen
- Innerhalb von Apple gibt es einzelne Personen, die sich um Entwickler kümmern und Verbesserungen anstreben, doch das Handeln des Unternehmens insgesamt kann inkonsistent sein
Erwartungen und Enttäuschung rund um die Apple Music API
- Als die Apple Music API um 2016 herum auf der WWDC angekündigt wurde, waren die Erwartungen groß, doch tatsächlich trat kein Moment ein, in dem „alles anders“ wurde
- Apples eigener Musikplayer wird weiterhin als schwer benutzbar empfunden, und die ausprobierten alternativen Player folgen größtenteils dem Spotify-Ansatz
- Erwartet wurde, ein schnelles, geschmeidiges, endlos weiterlaufendes und zugleich persönliches Musikplayer-Erlebnis wieder schaffen zu können – wie in der Ära von Justin Frankel bei Winamp
- Mit Apples Musikkatalog ließe sich ein solches Erlebnis reproduzieren, ohne wie früher auf Piraterie angewiesen zu sein
- Als freie Zeit entstand, wurde ein Musikplayer namens Flowers gebaut; außerdem sollte ein Tutorial entstehen, damit andere ihre eigenen Musikplayer bauen können
- Bei der Implementierung entstand acht Jahre später die Einschätzung, dass die API weiterhin fehlerhaft und nicht offen ist
- Schon um die API nur auszuprobieren, muss man Apple 100 US-Dollar pro Jahr zahlen
- Die Kosten fallen nicht für Massennutzung an, sondern bereits für einfachen Testzugang
- Selbst mit einem kostenpflichtigen Entwicklerkonto erhält man nur eine eingeschränkte API
- Gibt man in der Browser-Konsole von Apples Web-Musikplayer
MusicKit.getInstance().developerTokenein, erhält man kostenlos ein uneingeschränktes Root-Token; deshalb erscheint der Entwicklerprozess unvernünftig
Das Web ist eine gemeinsame Plattform ohne einzelnen Eigentümer
- Die Schlussfolgerung läuft darauf hinaus, Code zu schreiben, der im Web läuft
- Das Web ist eine gemeinsame Plattform ohne einzelnen Eigentümer und unterscheidet sich von Plattformen einzelner Unternehmen dadurch, dass selbst gute Absichten durch Inkompetenz scheitern können
- Die Webplattform befindet sich wegen folgender Faktoren in einem fragilen Zustand
- übermäßig eingreifende Regierungen
- ein Browser-Duopol
- ein komplexes Entwickler-Ökosystem
- Es gibt keine Garantie, dass das Web weiter floriert, doch es hat bis jetzt überlebt, und je länger es überlebt, desto größer wird die Wahrscheinlichkeit, dass es auch künftig gedeiht
- Der zuletzt im Zusammenhang mit dem Web nötige Workaround-Code sei wegen eines eigenartigen Safari-Verhaltens erforderlich gewesen
- Gleichzeitig leistet Google großartige Arbeit für das Web und wird in diesem Kontext als positive Kraft bewertet
Beziehungen zu Unternehmen lassen sich schwer in festes Gut und Böse einteilen
- So wie es wenig nützlich ist, Menschen dauerhaft in gute und schlechte Menschen einzuteilen, lassen sich auch Unternehmen schwer dauerhaft in gute und schlechte Unternehmen einordnen
- Unternehmen teilen menschenähnliche Eigenschaften: Intelligenz, Persönlichkeit, Geburt, Wachstum und Vergehen sowie Rechtspersönlichkeit
- So wie man nicht ohne Menschen leben kann, kann man auch nicht ohne Unternehmen leben; trotz unmenschlicher Eigenschaften werde die fraktale Form menschlicher Organisation weiter existieren
- Wenn man Unternehmen nicht in feste Kategorien von Gut und Böse einordnet, kann man flexibler mit ihnen in Beziehung treten
- Wenn ein Unternehmen einen in ein Zero-Sum-Game drängt, reduziert man die Abhängigkeit
- Wenn es eine stärker symbiotische Beziehung zulässt, beteiligt man sich wieder
- Steve Jobs sagte 1996, große, mittlere und kleine Unternehmen hätten begonnen, das Web als endgültigen direkten Vertriebskanal zum Kunden zu sehen – als Weg vom Anbieter direkt zum Verbraucher unter Umgehung von Zwischenhändlern
1 Kommentare
Hacker-News-Meinungen
Ich habe mich früh entschieden, native Mobile-Entwicklung nicht zu lernen und meine begrenzte Zeit ganz auf das Web zu konzentrieren; diesmal war das meiner Ansicht nach die richtige Entscheidung.
Heute kann man im Browser Erstaunliches bauen, und ganz persönlich denke ich: Abgesehen von Dingen wie Uber, Google Drive und Spielen hätten die meisten Apps Web-Apps sein sollen.
Ich habe in der Medienbranche gearbeitet, und in unserem Land waren die frühen 2010er eine Zeit, in der Medienhäuser mit ohnehin wenig Geld ihre Budgets in mobile Apps pumpten. Ich war der Außenseiter, der sich diesem Trend verweigerte.
Mir war klar, dass die meisten Apps kaum gut sein würden und dass die Unternehmen ihre mobilen Frontends nicht kontinuierlich aktualisieren würden – und genau so kam es.
Heute stecken sie in Apps fest, die kaum noch gewartet werden; die meisten wirken wie Relikte einer vergangenen Ära, und genau das sind sie auch.
Aber warum Uber, verstehe ich nicht. Uber hat oder hatte eine mobile Website, die Fahrtenbestellungen und fast alles, was die App tut, gut erledigt, und ich sehe nicht recht, welchen zusätzlichen Wert die native App dem Nutzer bringt.
Für die meisten Mobile Games gilt dasselbe. Meist handelt es sich um einfache Grafik, die ein Browser performant genug rendern kann, und oft werden gemeinsame UI-Komponenten ohnehin selbst neu gebaut, sodass es kaum einen Unterschied macht, keine nativen System-Buttons verwenden zu können.
Auch eine PWA kann ausreichend Speicherplatz für lokal gespeicherte Dateien und Spieldaten bereitstellen. Ausgenommen sind natürlich Spiele, die die Systemgrenzen ausreizen.
Ich würde nicht erwarten, dass Spiele wie Death Stranding oder das RE4-Remake ohne direkten Zugriff auf native Grafikbeschleunigung gut laufen; außerdem sind sie zu groß, um als einzelne Webseite geladen zu werden.
Aber die meisten Mobile Apps fallen nicht in diese Kategorie, nicht einmal umsatzstarke Free-to-Play-Spiele, die über das Web 30 % mehr vom Umsatz behalten könnten.
Warum also zielen sie nicht auf das Web? Mein Bauchgefühl: Mobile-Nutzer sind darauf konditioniert, Apps und Spiele im App Store zu suchen, während Desktop-Nutzer erwarten, dass Apps – abgesehen von einigen spezialisierten Tools und High-End-Spielen – im Browser bereitgestellt werden.
Am Ende ist vieles davon ein kulturelles Problem, und Apples mangelhafte PWA-Unterstützung hilft dabei nicht.
Ein Großteil der Frustration kommt von den Tools, insbesondere TypeScript. Es ist schwer kurz zu beschreiben, aber ich habe deutlich mehr Zeit damit verbracht, mit dem TypeScript-Typsystem zu ringen, als ich es aus dem nativen Bereich kenne.
Allerdings mache ich mir Sorgen, ob Google und Apple überhaupt einen Anreiz haben, PWAs so weit zu verbessern, dass sie mit nativen Apps konkurrieren können. Wenn sie dieses Niveau erreichen, könnte das ihre Einnahmen treffen.
Besser ist es, Zeit in die Grundbausteine des Tech-Stacks zu investieren.
Das sind alles Dinge, die man übers Web erledigen könnte.
Dass Apple sich nicht um Entwickler kümmert, liegt daran, dass es, wie sie selbst erklären, auf Nutzerseite eine Art Kult um einen Walled Garden geschaffen hat.
Entwickler verlieren die Hälfte des Marktes oder mehr, wenn sie keine Produkte für diese Plattform bauen.
In meinem Hauptjob, in einem kleinen Studio innerhalb eines Großunternehmens Mobile Games zu entwickeln, müssen wir uns mit Apple nicht nur bei technischen Fragen, sondern auch bei Richtlinien und Freigaben ständig auseinandersetzen.
Aber ein Mobile Game zu veröffentlichen, das auf iOS nicht lauffähig ist, ist schwer vorstellbar, also bleibt uns nichts anderes übrig, als uns zu fügen.
In vielerlei Hinsicht war Microsofts ursprüngliche PC-Strategie das genaue Gegenteil. Man kümmerte sich um Entwickler und stellte umfangreiche Dokumentation, Beispiele und Tools bereit.
Die Unternehmen dieser Entwickler hatten einen Anreiz, Software für Microsoft zu bauen, zu bewerben und zu verkaufen, und die Welle einzelner Entwickler, die Windows-Software hervorbrachten, hat das bis heute dominierende Desktop-Betriebssystem geschaffen.
Zum Apple-Ökosystem beizutragen ist eine Entscheidung, kein Zwang. Entwickler, die zum Apple-Ökosystem beitragen, beteiligen sich aktiv an der heutigen Situation.
Apple erreicht das, indem es Entwickler schlecht behandelt – oder genauer gesagt, indem es verhindert, dass Entwickler ihre Kunden schlecht behandeln.
Das ähnelt auch der Art, Lieferanten stark unter Druck zu setzen, aber am Ende ist ein gesundes und wohlhabendes Ökosystem entstanden, und Entwickler wie Lieferanten stellen dort weiterhin Apps bereit.
Dinge wie soziale Netzwerke, Dating-Apps, Reddit oder Stack Overflow. Nicht Dienste, die auf die Mobile Experience angewiesen sind, etwa Uber mit notwendigem Location-Tracking oder Mobile Games, die fürs Spielen unterwegs konzipiert sind.
Wenn das Business nicht von der Mobile Experience abhängt, kann man den Dienst auch ohne native App anbieten.
Mobile-Nutzer können auch über den mobilen Browser zugreifen; das ist vielleicht nicht die ideale Erfahrung, aber es ist eine Option.
Der Kern ist meiner Ansicht nach: Wenn eine mobile Plattform nicht zwingend erforderlich ist oder man nicht von ihr abhängt, sollte man nicht für sie bauen.
Vor ein paar Jahren habe ich mich intensiv damit beschäftigt, Swift und native iOS-Entwicklung zu lernen, konnte mich aber einfach nicht an Xcode gewöhnen.
Die UI/UX von Xcode war kaum in Worte zu fassen schrecklich, und ständig musste ich Panels öffnen und schließen, nur um auf Icons zu klicken, die nicht einmal intuitiv gruppiert waren.
Wenn man ein Panel öffnete, wurde ein anderes zwangsweise minimiert, und es fühlte sich so an, als verbringe man ein Zehntel der Zeit praktisch mit „Panel-Fahren“.
Die Designer bei Apple wollten offenbar keine IDE mit wenig Reibung für Entwickler bauen, sondern eine optisch hübsche und minimalistische IDE.
Aber eine IDE muss nicht minimalistisch sein; jeder Entwickler sollte sie so stark anpassen und unordentlich lassen können, wie es zu dem passt, was er bauen will.
Wenn man sich eine physische Werkbank in einer Garage vorstellt: Visual Studio lässt einen den Arbeitsbereich so chaotisch und individuell gestalten, wie man möchte, während Apple sich so anfühlt, als müsste man jedes Mal das vorherige Werkzeug wieder in die Kiste legen, bevor man das nächste nehmen darf.
Genau das meine ich mit Panel-Fahren, und ich frage mich, ob andere Entwickler das auch so empfinden.
Die Formulierung, dass Form über Funktion gestellt wird, hilft mir, in Worte zu fassen, was ich an Xcode nicht mochte.
Ich bin seit über zehn Jahren im JetBrains-Ökosystem und es hat auch seine Nachteile, aber ich hatte nie das Gefühl, dass JetBrains versucht, mich daran zu hindern, die IDE so funktionieren zu lassen, wie ich es will.
Was mich aber wirklich von der Entwicklung nativer Apps für Apple-Plattformen abgebracht hat, war die Kombination aus Bugs und fehlender Dokumentation.
Als ich SwiftUI vor einem Jahr zuletzt benutzt habe, war es nicht zweckgeeignet, und selbst reifere Libraries hatten oft kaum Dokumentation.
Es ist auch schwer zu erkennen, was eigentlich deprecated ist.
In meiner Arbeit sind die Vorteile nativer Apps aus Nutzersicht von vornherein gering, im Wesentlichen eine etwas zuverlässigere lokale Speicherung.
Wenn meine Produktivität deutlich niedriger ist als beim Bau einer Web-App, ist es schwer, die zusätzlichen Kosten und Risiken zu rechtfertigen, sich der Gnade eines monopolistischen Herrschers auszuliefern.
Xcode stört mich überhaupt nicht, aber das vielgelobte IntelliJ-basierte Android Studio geht mir ständig auf die Nerven.
Visual Studio ist ähnlich frustrierend und hat merkwürdige Einschränkungen. Zum Beispiel verstehe ich nicht, warum man bei Syntax-Highlighting keine Kursivschrift verwenden kann.
Bei Editoren ist es genauso. VS Code hat im Gegensatz zu Sublime Text oder TextMate kleine störende Macken.
Es fühlt sich an wie eine alte, schwere IDE: Je mehr man sich ihr anpasst, desto bequemer wird es, aber gleichzeitig bleibt das Gefühl, nicht die Kontrolle zu haben.
Wenn Apple sich nur darum kümmern würde, hätten sie es vielleicht nicht so flott wie VS Code, aber wenigstens halbwegs reaktionsschneller machen können; es könnte definitiv besser sein als jetzt.
Allein die miserable Unterstützung für Vim-Keybindings macht mich wütend. Zum Beispiel kann man die meisten Aktionen wie
coderrnicht wiederholen.Ich weiß nicht, ob damals SwiftUI verwendet wurde oder ob du mit Storyboards in UIKit gekämpft hast, aber Letzteres ist die schlimmste Erfahrung, die ich nicht einmal meinem ärgsten Feind empfehlen würde.
SwiftUI steckt noch in den Anfängen und hat einiges an Feinschliff nötig, fühlt sich im Vergleich dazu aber wie die Zukunft an.
Früher mussten wir einmal ein Apple-Entwicklerkonto einrichten, um eine unserer kommunalen Apps als in unserem Besitz auszuweisen.
Warum das bei den anderen Apps nicht nötig war, weiß ich nicht, aber jedenfalls mussten wir es tun, und es war eine ziemlich furchtbare Erfahrung.
Zuerst brauchte ich ein Apple-Konto, und da ich mein privates Konto nicht verwenden wollte, musste ich ein neues berufliches Konto anlegen.
Ein „Organisationskonto“ konnte man nicht erstellen, also war es an mich als Person gebunden; zum Glück hatten wir ein altes iPhone, das ohnehin ausgemustert werden sollte, und das konnte ich dafür verwenden.
Danach wartete ich mehrere Tage darauf, dass Apple meine Identität bestätigte; im Grunde rief Apple die Person an, die ich als meinen Vorgesetzten angegeben hatte, und diese Person sagte, dass das stimme.
Ich hoffe, sie haben noch weiter recherchiert, aber sicher bin ich nicht, und die Leute am Telefon sprachen noch schlechter Englisch als wir, sodass es zumindest lächerlich war.
Anschließend musste ich die Zahlung einrichten, denn aus irgendeinem Grund muss man Geld bezahlen, um ein Apple-Entwicklerkonto zu haben.
Für den Gesamthaushalt einer Stadt mit 60.000 Einwohnern ist das vermutlich ein Betrag, der gar nicht auffällt, aber weil es ein Auslandsabo war und Apple keine Möglichkeit bot, es als B2B-Kauf abzuwickeln, die sich einfach bei der lokalen Steuerbehörde registrieren lässt, wurde es jedes Jahr überprüfungspflichtig.
Bezahlen konnte man außerdem nur per Kreditkarte, und da auch Organisationskarten an reale Personen gebunden sind, brauchte es jemanden, der die Verlängerung übernimmt.
Menschen wechseln den Job, und um den Besitzer zu ändern, müssen Apple und reale Personen miteinander Kontakt aufnehmen; man kann sich vorstellen, wie unterhaltsam das war.
Das ist ein paar Jahre her, also hat sich vielleicht etwas geändert, aber unter den über 300 Enterprise-IT-Lösungen, mit denen ich zu tun hatte, war nichts so schrecklich wie Apple.
Fairerweise muss ich sagen, dass ich Entwickler bin und nicht weiß, warum ich diese Aufgabe überhaupt bekommen habe; vielleicht ist so etwas im IT-Betrieb üblicher.
Ausgenommen sind große US-Unternehmen, die den Papierkram problemlos erledigen können.
Es ist weiterhin zufällig. Es kann sofort klappen, oder wenn man Pech hat und auf einen der zufälligen Bugs in diesem Prozess trifft, scheitert es sehr lange.
Ich weiß nicht, wann das eingeführt wurde, aber ganz neu ist es nicht.
Man vergisst manchmal, wie offen das ursprüngliche Web/www war – und wie offen es insgesamt auch heute noch ist, verglichen mit den von Apple und Google monopolisierten „App-Ökosystemen“.
Klar, es gibt die „Cloud“, aber nichts hindert einen daran, einen Server zu mieten und die eigenen Dinge selbst zu hosten.
Wenn es nicht gut läuft, kann man sie dort herausziehen und einen anderen Server mieten. Es gibt Lock-in-Effekte, und es ist vielleicht nicht einfach, aber unmöglich ist es nicht.
Im gesamten App-Ökosystem gibt es nur zwei Optionen, und man ist buchstäblich auf deren Gnade angewiesen.
Ich persönlich würde niemals mein gesamtes Geschäft auf eine einzelne „App“ setzen. Wenn das Publikum es wirklich verlangt, könnte man eine App als kleine Ergänzung anbieten, aber mehr auch nicht.
Ich hasse Produkte, die mich auf Mobilgeräten zu einer App zwingen. Mir wäre es lieber, wenn so etwas wie m.website.com zurückkäme; ich möchte das ganze App-Ökosystem lieber meiden.
Über Nacht kann man ohne Grund oder aus irgendeinem Grund in die Lage geraten, „auf der HN-Startseite um Hilfe betteln zu müssen“.
Ich bete, dass die neue Sideloading-Entwicklung in der EU ähnliche Forderungen in den USA auslöst, weiß aber zugleich sehr genau, dass dafür genug Menschen wissen und sich dafür interessieren müssten, was „Walled Garden“ oder „Sideloading“ bedeutet.
Das Web ist theoretisch großartig, aber die Browser-Umgebung bietet viel zu sehr nur das Nötigste. Wenn man eine „Batteries included“-Entwicklungserfahrung wie auf Apple-Plattformen gewohnt ist, wirkt es als App-Plattform daher wenig attraktiv.
Unter macOS kann man selbst leistungsfähige und ausgefeilte Apps mit so wenigen Abhängigkeiten und transitiven Abhängigkeiten entwickeln, dass man sie an einer Hand abzählen kann; mit etwas Aufwand sogar ganz ohne.
Eine gleichwertige Web-App hat dagegen Dutzende bis Hunderte Abhängigkeiten, nur um Funktionslücken zu schließen.
Zum Beispiel sehe ich keinen Grund, warum der Browser keine native Listen-/Tabellenansicht bereitstellen kann, die Zellen effizient wiederverwendet und dabei gar kein oder nur äußerst wenig JavaScript benötigt.
Es ist nicht ungewöhnlich, durch Hunderte bis Tausende Einträge scrollen zu müssen, ohne dass das Gerät ruckelt oder der Speicher ausgeht.
AppKit, UIKit, SwiftUI, Android Framework, Compose und vermutlich auch Flutter erledigen das standardmäßig gut, aber im Browser muss man für diese sehr grundlegende Funktion eine Bibliothek heranziehen oder selbst Code schreiben.
Wenn dann noch Paketverwaltung und allgemeine Tooling-Probleme dazukommen, bleibt dasselbe Grundproblem hartnäckig bestehen, auch während Lösungen kommen und gehen.
Ich habe seit vor 15 Jahren auch einige iOS-/iPad-Apps gebaut.
Das Gute am Web ist, dass es meistens eine Bibliothek oder ein Framework gibt, das zu den Anforderungen passt. Electron ist ein Beispiel.
Auf der Apple-Seite gibt es oft keine guten Bibliotheken, und SwiftUI hat viel zu viele Bugs.
React funktioniert einfach gut und ist konzeptionell auch einfacher. Bidirektionales Data Binding ist eine schlechte Idee.
Apple hat die Vorstellung, alles einfacher zu machen, aber in der Praxis macht es die Dinge oft umständlicher und schwieriger.
Eine Tabelle ist bereits serverseitig mit den benötigten Daten in der richtigen Reihenfolge gefüllt.
Deshalb müssen Zellen und Zeilen nicht wiederverwendet werden, und selbst bei Tausenden Zeilen liegen die Daten im KB-Bereich, sodass es flott läuft.
Wenn man Alternativen wie WebAssembly und Flutter berücksichtigt, sollte der Mangel an nativen Browser-Funktionen kein Problem mehr sein.
Ich denke nicht, dass es stimmt, dass Entwickler Apple nichts bringen.
Ohne Drittanbieter-Apps auf dem iPhone hätte Apple deutlich weniger Geräte verkauft.
Theoretisch könnten viele Apps ins Web wandern, aber trotzdem machen Drittanbieter-Apps das iPhone weiterhin sehr viel besitzenswerter.
Bei echter Konkurrenz bemühen sich Betriebssystemhersteller sehr darum, Entwickler anzuziehen. Man denke nur an Ballmers altes „developers developers developers“-Video.
Denn sie wissen, dass Entwickler einer Plattform Wert hinzufügen und die Wahl der Verbraucher beeinflussen.
Das heutige Problem ist, dass es keinen nennenswerten Wettbewerb gibt.
Egal wie Apples Regeln aussehen: Entwickler müssen etwas fürs iPhone anbieten, und Apple kann sich sicher fühlen, dass eine dritte Mobile-Plattform kaum Fuß fassen wird.
Apple weiß das und hat die Situation durch strikte Richtlinien brutal auf den Kopf gestellt.
Obwohl Entwickler einen großen Anteil daran haben, dass sich der Besitz eines iPhones lohnt, erhebt Apple eine Steuer auf den gesamten Umsatz, als würde es ihnen gnädigerweise erlauben, iPhone-Kunden zu erreichen.
Das ist Missbrauch einer marktbeherrschenden Stellung, und wie der Blog sagt, kann man außer der Verteilung über das Web nicht viel tun.
Es ist nicht perfekt, aber neben Regulierung ist es die einzige sinnvolle Alternative, und Apple hat keinen Grund, freiwillig auf die Milliardenumsätze zu verzichten, die es durch die Besteuerung von App-Entwicklern erzielt; daher wird es alles versuchen, um Regulierung zu umgehen.
Ich hoffe, dass das Web als Weg an Bedeutung gewinnt, missbräuchliche Regeln für App-Distribution zu umgehen.
Ich denke jeden Tag darüber nach, wie großartig das Web ist – und wie bedauerlich es ist, dass Apple versucht hat, das Web so weit wie möglich zu ruinieren, indem es Entwickler dazu brachte, iOS-Apps statt Web-Apps zu bauen.
Ohne den App Store wäre das Web viel besser geworden.
Es gäbe mehr Vielfalt bei Content-Konsum, Quellen sozialer Medien, algorithmischen Empfehlungen und digitalen Erlebnissen.
Das Web läuft überall, und es gibt viele hervorragende APIs, mit denen sich immersive bzw. Next-Generation-Anwendungen wie WebXR erstellen lassen.
Aber wenn jemand auf seiner eigenen Website eine WebXR-App baut und kostenpflichtig verkauft, verdient Apple daran nichts; deshalb wird Apple solche Web-Apps niemals bewerben.
Langfristig stirbt das Web nicht. Unternehmen kommen, schöpfen Gewinne ab und verschwinden wieder, aber das Web stirbt nicht.
Apple stellt Tausende APIs bereit, die die Plattformentwicklung erleichtern, hat eine eigene Programmiersprache geschaffen, die gut in die Plattform integriert ist, und verfügt auch über eine vollständig integrierte IDE, die mit beidem zusammenarbeitet
Genau, „Freund“. Sie interessieren sich nicht für dich, solange du nicht für ihre Plattform entwickelst
Und wer könnte es ihnen verübeln? Das oben Genannte sind enorm teure und zeitaufwendige Investitionen
Ich habe versucht, ohne Swift und Apple-Tools direkt Apps unter macOS zu entwickeln, und es war extrem schmerzhaft
Sie haben OpenGL auslaufen lassen und auf eine Version festgenagelt, und das lässt sich kaum anders erklären als damit, ihre eigenen Tools zu pushen
Selbst das Laden einer einzigen externen DLL war nahezu unmöglich
Alles, was plattformübergreifend ist, muss in Apples Tool-Ökosystem heruntergebrochen werden, etwa wenn Vulkan in Metal übersetzt wird
macOS ist ein noch ungewöhnlicherer und speziellerer Sonderfall als jede Linux-Distribution
Es ist erstaunlich, wenn man sieht, wie einfach Windows-Entwicklung ist. Bei Microsoft ist fast alles plattformübergreifend
Von den genannten Apple-Dingen hilft nichts dabei, plattformunabhängig zu arbeiten
Windows unterstützt dagegen zwar eigene Technologien wie DirectX, erlaubt aber auch, Vulkan, OpenGL usw. direkt auszuführen
Aber dass der Autor über die Arbeit an einer Musik-App hineingekommen ist, ist bedeutsam. Apples Audio-APIs sind ein komplettes Durcheinander
Media Player, AVPlayer, Core Audio, AVFoundation, AVAudioEngine usw. – es wirkt, als hätten konkurrierende Teams bis zurück in die NeXT-Zeit jeweils ihre eigenen Libraries genutzt, und irgendwie haben sie alle bis in die iPhone-Ära überlebt
Während der COVID-Lockdowns habe ich etwa drei Monate damit verbracht, einen Shoutcast/Icecast-Player zu bauen, und es war wirklich schmerzhaft
Sie haben es faktisch unmöglich gemacht, nativen plattformübergreifenden Code zu schreiben, der auf iOS läuft, und im Rahmen der politischen Grenzen alles getan, damit Web-Apps nicht mit nativen Apps konkurrieren können
Mir gefällt die gesunde Haltung des Autors gegenüber Großkonzernen. Das ist eine grundlegende Überlebenstechnik der Gegenwart
Wenn ich frei entscheiden könnte, müsste ich auf iPhone oder iPad gar keine Apps installieren, aber durch Plattformbeschränkungen wird es praktisch notwendig
Ich habe gesehen, dass die X/Twitter-Web-App in Safari keine Videos abspielt, selbst nachdem ich den Lockdown Mode für X deaktiviert hatte
Ich wüsste gern, ob das Apples Schuld ist, weil sie Plattforminkompatibilität erzeugt haben, oder ob X beabsichtigt, Nutzer zur Installation der App zu bewegen
Ich bin auf Deep Learning und LLMs spezialisiert, habe aber auch Webentwicklung immer gern gemacht
Was mich ausbremst, ist, dass die Tools zu komplex sind
Trotzdem schreibt ein Bekannter viel über ClojureScript + Dart, daher überlege ich, es einmal auszuprobieren
Ich würde gern einen einfachen Web-App-Stack finden, den man in ein paar Tagen lernen kann und der gut unterstützt wird; Empfehlungen wären willkommen
Ein großer Teil der Webentwicklung besteht darin, den Browser gut zu kennen, und web.dev ist eine hervorragende Ressource
Danach sollte man React + TypeScript lernen. Das neue react.dev ist ebenfalls gut
React ist nicht perfekt, aber als Paradigma zum Erstellen von UIs so gut, dass Apple sich beim Bau von SwiftUI daran orientiert hat
Nimm Vite und fang an zu coden
Am meisten würde ich empfehlen, diese Materialien wirklich gründlich durchzuarbeiten. Man sollte mit der ersten Seite der Dokumentation anfangen und sich Schritt für Schritt bis zum Ende durcharbeiten
Allerdings kann man in ein paar Tagen nicht allzu viel lernen. Frontend-Arbeit ist aus guten Gründen schwierig