groumly a écrit 3302 commentaires

Dans l’ensemble, les utilisateurs iOS sont beaucoup plus engagés avec les applis et dépensent plus.
Accessoirement, d’un point de vue development, android est “toxic hell stew of a platform” pour citer un exec connu, et les choses sont généralement plus simple à developer sur iOS, sous réserve que la sandbox ne te l’interdit pas (ce qui est très rarement le cas en pratique).

Tu peux pas utiliser le gps en arrière plan, très peu acceptent de donner permission au gps en avant plan, t’as pas accès aux notifications push en arrière plan, tres peu donnent acceptent de donner les permissions push en avant plan, et tu peux faire moins de choses avec les pushs en règle générale, tu peux pas réveiller un site web en arrière plan sur une geo fence, tu peux pas faire un upload de gros fichier en arrière plan, tu peux pas faire de la découverte de réseau local en Bluetooth, tu peux pas configurer le wifi via un browser, tu peux pas faire un widget, tu peux pas faire un chat bot ou une extension iMessage, tu peux pas écrire un proxy ou un client vpn en web, tu peux pas partager ta keychain avec plusieurs applis du même développeur, t’as pas accès à la Secure Enclave, t’as pas accès aux api de validation du device (licensing service sur android ou device check sur iOS), tu peux pas faire de Quick launch actions, tu peux pas détecter que quelqu’un a prit une capture d’écran.
Une appli native ne perd pas son état parce que t’as rafraîchi la page, c’est beaucoup plus dur d’accidentellement fermer un onglet.
Les applis natives sont beaucoup plus réactives à travail équivalent, et viennent avec un langage design cohérent avec la plateforme, qui aide à la découverte de features avancées. Genre les pull to refresh, swipe to delete, ce genre de choses. Les transitions et animations sont un ordre de grandeur plus fluide et polies, et pour la plupart ne requiert pas ou très peu de travail.
Bon courage pour faire en web ne serait ce que 10% de ce que peuvent faire core animation, SpriteKit ou même la base de la base de UIKit.

pourquoi la version Web est inexistante bien souvent, ou alors si lente et mal fichu.

parce que ça fait qq années que tout le monde s’est rendu compte que les utilisateurs d’appli reviennent plus souvent et font plus de choses avec le service que les utilisateurs web, et donc les entreprises investissent beaucoup plus dans les applis. Le web mobile est devenu a 95% un vecteur d’acquisition d’utilisateurs: tu leur donne de quoi s’intéresser au service, et ensuite tu marketes l’appli autant que tu peux.
Parce que c’est plus simple de trouver l’appli Uber sur ton Home Screen, ou de dire “hey Siri call me an Uber” que ca l’est de sortir ton browser, trouver l’onglet ouvert, ou faire une recherche Google.

Alors qu'il est beaucoup plus difficile de développer une application (2 une pour Android et une pour Apple),

C’est très discutable ça. C’était probablement vrai y’a 10 ans, plus vraiment maintenant. Les frameworks sont très mûres, facilitent énormément de choses, et en regle générale, utilisent moins de resources pour faire la même chose. Les apis et process de builds sont aussi beaucoup plus stable, le monde natif ne s’amuse pas à tout réécrire en permanence non plus: j’ai du code en production qui a plus de 8 ans et qu’on a jamais eu a toucher, la ou l’équipe web en est à sa 3ieme réécriture du site web complet.
T’as aussi accès à des langages beaucoup plus expressifs, simple a utiliser et puissant que JavaScript (swift ou kotlin), et de vrais outils de debug et profiling.

laquelle peut-être banni sans préavis de l'AppStore et doit payer un "péage".

allez, ça va. Sorti des jeux en mode freemium, l’immense majorité des applis sont gratuites et monétisent de façon détournée sans verser un centime à Apple/google, sorti des 100 dol’ pour créer un compte chez eux. De même, les bannissements sont extrêmement rare, et sorti de Hey! qui a surpris tout le monde, toutes les applis bannies de l’AppStore savaient pertinemment qu’ils allaient se faire dégager (a commencer par epic qui a fait son coup de pub).
Ca serait mieux sans ce problème, clairement, mais c’est très très loin d’être ce qui me dérange le plus sur l’AppStore après 10 ans dans le milieu.

