- Apple fournit aux clients des appareils sûrs et peu contraignants à administrer, mais l’auteur en arrive empiriquement à la conclusion que l’entreprise ne crée pas le même niveau d’interdépendance avec les développeurs indépendants
- Le bug de mode sombre/clair de Google Search sert d’exemple pour montrer qu’un désagrément sans impact sur les revenus peut rester ignoré longtemps, plus qu’un manque de compétence technique
- La valeur centrale d’Apple tiendrait moins à l’écosystème d’apps qu’à des ordinateurs et appareils que les utilisateurs peuvent employer sans gestion particulière, et un iPhone ou un iPad resterait désirable même sans apps
- L’API Apple Music, très attendue en 2016, présente encore des bugs et des restrictions d’accès huit ans plus tard, et même un simple essai exige un compte développeur à 100 dollars par an
- La plateforme Web, qui n’appartient pas à une seule entreprise, reste imparfaite et fragile, mais demeure une option réaliste pour les développeurs qui veulent être moins enfermés dans la logique à somme nulle d’un acteur particulier
Apple est fort avec ses clients, mais ne dépend pas des développeurs
- L’idée centrale est qu’Apple apporte clairement de la valeur à ses clients particuliers, mais qu’elle a peu de raisons structurelles de se soucier des développeurs indépendants de la même manière
- La relation de dépendance s’écoule comme
Développeur -> Apple,Apple -> Consommateur, et il n’existerait presque pas de dépendance en sens inverse, d’Apple vers le développeur indépendant - Même si tous les développeurs cessaient de créer pour les plateformes Apple, Apple pourrait globalement survivre, parce que sa proposition de valeur essentielle ne repose pas sur chaque développeur pris individuellement
- Une coopération avec des développeurs d’entreprise « partenaires » peut être nécessaire, mais c’est un sujet différent de la dépendance envers les développeurs indépendants
- Certaines multinationales placent les développeurs au cœur de leur stratégie, mais Apple ne ferait pas partie de cette catégorie
- Une fois cette distinction acceptée, il devient possible de séparer l’affection pour les produits Apple de l’envie de développer pour Apple
Cas Google : les bugs sans impact sur les revenus peuvent durer longtemps
- Google Search a un problème où, dans un environnement où le système passe dynamiquement du mode clair au mode sombre, la première page de résultats s’affiche avec le thème opposé
- La nuit, alors que tout le système est en mode sombre, la première page de résultats surgit en clair et agresse les yeux
- Le matin, une fois l’ordinateur portable revenu en mode clair, les résultats s’affichent sur un fond noir difficile à lire
- Ce bug dure depuis des années, et il est jugé peu probable qu’il soit corrigé, sauf peut-être par hasard lors d’une refonte de grande ampleur
- L’interprétation n’est pas que Google est incapable de le corriger, mais que cela n’a aucun impact sur les revenus
- Les personnes qui préfèrent un moteur alternatif comme DDG sont déjà parties, et l’écrasante majorité reste liée à Google
- DDG met en avant la protection de la vie privée, mais la vraie raison de l’utiliser serait plutôt une UX simple rappelant les débuts de Google, des résultats de recherche exacts et de bonne qualité, et des publicités qui ne dérangent pas
- Google ne considérerait pas ses utilisateurs comme un objectif de théorie des jeux, et les interactions hostiles à l’utilisateur qui apparaissent lorsqu’il faut utiliser des produits Google seraient aussi une conséquence de cette structure
La valeur clé d’Apple : des ordinateurs sûrs et sans lourdeur d’administration
- Vers 2009, au moment de choisir un ordinateur pour la famille, Windows était jugé trop vulnérable sur le plan de la sécurité, tandis que Linux exigeait un support technique continu
- Un ordinateur avec OpenBSD, Firefox et quelques jeux de base a finalement été préparé, mais le gain en sécurité, en vie privée et en faible charge de support s’est payé par de fortes limites d’usage
- Après avoir utilisé un Mac professionnel dans une entreprise d’apps iOS, l’auteur en est venu à se dire : « c’est l’ordinateur que je voulais pour ma mère »
- Après avoir économisé pour acheter un MacBook, puis avec le temps, le format utilisé par la famille est passé de l’ordinateur portable à l’iPad, mais la même valeur essentielle a continué d’être satisfaite
- Même sans apps, un iPhone resterait un appareil qu’il pourrait acheter pour lui-même, et presque certainement pour sa famille
- Dans le modèle économique d’Apple, les développeurs ne seraient pas un élément indispensable ; leur satisfaction est acceptable, mais elle n’est pas structurellement nécessaire
- Il existe chez Apple des personnes qui se soucient des développeurs et cherchent à améliorer les choses, mais les actions de l’entreprise à l’échelle globale peuvent manquer de cohérence
Attentes et désillusion autour de l’API Apple Music
- Quand l’API Apple Music a été annoncée à la WWDC vers 2016, les attentes étaient grandes, mais dans les faits, rien de « totalement transformateur » ne s’est produit
- Le lecteur musical d’Apple reste jugé difficile à utiliser, et les lecteurs alternatifs testés suivraient eux aussi, pour la plupart, une approche à la Spotify
- L’auteur espérait pouvoir recréer une expérience de lecteur musical personnelle, rapide, fluide et sans fin, comme à l’époque de Justin Frankel et de Winamp
- Avec le catalogue musical d’Apple, il semblait possible de reproduire cette expérience sans dépendre du piratage comme autrefois
- Une fois du temps libre retrouvé, l’auteur a créé un lecteur musical appelé Flowers et voulait aussi écrire un tutoriel pour que d’autres puissent créer leur propre lecteur
- Au cours de l’implémentation, il en est venu à juger que, même huit ans plus tard, l’API était buguée et peu ouverte
- Rien que pour tester l’API, il faut verser 100 dollars par an à Apple
- Ce coût n’est pas un tarif lié à un usage massif, mais une exigence même pour un simple accès d’essai
- Même avec un compte développeur payant, on n’obtient qu’un ensemble limité d’API
- Dans la console du navigateur du lecteur web musical d’Apple, saisir
MusicKit.getInstance().developerTokenpermet d’obtenir gratuitement un token racine sans restriction, ce qui rend la procédure destinée aux développeurs déraisonnable
Le Web est une plateforme partagée sans propriétaire unique
- La conclusion mène à une direction claire : écrire du code qui s’exécute sur le Web
- Le Web est une plateforme partagée qui n’appartient pas à une seule entité, et il diffère des plateformes d’entreprise en ce que même la bonne volonté peut y être ruinée par l’incompétence
- La plateforme Web reste fragile à cause des facteurs suivants
- des gouvernements trop interventionnistes
- un duopole des navigateurs
- un écosystème développeur complexe
- Il n’y a aucune garantie que le Web continue de prospérer, mais il a survécu jusqu’ici, et plus il dure, plus ses chances de continuer à prospérer augmentent
- Le contournement récemment nécessaire côté Web était dû à un comportement particulier de Safari
- En même temps, Google fait d’excellentes choses pour le Web et joue, dans ce contexte, un rôle positif
La relation aux entreprises ne se laisse pas facilement figer en bien et en mal
- De la même manière qu’il n’est pas très utile de classer définitivement les gens entre bons et mauvais, il serait difficile de classer durablement les entreprises entre bonnes et mauvaises
- Les entreprises partagent avec les personnes des attributs comparables : une forme d’intelligence, une personnalité, une naissance, une croissance, une disparition et une personnalité juridique
- De même qu’on ne peut pas vivre sans les autres, on ne peut pas vivre sans entreprises, et même si elles ont des traits non humains, les formes fractales de l’organisation humaine continuent d’exister
- Ne pas enfermer les entreprises dans des catégories morales fixes permet d’entretenir avec elles des relations plus souples
- lorsqu’une entreprise pousse dans un jeu à somme nulle, on réduit sa dépendance
- lorsqu’elle autorise une relation plus symbiotique, on peut de nouveau s’y engager
- En 1996, Steve Jobs disait que les grandes, moyennes et petites entreprises commençaient toutes à voir le Web comme leur canal final de distribution directe vers le client, un chemin allant directement du fournisseur au consommateur en contournant les intermédiaires
1 commentaires
Commentaires sur Hacker News
Au départ, j’ai choisi de ne pas apprendre le développement mobile natif et de consacrer tout mon temps limité au web, et avec le recul je pense que c’était le bon choix
Aujourd’hui, on peut créer des choses incroyables dans le navigateur et, à titre très personnel, j’estime qu’à l’exception d’Uber, Google Drive et des jeux, la plupart des applications auraient dû être des web apps
Je travaillais dans les médias, et au début des années 2010 dans mon pays, c’était l’époque où des rédactions sans grands moyens engloutissaient leur budget dans la création d’apps mobiles, et j’étais celui qui détonnait en refusant cette mode
Je savais que la plupart de ces apps ne seraient pas de bonne qualité et que les entreprises ne maintiendraient pas durablement leurs interfaces mobiles, et c’est exactement ce qui s’est passé
Aujourd’hui, on est coincés avec des apps presque plus maintenues du tout, qui ressemblent pour la plupart à des reliques d’une époque révolue — et c’est effectivement ce qu’elles sont
En revanche, je ne vois pas pourquoi Uber. Uber avait, ou a toujours, un site mobile qui gère bien la demande de trajet et pratiquement tout ce que fait l’app, et je vois mal quelle valeur l’app native apporte en plus à l’utilisateur
C’est pareil pour la plupart des jeux mobiles. Le plus souvent, ce sont des graphismes simples que le navigateur peut rendre avec des performances suffisantes, et comme ils recréent souvent eux-mêmes les composants d’interface communs, l’absence de boutons système natifs ne change pas grand-chose
Les PWA peuvent aussi offrir suffisamment d’espace de stockage pour les fichiers locaux et les données de jeu. Bien sûr, les jeux qui poussent le système dans ses retranchements sont une exception
Je ne m’attends pas à ce que des jeux comme Death Stranding ou le remake de RE4 tournent correctement sans accès direct à l’accélération graphique native, et ils sont bien trop volumineux pour être chargés sous forme d’une seule page web
Mais cela ne concerne pas la plupart des apps mobiles, ni même les jeux free-to-play très rentables qui pourraient conserver 30 % de revenus supplémentaires en passant par le web
Alors pourquoi ne pas viser le web ? Mon intuition, c’est que les utilisateurs mobiles ont été habitués à chercher apps et jeux dans les app stores, tandis que les utilisateurs desktop s’attendent à ce que les apps soient fournies dans le navigateur, sauf pour certains outils spécialisés et les jeux très exigeants
Au fond, c’est largement une question culturelle, et le faible support des PWA par Apple n’aide pas
Une grande partie de cette frustration vient des outils, surtout de TypeScript ; c’est difficile à résumer simplement, mais je me suis bien plus souvent retrouvé à lutter avec le système de types de TypeScript qu’avec quoi que ce soit côté natif
En revanche, je me demande si Google et Apple ont vraiment intérêt à aider les PWA à atteindre un niveau leur permettant de concurrencer les apps natives. À ce stade, cela pourrait nuire à leurs revenus
Mieux vaut investir son temps dans les briques fondamentales de la stack technique
Tout cela pourrait parfaitement passer par le web
Si Apple se soucie si peu des développeurs, c’est parce que, comme l’auteur l’explique, l’entreprise a créé côté utilisateurs une sorte de culte assimilable à un jardin clos
Si un développeur ne crée pas de produit pour cette plateforme, il perd la moitié du marché, voire plus
Dans mon travail principal, qui consiste à créer des jeux mobiles dans un petit studio au sein d’un grand groupe, il faut se battre en permanence avec Apple non seulement sur des questions techniques, mais aussi de politique et de validation
Mais il est difficile d’imaginer sortir un jeu mobile qui ne puisse pas tourner sur iOS, donc on n’a pas vraiment le choix
À bien des égards, la stratégie originelle de Microsoft sur PC était l’exact opposé. L’entreprise prenait soin des développeurs et leur fournissait une documentation abondante, des exemples et des outils
Les entreprises auxquelles appartenaient ces développeurs avaient intérêt à créer, promouvoir et vendre des logiciels pour Microsoft, et la vague de développeurs indépendants qui ont inondé Windows de logiciels a contribué à faire de celui-ci le système d’exploitation desktop dominant encore aujourd’hui
Contribuer à l’écosystème Apple est un choix, pas une obligation. Les développeurs qui y contribuent participent activement à la situation actuelle
Apple y parvient en traitant mal les développeurs — ou plus précisément, en empêchant les développeurs de mal traiter les clients
C’est assez similaire à une manière de mettre une forte pression sur les fournisseurs, mais au final cela a produit un écosystème sain et prospère, et développeurs comme fournisseurs continuent d’y proposer des apps
Des choses comme les réseaux sociaux, les apps de rencontre, Reddit, Stack Overflow. Pas des services dépendants de l’expérience mobile, comme Uber qui a besoin de suivi de localisation, ou des jeux mobiles conçus pour être joués en déplacement
Si l’activité ne dépend pas de l’expérience mobile, on peut fournir le service sans app native
Les utilisateurs mobiles peuvent aussi y accéder via le navigateur mobile ; ce n’est peut-être pas l’expérience idéale, mais cela reste une option
L’idée essentielle, à mon sens, c’est que si une plateforme mobile n’est pas indispensable ou si le service n’en dépend pas, alors il ne faut pas développer pour elle
Il y a quelques années, j’ai essayé de me plonger dans Swift et le développement iOS natif, mais je n’ai jamais réussi à m’habituer à Xcode.
L’UI/UX de Xcode était si atroce qu’il est difficile de trouver les mots, et il fallait sans cesse ouvrir puis fermer des panneaux pour cliquer sur des icônes qui n’étaient même pas regroupées de façon intuitive.
Quand on ouvrait un panneau, un autre était forcé de se réduire, et j’avais l’impression qu’un dixième de mon temps passait en pratique à « piloter des panneaux ».
On dirait que les designers d’Apple voulaient créer un IDE visuellement joli et minimaliste, plutôt qu’un IDE avec peu de friction pour les développeurs.
Or un IDE n’a pas besoin d’être minimaliste : chaque développeur devrait pouvoir le personnaliser autant qu’il le souhaite et le laisser aussi encombré que nécessaire selon ce qu’il essaie de construire.
Si on imagine un établi dans un garage, Visual Studio vous permet de désordonner et de personnaliser votre espace de travail autant que vous voulez, alors qu’Apple donne l’impression d’exiger que vous rangiez chaque outil dans sa boîte avant d’en prendre un autre.
C’est ça que j’entends par piloter des panneaux, et je me demande si d’autres développeurs le ressentent aussi.
La formule selon laquelle la forme passe avant la fonction m’a enfin donné les mots pour expliquer ce que je n’aimais pas dans Xcode.
Ça fait plus de dix ans que je suis dans l’écosystème JetBrains, avec ses défauts, mais je n’ai jamais eu l’impression que JetBrains essayait d’empêcher l’IDE de fonctionner comme je le voulais.
Mais ce qui m’a vraiment détourné de la création d’apps natives pour les plateformes Apple, c’est la combinaison des bugs et du manque de documentation.
La dernière fois que je l’ai utilisé, il y a un an, SwiftUI n’était pas dans un état adapté à son objectif, et même des bibliothèques plus matures avaient souvent très peu de documentation.
Il est aussi difficile de savoir ce qui a été abandonné.
Dans mon travail, les avantages des apps natives sont de toute façon limités du point de vue de l’utilisateur, essentiellement à un stockage local plus fiable.
Si la productivité est bien plus faible que pour créer une web app, il est difficile de justifier le coût et le risque supplémentaires de dépendre de la bonne volonté d’une sorte de seigneur monopolistique.
Xcode ne me dérange pas du tout, mais Android Studio, pourtant tant vanté et basé sur IntelliJ, me tape constamment sur les nerfs.
Visual Studio a lui aussi des limitations frustrantes et bizarres. Par exemple, je ne comprends pas pourquoi on ne peut pas utiliser l’italique pour la coloration syntaxique.
C’est pareil pour les éditeurs. VS Code a de petits détails agaçants que Sublime Text ou TextMate n’ont pas.
Ça rappelle les gros IDE d’autrefois : plus on se conforme à leur manière de fonctionner, plus on est à l’aise, mais en même temps on garde l’impression de ne pas avoir le contrôle.
Si Apple y prêtait un peu attention, ils pourraient sûrement le rendre au moins deux fois plus réactif qu’aujourd’hui, sinon au niveau de VS Code ; ce serait déjà nettement mieux.
Rien que la prise en charge lamentable des raccourcis Vim m’agace. Par exemple, on ne peut pas rejouer la plupart des actions comme
cour.Je ne sais pas si la personne utilisait SwiftUI à l’époque, ou si elle se battait contre les storyboards de UIKit, mais dans le second cas c’est la pire expérience possible, au point que je ne la souhaiterais même pas à mon pire ennemi.
SwiftUI est encore à ses débuts et a encore besoin d’être peaufiné, mais par comparaison ça ressemble à l’avenir.
Il m’est arrivé autrefois de devoir configurer un compte développeur Apple pour marquer l’une des apps de notre collectivité comme nous appartenant.
Je ne sais pas pourquoi c’était nécessaire alors que ce ne l’était pas pour les autres apps, mais il fallait le faire, et ça a été une expérience assez horrible.
Il fallait d’abord un compte Apple, et comme je ne voulais pas utiliser mon compte personnel, j’ai dû en créer un nouveau pour le travail.
Il était impossible de créer un « compte organisation », donc il était lié à ma personne ; heureusement, j’avais un vieil iPhone destiné à être mis au rebut et j’ai pu l’utiliser.
Ensuite, il a fallu attendre plusieurs jours qu’Apple vérifie mon identité, ce qui consistait en pratique à appeler la personne que j’avais indiquée comme mon responsable pour qu’elle confirme que j’étais bien moi.
J’espère qu’ils ont fait plus de vérifications que ça, mais je n’en suis pas sûr ; en tout cas, les gens au téléphone parlaient un anglais encore pire que le nôtre, donc c’était au moins assez ridicule.
Ensuite, il a fallu configurer le paiement, car pour une raison quelconque, il faut payer pour avoir un compte développeur Apple.
À l’échelle du budget total d’une ville de 60 000 habitants, c’est sans doute un montant invisible, mais comme il s’agit d’un abonnement étranger et qu’Apple ne proposait aucun moyen simple de le traiter comme un achat B2B correctement enregistré auprès de l’administration fiscale locale, c’était réexaminé chaque année.
Le paiement n’était possible que par carte bancaire, et comme la carte de l’organisation est elle aussi liée à une personne réelle, il faut quelqu’un chargé du renouvellement.
Les gens changent d’emploi, et pour changer de propriétaire il faut qu’Apple entre en contact avec une vraie personne, donc vous pouvez imaginer à quel point c’était amusant.
Ça remonte à quelques années, donc les choses ont peut-être changé, mais parmi les plus de 300 solutions IT d’entreprise que j’ai manipulées, je n’ai rien vu d’aussi épouvantable qu’Apple.
Pour être juste, je suis développeur et je ne sais même pas pourquoi on m’a confié cette tâche ; peut-être que c’est plus courant côté opérations IT.
Sauf, bien sûr, si vous êtes une grande entreprise américaine capable d’absorber facilement la paperasse.
Ça reste aléatoire. Ça peut marcher tout de suite, ou, si on n’a pas de chance et qu’on tombe sur un bug aléatoire du processus, ça échoue longtemps.
Je ne sais pas quand cela a commencé, mais ce n’est pas tout récent.
On oublie parfois à quel point le Web/www était ouvert à l’origine, et à quel point il l’est encore globalement en comparaison de l’« écosystème des apps » monopolisé par Apple et Google
Bien sûr, il y a le « cloud », mais rien n’empêche de louer un serveur et d’héberger soi-même son propre service
Si ça ne marche pas, on peut le déplacer ailleurs et louer un autre serveur
Il peut y avoir un effet de verrouillage et ce n’est pas forcément simple, mais ce n’est pas impossible
À l’échelle de tout l’écosystème des apps, il n’y a que deux choix, et on dépend littéralement de leur bon vouloir
Personnellement, je ne miserais jamais toute une activité sur une seule « app »
Si le public le demandait vraiment, j’en proposerais éventuellement une comme petit canal auxiliaire, mais pas plus
Je déteste les produits qui m’imposent une app sur mobile
Je préférerais largement le retour de quelque chose comme m.website.com, et éviter tout l’écosystème des apps
Du jour au lendemain, on peut se retrouver, avec ou sans raison, dans la situation de « devoir mendier de l’aide en première page de HN »
J’espère que la nouvelle dynamique autour du sideloading dans l’UE provoquera des demandes similaires aux États-Unis, mais je sais aussi très bien que cela ne sera possible que si suffisamment de gens savent ce que veulent dire « jardin clos » ou « sideloading » et s’y intéressent
Le Web est formidable en théorie, mais comme l’environnement du navigateur ne fournit que le strict minimum, ce n’est pas une plateforme d’apps très séduisante si l’on est habitué à une expérience de développement batteries included comme sur les plateformes Apple
Sur macOS, on peut développer des apps puissantes et raffinées avec très peu de dépendances et de sous-dépendances, voire sans aucune avec un peu d’effort
À l’inverse, une web app équivalente finit avec des dizaines, voire des centaines de dépendances juste pour combler les manques fonctionnels
Par exemple, je ne vois pas pourquoi le navigateur ne pourrait pas fournir une vue de liste/tableau de base qui recycle efficacement les cellules avec très peu, voire pas du tout, de JavaScript
Ce n’est pas rare de devoir faire défiler des centaines ou des milliers d’éléments sans que l’appareil rame ni n’épuise sa mémoire
AppKit, UIKit, SwiftUI, Android Framework, Compose, probablement Flutter aussi, gèrent très bien cela de base, alors que dans le navigateur il faut tirer une bibliothèque ou écrire le code soi-même pour cette fonctionnalité pourtant très élémentaire
Si on ajoute à cela la gestion de paquets et les problèmes d’outillage en général, le même problème de fond persiste obstinément pendant que les solutions vont et viennent
J’ai aussi développé pas mal d’apps iOS/iPad depuis 15 ans
Ce qui est bien avec le Web, c’est qu’il existe en général une bibliothèque ou un framework adapté au besoin. Electron en est un exemple
Côté Apple, il manque souvent de bonnes bibliothèques, et SwiftUI a beaucoup trop de bugs
React fonctionne, tout simplement, et c’est aussi conceptuellement plus simple. La liaison de données bidirectionnelle est une mauvaise idée
Apple part de l’idée qu’ils rendent tout plus simple, mais en pratique ils rendent souvent les choses plus pénibles et plus difficiles
Le tableau est déjà rempli côté serveur avec les données nécessaires et dans le bon ordre
Il n’y a donc pas besoin de recycler cellules et lignes, et même avec des milliers de lignes, comme les données restent de l’ordre du Ko, cela reste réactif
Si l’on prend en compte des alternatives comme WebAssembly et Flutter, le manque de fonctionnalités natives du navigateur ne devrait plus être un problème
Je ne pense pas qu’il soit vrai que les développeurs ne feraient rien pour Apple
S’il n’y avait pas d’apps tierces sur l’iPhone, Apple aurait vendu bien moins de téléphones
En théorie, beaucoup d’apps pourraient migrer vers le Web, mais cela ne change rien au fait que les apps tierces rendent quand même l’iPhone beaucoup plus intéressant à posséder
Quand il existe une vraie concurrence, les fabricants de systèmes d’exploitation font de gros efforts pour attirer les développeurs
Il suffit de repenser à l’ancienne vidéo de Ballmer « developers developers developers »
Ils savent que les développeurs ajoutent de la valeur à la plateforme et influencent le choix des consommateurs
Le problème aujourd’hui, c’est l’absence de concurrence significative
Quelles que soient les règles d’Apple, les développeurs doivent proposer quelque chose pour l’iPhone, et Apple peut être rassuré par le fait qu’un troisième grand système mobile a très peu de chances d’émerger
Apple le sait, et a cruellement renversé la situation grâce à des politiques strictes
Alors même que les développeurs contribuent largement à rendre l’iPhone digne d’être possédé, Apple taxe l’ensemble de leurs revenus en prétendant leur faire la faveur de les laisser accéder aux clients iPhone
C’est un abus de position dominante, et comme le dit le billet de blog, il n’y a pas grand-chose à faire à part distribuer via le Web
Ce n’est pas parfait, mais en dehors de la régulation c’est la seule alternative réellement significative, et Apple n’a aucune raison d’abandonner de lui-même les milliards de dollars de revenus qu’il tire de cette taxe sur les développeurs d’apps, donc il fera tout son possible pour échapper à la régulation
J’espère que le Web gagnera en puissance comme moyen d’éviter des règles abusives de distribution des apps
Je pense tous les jours à quel point le Web est formidable, et à quel point il est regrettable qu’Apple ait essayé de le saboter autant que possible en poussant les développeurs à créer des apps iOS plutôt que des web apps
Sans l’App Store, le Web serait bien meilleur
Il y aurait eu plus de diversité dans la consommation de contenu, les sources des réseaux sociaux, les recommandations algorithmiques et les expériences numériques
Le Web fonctionne partout, et il dispose aussi d’excellentes API pour créer des applications immersives / de nouvelle génération comme WebXR
Mais si quelqu’un crée une app WebXR sur son propre site et la vend, cela ne rapporte rien à Apple, donc Apple ne fera jamais la promotion de ce type de web app
À long terme, le Web ne mourra pas
Les entreprises viennent, en tirent profit, puis disparaissent, mais le Web, lui, ne meurt pas
Apple propose des milliers d’API qui facilitent le développement sur sa plateforme, a créé son propre langage de programmation bien intégré à la plateforme, et dispose aussi d’un IDE entièrement intégré qui fonctionne avec les deux
Oui, « mon ami ». Ils ne se soucient pas de toi à moins que tu développes pour leur plateforme
Et qui pourrait les blâmer ? Tout ce qui précède représente des investissements extrêmement coûteux et très longs
J’ai essayé de développer directement une app sur macOS sans utiliser Swift ni les outils Apple, et ça a été une souffrance absolue
Ils ont abandonné OpenGL et l’ont figé à une version d’une manière difficile à expliquer autrement que par la volonté de pousser leurs propres outils
Charger ne serait-ce qu’une DLL externe était presque impossible
Comme pour convertir Vulkan en Metal, tout ce qui est cross-platform doit passer par l’écosystème d’outils Apple
macOS est un cas encore plus atypique et particulier que n’importe quelle distribution Linux
C’est presque surprenant de voir à quel point le développement sous Windows est facile. Chez Microsoft, presque tout est cross-platform
Rien de ce qui a été mentionné côté Apple ne permet de travailler de façon indépendante de la plateforme
À l’inverse, Windows prend aussi en charge ses propres technologies comme DirectX, mais permet également d’exécuter directement Vulkan, OpenGL, etc.
Mais le fait que l’auteur se soit lancé dans une app musicale est important. Les API audio d’Apple sont un véritable chaos
Media Player, AVPlayer, Core Audio, AVFoundation, AVAudioEngine, etc. : on dirait que des équipes concurrentes, remontant jusqu’à l’époque NeXT, utilisaient chacune leur propre bibliothèque, et que tout a survécu tant bien que mal jusqu’à l’ère de l’iPhone
Pendant les confinements du COVID, j’ai passé environ trois mois à essayer de créer un lecteur Shoutcast/Icecast, et ça a été vraiment pénible
Ils ont rendu pratiquement impossible l’écriture de code natif cross-platform qui fonctionne sur iOS, et ont fait tout ce qu’ils pouvaient dans les limites politiques pour empêcher les web apps de concurrencer les apps natives
J’aime l’attitude saine de l’auteur vis-à-vis des grandes entreprises. C’est une compétence de survie de base aujourd’hui
Si je pouvais faire comme je veux, je préférerais n’avoir à installer aucune app sur iPhone ou iPad, mais en pratique cela devient nécessaire à cause des limitations de la plateforme
J’ai vu la web app X/Twitter ne pas lire les vidéos dans Safari, même après avoir désactivé le Lockdown Mode pour X
J’aimerais savoir si c’est la faute d’Apple, qui a créé ce décalage de plateforme, ou si c’est intentionnel de la part de X pour pousser les utilisateurs à installer l’app
Je suis spécialisé en deep learning et en LLM, mais j’ai aussi toujours aimé le développement web
Ce qui me freine, c’est que les outils sont devenus trop complexes
Cela dit, quelqu’un que je connais écrit beaucoup sur ClojureScript + Dart, donc je me dis que je vais peut-être essayer
J’aimerais trouver une stack simple pour les web apps, qu’on puisse apprendre en quelques jours et qui soit bien prise en charge ; si vous avez des recommandations, je suis preneur
Une grande partie du développement web consiste à bien connaître le navigateur, et web.dev est une excellente ressource
Ensuite, il suffit d’apprendre React + TypeScript. Le nouveau react.dev est aussi très bien
React n’est pas parfait, mais comme paradigme pour construire des interfaces, c’est tellement bon qu’Apple s’en est inspiré pour créer SwiftUI
Prends Vite et commence à coder
Ce que je recommande le plus, c’est d’étudier sérieusement ces ressources. Il faut partir de la première page de la documentation et avancer méthodiquement jusqu’au bout
En revanche, il n’y a pas grand-chose qu’on puisse apprendre en seulement quelques jours. Le travail frontend est difficile pour de bonnes raisons