UIKit sur Mac : l’avis des développeurs sur le projet Marzipan

Anthony Nelzin-Santos |

L’annonce a beaucoup fait parler : le framework UIKit, qui permet de construire des applications iOS et tvOS, sera bientôt disponible sur macOS. Enfin… elle a surtout fait parler les journalistes et les commentateurs. Les développeurs sont restés étonnamment discrets, eux qui sont pourtant les premiers concernés, sans doute parce qu’ils sont dans l’expectative.

En effet, Apple se réserve la primeur d’UIKit sur Mac, et se donne jusqu’à 2019 pour l’améliorer avant de le confier aux développeurs. En attendant, ces développeurs ont bien un avis sur la question. Pour savoir lequel, nous avons interrogé une demi-douzaine de développeurs français et européens.

« Prudence », voilà le maître-mot des développeurs que nous avons interrogés. Avant de s’engager, ils attendent bien sûr d’en savoir plus. Une prudence qui ne les empêche pas d’avoir un avis, parfois tranché, sur les choix d’Apple. Raphael Sebbe, le fondateur de Creaceed, dit ainsi qu’il aurait « préféré un rapprochement d’AppKit et UIKit » :

Comme Apple l’a fait avec tvOS, qui utilise UIKit avec des extensions qui sont propres à [l’Apple TV]. Ici avec le déploiement d’apps iOS directement sur Mac, ça fait quand même un peu bâclé en termes d’expérience utilisateur, même si cela peut avoir du sens dans certains cas pour des apps « monolithiques » et que cela peut ramener de la vie sur le Mac, qui en a bien besoin.

Florent Morin, développeur freelance spécialiste d’iOS, est plus optimiste et « trouve que l’idée de porter UIKit sur Mac est cohérente » :

Aujourd’hui, quand on écrit des frameworks iOS, ils sont pour ainsi dire déjà prêts pour macOS, watchOS et tvOS. Cela est notamment dû au fait que les quatre OS partagent leurs bibliothèques bas niveau ainsi qu’un langage de programmation commun. On peut également ajouter le web, qui est également une plateforme qui peut partager une partie du code avec les quatre plateformes Apple grâce à Swift. […]

watchOS partage certains composants UIKit avec iOS : UIImage par exemple. Pour autant, certains composants iOS sont absents de watchOS (UIViewController) mais ont leur équivalent adapté à l’appareil (WKInterfaceController). De la même manière, tvOS partage beaucoup de composants avec iOS (UIViewController, UITabBarController) mais dispose depuis iOS 12 de ses propres composants au travers de TVUIKit (TVDigitEntryViewController).

D’ailleurs, certains composants UIKit sont disponibles exclusivement sur iPad. Et cela ne choque personne. macOS est la seule plateforme a avoir uniquement la couche bas niveau en commun avec iOS. Cela me semble cohérent que macOS dispose de ses propres composants, associés à une expérience orientée Mac.

Aucun des développeurs que nous avons interrogés ne remet en cause la pertinence du choix d’Apple, mais beaucoup s’inquiètent des conséquences pour le devenir de la « plateforme Mac ». Raphael Sebbe, qui a commencé sa carrière avec des applications Mac mais propose aujourd’hui une gamme d’applications sur iOS, craint ainsi que UIKit « risque aussi d’être utilisé à outrance [pour porter] toutes les apps iOS, et pourrait produire l’effet inverse ».

Paulo Andrade, le développeur portugais du gestionnaire de mots de passe Secrets, disponible sur les deux plateformes, attaque le problème par l’autre bout :

Même avec Marzipan [le nom du code du projet dont UIKit sur Mac dérive], les applications iOS resteront des citoyens de seconde zone. Avec Marzipan, les développeurs resteront déconnectés d’AppKit, comme les applications Electron le sont aujourd’hui. Apple essaiera de le cacher, bien sûr, de créer des ponts vers le plus grand nombre possible d’API.

« Electron », le mot est lâché, et revient régulièrement, comme un repoussoir. « En tant qu’utilisateur », dit Florent Morin, « si cela peut m’éviter de subir les apps web embarquées dans des conteneurs macOS, je ne m’en plaindrai pas non plus ! » Raphael Sebbe craint pourtant que l’approche choisie par Apple ne « fragilise davantage le Mac, en décourageant les développeurs de faire des apps classiques, s’orientant plus vers iOS ou Electron ».

