Expertise · Applications de bureau

Applications qui s’installent sur l’ordinateur. Sur macOS, nous en avons construit deux ; pour Windows et Linux, cette page est une offre, pas un historique.

Nous construisons des applications natives pour macOS, avec le noyau logique séparé de l’écran, afin que la même logique fonctionne aussi sur le téléphone. Pour Windows et Linux/Ubuntu, nous n’avons encore rien livré et nous l’écrivons tel quel, avec les conditions dans lesquelles nous accepterions le travail. La première question reste de savoir si vous avez vraiment besoin d’une application installée.

Discuter d'un projet

Offre, avec conditionsLa règle est mécanique et je l’applique mécaniquement. Sur macOS, nous avons deux implémentations propres, construites et exécutables : une application de barre de menu avec 25 fichiers Swift, qui réutilise 15 fichiers du noyau d’un projet d’iPhone, et une deuxième application, plus simple, qui est une enveloppe WebKit au-dessus d’une application web. Les deux ont un binaire compilé sur cette machine. Mais le service, tel qu’il est nommé, couvre trois familles de systèmes, et pour deux d’entre elles — Windows et Linux/Ubuntu — nous avons cherché sérieusement et trouvé zéro : aucun projet .NET ou Qt propre, aucun `tauri.conf.json`, aucun Electron écrit par nous, aucun `.desktop`, aucun paquet deb, rpm ou AppImage. En plus, aucune des deux applications macOS n’a jamais été empaquetée dans un installateur distribuable. Avec seulement une des trois plateformes couverte et zéro distributions, la page s’écrit comme une offre avec conditions. Quand nous livrerons la première application Windows ou Linux, la valeur changera, pas le texte.

La première question que nous vous posons n’est pas pour quel système, mais si vous avez réellement besoin d’une application installée. Elle mérite d’être installée lorsqu’elle a besoin de quelque chose que le navigateur ne lui donne pas : accès direct aux capteurs ou aux périphériques, présence permanente dans la barre système, travail sans internet, accès aux fichiers du disque sans que la personne les charge à chaque fois, ou exécution en arrière-plan quand la fenêtre est fermée. Si rien de tout cela n’est requis, un site qui s’ouvre depuis un lien est moins coûteux à construire, à mettre à jour et à maintenir — et nous vous le disons, même si le travail devient plus petit.

Sur macOS, nous avons deux applications construites. La première est une application de barre de menu : 25 fichiers Swift propres, plus 15 fichiers de noyau repris directement du projet iPhone du même produit — les mêmes fichiers, pas une copie. Elle se construit avec un script qui appelle directement le compilateur Swift, cible `arm64-apple-macosx14`, en liant onze frameworks système, parmi lesquels SwiftUI, AppKit, CoreMotion, Vision et UserNotifications. Le binaire obtenu a 6.516.128 octets. La seconde est beaucoup plus simple et il est honnête de dire combien : trois fichiers Swift, un habillage WebKit au-dessus d’une application web, avec sandbox et runtime renforcé activés, compilé universellement pour processeurs Intel et Apple. Ce sont deux choses différentes et nous les nommons différemment.

Ce que nous n’avons pas, dit clairement. Windows : zéro. Nous avons recherché des projets .NET, WPF, WinForms, WinUI, des fichiers `.xaml`, `.appxmanifest`, `.msi`, `.wxs` — tout ce que nous avons trouvé sur le disque appartient à une bibliothèque C tierce, vendorisée dans un autre projet, que nous n’avons pas écrite. Linux desktop : zéro — aucun fichier `.desktop`, aucun paquet deb ou AppImage construit ici. Electron ou Tauri écrits par nous : zéro. Et, tout aussi important : aucune des deux applications macOS n’a jamais été empaquetée dans un installateur. Elles existent comme paquets `.app` construits localement, signés ad hoc, sans identifiant d’équipe.

Ce que l’expérience acquise transfère malgré tout, et c’est la partie qui compte pour un nouveau projet : la discipline de garder le noyau de logique séparé de l’interface. Dans le projet macOS, les fichiers de calcul et de politiques n’importent pas l’interface, donc ils se compilent et s’exécutent sur Mac comme programme ordinaire, sans simulateur ; leur suite de logique s’exécute en quelques secondes. La même séparation fait que le portage sur un autre système est un problème d’habillage, pas de réécriture. C’est sur cela que nous nous appuyons quand nous disons que nous pourrions faire Windows ou Linux — pas sur une expérience que nous n’avons pas.

