Sept ans après son lancement, SwiftUI donne toujours du fil à retordre aux développeurs. Pensé pour simplifier la création d’interfaces sur tous les appareils Apple, le framework souffre encore de lacunes sur macOS, au point de compliquer la confection d’applications impeccables. C’est le constat dressé récemment par le développeur indépendant Paulo Andrade.
Dans un long billet de blog, celui-ci raconte son expérience frustrante avec SwiftUI. Paulo Andrade connait bien le développement sur macOS : c’est le créateur de Secrets, un gestionnaire de mots de passe qu’il considère, à juste titre, comme une « vraie » application Mac. Dans la blogosphère Apple, un terme s’est imposé pour désigner ce type d’app : « Mac-assed app », que l’on pourrait traduire par « app Mac pur jus ». Il signifie qu’une application ne se contente pas d’utiliser des technologies natives, mais respecte aussi les conventions du système et s’intègre parfaitement à macOS. En portant son application Shopie d’iOS vers le Mac avec SwiftUI, Paulo Andrade espérait conserver ce soin, mais il a buté sur les limites du framework.
Shopie, la nouvelle app des créateurs de Secrets pour traquer les baisses de prix
Le développeur pointe notamment des problèmes autour de la gestion de la sélection. Sur Mac, celle-ci comporte plusieurs subtilités : un élément peut être sélectionné dans une fenêtre inactive, dans une vue qui n’a plus le focus ou encore rester la cible d’un menu contextuel sans être sélectionné. Or, SwiftUI ne gère pas tous ces cas de figure correctement.
Le cas des menus contextuels illustre bien le problème. Dans une application Mac bien conçue, ouvrir un menu contextuel fait apparaître un indicateur visuel autour de l’élément concerné, même s’il n’est pas sélectionné. Dans l’exemple ci-dessous pris dans l’app Rappels, le menu contextuel s’applique à la liste « Shopping » alors que « Reminders » reste sélectionné, et l’interface communique clairement cette distinction.
À l’inverse, dans Bourse (exemple ci-dessous), rien n’indique à quel élément est lié le menu contextuel. Quant à Notes, un clic secondaire sur une note non sélectionnée modifie immédiatement la sélection. Ces trois applications sont pourtant toutes basées sur SwiftUI, mais chacune a un comportement différent.
Autre point sensible : le glisser-déposer. Paulo Andrade explique que SwiftUI ne permet toujours pas de gérer ces interactions avec la même finesse qu’AppKit, le framework historique du Mac. Résultat, certains comportements restent imparfaits. Il évoque aussi des difficultés autour des raccourcis clavier et de la création de barres d’outils.
Ces limitations ne mènent pas forcément à une impasse, mais les contourner demande souvent beaucoup d’efforts. « SwiftUI est productif, moderne et souvent agréable, jusqu’à ce que vous essayiez de créer une vraie bonne application Mac. On se retrouve alors à lutter contre le framework pour des fonctionnalités que le Mac a résolues il y a 20 ans », résume-t-il.
De NeXTSTEP à SwiftUI, comment Apple a réarchitecturé ses systèmes
Le constat est partagé par d’autres développeurs. Celui de l’application Radiccio déclare par exemple avoir passé « la majeure partie de la journée à se battre avec SwiftUI sans succès. » Sa solution a finalement été de réécrire certaines parties avec AppKit. Mais cette roue de secours ne devrait plus être nécessaire aujourd’hui. SwiftUI est censé être le framework universel d’Apple et il n’a plus l’excuse de la jeunesse sept ans après son lancement.
Le problème de fond, c’est qu’en compliquant inutilement le travail des développeurs, Apple pousse à faire des compromis ou à abandonner certains raffinements propres au Mac, tirant la qualité globale des applications vers le bas. Et dans le même temps, Electron devient une tentation de plus en plus forte avec son approche web et multiplateforme. Une rumeur veut qu’Apple peaufine l’interface de macOS 27. Espérons qu’elle en profite aussi pour donner aux développeurs les moyens de créer des apps Mac pur jus avec ses propres technologies.
Qu’attendre de macOS 27 ?
