Synchronisée avec ROADMAP.md dans le dépôt principal (la source de vérité). Cette page liste ce qui est devant ; ce que le produit fait déjà est documenté sur les pages de produit.

Voie web

•

État global (signaux, contexte).

•

Benchmarks au moment de l'hydratation et vérification du tree-shaking, le reste du pilier performance : le runtime servi et la frame Photon ont déjà des budgets qui échouent en CI.

•

Événements serveur, les tranches suivantes : une Server Action qui diffuse en flux (IAsyncEnumerable<T>), la présence, le rejeu depuis l'id du dernier événement, un transport WebSocket, un paquet de backplane Redis et la réalisation sur Photon. Les topics typés sur un seul flux par page sont sur Événements serveur.

•

API Navigator programmatique et typée pour la navigation côté client (le routeur lui-même est complet, et piloté par les liens).

Voie native (Photon)

•

Décodage d'images sur le shell Android (Apple décode aujourd'hui via CoreGraphicsImageLoader vers des textures RGBA8).

Voie des composants

•

Étendues d'éléments variables dans le ListView (mesure incrémentale) ; la v1 est verticale à étendue fixe.

•

Spreadsheet : défilement 2D (feuilles larges), moteur de formules, mise en forme par cellule, fusions, volets figés, tout hors du périmètre de la v1.

•

Rendu du texte marqué en ligne dans les surfaces de code pendant la composition IME.

Track D : les capacités d'un téléphone en C#

Une capacité est un service : un contrat dans le vocabulaire, une déclaration comme builder.Capabilities.UseCamera("why") que le SDK écrit dans l'Info.plist et le manifeste Android, une réalisation par shell, et null là où un hôte n'en a pas (Capacités). Ce modèle est en place ; ce qui est devant, c'est le reste de ce qu'un téléphone offre. Mesuré contre ce que les plateformes offrent aujourd'hui à qui développe (355 capacités sur iOS 26 et 27, et 323 sur Android 16 et 17 avec Jetpack et les services Play, dont 129 d'IA), la moitié d'iOS et 60% d'Android sont déjà liés par les workloads .NET et n'ont besoin que d'un contrat.

•

Les contrats qui n'ont pas besoin de pont : la caméra sur Android, les liens profonds sur les téléphones, ouvrir un lien, partager, les notifications, un sélecteur de documents, les informations d'appareil et d'énergie, la caméra complète, les codes-barres, les visages et le texte, enregistrer dans la galerie, les contacts, le son, les autres capteurs et l'haptique. Quatre déclarations qui écrivent une permission qu'aucune API n'utilise encore reviennent avec l'API qui les utilise.

•

Le pont : des connecteurs Swift que le SDK compile en un framework, et des connecteurs Kotlin en un .aar, livrés tous deux dans les paquets propres au SDK. Votre machine n'a besoin de rien de neuf, et rien ne vient de MAUI.

•

IA et agents sur l'appareil : un contrat au-dessus des Foundation Models d'Apple et de Gemini Nano ; parole, traduction et outils de texte ; App Intents et AppFunctions depuis une déclaration C# ; surfaces d'écran d'accueil et de verrouillage, Live Activities et Live Updates alimentées depuis le C#.

•

Entretien : atteindre l'API 37 d'Android 17 depuis .NET 10, chaque capacité exécutée sur des appareils physiques, et le catalogue des plateformes rafraîchi après chaque WWDC et Google I/O.

•

Limite, avec la raison : ce que le système dessine dans un autre processus (WidgetKit, la Dynamic Island, Glance) et ce qui n'existe qu'à la compilation (App Intents, @Generable, KSP, Compose) ne peut pas exécuter du C# ; le plan nomme la route de chacun.

Track F : facteurs de forme (tablette, montre, TV)

Un facteur de forme n'est pas un second projet ici : le même C# tourne déjà sur macOS, iOS et Android depuis un seul equantic-native. Ce qui diffère, c'est le SHELL à une largeur donnée, et ce qu'un appareil peut faire et qu'un téléphone ne peut pas.

