La version finale d'Android 11 est disponible
La journée ne veut décidément pas s'arrêter. Google ajoute au lot du jour la version finale d'Android 11 ! La nouvelle version du système d'exploitation est arrivée et on peut la télécharger pour peu qu'on possède un Pixel 2, 3/3A, 4/4A, un OnePlus 8 et 8 Pro, ainsi que des modèles (non spécifiés pour le moment) de Xiaomi, OPPO et Realme.
Android 11 n'est pas une révolution, c'est une évolution en douceur d'un OS mature. Les nouveautés ne sont donc pas spectaculaires, mais les utilisateurs apprécieront les petites bulles de profils de leurs interlocuteurs, l'enregistrement audio et vidéo intégré de l'écran, le nouvel écran de contrôle des appareils domotiques, les nouveaux contrôles multimédia accessibles depuis les notifications, ou encore les autorisations plus granulaires.
A😪😍😊🙃
Et la bêta 8 d’iOS 14?! #Troll
Cool. Le Pixel va manger des GB tous frais.
Ça sort quand iOS 14 ?
Je peux mettre la Version test en attendant ?
@chmouss
Perso j’y suis en public bêta et 0 soucis.
Si t as des apps de banque ou un token special pour le VPN du bureau... faut être sûr que ça marche...
Mais sinon non j’ai 0 soucis. Sauf éventuellement l’autonomie un poil plus basse qu’une version officielle.
Dans un an chez Samsung, c’est ça ?
@Bigdidou
Sur les modèles qui ont moins d'un an... J'ai testé 3 galaxy s (1, 3 et 4) le suivi c'était 2 ans max voire 18 mois... Et c'était le prix d'un iPhone...
@Boboss29
C’est juste.
Mais sur Android, les applications sont compatibles la plupart du temps avec 4 ou 5 versions antérieures d’Android, alors que sur iOS c’est plutôt 2...
Niveaux usages, c’est similaire au final.
@fte
N’importe quoi 🤪 On se rassure comme on peu , hein.🤠
Les MaJ OS apportent aussi beaucoup de nouvelles fonctionnalités dans les SDK des Apps,
donc des nouveautés pour les Apps, qui ne sont pas dispo pour ceux ayant un ancien OS tout naze.
.
D’ailleurs une grosse galère pour les Devs d’App Android que de gérer ce merdier .
@Sgt. Pepper
"On se rassure comme on peut , hein."
Je n’ai aucun besoin d’être rassuré. Mais je te remercie de te soucier de mes angoisses.
@Sgt. Pepper
Les nouvelles fonctionnalités sont justement directement mis à jour via le Play store et notamment les Google Play service, et ça, même sur les anciens OS...
@armandgz123
Un truc que les fanboys ont décidément du mal à comprendre
@Sgt. Pepper
> donc des nouveautés pour les Apps, qui ne sont pas dispo pour ceux ayant un ancien
> OS tout naze.
Pas mal de ces nouveautés sont rendues disponibles soit via un framework de forward compatibility qui ajoute le support de ces nouveautés soit via la maj des Google Play Services.
> D’ailleurs une grosse galère pour les Devs d’App Android que de gérer ce merdier .
Ouais.
Tandis que devoir adapter son app forcément pour supporter la toute dernière version de iOS, c'est tellement divertissant...
byte_order semble savoir de quoi il parle, contrairemenr à Sgt Pepper
Je suis dev Android et iOS, et excuse moi, mais tu dis de grosses conneries. Merci de ne pas parler à notre place!
Tout le monde utilise les libs androidx (anciennement Support Library) et c'est un plaisir de le voir tourner sur une telle variété de modèles.
Il y a d'énormes avantages sur le dev iOS, même si tout n'est pas rose, mais ce que tu dis est faux et vraiment limite.
@fte
En réalité, c’est bien mieux que ça. Non seulement c’est sûrement bien plus que 4/5 ans maintenant que les smartphone sont très puissant, mais en plis ce sont des composants de l’OS qui sont mis à jour, indépendamment de la version de l’OS.
Ainsi, un smartphone Android de 4/5 ans, même avec un Os d’origine, dispose des dernières fonctions : le dernier Google assistant, le dernier moyen de paiement par NFC, la dernière application de SMS...
Chez Samsung, certains composant de la surchouche sont aussi mis à jour via le store, comme l’Always On Display
@armandgz123
"des composants de l’OS qui sont mis à jour, indépendamment de la version de l’OS."
Yep 👍
@quentinf33
Et pour cause, Apple ne laisse pas le choix, car elle impose d'utiliser forcément à minima le SDK 12 (et donc d'être compatible avec iOS 12 au pire) pour qu'une app continue d'être distribuée sur l'AppStore, seul canal de distribution autorisée par ailleurs.
@quentinf33
> Êtes-vous sûr que le SDK minimal est le 12 aujourd’hui ?
Aujourd'hui ? Non, je ne suis pas sûr, en effet :
https://developer.apple.com/ios/submit/
"App updates must be built with the iOS 13 SDK starting June 30, 2020."
C'est plus le 12 le SDK minimal aujourd'hui, vous avez raison, c'est le... 13.
@byte_order
J’ai des apps qui ont besoin juste d’iOS 8-9
@Krysten2001
Ouais, mais si leurs développeurs voulaient pousser une maj, ils devront développer la mAJ avec le SDK 13 désormais.
@byte_order
Non, j’ai des apps qui sont mises à jour et demandent juste iOS 10
@byte_order
Ce qui ne change strictement rien car on peut préciser la version minimale d’iOS compatible lorsqu’on développe l’app.
Si je veux je peux très bien utiliser le SDK d’iOS 13 et rendre mon app compatible avec iPhone OS 2. Tant que je prévois mon code pour qu’il n’utilise que des frameworks disponibles sur la version pour laquelle je développe, il n’y aura pas de problème.
@Nico_Belgium
> Ce qui ne change strictement rien car on peut préciser la version minimale
> d’iOS compatible lorsqu’on développe l’app.
Ouais, enfin entre déclarer dans le manifeste et que cela marche au runtime, y'a une petite différence quand même.
> Si je veux je peux très bien utiliser le SDK d’iOS 13 et rendre mon app compatible
> avec iPhone OS 2.
J'en doute fort. Si votre app utilise SwitfUI par exemple, bon courage.
> Tant que je prévois mon code pour qu’il n’utilise que des
> frameworks disponibles sur la version pour laquelle je développe, *
> il n’y aura pas de problème.
Mais un surcout. Qu'on appelle le cout de la compatibilité "arrière" (on cible l'ancien).
Qui retombe sur le développeur, qui par ailleurs n'est pas forcément le mieux placé pour connaitre toutes les petites subtilités de retro-compatibilités ou équivalences entre anciennes API et nouvelles.
Côté Android, c'est un cout de compatibilité "avant" (on cible le nouveau, on ou google ajoute le nouveau manquant aux anciennes cibles), et ce cout est pris en charge principalement par Google, pas le développeur.
Ce faisant, l'énergie du développeur est dépensée principalement sur la nouvelle cible, le vendeur de la plateforme lui dépensant la sienne à compléter les cibles anciennes pour qu'elles deviennent compatibles nouvelle cible, en bref à réduire la fragmentation. A opposer à l'énergie du développeur dépensé à supporter une ancienne cible, un surcout difficile à rentabiliser, qui ne prépare pas l'avenir non plus, tandis que le vendeur, lui, ne dépense rien concernant la fragmentation, sa stratégie étant de pousser tout le monde à migrer quand cela l'arrange, lui.
@byte_order
Je caricaturais volontairement en spécifiant iPhone OS 2.
L’idée étant surtout de dire que dire « l’app doit compiler avec le SDK de iOS 13 » n’est pas pareil que de dire « l’app est uniquement compatible avec iOS 13 » (ce que les non connaisseurs auraient pu déduire de vos messages plus tôt ^_^ )
Évidement qu’on ne peut pas utiliser SwiftUI sur des versions antérieures à iOS 13. Mais c’est logique en même temps.. mais rendre l’app rétro compatible jusqu’à iOS 11 par exemple c’est largement jouable sur la grande majorité des apps (et suffisant pour être compatible avec la majorité des iPhones)
@byte_order
(Et soit dit en passant, indiquer une version antérieure à la version actuelle sous XCode ne fait pas que inscrire une ligne dans un manifest.
XCode indique automatiquement tous les morceaux de code incompatibles avec la target visée et demande à proposer une version différente selon les OS visée et refuse de compiler tant que ces erreurs n’ont pas été corrigées. Donc rendre l’app rétro compatible n’est en soi pas si compliqué que ça..)
@quentinf33
"Exagérons pas non plus, il doit y avoir moins d’1% d’applications compatibles avec iOS 12 au minimum. Ou alors je me trompe mais j’ai pas d’exemple en tête..."
Okay. Alors je n’ai vraiment pas de bol. La première app que je chèque est 12+ : Apple Pages. La deuxième : 12.4+ : Apple Developer. La troisième : 13.1+ : Apple Logic Remote...
Je vais aller me faire exorciser.
@fte
J’en ai qui ont besoin d’iOS 8-9
@Krysten2001
"J’en ai qui ont besoin d’iOS 8-9"
Je n’ai pas dit que ça n’existait pas.
@quentinf33
"Ou alors je me trompe"
C’est ça.
Apple force de mettre à jour pour le dernier iOS, et ses SDK sont limites en backward compatibility, drastiquement.
Seules les apps anciennes sont compatibles avec les anciens iOS.
@quentinf33
"Ah oui voilà, les anciennes versions sont tout de même dispo (cf mon autre commentaire)."
Pas toujours. Seulement à la réinstallation, pas à l’achat nouveau, si je ne m’abuse. Et pas de mise à jour possible, genre protocole réseau qui évolue ou security fixes.
C’est bancal. C’est du bol. Ce n’est pas officiel. Ce sont de vieilles apps, pas les nouvelles versions.
De plus comme Apple supporte les téléphones plus longtemps, les utilisateurs faisant volontiers la mise à jour même si ça plombe lourdement leur téléphone, et sans retour en arrière possible ne l’oublions pas, les devs sont encouragés à faire le ménage. Pourquoi s’emmerder avec des OS utilisés sur 10% des appareils actifs ?
Google fournit des frameworks de compatibilité pour tourner des apps récentes sur d’anciens Android. La VM java permet ça facilement... c’est fiable, c’est utilisé depuis longtemps, c’est nécessaire du fait de la grande fragmentation d’Android. Bref, ça marche.
@quentinf33
"A moins que ce soit bien plus complexe ?"
C’est aisé sur Android, parce que les classes Java en bytecode sont assemblées depuis les diverses archives, puis compilées au vol. La mise à jour et les patches sont partie intégrante de l’infrastructure d’Android depuis le premier jour.
Ça ne l’est pas sur iOS parce que Swift est rigide, incompatible avec lui-même entre versions, compilé. Objective-C était plus souple. C’était avant.
Ce n’est pas plus complexe sur iOS. C’est pire. C’est mort.
@quentinf33
"Le problème avec Swift est qu’il est très récent, donc je peux encore comprendre qu’il y ait encore pas mal de changements en profondeur..."
Pour cet aspect spécifique, ce n’est pas sa jeunesse le problème, c’est qu’il est fort peu dynamique.
@fte
Alors à quoi sert les MAJ ? Pour les nouveautés systèmes, correction de bug et de sécurité j’imagine.
@Krysten2001
"Alors à quoi sert les MAJ ?"
Nouveautés des apps. Comme toute évolution de toute application -> fonctionnalités.
@fte
Si les vieilles version d'iOS sont vites abandonnées par les développeurs, c'est justement parce qu'il y a peu de fragmentation. Le pourcentage d'appareils tournant sous une version sous iOS 11 ou antérieur est ridicule, alors pourquoi continuer à le supporter en se privant des nouvelles fonctionnalités des derniers SDK ?
@idhem59
Merci, enfin du bon sens ! Sur l'iPhone, iOS 12 et 13 c'est une couverture de 94% des devices (sur l'iPad 89%), donc si tu supportes iOS 11+ t'es bien. Sur Android pour voir autant de couverture faut supporter quasi une dizaine de versions, la 5.0 (api 21) c'est 94% des devices.
Donc au final on s'en fout pas mal de savoir combien de versions sont supportées, l'important c'est de savoir le parc couvert. Et encore peut-être qu'on s'en fout aussi ? Les développeurs ne sont pas cons, ils veulent donner accès au plus grand nombre.
Ah oui aussi, on s'en fout de savoir qui a la plus grosse, on a largement le choix pour se diriger vers l'un ou l'autre...
Cela tombe bien car Jetpack, ou la support Library couvent Android 19 avec toutes les API, donc le parc entier est aussi couvert ! Et quand une fonction cassé avec une mise à jour, ce n'est pas 95% des utilisateurs touchés.
Au final c'est kif kif
@Bigdidou
Pas du tout c’est beaucoup plus rapide que cela maintenant. Les clichés ont la vie dure
😂 les galaxy fold n’ont pas droit à Android 11
Non, y font des maj chez andropid, et les gens peuvent les installer, incredible, je sais même pas si les gens savent comment faire tellement cela doit être rare😂
Aussi rare qu'un commentaire intelligent de ta part...
Pages