Swift quasiment à égalité avec C++ dans la composition de macOS Sonoma
Comme les autres systèmes d'Apple, macOS et ses applications natives poursuivent leur transition vers Swift. Après avoir analysé la répartition des langages utilisés dans iOS 17, le développeur Alexandre Colucci, alias Timac, a passé au peigne fin Sonoma.
D'après son étude portant sur l'essentiel des binaires du système, 13 % sont écrits en Swift, soit presque autant que ceux écrits en C++ (14 %). Objective-C reste majoritaire (53 %), mais sa part se réduit par rapport à Ventura, tout comme celle de C (19 %).
En matière de technologies de création d'applications Mac, l'historique AppKit et la passerelle Catalyst (qui facilite les portages depuis l'iPad) reculent au profit de SwiftUI, le dernier framework en date.
Les applications Localiser et Météo ainsi que le panneau Temps d'écran sont en effet passés de Catalyst à SwiftUI. « Six ans après son introduction, il devient évident qu'il s'agissait d'une technologie de transition », observe le développeur à propos de Catalyst. SwiftUI a aussi fait son trou dans plusieurs apps qui restent en partie constituées avec AppKit, comme Aperçu, Rappels et Partage d'écran.
Des statistiques supplémentaires sont disponibles dans le billet de blog de Timac.
De NeXTSTEP à SwiftUI, comment Apple a réarchitecturé ses systèmes
Etrange que la dose de Obj-C augmente. A moins qu’ils reduisent les lines of code avec les années mais ca aussi serait etrange (ce serait un belle surprise mais j’ai du mal a y croire).
@hawker
SwiftUI n’est qu’un framework qui utilise la syntaxe Swift, mais en réalité un grand nombre des API de SwiftUI repose encore sur du code Foundation quand tu regardes leur code.
Du coup il n’est pas surprenant que la part d’Objective-C augmente en même temps que la part de SwiftUI
Aaaah, les apps Catalyst absolument pas faites pour le Mac mais pour l'iPad et qui perdent toutes les idées et les guidelines élaborées et raffinées pour un clavier et un souris depuis des décennies...
EDIT:
SwiftUI est aussi fort centré iPad et iPhone...
@Deckard
Tout à fait…
@ Deckard
SwiftUI, probablement le truc de devs venant du web et qui voulaient retrouver ReactJS, c'est pour moi une pure hérésie.
Comme le markdown où on revient aux années 80 et où on tape des tags pour formater son texte. On oublie le WYSIWYG et les éditeurs tels TextEdit ou le vénérable Word.
Avec SwiftUI on code et on compte les pixels au lieu de dessiner de manière intuitive. C'est aussi comme si on s'amusait à taper du code SVG au lieu d'utiliser un "éditeur graphique" pour faire du dessin vectoriel.
Je suis sûr que les amateurs de SwiftUI sont également fans de fonds sombres.
@marc_os
Quoi ???
SwiftUI c’est la meilleure amélioration depuis Swift !
Déclaratif
Réactif
Intuitif
Ah et j’utilise que le dark mode, partout 😂
@marc_os
C’est une techno bas-niveau. Rien n’empêche de faire des outils WYSIWYG par-dessus.
@ serenity
> Rien n’empêche de faire des outils WYSIWYG par-dessus
Ça existe déjà : Xcode builder — pas besoin de rajouter cette merde.
@marc_os
Il suffit d'un Interface Builder pour Swift UI et basta.
Ok ta critique du markdown te fait perdre toute crédibilité…
@ hawker
> Ok ta critique du markdown
Oui, il y a plein de gens qui en font la promo.
Mais qui en même temps pratiquent le "faites ce que je dis, pas ce que je fais" avec leur site qui ne le supporte pas. Alors question crédibilité...
Xcode non plus.
Trop cool de devoir utiliser un éditeur supplémentaire.
Et pour quoi ?
Pour avoir un readme dans github.
Le seul usage que j'en connais.
Et toi, tu l'utilises dans quel cadre ?
@marc_os
"Comme le markdown où on revient aux années 80 et où on tape des tags pour formater son texte. On oublie le WYSIWYG et les éditeurs tels TextEdit ou le vénérable Word."
Le Markdown a été inventé dans un seul but : faciliter l’écriture pour le web. Pour ce but là, Word est une plaie, qui a été inventé pour propriété une sortie papier, tandis que le Markdown propose un balisage léger qui est un sous-ensemble du HTML. C’est un langage natif du web.
Son 2e avantage, est justement qu’il rend visible le formatage et la structuration, ce que Word ne fait pas a priori. Le nombre de fichiers Word que je reçois avec un pseudo formatage visuel et sans aucune structuration ! La galère à récupérer !
Et puis, va demander aux devs aujourd’hui de retourner écrire leur documentation en ligne avec Word…
En 3e lieu, il permet de partager des fichiers texte ouvrable par n’importe quel éditeur, sans restriction. Essaie d’ouvrir un fichier Word dans VS Code, pour voir.
Enfin, l’eco-système du Markdown est essentiellement libre, et non propriétaire, ce qui n’empêche pas des tas de boîtes de proposer des logiciels l’intégrant de manière plus ou moins approfondie. Mais tu trouves des tas d’apps libres qui le gèrent.
Donc, pour être bref, tu as peut-être raison pour Swift , je n’en sais rien, je ne suis pas dev pour pouvoir en juger, mais non, ce n’est pas « comme le Markdown ».
@ pat3
> C’est un langage natif du web
Le markdown ? C'te blague.
Vous savez de quand date le "web" ? 😳
Autre chose : Vous avez déjà tenté d'ouvrir un fichier .md avec Safari ou Firefox ? 😂
Ceci dit, en pratique, on utilise des éditeurs WYSIWYG pour le markdown ! (Perso j'utilise Markdown Editor.)
Car seuls les marqueurs de base sont simples à retenir.
Et pour voir le résultat immédiatement... Comment faire autrement et simplement, vu que ni Safari ni Firefox ne sont utilisables pour de la prévisualisation ?
Et quand il faut compter le nombre d'apostrophes, bonjour.
C'était bien la peine de promouvoir ce format alors que pour le WEB, on a déjà un langage à base de marqueurs.
Mais c'est quoi déjà ?
Ah oui : HTML. 🤪
@marc_os
"> C’est un langage natif du web
Le markdown ? C'te blague.
Vous savez de quand date le "web" ? 😳
Je ne parle pas du HTML ! Je ne sais pas ce que vous entendez par natif du web, mais pour moi ça signifie que ce langage de balisage a été créé pour un usage web (c’est au départ un script perl de conversion de texture en html), contrairement aux traitements de texte écrit pour un usage print. Mais vous avez raison, j’aurais dû m’en tenir à « créé pour le web ».
Autre chose : Vous avez déjà tenté d'ouvrir un fichier .md avec Safari ou Firefox ? 😂
Euh…, c’est ça votre argument contre le Markdown ? Parce que bon, ouvrir un fichier Word avec Safari ou Firefox, c’est tout pareil… en revanche, changez le suffixe d’un fichier Word en txt et ouvrez-le avec un navigateur, et faites de même avez un fichier .md. Lequel des deux est le plus lisible ?
De plus, la majeure partie des éditeurs de blogs intègrent le Markdown, tout comme Github, et nombre de sites communautaires.
Certains éditeurs permettent de produire un diaporama depuis un fichier Markdown. (Il y a même des éditeurs spécialisés dans cet usage), d’autres une mindmap, d’autres un site flat, d’autres encore de gérer un blog.
"Ceci dit, en pratique, on utilise des éditeurs WYSIWYG pour le markdown ! (Perso j'utilise Markdown Editor.)"
Euh… Markdown Editor est un éditeur Markdown WYSIWYM comme les autres ?!? Il a juste un autopreview (c’est dans sa description), qui n’est pas activé par défaut, et une barre d’outils par ailleurs escamotable.
"Car seuls les marqueurs de base sont simples à retenir."
C’est déjà ça, vu que les marqueurs de base permettent de structurer un texte pour sa manipulation en ligne. Mes étudiants après 10 ans de traitement de texte ne savent toujours pas structurer un texte avec Word ou LibreOffice alors qu’ils l’apprennent en une heure en Markdown.
Après, c’est vrai, la gestion des liens ou des images demande un peu d’habitude, et plus encore celle des tableaux. Mais les éditeurs Markdown ont majoritairement facilité la tâche aujourd’hui, certains en gérant le glisser-déposer des images, ou en proposant un bouton et/ou une pop-up de création de tableau.
Bon ensuite ça se complique vraiment quand on veut éditer des diagrammes et des équations, mais ça se complique quelque soit l’éditeur ou le traitement de texte…
"Et pour voir le résultat immédiatement... Comment faire autrement et simplement, vu que ni Safari ni Firefox ne sont utilisables pour de la prévisualisation ?"
Avec un éditeur en local ou en ligne ? C’est pareil pour produire du HTML, vous avez bien besoin d’un éditeur de texte avec une interface de prévisualisation ?Je ne suis pas allé voir si les outils de dev des navigateurs intégraient un parseur Markdown.
Mais à ma connaissance, aucun navigateur ne gère la prévisualisation de fichier Word non plus, ni même du rtf. Seulement du txt ou du HTML.
En revanche il existe plusieurs extensions pour lire, éditer, convertir et exporter du Markdown depuis son navigateur (j’ai regardé pour Firefox).
"Et quand il faut compter le nombre d'apostrophes, bonjour."
Je ne comprends pas cet « argument » ?!? L’apostrophe n’étant pas utilisé comme balise en Markdown, je ne vois pas ce qui empêcherait de les compter, dans n’importe quel éditeur ?
"C'était bien la peine de promouvoir ce format alors que pour le WEB, on a déjà un langage à base de marqueurs.
Mais c'est quoi déjà ?
Ah oui : HTML. 🤪"
Bon, ok, vous êtes réfractaire, mais ça n’est pas une raison pour être de mauvaise foi 😂
Gruber a créé le Markdown pour se faciliter la tâche de publication de Daring Fireball qu’il codait à la main en HTML. Le Markdown facilite la tâche d’édition de documentation à pas mal de développeurs avant d’être utilisé par des usagers lambda.
On peut se faire des flux de travail depuis un éditeur markdown pour publier directement sur une plateforme.
@Deckard
Dans les choses "récentes", dont Catalyst ou SwiftUI, rien, absolument rien, n’est pensé pour le Mac. Ça ne vaut pas mieux qu’Electron, alors pourquoi s’ennuyer ?
@fte
“Dans les choses "récentes", dont Catalyst ou SwiftUI, rien, absolument rien, n’est pensé pour le Mac.”
Je t’invite à aller consulter les tutoriels de Paul Hudson (HackingWithSwift). Parce que là, vraiment, tu racontes absolument n’importe quoi.
SwiftUI a été spécifiquement conçu pour remplacer UIKit et AppKit, dans le but d’en faire un framework universel.
@joneskind
"Parce que là, vraiment, tu racontes absolument n’importe quoi."
Leçon de communication et savoir-vivre. On ne dit pas à quelqu’un que l’on ne connaît pas, ni ses chaussettes préférées ni son expertise professionnelle, qu’il raconte n’importe quoi. On dit qu’on est en désaccord, éventuellement. Le risque de passer pour un fion n’est pas minuscule.
"SwiftUI a été spécifiquement conçu pour remplacer UIKit et AppKit, dans le but d’en faire un framework universel."
C’est exact. Electron aussi a été spécifiquement conçu pour remplacer UIKit, SwiftUI, .NET, wxWidgets, tout quoi, et c’est un framework pratiquement universel, beaucoup plus que SwiftUI. Dans cet esprit, Electron est une réussite très supérieure. Ça n’en fait pas une API brillante pour le Mac. Mais meilleure que SwiftUI. Passons.
Tu as ton degré d’exigences. Liberté. Personne n’est obligé de mettre la barre au dessus du sol.
En attendant, Apple Music, ex-iTunes, est toujours partiellement en Carbon tout pourri. Il serait temps d’avoir une version moderne digne de ce nom.
@serenity
Je comprends maintenant pourquoi cette application manque de fluidité alors que c’est le cas dans d’autres applications.
Ils attendent quoi pour optimiser ces feignants de développeurs ?
Music où il faut trouver une icône pas du tout visible pour changer le tri d'une lecteur au lieu de le faire en cliquant sur l'entête de la colonne d'une liste de lecture comme on a toujours fais depuis... des décennies.
SwiftUI est très très bien.. pour iOS et iPadOS.
Essayez de faire tourner une grosse liste (en grid) sur macOS ou surtout tvOS et vous allez voir que ces plateformes sont vraiment pas la priorité d’Apple ..
Et pour info, les listes de SwiftUI utilisent UICollectionView (après avoir était basé UITableView)
SwiftUI très bon on peut faire des trucs impressionnants avec un minimum de lignes de code. Seul problème c’est qu’il y a encore pas mal de manques par rapport a UIKit, mais bon ca arrive…
Pourquoi le dev chez Apple prend des plombes ?