Développement Mac Natif : Pourquoi Electron Ne Suffit Pas Toujours

Chez HarborDB, nous avons pris une décision controversée au début de notre développement : nous avons construit une application macOS native en utilisant Swift et SwiftUI, au lieu d'utiliser un framework multiplateforme comme Electron (utilisé par VS Code, Slack (qui pèse lourd), Discord, etc.) ou Tauri.

Dans une ère où "écrire une fois, exécuter partout" est le mantra par défaut, choisir le natif semble être un retour en arrière. Voici notre défense technique et philosophique du développement logiciel véritablement natif en 2025.

L'Argument de la Performance : Mémoire et Threads

La Surcharge d'Electron

Chaque application Electron regroupe une instance entière de Chromium et Node.js.

• Utilisation RAM au Repos : ~150 Mo pour une fenêtre "Hello World".
• Utilisation RAM Réelle : Slack utilise souvent > 1 Go juste pour afficher du texte.
• Architecture : Chaque fenêtre est un processus de rendu séparé. La communication entre le processus principal (Node) et le rendu (UI) nécessite une sérialisation (IPC), ce qui est lent pour les gros volumes de données.

L'Avantage Natif

Une application SwiftUI partage les bibliothèques du système d'exploitation qui sont déjà chargées en mémoire.

• Utilisation RAM au Repos : ~15-30 Mo.
• Manipulation de Données : Nous pouvons passer des pointeurs mémoire directement du moteur de base de données (C++) à la couche UI (Swift) sans copier les données (Zero-Copy).

Exemple Concret : Charger 100 000 lignes dans un tableau.

• Electron : Doit sérialiser l'objet JS -> IPC -> Désérialiser dans le rendeur -> Générer le DOM. (Latence perceptible).
• Swift : Charge les structures en mémoire -> NSTableView ou List défile instantanément en ne rendant que ce qui est visible.

Intégration Système Profonde

Être une "Application Mac Adéquate" signifie plus que d'avoir la barre de menu en haut. Cela signifie supporter les fonctionnalités pour lesquelles les utilisateurs Mac paient.

1. Raccourcis Clavier et Focus

Les applications web gèrent souvent mal le focus clavier complexe. Avez-vous déjà essayé de faire tabulation hors d'un éditeur de code dans une application web ? Le système de répondeurs natif de macOS (NSResponder) gère la propagation des événements de manière prévisible et standard.

2. Le Système de Fichiers

HarborDB est un outil de base de données. Il doit lire des fichiers SQLite, des dumps SQL massifs et des exports CSV. Les navigateurs (et par extension Electron) sont "sandboxés" de manière agressive pour des raisons de sécurité. Bien qu'Electron puisse accéder au système de fichiers, l'expérience n'est jamais aussi fluide que le Framework FileCoordinator natif, qui gère :

• Le verrouillage de fichiers.
• Les mises à jour atomiques.
• La coordination avec iCloud Drive.

3. Services et Automator

Une application native expose des "Services". Vous pouvez faire un clic droit sur un fichier .db dans le Finder et voir une action personnalisée. Vous pouvez scripter l'application via AppleScript ou Raccourcis.

"Le logiciel natif respecte l'ordinateur de l'utilisateur. Il ne prétend pas être le seul programme en cours d'exécution."

L'Expérience de Développement (DX) : Swift vs Typescript

C'est là que ça devient subjectif, mais écoutez-nous.

TypeScript est incroyable. C'est le meilleur outil pour construire des UIs web. Mais l'écosystème JavaScript est fragile. Il y a 10 000 dépendances dans node_modules, des configurations webpack/vite/rollup complexes, et des changements constants.

Swift est typé fortement, compilé, et incroyablement rapide. Avec SwiftUI, la construction d'interfaces déclaratives est aussi rapide qu'avec React, mais avec :

• Une véritable sécurité de type à la compilation (pas de any).
• Des liaisons directes avec les API C++ (via Objective-C++ ou Swift C Interop).
• Des outils de profilage incroyables (Xcode Instruments) qui vous montrent exactement quelle ligne de code alloue de la mémoire ou bloque le thread principal.

Pourquoi Tout le Monde n'utilise pas le Natif ?

Si le natif est si génial, pourquoi Electron gagne-t-il ?

1. Multiplateforme : C'est la raison évidente.
2. Recrutement : Il y a 100 dév React pour 1 dév Swift/macOS.
3. Vitesse d'itération : Pousser une mise à jour web est instantané ; pousser une mise à jour d'application native nécessite une validation de l'App Store ou des mises à jour Sparkle.

Notre Pari

Nous parions qu'il y a un marché pour la qualité logicielle artisanale. Les utilisateurs professionnels sont fatigués des applications lentes qui ne ressemblent pas à des applications. Ils sont fatigués de voir leur batterie se vider parce que leur application de chat mine du crypto (blague, mais à peine).

HarborDB est rapide. Il s'ouvre en 200ms. Il fait défiler 1 million de lignes à 120 FPS. Il respecte vos raccourcis clavier.

C'est peut-être la vieille école, mais pour nous, c'est le futur de la productivité professionnelle.