La firme de Cupertino enverrait des signaux contraires : « si Apple elle-même développe ses nouvelles apps Mac en UIKit, pourquoi cela aurait-il du sens pour les développeurs de continuer en AppKit ? » Max Seeleman, fondateur et directeur du développement d’Ulysses, pense qu’il s’agit d’un faux problème. De son point de vue, UIKit est désormais une technologie « native » au Mac, sur le même plan qu’AppKit :

Je suis persuadé que nous n’avons encore rien vu. Cette technologie a un potentiel énorme — pour nous, mais aussi pour la plateforme. Pour la plateforme, […] je vois un intérêt à développer des applications véritablement natives, plutôt que d’utiliser Electron ou des techniques similaires. Pour nous, j’espère que [UIKit] nous permettra d’augmenter la part de code partagé dans notre application, que cela nous rendra plus efficaces et nous permettra de proposer de nouvelles fonctions plus rapidement.

Raphael Sebbe le reconnaît lui-même : « il est aussi possible que les apps UIKit deviennent un genre de standard chez Apple, des “rectangles interactifs” qui seraient une alternative plus puissante aux pages web car natifs ». Mais Paulo Andrade ne croit pas que les adeptes d’Electron seront convaincus :

Electron est populaire auprès des développeurs qui veulent cibler le Mac. […] Apple pense peut-être pouvoir combattre cette tendance, et convaincre certains développeurs de porter leur application iOS vers macOS [avec UIKit] plutôt qu’Electron. Mais franchement, je ne suis pas certain que cela va marcher. Je crois que lorsque les développeurs choisissent Electron plutôt qu’AppKit, c’est parce qu’ils peuvent réutiliser leur code sur Windows et Linux, pas parce qu’ils détestent le développement natif. Marzipan n’y changera rien.

Florent Morin préfère replacer le choix d’Apple dans une longue succession d’évolutions techniques. Apple assure ne pas vouloir fusionner macOS et iOS, mais travaille depuis plusieurs années à rapprocher progressivement les deux plateformes, jusqu’aux frameworks applicatifs, pour aboutir à un véritable coreOS commun. « Pour aller jusqu’au bout », dit Morin, « il faudrait qu’Apple sorte de UIKit certains composants propres à iOS » :

Le procédé a vraiment bien fonctionné avec tvOS : les composants UIKit remplissent le même rôle que sur iOS, mais leur interface est adaptée à l’interface de la TV, manipulée à la télécommande. Si la même méthode est employée, et il n’y a aucune raison pour qu’elle ne le soit pas, c’est un vrai tremplin pour l’adoption de macOS par les développeurs : la courbe d’apprentissage est drastiquement réduite.

Apple nous incite depuis quelques années à sortir le code et les éléments communs aux différentes plateformes au sein de frameworks. Cela fait partie d’un tout. In fine, Apple reste totalement en phase avec sa politique vis-à-vis des développeurs : en suivant bien les recommandations, sans essayer de mettre en place des procédés exotiques, le cap se passe aisément.

Au final, cette évolution est tout à fait cohérente : le code qui est commun aux différentes plateformes est mis en commun, y compris côté interface quand c’est possible, le code propre à chaque plateforme, en général liée aux interfaces, est adapté au cas par cas.

Paulo Andrade parle même d’un framework unifié :

Cela ne veut pas dire que les applications auront la même apparence sur les deux plateformes, bien sûr, mais cela signifie que les développeurs pourront partager de plus en plus de code d’interface entre macOS et iOS. Le fait que les deux plateformes n’aient pas le même mode d’interaction n’est pas un obstacle : le mode d’interaction de l’iPhone est radicalement différent de l’Apple TV, et ils utilisent pourtant tous deux UIKit.

Apple l’a dit et redit : différents usages appellent différents matériels utilisant différentes interfaces. Avec UIKit et demain un processeur ARM, un Mac ne sera rien d’autre qu’un iPhone sous une autre forme. L’interface des applications s’adaptera aux conditions d’usage, du petit écran de l’Apple Watch au poignet au grand écran de l’iMac Pro sur le bureau, en passant par l’iPhone dans la poche.