Ce que cela comprend

Le travail, par composantes

D’abord, nous décidons si vous avez besoin d’une application installée

Cinq critères, vérifiés l’un après l’autre : accès aux capteurs ou aux périphériques, présence dans la barre système, travail sans internet, accès direct aux fichiers du disque, exécution en arrière-plan avec la fenêtre fermée. Si aucun ne s’applique, la recommandation est une application web, et la raison est pratique : une application installée doit être signée, distribuée et mise à jour sur chaque ordinateur, et chacun de ces trois étapes coûte sans fin, pas une seule fois.

Le noyau s’écrit une fois et ne sait pas sur quoi il s’exécute

Dans notre application macOS, la cible de bureau liste 15 fichiers du noyau du projet iPhone comme sources propres — calcul, calibration, historique, politiques de notification et de données de santé. Ils ne sont pas copiés, ce sont les mêmes fichiers. Conséquence : une correction d’algorithme se fait à un seul endroit et apparaît sur les deux. Deuxième conséquence, plus importante pour vous : le noyau peut être testé sans lancer l’application.

L’habillage de plateforme reste mince, et nous vous disons à quel point il est mince

L’application de barre de menu utilise `MenuBarExtra` au-dessus d’un délégué d’application AppKit — du code natif, mais peu, parce que le reste est le noyau commun. Notre autre application macOS est à l’extrême opposé : trois fichiers, un `WKWebView` emballé pour SwiftUI, c’est-à-dire une fenêtre au-dessus d’une application web. Toutes deux sont de véritables applications macOS, mais elles signifient des choses différentes en termes d’effort, de vitesse et d’accès au système. Celle qu’il vous faut se décide au début, pas au moment de la livraison.

Nous construisons avec un script, pas avec l’appui d’un bouton

L’application de barre de menu est construite à partir d’un script de moins de cent lignes qui appelle directement le compilateur Swift, avec la cible et la liste des cadres écrites explicitement, puis place le paquet `.app` et le signe. Un build qui tient dans un script s’exécute de la même manière sur une autre machine et peut être intégré dans une ligne automatisée ; un build qui n’existe que dans l’interface d’un programme de développement ne le peut pas.

Sandbox et runtime renforcé, quand l’application sort sur le réseau

La deuxième application macOS démarre avec le sandbox activé et avec une seule permission réseau, celle de client — pas serveur, pas d’accès aux fichiers de l’utilisateur, pas de caméra, pas de microphone. Le runtime renforcé est activé depuis la configuration du projet. Les permissions sont déclarées dès le départ, comme une liste courte et lisible, elles ne s’ajoutent pas en cours de route quand quelque chose ne fonctionne pas.

La signature est un problème de compte, pas de code, et nous le mettons sur la table dès le début

Nos applications macOS sont signées ad hoc : la vérification passe localement, mais il n’existe pas d’identifiant d’équipe, et dans la configuration du projet le champ de l’équipe de développement est vide. Pour une distribution en dehors du magasin, un paquet macOS a besoin d’une signature avec un certificat de développeur identifiable et d’un passage par la notarisation Apple, sinon le système d’exploitation de celui qui le reçoit le bloque. C’est un problème de compte et de processus, pas de fonctionnalité — mais c’est un problème réel et nous ne le cachons pas lors de la dernière réunion.

Windows et Linux : ce que nous demandons avant d’accepter

Une vérification de compatibilité payante comme première étape, qui se termine par une structure qui démarre sur votre ordinateur, pas par un document. Trois choses y sont décidées : quel environnement d’exécution nous utilisons et pourquoi, qui détient le certificat de signature et le compte de distribution, et comment une mise à jour arrive sur les ordinateurs des gens. Si l’une des trois n’a pas de réponse, le travail ne commence pas. Nous n’assumons pas une plateforme que nous n’avons pas livrée en prétendant que c’est une formalité.

Linux server n’est pas Linux desktop, et nous ne confondons pas les deux