Mh, non.
iOS 14 tourne sur 30 modèles différents (je compte pas les iPad gsm va wifi, ou les cdma dans la liste).
Si tu remontes à iOS 12, ce qui est très courant en ce moment, ça doit monter à 35/40, et un bon 45 bien tassé si tu supporte aussi iOS 11 (moins courant, mais justifiable en fonction de ton marché).

Edit: c’est sur, c’est pas les 2500 modèles qu’android supporte, mais c’est du même tonneau que supporter 95% des devices existants comme le font tous les shops android.

Heu sur mobile, il te faut acheter (oui acheter pas émuler) au moins 42 téléphones et tablettes de différentes marques et générations puis mettre en place une ferme de tests autos et manuels si tu veux une QA pas trop pourrave.

bravo, tu viens de comprendre une des raisons qui fait qu’ios mène la danse dans le monde mobile.

A savoir un comportement extrêmement similaire entre le simulateur et les devices, ainsi qu’entre devices ou versions d’os.
Les ingénieurs bossent à 99% sur simulateur.
Les designers bossent dans figma/abstract ou que sais je encore et voient facilement ce qui passe ou pas en fonction de la taille du device.
Les product managers valident sur leurs propres devices via TestFlight.

T’écrit des tests automatisés pour tes régressions, et tu fais la qa finale sur un iPhone/iPad. Ça te couvre 99% des cas, et une fois tous les 36 du mois tu te tapes un bug à la con sur un vieil os utilisé par moins de 5% de tes utilisateurs.

Et ça ne marche pas si le site n'est pas ouvert (et pas du tout sur mobile à ma connaissance).

et accessoirement, le taux d’acceptation pour la permission est abysal.