Un défi pour les développeurs, qui vont devoir changer leur manière de concevoir leurs applications, et sans doute leur manière de les promouvoir. « Il est encore trop tôt pour en parler », dit Mick Payne, le directeur du marketing de Cultured Code, l’entreprise allemande développant le gestionnaire de tâches Things :

Nous avons déjà une application Mac entièrement native, donc nous n’avons aucun intérêt particulier à utiliser [UIKit]. Il semble s’adresser à des entreprises qui ne possèdent pas encore d’application Mac, qui pourront être convaincues […] de porter leur application un peu plus facilement qu’auparavant.

Paulo Andrade ne compte pas plus abandonner son application Mac : « Secrets continuera de faire évoluer sa version Mac, et restera un citoyen de première zone sur le Mac ». Mais Jérémie Francone, le cofondateur de 1Button, voit l’occasion de simplifier le développement des versions macOS de ses nombreux jeux :

On peut certes voir [UIKit] comme un moyen au rabais de porter des apps iOS sur Mac. Pour nos jeux on utilise OpenGL/ES (et bientôt Metal…), le portage du jeu lui-même serait donc assez aisé. Mais pour les menus on utilise UIKit, ça pourrait donc grandement faciliter le portage de certains de nos jeux.

Et « bien sûr », l’équipe de développement iOS/tvOS de Canal+ réfléchira à porter son application iOS vers macOS, myCanal étant déjà proposé sur Windows par le biais du Microsoft Store. Les choses doivent encore se décanter, et les avis s’affineront à mesure que l’on y verra plus clair.

Une chose est sûre : l’arrivée d’UIKit sur Mac ne résout pas tous les problèmes de la plateforme. Raphael Sebbe le résume mieux que personne : « il existe d’autres leviers, à mon sens, si Apple veut rendre le Mac App Store plus intéressant pour les utilisateurs et les développeurs, comme la modernisation des modèles économiques : de vraies périodes d’essai, des mises à jour payantes, un abonnement unique à la SetApp… ».

Avec Mickaël Bazoge, Florian Innocente, Christophe Laporte, et Stéphane Moussie. Certaines citations ont été éditées pour des raisons de brièveté et de clarté.

avatar reborn | 

Bizarre, pourquoi tout le monde parle de Marzipan ici ?

Demandons à l’analyste en chef ?

avatar Bigdidou | 

@reborn

Oui, c'est pas appétissant. Ça sent le truc lourd bien étouffe chrétien.

avatar iPop | 

Moi je veux un iPad 20 pouce !

avatar occam | 

« Aucun des développeurs que nous avons interrogés ne remet en cause la pertinence du choix d’Apple, mais beaucoup s’inquiètent des conséquences pour le devenir de la « plateforme Mac ». »

Et de un.

« And since UIKit on the Mac has already existed for years (presently contained in the iOS simulator), it's probably not as big of an investment on Apple's part as you'd think it would be. For sure, AppKit engineers have performed heroics to make it work as well as it does- but it's not like UIView wasn't already compiling on 64 bit Intel processors. It's there today. It was there 10 years ago.

This could go completely off the rails too.

What if MacOS on ARM only ran these new UIKit apps?

That's a scary thought for this MacOS developer.

But then again, we already have this and it's called iOS on the iPad. And maybe, just maybe, and remember these are half baked thoughts, but maybe Apple is wondering if some Pro users might be better served by MacOS Touch 1.0 running on ARM. »