Nos systèmes fonctionnent jour après jour sur Linux : unités système avec redémarrage en cas d’échec, serveur web en frontal, journaux et leur rotation. C’est une vraie expérience avec Linux, mais c’est une expérience de serveur. Une application à fenêtres pour Ubuntu est une autre discipline — empaquetage, intégration avec l’environnement graphique, distribution via dépôt ou via un fichier autonome — et là nous n’avons rien livré. Cette différence, un ingénieur la voit en trois secondes ; il vaut mieux que nous la disions nous-mêmes avant.

Ce que nous ne faisons pas

Nous ne promettons pas un installateur que nous n’avons jamais produit sans dire que c’est la première fois. Nous ne choisissons pas un environnement d’exécution simplement parce qu’il est à la mode, sans vérifier d’abord ce que l’application exige du système. Et nous ne reprenons pas une application desktop existante avant de pouvoir la construire de zéro, sur notre machine, à partir des sources reçues — si le build n’est pas reproductible, toute estimation après coup n’est qu’une devinette.

À quoi cela ressemble

Le parcours, étape par étape.

Nous décidons installé ou web, selon cinq critères

Capteurs et périphériques, barre système, travail sans internet, accès aux fichiers, exécution en arrière-plan. Nous livrons la décision écrite, avec le motif, même quand le motif est « vous n’avez pas besoin d’une application installée ». Cette étape est courte et peut s’arrêter là sans perte.

Nous construisons le noyau et nous le testons sans plateforme

La logique, les états, la persistance, les politiques — écrites de manière à ne pas dépendre de l’interface et à pouvoir se compiler et s’exécuter comme programme en ligne de commande. Nous livrons la suite de tests et la commande avec laquelle vous l’exécutez. Si plus tard une deuxième plateforme apparaît, on voit ici si le travail a été fait correctement dès le début.

Nous posons l’enveloppe de plateforme

Sur macOS : fenêtres ou barre de menu, notifications, permissions, le paquet `.app`, le script de construction. Sur Windows ou Linux : après la vérification de compatibilité de la première étape, avec l’environnement d’exécution choisi là-bas. À la fin de l’étape, l’application démarre sur votre machine, pas sur la nôtre.

Signature, distribution, mise à jour

L’étape que la plupart des projets découvrent trop tard, et que nous plaçons explicitement en dernier pour qu’elle soit visible : certificat, compte, notarisation lorsque la plateforme l’exige, canal de mise à jour. C’est aussi notre blocage actuel sur macOS — les applications sont signées ad hoc, sans identifiant d’équipe. Dans votre projet, le compte est le vôtre et le blocage disparaît.

Un noyau au centre — calcul, calibration, historique, politiques — qui n’importe aucune interface et se teste donc lui-même. Autour, quatre enveloppes de plateforme : iPhone et macOS, liées et construites, dessinées en plein ; Windows et Linux desktop, dessinées en ouvert, car elles n’existent pas. Le cinquième nœud, la distribution, est relié à macOS par une ligne en pointillés : le paquet est construit et signé ad hoc, mais ne passe pas la notarisation, donc n’arrive pas sur un autre ordinateur. Le schéma dit ce qui est fait et ce qui ne l’est pas, dans la même image.

Les données

Ce que nous touchons, où elles sont et combien de temps elles restent

Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.