La tablette marche déjà. WindowSizeClass (Compact <600dp, Medium 600-839, Expanded ≥840) et AdaptiveNode sont réalisés sur les deux cibles, et NavigationRail a complété le vocabulaire : une liste de NavItem, une barre sous un téléphone et un rail le long du bord initial d'une tablette ; ListDetail est le motif à deux volets sous forme de composant (le premier adaptatif du catalogue).

•

Shells préfabriqués dans les modèles, livrés : `dotnet new equantic-native --shell blank|tabs|drawer| list-detail (et --shell blank|topnav|dashboard` sur le modèle web), un paramètre de CHOIX sur les deux modèles existants plutôt qu'un modèle par forme ; chaque forme est adaptative.

•

Wear OS : zone sûre ronde, une classe de taille sous Compact (une montre fait environ 200dp), entrée rotative depuis la couronne ou la lunette, balayage pour fermer. Limite : les Tiles et les Complications ne sont pas des Activities, donc le write-once couvre l'application de la montre et pas la tuile.

•

Android TV : la pièce centrale, la navigation du focus aux flèches, existe depuis la passe clavier ; ce qui manque, c'est le manifeste leanback, une zone sûre contre l'overscan, l'échelle typographique de trois mètres et un anneau de focus lisible à trois mètres.

•

Hors périmètre, avec la raison : Android Auto et AAOS font que l'application assemble les modèles approuvés de Google au lieu de dessiner ce qu'elle veut, l'inverse de ce moteur. La XR est sur la même étagère.

Track W : Photon sur le bureau