Et de deux. (Gus Mueller, http://shapeof.com/archives/2018/6/marzipan_to_arm_on_mac.html )

avatar webHAL1 | 

@occam
« "What if MacOS on ARM only ran these new UIKit apps?" »

C'est effectivement une piste intéressante... Cela permettrait à Apple de rendre la case Mac App Store obligatoire et de bien mieux contrôler les applications Mac, tout en touchant au passage sa dîme de 30%.
C'est ce que Microsoft a essayé de faire avec ses Surface RT et sa version spéciale de Windows 10, sans aucun succès...

avatar webHAL1 | 

Tiré de l'article, citation de Paulo Andrade :
« Je crois que lorsque les développeurs choisissent Electron plutôt qu’AppKit, c’est parce qu’ils peuvent réutiliser leur code sur Windows et Linux, pas parce qu’ils détestent le développement natif. Marzipan n’y changera rien. »

Je partage grandement cet avis. D'après moi, UIKit ne permettra pas d'augmenter de manière significative le nombre d'applications sur Mac. Pour que cela arrive, il faudrait qu'Apple se préoccupe de la part de marché de macOS, qui tourne aujourd'hui autour de 7-8%. Plus que les difficultés technologiques, c'est probablement la confidentialité des ordinateurs pommés qui fait que les éditeurs ne s'intéressent pas davantage au Mac.

avatar lord danone | 

Les plateformes sont amenées a converger. Que ce soit tous les derivés d’OS apple ou tous les OS de bureaux. Les problematiques evoluent, le hardware evolue, le logiciel evolue, les besoins evoluent,... macg est encore une fois obnubilé par electron (oh mon dieu, une appli JS encapsulée, vade retro !!!) sans se rendre compte qu’il continue son bonhomme de chemin et qu’a part le puriste qui passe sa vie a regretter l’assembleur et balancer des evidences natif vs non natif, ce n’est qu’evolution logique, tout comme UI kit n’est que logique.
Les equipes de devs n’ont pas des ressources illimités, des developpeurs solo veulent pouvoir proposer leur app sur toutes les plateformes sans avoir a faire quinze versions de leurs apps, et oh miracle, reveillez vous, on est en 2018 !! Bientot 2019 !!! Le hardware et le software permettent de faire du multiplateforme « correct » pour le developpeur et l’utilisateur. J’irais meme plus loin dans l’obvious, tant que les horloges tourneront dans le même sens, on ne peut que se diriger vers un moment où n’importe quel dev aura a disposition des outils pour creer des apps multiplateformes de qualité et sans aucun compromis en utilisant une seule base de code. Et oui, désolé pour tous les devs bloqués je ne sais où dans l’épopée informatique, electron et UI kit sont des etapes indispensables (et tres loin d’etre les plus idiotes) du long processus informatique qui nous mene inexorablement vers le moment où les IA coderont en binaire ce que nos cerveaux ne pourront meme pas imaginer : a ce moment la, elles se foutront bien de la gueule des devs de 80 piges qui feront du natif parce que ca marche mieux qu’electron <:°D

avatar reborn | 

@lord danone

C’est vrai, mais le javascript en desktop c’est pas encore ça. Ça m’attriste, mais je pense que l’heure des apps natives est terminé. Microsoft pousse les PWA sur son store et a acquis Electron.. Skype est en javascript, Visual studio code aussi..

La seule chose possible c’est de retarder cette échéance ?‍♂️

avatar byte_order | 

C'est surtout l'heure du monoplateforme qui est terminé.
On peut faire du multiplateforme sans pour autant ne pas être compilés, ou avoir 90% de natif (genre via Qt par exemple).
Mais le 100% natif, et donc monoplateforme, y'a tout simplement plus une seule plateforme logicielle suffisamment rentable pour permettre d'en vivre désormais.

Quand une application doit être gratuite, c'est assez logique que le surcout de cette gratuité puisse se faire aussi sous la forme "utilise un gros framework multiplateforme qui bouffe du CPU et de la RMA et l'expérience utilisateur n'est pas homogène avec le reste de la plateforme.".

avatar dxosi | 

"y'a tout simplement plus une seule plateforme logiciel suffisamment rentable pour permettre d'en vivre désormais"
Si... iOS
Et c'est pour cela qu'une certaine convergence entre iOS et macOS ne peut qu'être bénéfique pour le mac.

Les apps Electron ont souvent un modèle économique différent de celui des apps payantes ou avec IAP. Beaucoup sont des apps gratuites / "vitrine". Quant aux apps payantes, la plupart se rapprochent d'apps natives de piètre qualité.

avatar oomu | 

"C'est surtout l'heure du monoplateforme qui est terminé."

discours archi classique et archi mis en déroute régulièrement au grès des besoins de l'industrie de créer de la "valeur" et de la nouveauté.

"On peut faire du multiplateforme sans pour autant ne pas être compilés, ou avoir 90% de natif (genre via Qt par exemple)."

bien sur, on peut faire n'importe quoi, tout est possible.

"Mais le 100% natif, et donc monoplateforme, y'a tout simplement plus une seule plateforme logiciel suffisamment rentable pour permettre d'en vivre désormais."

Dites ça à Microsoft et Adobe.

-
QT, j'utilise du logiciel QT. C'est sympatoche oui , mais ce sont des logiciels qui ont des comportements assez étranges selon la plateforme.

Sur Mac Os, le copier coller est incohérent, via VNC/autre, QT se comporte totalement différemment d'une app Cocoa (glisser jeter, etc)

Sur Linux, son principal usage est au sein de KDE, et du coup on y perd le multiplateforme (pas KDE windows malgré quelques vielles initiatives intéressant personne)

Dans la pratique, pour 1 Krita, on a 100 3ds Max.

-
concrètement :

Cuda est une plateforme propriétaire, y a opencl, cuda et maintenant metal, rien qu'en gpu/graphismes, on a _3_ plateformes, Apple en a ajouté une de plus il y a à peine quelques années

Windows a deux plateformes majeures qui sont monoplateformes, propriétaires : win32/64/mfc/etc et new ui/store/quoi que soit son nom actuellemnet

Apple continue de rester monoplateforme et propriétaire. ios et Mac ont toujours été proches. Même outils de développement, même langage, et le framework d'ios dérive de cocoa, avec de la modernité.

Autant dire, que dans l'écosystème Apple, les développeurs ont toujours eu des facilités pour migrer de ios au mac. Ils en voient simplement pas l'intérêt.

-
La Magie N'Existe PAS

vous pouvez me raconter ce que vous voulez, les interfaces ios et mac sont fondamentalement DIFFERENTES

nécessitant des contrôles appropriés et des comportement donc différents, avec des choix d'interfaces donc différents et donc un développement spécifique, des tests spécifiques, de la qualité assurance spécifiques.

Comparons Affinity Photo ipad et Mac Os : ce sont deux bêtes différentes. Les choix d'UI découlent du tactile et ou Souris

pour les maigres contrôles en commun pour changer un chiffre ou un pinceau, il y a tout le reste qui est spécifique : l'UI et sa logique, son flot.

UIKit sur les deux plateformes n'affranchit pas d'apprentissage (leur comportement adapté aux deux environnements) ni de travail.

A mon sens, vous vous laissez aveugler : la différence AppKit / UIKit est minime, ce n'est pas là que se trouve le frein à + de logiciels Mac.

-
La seule chose qui freine un développeur : le contexte économique.

UIkit en commun peut baisser un peu le coût de développement sur ios et mac, mais je ne suis pas convaincu que cela ait un impact significatif.

ça restera deux produits séparés (sinon ça serait du merdique à la javascript/electron : identique partout, génial nul part).

Et si le mac a des logiciels de feignasse, pourquoi acheter du Mac ? c'est un non sens.

je reste donc persuadé que pour être viable sur le marché, un développeur ios souhait faire un logiciel Mac de qualité, devra s'investir autant qu'il le ferait aujourd'hui avec AppKit.

Il n'y aurait aucun intérêt de payer aux prix fort un Omnigraffle Mac s'il était un portage bas de gamme d'Omnigraffle iOs. Autant acheter Visio sur son windows.

-
Les deux machines sont différentes: iPhone/iPad face au Mac.

Si on sort des petits jeux premium aux mécaniques simplistes ou des petites applications pour la météo/trier ses courses, on a une grande différence de potentiel entre les deux types de machines

les iphones/ipad ont en gros 2 à 4go de ram, les Mac de 8 à 64Go

en plus de la différence significative de tailles d'écrans, de la présence d'une souris pour pointer précisément, etc.

Au final : la différence est telle que ces machines ne font de sens que si on les utilise pour des besoins spécifiques qui font du sens sur chacune.

Même les applications de musiques ne font pas le même usage et ambitions sur ipad que sur mac. Garageband est une exception notoire.

Hormis quelques logiciels de dessin/retouche (type Affinity tel ArtRage, Clip Studio), rares sont les logiciels fonctionnellement identiques sur ipad et mac (encore moins avec l'iphone, ne serait-ce que par l'intérêt de tout faire dans un mouchoir de poche).

Seul Microsoft a porté la quasi-totalité des fonctionnalités de ses logiciels phares à une plateforme mobile. Office 365, en apps natives, pas weberies.

Pléthores de logiciels sont monoplateformes et leurs éditeurs en vivent.

Autodesk a presque tout qui n'est que windows ,et quelques jouets sur ios/android, essentiellement associés à du cloud comme des petits assistants.

Adobe reste essentiellement Mac/Windows, avec quelques gadgets android/ios. Absolument toute la valeur de Adobe CC est sur Windows/Mac.

L'industrie joue le jeu, elle a expérimenté, elle a essayé, ensuite elle voit le manque d'intérêt et revient tranquillement au fondamental.

-
quand j'écrits "weberies" ou "electron" ou "javascript" (dans le cadre d'apps de travail), lisez les avec le ton le plus méprisant, snobinard, d'un anglais fantasmatique avec monocle et moustache tête à claque.