Une application installée voit plus qu’une application dans le navigateur: C’est la raison pour laquelle vous la voulez et, en même temps, son risque : elle a accès au disque, au système de fichiers de l’utilisateur et, si des permissions lui sont accordées, aux périphériques. C’est pourquoi les permissions sont déclarées explicitement et maintenues au minimum. Notre application avec sandbox n’a exactement qu’une permission, celle de client réseau.
Où se trouvent les données quand l’application n’a pas de serveur: Sur l’ordinateur de la personne. Dans l’application de barre de menus, l’historique est écrit dans un fichier propre, et les préférences dans le magasin de réglages du système, avec des clés préfixées par application. Rien n’est envoyé vers un serveur pour une raison simple : il n’y a pas de code réseau dans l’application. Lorsqu’il y en a, la page des permissions indique qui reçoit quoi.
Ce que nous ne collectons pas par défaut: Aucune télémétrie, aucun identifiant d’appareil, aucun rapport d’utilisation, s’ils ne sont pas demandés explicitement et déclarés dans l’interface. Une application desktop est un endroit où la télémétrie passe inaperçue ; c’est pourquoi, si elle est mise en place, elle l’est de manière visible, avec un bouton d’arrêt, et l’on écrit quels champs partent.
Les mises à jour sont une décision, pas un détail technique: Nous n’avons pas aujourd’hui de canal de mise à jour automatique construit. Dans un nouveau projet, c’est l’une des trois premières décisions, avec la signature et la distribution : mise à jour manuelle, via la boutique de la plateforme, ou via un canal propre ? Chaque variante a un autre coût permanent et une autre surface de sécurité, et se choisit avant la première ligne de code, pas après.
Ce qui reste chez nous: Les sources, tant que nous travaillons ; après la livraison, ce qui a été convenu dans le contrat. Les certificats de signature restent, idéalement, sur le compte de votre organisation — s’ils restent sur le nôtre, vous êtes lié à nous pour chaque mise à jour, et cela doit être un choix conscient, pas une conséquence.

Un cas

Une application macOS sortie du noyau d’une application iPhone, sans deuxième implémentation

La situation

Nous avions un produit propre pour iPhone, qui mesure l’inclinaison de la tête par rapport à une position calibrée au début de la session. Les mêmes règles — calibration, seuils, historique, politiques de notification — avaient aussi du sens sur Mac, où la personne est de toute façon face à l’écran. La vraie question n’était pas de savoir si c’était possible, mais quelle part de la logique devait être réécrite.

Ce que nous avons construit

Zéro, parce que le noyau avait été écrit dès le départ sans connaître l’écran. La cible macOS liste 15 fichiers du projet iPhone comme sources propres, auxquels s’ajoutent 25 fichiers Swift spécifiques au desktop : la fenêtre, le menu de la barre système via un délégué AppKit, les notifications, le service d’environnement. La construction ne passe pas par l’interface Xcode : un script appelle directement le compilateur Swift avec la cible `arm64-apple-macosx14` et lie explicitement onze cadres système, puis place le paquet `.app` et le signe, et à la fin vérifie la signature.

Ce qui en est sorti

Un binaire de 6.516.128 octets pour processeurs Apple, qui démarre et reste dans la barre de menus, construit d’une seule commande. La même correction d’algorithme arrive sur le téléphone et sur Mac, parce que c’est le même fichier, et non une copie synchronisée manuellement.

Ce que le cas ne dit pas

L’application n’est pas distribuée et ne peut pas l’être, aujourd’hui, sous cette forme : la signature est ad hoc, sans identifiant d’équipe, et le champ de l’équipe de développement est vide dans la configuration du projet. Sur un autre ordinateur, elle serait bloquée par le système. C’est un problème de compte et de notarisation, pas de fonctionnalité — mais cela reste un problème non résolu et nous l’écrivons tel quel, pas comme un détail.

Questions

Ce que les gens nous demandent avant d'appeler

Pourquoi est-il écrit « offre » sur cette page, si vous dites que vous avez deux applications Mac ?

Parce que le service s’appelle « applications desktop » et couvre trois familles de systèmes, alors que nous n’en avons livré que sur une. La règle que nous nous appliquons à nous-mêmes exige au minimum deux implémentations propres, montrables dans le code, pour chaque affirmation du type « nous avons fait ». Sur macOS, nous les avons. Sur Windows et sur Linux, nous en avons zéro, et aucune des deux applications Mac n’a jamais été emballée dans un installateur distribuable. Une page qui dirait autre chose échouerait à la deuxième question d’un ingénieur.

Avez-vous une application Mac que je peux télécharger maintenant ?

Non. Elles existent toutes deux sous forme de paquets `.app` construits sur notre machine : l’une compilée pour les processeurs Apple, l’autre universelle, pour Intel et Apple. Elles sont signées ad hoc, ce qui signifie qu’elles passent la vérification locale mais n’ont pas d’identifiant d’équipe, donc sur un autre ordinateur le système les bloquerait. Ce que nous pouvons faire devant vous, c’est les lancer, ouvrir le code et le script de construction, et exécuter la suite de logique.