Les limites entre le Photon d'aujourd'hui et une plateforme d'applications de bureau livrable, chacune vérifiée dans le code : aucun chemin arbitraire dans le moteur (neuf commandes SDF/texture, et la neuvième, FillAnnularSector, est sortie en 0.2.0-preview.45), une IClock délibérément périodique dont la propre limite nomme l'horloge de frames comme la chose encore à construire, un hit-testing uniquement rectangulaire, aucune surface de shell de bureau (menus, barre d'état, dialogues de fichiers, notifications, liens profonds), la signature ad-hoc qui casse les octrois TCC de macOS à chaque build, et une fenêtre par processus.

Ce qui réduit le travail, trouvé dans le même balayage : un canal de temps déterministe traverse déjà le layout natif (TransitionStore), le pilote 120 Hz et les dégradés radiaux à deux arrêts existent, et la toolchain de shaders se résout elle-même, et la première forme du moteur, le secteur annulaire, est FAITE : un SDF exact avec la parité Reference↔Metal↔Vulkan, éprouvée chez un consommateur sur un sunburst réel de 5,38 millions de fichiers.

Sept chantiers : les formes du moteur (le secteur est sorti ; la décision polygone contre texture attend le benchmark de blobs du consommateur), l'horloge de frames + l'animation + un dispatcher d'UI, un nœud de dessin personnalisé avec des événements de pointeur en coordonnées locales, la surface de shell macOS, l'empaquetage réel (signature, notarisation, bundles fondés sur le publish, un updater minimal, séquencé en premier ; le bundle ad-hoc se reconstruit déjà depuis le payload, met les RID en liste blanche et fait échouer le build sur une mauvaise signature, voir Photon), la boucle de développement (lancements simulateur/émulateur en une commande, profils d'IDE, redéploiement à la sauvegarde), et les shells Windows et Linux qui restent après M5. Né d'une vraie migration d'application (un produit de bureau en Electron), et chaque pièce est générique : le premier consommateur compile contre le SDK depuis des paquets LOCAUX (voir Flux de build) et rend de façon identique octet pour octet depuis les paquets et depuis les sources.

Plan complet : docs/DESKTOP-PLAN.md dans le dépôt principal.

Track M : rendu des e-mails

Écrivez un e-mail en C# avec les mêmes composants qu'une page, et récupérez du HTML qu'un client de messagerie va réellement rendre. L'e-mail est un troisième réalisateur à côté du web et de Photon : une cible dont le moteur est simplement très restrictif, ce qui a la même forme architecturale qu'une cible sans DOM.

Livré en 0.2.0-preview.45 : eQuantic.UI.Email, avec des tables imbriquées et des cellules d'espacement pour les gaps, des styles en ligne, des couleurs littérales, une garde d'URL absolue, une coque de 600px, un jumeau en texte brut depuis le même arbre, et des refus au build pour tout ce qu'un e-mail ne peut pas faire. Devant nous : la matrice de clients réels (un exemple généré face à Gmail, Outlook et Apple Mail) et les pins HTML une fois la sortie stabilisée. La conception et les limites sont sur Rendu des e-mails.

Track I : intelligence de l'éditeur (CodeEditor)

Le framework livre un vrai éditeur de code (modèle de document, sélection, historique, coloration, appariement des accolades, recherche, soulignements ondulés) et il ne peut pas encore vous aider à écrire. La moitié qui manque, c'est l'intelligence, et la pièce qui la rend possible est éprouvée : Roslyn répond des complétions sémantiques au-dessus de la même compilation que la page construit (éprouvé dans le playground, qui compile le C# des visiteurs avec le vrai eqc) (context. propose Theme ; Col propose Column, parce que la surface du using static fait partie de cette compilation).

•

I1, le modèle de complétion dans Primitives, à côté de CodeEditorController : les éléments, la sélection, la portée qu'un commit remplace, ouvrir/filtrer/déplacer/accepter/rejeter. Write-once, testable sans interface.

•

I2, les touches et la liste dans Components : la liste est placée au caret depuis les métriques que l'éditeur calcule déjà (ContentTop, LineHeight, ContentLeft, ColumnWidth), comme la barre de recherche flotte déjà au-dessus du code.

•

I3, l'aide de signature : le panneau de paramètres sur (, sur la plomberie d'I1 et le placement d'I2.

Le vrai problème est la latence, pas les complétions : récupérer sur un déclencheur (. ou Ctrl+Espace), filtrer localement pendant que la frappe continue, annuler les requêtes périmées. Les diagnostics vivants, les soulignements pendant que vous tapez, ont la même forme.

Track E : l'extension VS Code "eQuantic UI"

Un éditeur visuel de première partie sur le SDK lui-même : aperçu de l'écran en direct (le VRAI réalisateur web dans une webview), clic pour sélectionner dans la visionneuse, un panneau de propriétés qui modifie la source C# par des rewrites Roslyn, jusqu'à l'édition visuelle complète. Jalons d'E1 (aperçu en direct) à E4 (édition complète).

Correction (2026-08-14) : les source maps V3 ne peuvent pas porter la sélection. Tout le corps de Build est émis par un seul appel, donc la position la plus fine qu'une map peut nommer est le début de la méthode, et un module déjà livré a une ligne de 942 caractères. L'identité vient plutôt d'un VisualNode.Origin neutre vis-à-vis de la cible, estampillé par une émission en mode conception, qui est exacte plutôt que corrélée, et que la voie native hérite gratuitement.

E1 (aperçu en direct du buffer non enregistré), E2 (clic pour sélectionner et saut vers la source), E3 (le panneau de propriétés) et la moitié structurelle d'E4 (insérer, déplacer, retirer) ont atterri. Voir Éditeur visuel.

Directives permanentes

•

Zéro dépendance tierce partout où la plateforme fournit la capacité (frameworks système, toolchains embarquées, le modèle Bun/slangc).

•

Échouer bruyamment : tout ce que le SDK ne peut pas réaliser fidèlement est une erreur de build, jamais une divergence silencieuse.

•

Tout épinglé : la conformité de façon différentielle, les styles par cross-pins identiques octet pour octet, les pixels par goldens, l'hydratation par identité de classe (e2e).

PREVIOUSLottie

ON THIS PAGE