avatar oomu | 

je vais vous dire pourquoi le mot "electron" dans ce contexte me donne juste envie de vomir :

- les applications electrons sont systématiquement médiocres en terme d'interface (s'intègre à rien) et plus lentes (ce qui est rédhibitoires) : c'est une technique de feignants pour développeurs feignants pour portage à bas coût.

Cela permet d'obtenir + d'applications, mais des applications médiocres.

avatar byte_order | 

Le mot qui devrait vous donner juste envie de vomir, c'est pas "electron", mais "bas coût".

Les développeurs, même ceux pas feignants, ils ne se nourrissent pas que d'amour et d'eau fraiche, hein. Payez-les au lance pierre, et ils vous pondront une solution faite au lance pierre.

La médiocrité n'est pas le problème, le problème c'est le ratio rentabilité / qualité qui est de plus en plus médiocre. Le reste vient de là.

Les développeurs payés en low cost produisent des logiciels low cost.
Y'a pas de miracle.

avatar dxosi | 

"Les développeurs payés en low cost produisent des logiciels low cost." Je suis d'accord, mais ce n'est pas le seul problème.

Le problème actuellement est qu'il y a une demande de développeurs très supérieure à l'offre. De nombreuses entreprises, notamment des SSII, compensent avec des "développeurs" web, d'où aussi la popularité d'Electron et autres plateformes utilisant des technologies web.
On peut alors comprendre les propos de Tim Cook, qui incite fortement les étudiants à se former au code natif. Ces propos ne se font pas sans arrière pensée.