Quelle est, chez vous, la différence entre les deux applications Mac ?

L’une est native, l’autre est une fenêtre par-dessus le web, et la différence est grande. La native a 25 fichiers Swift propres plus 15 fichiers de noyau communs avec la version iPhone, s’accroche à la barre de menus via un délégué d’application AppKit et relie onze cadres système, parmi lesquels les capteurs de mouvement, les notifications et le traitement d’image. La seconde a trois fichiers et affiche une application web dans un `WKWebView`. La seconde se fait rapidement et c’est un bon choix quand votre application est déjà web et que vous voulez seulement une icône dans le Dock. Ce n’est pas un bon choix quand vous avez besoin du système.

Faites-vous des applications pour Windows ?

Nous n’en avons livré aucune et nous ne prétendons rien d’autre. Nous avons cherché sur nos disques toute trace — projets .NET, WPF, WinForms, WinUI, fichiers d’interface XAML, manifestes d’application, emballages MSI ou WiX — et tout ce qui apparaît appartient à une bibliothèque C tierce que nous utilisons seulement dans un autre projet. Si vous avez besoin de Windows, la première étape est une vérification de compatibilité qui se termine par un squelette qui démarre sur votre ordinateur, et ce n’est qu’après cela que nous discutons du reste.

Et pour Linux ou Ubuntu ?

Même position, avec une précision qui compte. Application avec fenêtres pour Linux : zéro livrée, aucun emballage deb ou AppImage construit par nous. Serveurs Linux : au quotidien — unités système, serveur web en façade, journaux, redémarrage en cas d’échec. Ce sont deux disciplines différentes et il serait malhonnête d’utiliser la première comme preuve de la seconde.

Pourquoi pas Electron, si c’est plus simple ainsi ?

Parce que nous n’en avons livré aucune et nous n’allons pas prétendre avoir de l’expérience là où nous n’en avons pas. Sur nos disques existent deux applications Electron fonctionnelles, mais ce sont des dépôts clonés d’autres auteurs, avec zéro contribution de notre part — nous les avons vérifiés dans l’historique des commits précisément pour qu’ils ne deviennent pas une « preuve » sur cette page. Dans un vrai projet, le choix entre un environnement web emballé et du code natif se fait après avoir su ce que l’application exige du système, quel est le poids du paquet et qui paie la maintenance, pas à la mode.

Qu’est-ce qui bloque, chez vous, la publication d’une application Mac ?

Le compte, pas le code. Dans la configuration du projet, le champ de l’équipe de développement est vide, et la signature du paquet construit est ad hoc, sans identifiant d’équipe. Pour la distribution en dehors de la boutique, macOS exige un certificat de développeur identifiable et le passage du paquet par la notarisation. Dans un projet à vous, le certificat et le compte appartiennent à votre organisation, donc ce blocage n’apparaît tout simplement pas — mais il faut le prévoir dès le départ, avec son coût et son temps.

N’est-il pas plus simple de faire un site et d’en finir ?

Souvent oui, et nous vous le disons avant que vous nous le disiez. Un site n’a pas besoin de signature, de notarisation, d’installateur, de canal de mise à jour ni d’une version pour chaque système d’exploitation. L’application installée l’emporte quand vous avez besoin de capteurs, de périphériques, de travail sans internet, de présence permanente dans la barre système ou d’accès direct aux fichiers de l’utilisateur. Si rien de tout cela n’est sur la liste, l’argent est mieux dépensé ailleurs.

Pouvez-vous reprendre une application desktop que nous avons déjà ?

Avec une condition vérifiée avant toute estimation : pouvoir la construire de zéro, sur notre machine, à partir des sources reçues. Si le build ne se reproduit pas — dépendances manquantes, certificats, étapes non écrites — alors personne ne peut estimer honnêtement quoi que ce soit, et le premier travail devient la reproduction du build, pas la nouvelle fonctionnalité. Nous le disons à l’avance, pour que cela ne soit pas découvert au milieu.

Sur quoi reposent les affirmations ci-dessus (14 sources)

14 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.

Comment nous travaillons Tous les services

Qu'est-ce que vous voudriez voir mieux fonctionner ?

Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.

Discutons