tu sais que ton site oueb bien codé (j'insiste sur le bien codé)

C’est sur que si tu pose comme axiome que ton site est bien codé et n’a pas de problèmes, alors il est bien code et n’a pas de problèmes. Ça simplifie vachement le problème.
Surtout si tu déclares safari, et tous les browsers mobiles en fait vu ce que tu sous entends, des citoyens de seconde zone même pas dignes d’être testés.

Je vois pas trop ce que ca change?

Soit tu enfonces une porte ouverte en disant que l'installation par défaut de windows a boosté ses ventes, soit tu insinues que windows n'aurais jamais pu prétendre être l'os majoritaire s'il n'avait pas été installé par défaut.
Vu le ton et l'audience, je suis a peu près sur que la bonne interpretation est la deuxième.

J'essaye juste de te rappeler qu'être installé par défaut sur 95% des machines de la planète n'est pas un hasard, et est une conséquence de la popularité de Windows, plutôt que la cause.

Windows n'aurait jamais eu autant de succès si il n'avait pas été installé par défaut

As tu considéré que Windows était installé par défaut parce qu’il avait du succès?

Pardon, j'ai mal lu.
Un seul header, 2 librairies, tu cherches les problèmes.

J'ai pas suivi les details des modules C++, mais au pire du pire, tu te retrouves avec 2 headers differents, chacun étant "compile" pour le #ifdef spécifique.
Le code de tes clients va peter s'ils linkent la mauvaise librairie, mais ca c'est une feature, pas un bug. C'est une des raisons pour laquelle faire de la compilation conditionnelles de features est une mauvaise idée.
Expose une configuration runtime, ou utilise de la genericite (template je suppose dans ton cas) pour l'api. Ta librairie sera un peu plus grosse, mais vu ton domaine, je suis pas sur que ca soit un reel probleme.

En quoi les modules vont changer ce genre de hack crade?
Ton #ifdef il va s'appliquer au module, et il va exporter ton api avec bar aliasant int ou char en fonction du #ifdef. Ton module doit toujours etre compilé a l'avance, avec les bonnes options.
La grosse différence c'est que tu peux plus casser ton build en important le mauvais header au mauvais endroit, ni te demander s'il faut utiliser < ou ". tu fais juste import NomDeLaLib

Et tout a fait entre nous, si ta justification anti module c'est que ca rend plus dur de faire du polymorphisme a coup de #ifdef, heu ben voila quoi. Utilise une configuration runtime, utilise des templates, je sais pas, fait qq chose, mais traiter les type comme du texte, ca va te peter a la gueule un jour.
Vu les commentaires que tu as fait récemment sur les Linuxiens qui refusent de se remettre en question sur le DE, je suis convaincu que tu vas immédiatement te remettre en cause, d'ailleurs?

genre xcode il y a quelques semaines pour mettre mon app ios à jour

Ok, alors, t’aimes pas macOS, t’aimes pas macOS. C’est ton droit. Mais t’es pas obligé de mentir.

Xcode n’a jamais force quiconque à mettre quoi que ce soit à jour. Genre jamais. Principalement parce que Apple ne peut pas forcer les gens à mettre Xcode à jour vu les différences de compilateurs etc.

Je dirais plutôt que ce qu’il s’est passé c’est que t’as mit ton téléphone à jour vers 13.6, et t’as du mettre Xcode à jour pour pouvoir debugger sur device.
D’où l’intérêt de developer principalement sur le simulateur et d’utiliser TestFlight pour les deployments.

Tu ne croise pas les doigts au moment des tests pour savoir si tu fait de la marge ou non.

De ce que j’en comprends, même si c’est pas volontaire, c’est “maîtrisé” et intégré au process. Et très courant comme pratique.

Apple a fait ça récemment avec leur dernier iPad, qui est le même cpu que ce qu’ils avaient dans l’iPhone sorti 9 mois avant. Leur process a évolué, et ils peuvent activer un cœur de plus.
Ils savaient quel était le yield, ils avaient planifié un iPhone avec n-1 cœurs, savaient que le process s’améliorerait à temps pour la production de l’iPad avec n cœurs. Ça leur permet de lisser les coûts de Dev et production, et ça rallonge la durée de vie commerciale du cpu.
A plus forte raison quand t’as une gamme qui va de 8 à 32 cœurs.

Ils m'ont demandé de m'occuper de tout ça. Personnellement, ça m'******e parce-que c'est une charge en plus pour moi, et c'est une tâche qui ne m'intéresse pas.

Ben je suis désolé pour toi, mais c’est pour ça que c’est pas un loisir, et que ça s’appelle du bénévolat. T’es pas la pour le fun, t’es la pour fournir une infra efficace.
Si ne pas utiliser ton outil préféré est si gênant que ça pour toi (y’a pas de mal), comme dit pbpg, faut se demander si tu devrais accepter le poste en premier lieu.

Apres, ben écoutes, c’est toi qui voit hein, ya pas de quoi m’en relever la nuit. Tout ce que je voulais dire c’est que de ce que j’en lit (parce que comme répondu à ysabeau, on a très peu de details), on dirait que t’as une solution à la recherche d’un problème.

À partir de là, les solutions qu’il envisage semblent correspondre aux besoins de la structure à savoir :

On ne sait pas quelle est l’assoc’, ce que fait l’assoc’, sa taille (ça parle de responsables de département, pluriel, donc ça a l’air d’être plusieurs dizaines de personnes minimum?), le niveau de familiarité avec l’outil informatique de l’utilisateur typique, la quantite de documents, leur taille, combien de personnes y accèdent, la fréquence d’accès aux document, s’ils sont mobile ou non, que sais je encore.

Il admet aussi ne pas avoir de détails sur les problèmes de Google drive, a part la “performance”, ce qui a tendance à me surprendre. Je suis perso pas fan de Google drive, mais se plaindre de sa performance, franchement, je vois pas.

Bref, vu le peu de détails dispos, dire que ça correspond au besoin me parait un peu cavalier.

D’où l’intérêt des soft skills, de passer du temps sur le terrain pour comprendre le besoin, et de ne pas mettre la charrue avant les bœufs en choisissant un critère arbitraire et personnel comme requirement principal.

Parce que c’est ça qui évite de finir avec du sharepoint pour de l’édition collaborative, ou avec une solution libre qui ne répond pas au besoin.

T'as une solution, et tu cherches un problème a résoudre, ou plutôt, tu cherches a changer le problème pour qu'il colle a ta solution pre choisie.

La question est pas de savoir si Google a des pratiques discutables ou pas, mais de savoir si Google Drive répond mieux au problème que NextCloud (ou l'inverse). Features, disponibilité, formation des membres de l'asso, maintenance.
Prends tout en compte, pas juste un point arbitraire qui n'est important que pour toi, qui n'utilises de toutes façons pas le service. Tu fais quoi si ya un disque qui lache? Tu vas etre dispo d'astreinte pour aller le changer, et remettre un backup en place? Ton backup d'ailleurs, il va ou? Et si la femme de menage débranche le serveur auto hébergé pour passer l'aspirateur, ou si ya une panne de courant dans le quartier?

Une machine qui met 10 minutes a démarrer, soit ya un très sérieux problème hardware, soit windows a vraiment été configuré avec les pieds (ou la machine mine du bitcoin dès le boot loader). Dans un cas, linux ne fera rien de mieux, dans l'autre ca se résout en moins de 2 heures avec une install fraiche.

Bref, plutôt que de te mettre tout le monde a dos en poussant ton propre agenda, focalise toi sur le fond du problème: mettre en place l'infrastructure qui répond le mieux au besoin des utilisateurs.

Depuis quasiment toujours en fait. C’est juste que les applis tierces ont beaucoup évolué en complexité et en finition, et plus le temps passe plus ça devient problématique.
Mais oui, ça va en s’empirant.

Pour être tout à fait honnête, ya à boire et à manger, ça dépends pas mal de la team qui a pondu le code. J’ai passé pas mal de temps sur les app clips récemment, et ça va là dessus. Enfin, sauf pour un des points les plus importants (taille max du binaire), ou il a fallu demander à WWDR à quoi elle s’appliquait.
J’ai aussi bossé sur des trucs semi privés, et la seule doc, c’est les headers. Apple a pas une culture d’expliquer à tout le monde ce qu’il font.

Ça commence à lâcher prise côté serveur car il devient vraiment difficile de justifier auprès du client de ne pas vendre un produit objectivement meilleur, mais ça résiste encore beaucoup du côté des stations de travail haut de gamme (et autre ordinateur portable haut de gamme professionnel).

Qu’est ce que tu impliques par la?

Apple a imposé bitcode précisément pour cette raison. C’est horriblement documenté, donc c’est très dur de savoir ce qu’ils font précisément avec ça, mais c’est typiquement le genre de choses qu’ils pourrait faire avec, a savoir recompiler le code optimise finement pour chaque device.
Ils optimisent déjà les bundles en ne gardant que les assets nécessaires.
Va savoir ce qu’ils ont dans leur roadmap cpu, mais vu l’écart entre un iPhone et un Mac Pro, je serais pas surpris qu’ils ait sorti ça longtemps en avance pour l’avoir dispo sur l’intégralité du store au moment de la transition arm.

Apres, ça fout complètement en l’air les dsyms, et vu la qualité risible de leur crash reporter, j’ai vraiment pas envie de l’utiliser.

Pas totalement car si on contrôle plus d'arabes que de blancs, mais que les blancs se font plus mettre en prison que les arabes parce que les arabes sont en majorité innocents, alors on devrait reconnaître que la criminalité arabe est moindre et le policier consciencieux devrait alors venir à la conclusion qu'il devrait moins contrôler les arabes.

Donc en gros, les arabes doivent se comporter au grand minimum 4 fois mieux que les blancs pour corriger le biais de selection.
Ce qui est très précisément ce que racisme systémique et white privilege veulent dire: les blancs ont beaucoup plus de marge de manoeuvre que les autres face a la police.

Et encore une fois, il faut bien lire, lorsque je dis que une mamie à 70% de chances d'être une criminelle sur ce seul critère,

Non, ce que tu dit, c'est qu'une fois condamné, un criminel a 70% de chance d'être une mamie. Une mamie prise au hasard dans la population a 0.7% de chances d'être une criminelle.

Ca ne veut pas dire non plus que 70% des criminels sont des mamies, précisément a cause du biais de sélection. La police n'attrape clairement pas tous les criminels, donc si la police applique un filtre arbitraire a l'arrestation, ce filtre va se manifester dans les stats d'incarceration.
A plus forte raison quand les stats générées par le biais de selection sont utilisées pour justifier le biais de selection.

ce sont des chances, je ne suis pas en train de dire que 70% des mamies sont criminelles.

??
Si tu dit qu'une mamie a 70% de chance d'être une criminelle, tu dit en substance que 70% des mamies sont des criminelles.

Les portages ne semblent pas triviaux vu qu'Apple a annoncer vouloir aider les projets open source à faire leur portage.

Ca depend lesquels. Une très très grosse majorité des applis importantes sur macOS ont très peu, voir aucun, de code spécifique x86.
Une simple recompilation et ca repart. J'en ai vu quelques un faire les coqs sur twitter a ce sujet. Et il me semble qu'un des studios de jeux (pas epic du coup…) qui était la pour la demo disait qu'ils avaient un build macOS ARM en moins de qq heures.

La ou Apple a offert d'aider c'est sur le code assembleur, les changements bas niveau (me rappelle avoir vu passer des threads twitter la dessus, en gros des applis qui faisait des assomptions erronées sur certains comportements du système qui petent avec le passage a ARM). Et j'imagine aussi sur les scripts de builds.
En gros, ca fait plus de 10 ans que tout le monde part du principe que si ca build pour macOS, c'est forcement x86, et que donc si ca build pour arm, c'est forcement pour iOS.
Entre les #if arch(x86_64) qui veulent vraiment dire #if targetEnvironment(simulator) et les builds de script qui déterminent la platforme a partir de l'archi du CPU, ya un certain nombre de librairies multiplateformes dont les builds vont peter.
Genre libgit2 (ou plutot, les scripts d'objective-git2 pour libgit2) est plein a craquer de ce genre de choses. J'ai deja galeré pour sortir un build catalyst (donc iOS ARM + iOS sim x86 + macOS x86) dans un xcframework, je m'approche pas de ce script pour macOS ARM.

Si ton certificat n'est valide que 15 jours, tu vas très vite automatiser la generation des certificats, parce que t'as autre chose a faire tous les 15 jours.
Et du coup, t'as vachement moins de chances d'avoir un problème.

C'est aussi beaucoup plus dur de valider que le renouvellement automatique d'un certificat valide 4 ans fonctionne bien, vu qu'il faut attendre 3.8 ans pour s'assurer que la tache démarre.
Sans compter qu'après 4 ans, ya des grandes chances que pour la stack de gestion de l'infra ait suffisamment changée pour douter que la tache en question va toujours fonctionner. Ou que le mec qui a mit un reminder dans son calendrier bosse plus la, ou que l'alerte nagios/sensu/whatever ait été supprimée/perdue dans une migration.

Le "c'est pour ça" est un peu bizarre, mais ce qu'il veut dire c'est que changer les certificats tous les mois en fait une tache régulière qui a beaucoup moins de chance d'être oubliée/foirée vu que les équipes le font souvent.
C'est du meme tonneau que "si les deployments sont douloureux ou risqués, c'est que tu déploies pas assez souvent".

Je sais pas pour les Clio, mais ma Jetta gueule comme un putois quand je sort de l’habitacle et m’éloigne de plus d’un mètre avec la clé pour sortir les poubelles en rentrant du boulot. Idem quand c’est madame qui a la clé dans son sac et qu’elle sort avant que j’ai finit de garer la voiture.
J’ai jamais tenté de rouler plus de 15 mètres comme ca, mais ça me parait difficile d’ignorer l’alerte pendant 30km.

Genre s’assurer que la police arrête de faire chier les bronzés plus que les blancs (on ne dit pas que les blancs doivent se faire emmerder, juste d’arrêter les contrôles au faciès non justifiés), que les proprios arrête de refuser de louer juste parce que le gars noir, d’allouer un budget similaire aux écoles des quartiers défavorisés etc.

C’est clairement pas facile, surtout quand il s’agit de rétablir la balance d’un point de vue patrimoine accumulé en profitant des dit privilèges, mais d’un autre côté, personne a dit que c’était facile, ni n’a prétendu avoir la solution.
Refuser d’admettre qu’il existe un problème, par contre, ça aide pas.

Et sinon:

sachant que tu définis tout individu comme un superposition de privilèges dans ta conception

C'est vilain les hommes de pailles. J'ai jamais dit ca, et pour etre tout a fait honnête, je comprends meme pas vraiment ce que tu veux dire par la.