avatar byte_order | 

@dxosi
> Le problème actuellement est qu'il y a une demande de développeurs très supérieure
> à l'offre.

En général, quand l'offre est inférieur à la demande, les prix grimpent.
Sauf que là...

> De nombreuses entreprises, notamment des SSII, compensent avec des
> "développeurs" web, d'où aussi la popularité d'Electron et autres plateformes
> utilisant des technologies web.

Les SSII proposent des jeunes - plus souvent formé aux technos web qu'autre chose en effet - parce que leurs clients, les entreprises, veulent certes le mouton à 5 pattes mais ne payeront pas son véritable prix aux SSIIs, qui du coup pour se conserver une marge proposent des profils moins expérimentés, donc moins chers, autant pour le client que la SSII.

Mais les entreprises pourraient très bien NE PAS passer par une SSII, et recruter directement ce mouton à 5 pattes. Pourtant, elles ne le font pas massivement : hors de question d'alourdir leur masse salariale durablement.

Y'a pas de magie.

Par ailleurs, les technologies du web intéressent aussi les entreprises. Les microservices, la cloudification pour monter en charge de manière souple, c'est pas que du pipi de chat.

avatar Bigdidou | 

@byte_order

"Les développeurs payés en low cost produisent des logiciels low cost.
Y'a pas de miracle."

Ben moi, je suis sincèrement d'accord pour payer plus les développeurs si ça améliore la qualité. Et comme je suis un garçon très banal, je dois pas être le seul.
J'ai des fois un peu honte de payer un ou deux euro une application, la payer 5 ou 10 € ne me dérangerait nullement (j'irais par contre un peu moins "à l'aventure").
Après, ça ne dépend pas de moi, mais d'un système assez pervers lié aux stores, et la concurrence effrénée entre des clones d'app similaires qui tirent à mon avis tout vers le bas. Difficile, par exemple, pour un développeur d'imposer un explorateur de fichiers bien léché à 10€, là où une multitude de clone ont l'air de faire le boulot pour un ou deux euros. Enfin, je pense.

avatar byte_order | 

