Le Mac App Store bloque les apps Electron pour cause d’API privées
Plusieurs développeurs signalent que le Mac App Store a refusé leur nouvelle app ou une mise à jour suite à l’utilisation d’API privées. C’est en effet une règle de base de la boutique d’apps d’Apple, seules les API publiques et documentées par la firme peuvent servir. Les développeurs qui utilisent des API privées sont automatiquement bloquées par le processus de validation mis en place par l’entreprise.
Le seul hic dans l’affaire, c’est que ces développeurs en question n’utilisent pas sciemment ces API privées. Ils exploitent tous Electron, le framework multiplateforme créé par GitHub qui permet de créer des apps pour macOS, Windows et Linux en utilisant des technologies issues du web. Même si Apple n’a jamais incité les développeurs à l’utiliser, ce framework a jusque-là été parfaitement accepté sur le Mac App Store, comme en témoigne notamment la présence de la messagerie instantanée Slack.
S’agit-il d’une nouvelle politique d’Apple contre Electron ? Maintenant que le projet Catalyst favorise la création d’apps macOS depuis iOS avec macOS Catalina, la théorie ne serait pas totalement absurde. Mais le plus réaliste est sans doute qu’Apple a renforcé ses mesures de vérification et que les apps Electron passaient jusque-là, mais sont désormais bloquées par le processus de validation automatisé.
Le problème concerne toutes les versions actuelles d’Electron et il n’y a pas encore de solutions. Cela dit, les créateurs du framework vont certainement s’atteler au problème et supprimer les API privées concernées. En attendant, vous pouvez toujours essayer d’argumenter, mais Apple est inflexible sur cette règle. Et attention, les règles sont très claires : si vous essayez trop souvent d’utiliser des APIs privées, Apple peut supprimer votre compte développeur et toutes vos apps. Mieux vaut patienter pour une réponse officielle de la part des concepteurs d’Electron…
L’art de ne pas être maître de ses propres apps.
@FloMo
"L’art de ne pas être maître de ses propres apps."
On ne l’est jamais, pas même en pur embarqué. Personne ne conçoit matériel, CPU et logiciel, personne ne maîtrise la pile complète.
Il y a peut-être un gars qui l’est. Juste pour me faire mentir. Mais deux, nope.
@fte
Bien entendu. Mais quand on conçoit une vraie app macOS, on ne rencontre pas ce genre de soucis.
@FloMo
On peut en rencontrer d’autres 😒
@ heu
Les autres problèmes sont hors sujet, autant que le temps qu'il fait en Chine.
@marc_os
Je vois pas en quoi c'est hors sujet de souligner que l'on utilise des API privées ou uniquement des API publiques, on peut rencontrer des problèmes quand même, que y'a pas de maitrise complète de son app dès lors que toute app repose sur les services fournis par un ou des tiers.
Comme dit plus haut, y'a toujours une dépendance à une interface, logicielle, matérielle fournie par un tiers. De facto toute app n'est donc jamais maitrisable de bout en bout par son développeur.
Et n'importe quel développeur avec un minimum d'expérience a déjà vécu une rupture de compatibilité d'une API, volontaire ou involontaire d'un tiers.
Les apps 32bits reposant sur l'API publique de macOS n'en sont-ils par le parfait exemple ?
C'est Apple qui a la maitrise, pas les développeurs.
D'autant que les utilisateurs acceptent l'idée que Apple est légitime à faire la loi là où elle n'est pourtant plus chez elle, vu qu'elle ne loue pas des macs.
@FloMo
C’est quoi une ‘vraie’? Les autres sont fausses et ne fonctionnent pas?
@en chanson
Une app web embarquée dans une app macOS n’est pas une vraie app macOS.
@FloMo
"Une app web embarquée dans une app macOS n’est pas une vraie app macOS."
Une app iOS embarquée dans une app macOS Catalyst est-elle une vraie app ? Apple en livre plusieurs. Apple encourage à en livrer. Quelle est la différence par rapport à Electron ?
@fte
Une app Catalyst utilise des frameworks fournis par Apple. C’est du code UIKit, mais ça reste du code natif.
De fait, l’appel à une API privée sera ciblé et enlevé par le développeur de l’app en parfaite maîtrise de son outil.
@FloMo
"Une app Catalyst utilise des frameworks fournis par Apple. C’est du code UIKit, mais ça reste du code natif. "
Electron utilise Cocoa pour afficher les fenêtres. Des frameworks fourni par Apple. Donc c’est natif ?
Sur iOS, Electron utilise la webview fournie par Apple et l’interpréteur JavaScript fourni par Apple. Donc c’est natif.
@FloMo
"une vraie app macOS"
Définis "vraie app".
Si on utilise un composant d’interface tiers, ce n’est plus une vraie app ? Une librairie JSON tierce ? Où est la limite entre une vraie et une fausse app ?
@fte
J’ai précisé ce que je considère comme une app macOS dans ma précédente réponse.
Mais tu soulèves un point très intéressant par rapport aux composants externes.
Si tu utilises un composant externe crucial au fonctionnement de ton app, tu dois être sûr de ton choix.
Si c’est un composant de type PSPDFKit (pour les PDF), tu auras un vrai support technique. Donc une maîtrise de ton app sous contrôle, malgré une dépendance vis-à-vis du fournisseur de la solution.
Si c’est un composant open-source, tu as intérêt de pouvoir corriger toi-même le code, car il n’y a aucune garantie.
À défaut, tu dois pouvoir bloquer le composant sans impact majeur sur le fonctionnement de ton app.
Mais, a priori, côté Électron, personne n’a fait un fork corrigeant le problème.
C’est une non-maitrise de son app. Une app maîtrisée aurait été corrigée sans soucis, vu qu’elle utilise des composants open-source.
@FloMo
"Mais, a priori, côté Électron, personne n’a fait un fork corrigeant le problème."
Tu peux le faire et maîtriser ton app.
@fte
Complètement. Mais ce qui est déplorable, c’est que personne ne l’a fait alors que beaucoup d’apps utilisent Electron.
Normalement, ce genre de problème se résout en une poignée d’heures.
@FloMo
"Mais ce qui est déplorable, c’est que personne ne l’a fait"
Source ?
Tu as regardé les commits sur GitHub ?
@fte
Il suffit de lire l’article et ses sources : ce sont les concepteurs qui doivent mettre à jour alors qu’il y a un nombre incroyable d’utilisateurs qui donc devraient pouvoir régler leurs problèmes.
@FloMo
GitHub, issue 13938. Closed. Issue 17263. Closed...
Ce n’est ni la première fois ni la dernière que ce problème se pose, et est fixé.
Encore faut-il utiliser un build à jour, voire accepter d’utiliser un build beta si on ne peut pas attendre que la version soit promue finale.
Ou fixer le problème soi-même dans son build privé, et proposer le fix en pull request.
Bref. C’est transitoire, les devs sont au contrôle contrairement à ce qui est dit, et la notion de vraie application n’a plus de sens aujourd’hui, en particulier sur macOS. MacOS serait mort depuis longtemps si les apps "non natives" étaient exclues.
@FloMo
> Normalement, ce genre de problème se résout en une poignée d’heures.
... quand le problème touche un grand nombre de gens.
MacOS est une cible minoritaire. C'est ainsi.
A la communauté des développeurs macOS d'être plus nombreux ou réactifs pour compenser ce fait. Mais vu l’accueil fait par les utilisateurs de cette plateforme pourtant minoritaire parce que Electron c'est pas "du code natif", sous-entendu sanctifié par leur fabricant préféré, j'imagine que les développeurs compétents en Electron *et* macOS, déjà peu nombreux, vont pas se bousculer au portillon.
@FloMo
"Si c’est un composant open-source, tu as intérêt de pouvoir corriger toi-même le code, car il n’y a aucune garantie. "
Electron est « un composant open-source », certes gros, avec une large communauté. Il y a beaucoup plus de garanties qu’avec Catalyst closed source et bourré de problèmes actuellement.
Quel intérêt d’utiliser,une bibliothèque JSON sur iOS et macOS ? Ça fait des années qu’ils embarquent un parser JSON complet…
@dscreve
"Ça fait des années qu’ils embarquent un parser JSON complet…"
Il fut un temps où il n’y avait pas de parser stream. Il fut un temps où il n’y avait pas d’API Swift. Il fut un temps où les librairies tierces étaient beaucoup plus performantes, pour certaines tout au moins. Une librairie permettant des validations de schéma pendant le décodage peut être très utile. Une librairie cross-plateforme peut être bienvenue aussi. Plein de raisons en somme.
@FloMo
Ouais, car comme chacun sait quand on s'en tient uniquement aux API publiques d'Apple, jamais, oh grand jamais on ne perd la maitrise de ses propres apps.
Bonjour,
Serait-il possible d’expliquer ce que sont les api privées précisément ? Elles sont écrites par Apple ou des dev tiers ? Est-ce qu’elles font partie du système ? Est-ce que le mot privé est utilisé dans le même sens qu’en programmation orientée objets ? Et si oui cela me paraît contradictoire avec le fait que le code puisse tourner...
Merci de vos lumières !
Même question, j'ai trouvé ça, ici: https://www.programmez.com/avis-experts/analogies-et-differences-entre-api-publiques-et-privees-1061
"Les API (Application Programming Interface) Web sont largement utilisées à des fins d'intégration, notamment pour connecter des applications mobiles. Les API se divisent globalement en deux catégories : API publiques (ou OpenAPI) et les API privées (ou EnterpriseAPI). Les API publiques sont accessibles par tous et sont généralement hébergées dans le cloud. Les API privées s'exécutent sur un serveur d'entreprise et leur accès est réservé à un public restreint. En quoi ces deux catégories d'API se distinguent-elles? Une partie de la réponse se trouve dans leurs points communs. Par Mark O'Neill, Vice Président Innovations Axway.
[…]
Abordons maintenant leurs différences. Généralement, une API privée est utilisée dans un système fermé où les utilisateurs (le plus souvent les employés) sont répertoriés, dans un annuaire ou une base de données, et leur identité connue. Avec les API publiques, une entreprise souhaite atteindre le plus grand nombre d'utilisateurs, en permettant par exemple, à quiconque de créer une application ou d'appeler son API. Les API publiques intègrent donc en général un aspect « libre-service », avec l'auto-inscription des utilisateurs. Il s'agit d'une différence clé entre les API publiques et privées."
@YAZombie
Merci pour ces éléments :)
@Musexp
C’est le même privé qu’en programmation orientée objet oui. À ceci prêt que objective c n’a pas ce genre de concept.
En Obj-C il n’y a pas réellement de composant public ou privé. Il y a ce qui est présent dans le fichier header (le fameux .h) qui est publiquement exposé et documenté et tout le reste qu’on déclare directement dans le code qui est de fait privé. La plupart du temps, même si il existe d’autres techniques.
Maintenant si on prend le code une fois compilé celui contient une table avec tous les composants (publics et privés) qui est utilisée pour le dynamic dispatch. Ce principe fait qu’on peut envoyer un message à un objet, un message valide est contenu dans cette table le reste est invalide (grosso modo c’est plus complexe en vrai).
Si j’ai un objet avec une méthode printHello qui affiche « hello » dans la console le simple fait d’envoyer le message printHello à l’objet produit l’effet désiré.
Imaginons maintenant que printHello ne soit pas déclaré publiquement je serai quand même en mesure d’envoyer ce message parce qu’il est dans la table contenue dans l’exécutable. Il suffit de récupérer cette table pour savoir quels messages sont valides et les tester si le nom n’est pas suffisamment clair.
C’est une vieille technique qui a permis d’utiliser beaucoup d’API qu’Apple se réservait mais il y’a un hic. Les API publiques sont garanties et pérennes au fil des versions, les privées non et peuvent disparaître au gré des versions. Un code qui envoie des messages non valide plante à coup sûr. D’où leur « illégalité ».
Merci PyrOh, c'est bien expliqué.
Pas de quoi 😃
@Pyr0h
> D’où leur « illégalité ».
Sans les guillemets, cela serait un abus de langage que l'on lit malheureusement de plus en plus souvent, comme si le fait qu'Apple s’octroie ce type de prérogative arbitrairement (et pas sans arrière pensée financière) allait de soit.
Tout cela n'a rien à voir avec la Loi.
Par contre, le contrôle de plus en plus autoritaire d'Apple qui créer une entrave à la concurrence des éditeurs de logiciels *et* aux usages qu'un utilisateur légitimement (et là, c'est bien au sens légal du terme) propriétaire d'un mac et d'une licence d'utilisation de la version de macOS préinstallée dessus, ça par contre, cela peut relever d'un problème de légalité au regard du droit du commerce par exemple.
De quel droit (là aussi, au sens légal du terme) Apple s'intercale entre un développeur de logiciel pour macOS et le propriétaire d'une plateforme matérielle compatible avec la licence d'utilisation de macOS acquise au moment de l'achat de ladite machine ?!
@byte_order
1) Il y a une licence d’utilisation spécifique au mac app store.
2) le mac app store n’est pas l’unique moyen de télécharger des apps pour macOS.
@reborn
Alors pourquoi menacer de résilier un DevID ?
Jusqu'à preuve du contraire, si un DevID est nécessaire pour publier sur le MAS, on a (encore) le droit de publier en dehors du MAS ce qui est développé avec ce même DevID.
Qu'ils rejettent toute app non conforme aux règles du MAS, okay, pourquoi pas, mais qu'ils se permettent de résilier le DevID alors que celui-ci n'est pas exclusif à ce qui est proposé exclusivement à la distribution via MAS, là, non.
Hors, le DevID est bel et bien l'uniquement moyen de publier des apps pour macOS, quelque soit le ou les vecteurs de distribution.
@byte_order
Il y a un contrat de licence spécifique entre Apple et les devs.
le DevID est bel et bien l'uniquement moyen de publier des apps pour macOS, quelque soit le ou les vecteurs de distribution.
Non
@reborn
> Il y a un contrat de licence spécifique entre Apple et les devs.
Qui n'implique nullement d'utiliser le circuit de distribution d'apps d'Apple et donc de se conformer aux règles de soumission (et le nom n'est pas fortuit ici) sur le MAS.
> Non
Ah.
Merci d'indiquer alors comment programmer légalement des apps pour macOS sans avoir un DevID.
@byte_order
Qui n'implique nullement d'utiliser le circuit de distribution d'apps d'Apple et donc de se conformer aux règles de soumission (et le nom n'est pas fortuit ici) sur le MAS.
Oui le dev id n’implique pas le MAS. Donc Firefox peut signer son app avec son dev id sans se conformer au régle du MAS.
Merci d'indiquer alors comment programmer légalement des apps pour macOS sans avoir un DevID
C’est une blague ?
@Pyr0h
Merci de ta réponse qui est très complète !!
Sur le fil GitHub, humphrey vient juste de rappeler le rôle de Core Animation Layer dans la baisse de consommation d’énergie de Firefox 70+. Or, l’article de Markus Stange note ouvertement que l’API en question n’est pas proprement documenté :
« (IOSurface is the macOS API which provides a handle to a GPU buffer that can be shared between processes. It’s worth noting that the ability to assign an IOSurface to the CALayer contents property is not properly documented. Nevertheless, all major browsers on macOS now make use of this API.) »
https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/
Une règle pour le Mac App Store, un autre pour les apps (encore) librement installables ? Et pour combien de temps encore ? Pour être conséquent, Apple devrait tout verrouiller.
@occam
"Pour être conséquent, Apple devrait tout verrouiller."
C’est en chemin. Patience.
[edit]Le post date de 5 ans[/edit]
Nouvelle version du framework compatible avec le MAS.
Y’a un blog qui explique le détail: https://twitter.com/electronjs/status/662345573606031360?s=21
@austinforest
"Y’a un blog qui explique le détail: https://twitter.com/electronjs/status/662345573606031360?s=21"
Merci :)
Vala. Transitoire je disais. Évidemment. Les bugs sont corrigés bien plus vite que chez Apple. Évidemment. D’ailleurs, ce n’était pas un bug. Juste une lubie d’Apple. Évidemment.
@austinforest
5 novembre 2015 ? 🤔
@nicolasf
Oups. N’imp. Pardon.
C'est comme concevoir une voiture tout en métal mais on ne sait pas créer ses pneus...
Quand des API privées insèrent des trackers, des key loggers ou des détourner de pub, ça retombe sur toutes les API privées. Et les conséquences, merci aux margoulins …
Tant mieux... Il y aura peut-être des apps qui respectent enfin les normes d'accessibilité ?
Je rêve sûrement, mais on sait jamais...
S’agit-il d’une nouvelle politique d’Apple contre Electron ?
Ca y ressemble assez. Plus que contre electron ce serait une attaque contre les autres navigateurs : Firefox s'est aligné récemment sur Chrome pour leur pipeline de rendering. En utilisant les fonctions non documentées, ils obtiennent un gain de x3. En se réservant l'usage de ces fonctions, Apple va pouvoir mettre en difficulté les autres navigateurs et pousser ses propres technos (safari et catalyst).
Pourquoi FF et chrome ont utilisé les fonctions non documentées? Parce que l'api opengl et metal sont incomplètes (par rapport à windows)
@ vince29
Le code de la route impose des limitations de vitesse sur la route.
S'agit-il d'une politique des gouvernements contre les citoyens ?
Ça dépend. Est-ce que le gouvernement s'applique les mêmes règles qu'aux autres ? Ou bien est-ce qu'ils roulent à 200, prennent les sens interdits ou plus simplement prennent l'hélicoptère.
https://www.autoplus.fr/actualite/Manuel-Valls-Bernard-Cazeneuve-Arnaud-Montebourg-Francois-Hollande-exces-vitesse-1484319.html
Est-ce qu'ils prennent des décisions en accord avec les besoins de la population (besoin d'api avec partial rendering) ou bien décident-ils unilatéralement de ce qui sera (suffisamment) bon pour la plèbe (limitation à 80) ?
@marc_os
Apple est un gouvernement ?!
Elle détient son pouvoir de régulation de quelle autorité démocratique !?
Comparer les lois de pays démocratiques avec les choix unilatéraux d'une entreprise privée, on aura tout vu dans les tentatives d'analogies pour nous faire passer des vessies pour des lanternes...
@marc_os
"S'agit-il d'une politique des gouvernements contre les citoyens ?"
Je cherche mais échoue totalement à trouver le moindre rapport entre Apple et ses lubies unilatérales et les lois de pays démocratiques.
Pages