@Bigdidou
> Ben moi, je suis sincèrement d'accord pour payer plus les développeurs si ça améliore
> la qualité. Et comme je suis un garçon très banal, je dois pas être le seul.

Et bien contactez-le directement, je suis certain qu'il proposera un compte paypal ou un IBAN pour le permettre.

Évidemment c'est pas aussi pratique que d'acheter dans le magasin, et tant pis si du coup le prix plus élever profite autant au magasin qu'au développeur (et en pratique, génére un profit supplémentaire nettement supérieur pour le magasin, qui n'aura rien à améliorer pour le mériter) que pour lé développeur, qui lui devra sûrement améliorer son application pour justifier aux yeux de l'acheteur que son produit continue de mériter un prix supérieur.

C'est un peu comme de dire "je veux bien payer le litre de lait plus cher", mais de le refuser de le faire parce qu'en pratique cela ne va pas au producteur mais aux intermédiaires, et que le lait est de toute façon le même. On oublie vite que le producteur a des envies de suicide à la vu de ses revenus...

avatar Bigdidou | 

@byte_order

"C'est un peu comme de dire "je veux bien payer le litre de lait plus cher", mais de le refuser de le faire parce qu'en pratique cela ne va pas au producteur"

Alors t'as rien compris à ce que j'ai écrit (ou pas lu : il y a une suite après la phrase que tu cites).
Pas grave.

avatar Ast2001 | 

N'importe quoi. Une app Electron peut aussi être de qualité. Et cette tendance est une tendance lourde. Pour un budget développement _donné_ et pour un App multi-plateforme, tu auras via Electron un résultat d'une qualité sans commune mesure avec n app natives (de la conception, à la réalisation, à l'AQ, au déploiement à la maintenance). Aujourd'hui, javascript / typescript et les frameworks / librairies / modèles de développement associés deviennent une sorte de lingua franca dans le domaine du développement informatique.

avatar dxosi | 

De qualité, non. De moins mauvaise qualité, oui.
Quant à la tendance, elle n’est que le résultat du manque de développeurs compétents.
Enfin, si le budget alloué au développement n’est pas suffisant, il ne faut pas s’attendre à un miracle.
Ce n’est pas pour rien qu’un grand nombre de projets informatiques échouent.

avatar lord danone | 

@oomu

Comment quelqu'un d'intelligent comme vous ne peut pas comprendre que la demande en logiciel est beaucoup plus élevée que le nombre de devs disponibles sur le marché? Ne croyez vous pas qu'electron n'est que la conséquence de ce marché? Vous ne faites que parler des gros éditeurs qui ont les moyens de faire du natif et de petits éditeurs qui choisissent (à raison pour l'instant) de se concentrer sur une plateforme parce que c'est RENTABLE. Mais vous rendez vous compte de l'ENORME demande en logiciel qui existe?

Vous croyez vraiment que les devs de skype, discord, spotify, zeit, (now, hyper,...), github, etc... sont des feignants? Je pense surtout qu'ils sont beaucoup plus réalistes que vous et qu'ils investissent leur temps et leur argent dans un créneau et des langages qui ne peuvent qu'aller de l'avant. Le jour où on pourra compiler du typescript et l'encapsuler dans autre chose qu'un process chromium, l'argument de la performance et du langage ne tiendra plus. Pour les interfaces, ce n'est que question de point de vue et de temps.

avatar dxosi | 

@lord yaourt: C1rc3@0rc sort de ce corps !

avatar rimshot | 

Vous pouvez arrêter de foutre des pubs en plein écran avec du son!!! C’est une app pour lire des articles on n’est pas sur Spotify. C’est la cinquième fois cette semaine. merci.

avatar Scotosh | 

@rimshot

Tu peux t’abonner au club MacG.

avatar debione | 

Je suis toujours un peu dubitatif... Il y a il me semble déjà quelque portage déjà fait depuis iOS vers macOS, et le résultat est catastrophique. En cause principale, les interactions et l'interface. Il faudrait obliger à revoir entièrement l'interface quand on passe d'un soft fait pour être utilisé avec nos doigts sur un écran 9" à un soft souris clavier sur un écran de 27".
La j'ai un peu peur de me retrouver avec moult soft qui seront simplement porté et pas revu de fond en comble...

Pages

CONNEXION UTILISATEUR