Synchron mit ROADMAP.md im Haupt-Repository (der Quelle der Wahrheit). Diese Seite listet, was vor uns liegt; was das Produkt schon tut, ist auf den Produktseiten dokumentiert.

Web-Spur

•

Globaler Zustand (Signale, Kontext).

•

Benchmarks zur Hydrationszeit und Verifikation des Tree-Shakings, der Rest der Performance-Säule: Die ausgelieferte Runtime und der Photon-Frame haben schon Budgets, die in der CI scheitern.

•

Server-Events, die nächsten Scheiben: eine Server Action, die streamt (IAsyncEnumerable<T>), Präsenz, Wiederholung ab der Id des letzten Events, ein WebSocket-Transport, ein Redis-Backplane-Paket und die Realisierung auf Photon. Typisierte Topics über einen Strom je Seite stehen auf Server-Events.

•

Typisierte programmatische Navigator-API für die clientseitige Navigation (der Router selbst ist vollständig und linkgetrieben).

Native Spur (Photon)

•

Bilddekodierung auf der Android-Shell (Apple dekodiert heute über CoreGraphicsImageLoader in RGBA8-Texturen).

Komponenten-Spur

•

Variable Elementausdehnungen in der ListView (inkrementelles Messen); die v1 ist vertikal mit fester Ausdehnung.

•

Spreadsheet: 2D-Scrollen (breite Blätter), Formel-Engine, Formatierung je Zelle, Verbünde, fixierte Bereiche, alles außerhalb des Umfangs der v1.

•

Rendern von markiertem Text inline in den Code-Flächen während der IME-Komposition.

Track D: die Fähigkeiten eines Telefons in C#

Eine Fähigkeit ist ein Dienst: ein Kontrakt im Vokabular, eine Deklaration wie builder.Capabilities.UseCamera("why"), die das SDK in die Info.plist und das Android-Manifest schreibt, eine Realisierung je Shell, und null dort, wo ein Host keine hat (Fähigkeiten). Dieses Modell steht; was vor uns liegt, ist der Rest dessen, was ein Telefon anbietet. Gemessen an dem, was die Plattformen einer Entwicklerin heute anbieten (355 Fähigkeiten auf iOS 26 und 27 und 323 auf Android 16 und 17 mit Jetpack und den Play-Diensten, 129 davon KI), sind die Hälfte von iOS und 60% von Android schon von den .NET-Workloads gebunden und brauchen nur einen Kontrakt.

•

Die Kontrakte, die keine Brücke brauchen: die Kamera auf Android, Deep Links auf den Telefonen, einen Link öffnen, Teilen, Benachrichtigungen, eine Dokumentauswahl, Geräte- und Energieinformationen, die vollständige Kamera, Barcodes, Gesichter und Text, in die Galerie speichern, Kontakte, Ton, die anderen Sensoren und Haptik. Vier Deklarationen, die eine Berechtigung schreiben, die noch keine API nutzt, kommen mit der API zurück, die sie nutzt.

•

Die Brücke: Swift-Konnektoren, die das SDK zu einem Framework kompiliert, und Kotlin-Konnektoren zu einer .aar, beide in den eigenen Paketen des SDK ausgeliefert. Ihre Maschine braucht nichts Neues, und nichts kommt von MAUI.

•

KI und Agenten auf dem Gerät: ein Kontrakt über Apples Foundation Models und Gemini Nano; Sprache, Übersetzung und Textwerkzeuge; App Intents und AppFunctions aus einer C#-Deklaration; Flächen auf Start- und Sperrbildschirm, Live Activities und Live Updates, aus C# gefüttert.

•

Pflege: die API 37 von Android 17 aus .NET 10 erreichen, jede Fähigkeit auf physischen Geräten ausführen, und den Plattformkatalog nach jeder WWDC und Google I/O auffrischen.

•

Zaun, mit dem Grund: Was das System in einem anderen Prozess zeichnet (WidgetKit, die Dynamic Island, Glance) und was nur zur Kompilierzeit existiert (App Intents, @Generable, KSP, Compose), kann kein C# ausführen; der Plan benennt für jedes den Weg.

Track F: Formfaktoren (Tablet, Uhr, TV)

Ein Formfaktor ist hier kein zweites Projekt: Dasselbe C# läuft aus einem einzigen equantic-native schon auf macOS, iOS und Android. Was sich unterscheidet, ist die SHELL bei einer gegebenen Breite, und was ein Gerät kann, was ein Telefon nicht kann.

Tablet funktioniert schon. WindowSizeClass (Compact <600dp, Medium 600-839, Expanded ≥840) und AdaptiveNode sind auf beiden Zielen realisiert, und NavigationRail hat das Vokabular vervollständigt: eine NavItem-Liste, eine Leiste unter einem Telefon und eine Schiene am Anfangsrand eines Tablets; ListDetail ist das Zweibereichsmuster als Komponente (die erste adaptive im Katalog).

•

Vorgebaute Shells in den Vorlagen, ausgeliefert: `dotnet new equantic-native --shell blank|tabs|drawer| list-detail (und --shell blank|topnav|dashboard` auf der Web-Vorlage), ein WAHL-Parameter auf den zwei bestehenden Vorlagen statt einer Vorlage je Form; jede Form ist adaptiv.

•

Wear OS: runder Safe-Bereich, eine Größenklasse unter Compact (eine Uhr hat etwa 200dp), Dreheingabe von der Krone oder der Lünette, Wischen zum Verwerfen. Zaun: Tiles und Complications sind keine Activities, Write-once deckt also die Uhren-App und nicht das Tile.

•

Android TV: Das zentrale Stück, die Fokusnavigation mit den Pfeiltasten, existiert seit dem Tastaturdurchgang; was fehlt, ist das Leanback-Manifest, ein Safe-Bereich gegen Overscan, die Typskala für drei Meter Abstand und ein Fokusring, der aus drei Metern lesbar ist.

•

Außerhalb des Umfangs, mit dem Grund: Android Auto und AAOS lassen die Anwendung Googles genehmigte Vorlagen zusammensetzen, statt zu zeichnen, was sie will, das Gegenteil dieser Engine. XR steht im selben Regal.

Track W: Photon auf dem Desktop

Die Zäune zwischen dem heutigen Photon und einer auslieferbaren Plattform für Desktop-Anwendungen, jeder im Code verifiziert: keine beliebigen Pfade in der Engine (neun SDF-/Textur-Befehle, und der neunte, FillAnnularSector, kam in 0.2.0-preview.45), eine absichtlich periodische IClock, deren eigener Zaun die Frame-Uhr als das noch nicht Gebaute benennt, Hit-Testing nur mit Rechtecken, keine Desktop-Shell-Fläche (Menüs, Taskleiste, Dateidialoge, Benachrichtigungen, Deep Links), die Ad-hoc-Signierung, die bei jedem Build die TCC-Freigaben von macOS bricht, und ein Fenster je Prozess.

Was die Arbeit kleiner macht, im selben Durchgang gefunden: Ein deterministischer Zeitkanal läuft schon durch das native Layout (TransitionStore), der 120-Hz-Treiber und radiale Gradienten mit zwei Stops existieren, und die Shader-Toolchain löst sich selbst auf, und die erste Form der Engine, der Ringsektor, ist FERTIG: ein exaktes SDF mit Reference↔Metal↔Vulkan-Parität, bei einem Konsumenten an einem echten Sunburst mit 5,38 Millionen Dateien bewiesen.

Sieben Arbeitsströme: die Formen der Engine (der Sektor ist raus; die Entscheidung Polygon gegen Textur wartet auf den Blob-Benchmark des Konsumenten), die Frame-Uhr + Animation + ein UI-Dispatcher, ein eigener Zeichenknoten mit Zeiger-Events in lokalen Koordinaten, die macOS-Shell-Fläche, echtes Paketieren (Signierung, Notarisierung, auf dem Publish beruhende Bundles, ein minimaler Updater, zuerst in der Reihe; das Ad-hoc-Bundle baut sich schon aus dem Payload neu, setzt RIDs auf eine Erlaubnisliste und lässt den Build bei einer schlechten Signatur scheitern, siehe Photon), die Entwicklungsschleife (Simulator-/Emulator-Läufe mit einem Befehl, IDE-Profile, erneutes Ausliefern beim Speichern), und die Windows- und Linux-Shells, die nach M5 bleiben. Aus einer echten Anwendungsmigration geboren (ein Desktop-Produkt in Electron), und jedes Stück ist allgemein: Der erste Konsument baut gegen das SDK aus LOKALEN Paketen (siehe Build-Ablauf) und rendert aus den Paketen und aus dem Quellcode byte-identisch.

Vollständiger Plan: docs/DESKTOP-PLAN.md im Haupt-Repository.

Track M: E-Mail-Rendering

Schreiben Sie eine E-Mail in C# mit denselben Komponenten wie eine Seite, und bekommen Sie HTML, das ein E-Mail-Client tatsächlich rendern wird. E-Mail ist ein dritter Realisierer neben Web und Photon: ein Ziel, dessen Engine bloß sehr restriktiv ist, was dieselbe architektonische Form hat wie ein Ziel ohne DOM.

Ausgeliefert in 0.2.0-preview.45: eQuantic.UI.Email, mit geschachtelten Tabellen und Abstandszellen für die Gaps, Inline-Styles, wörtlichen Farben, einer Wache für absolute URLs, einer 600px-Hülle, einem Zwilling in reinem Text aus demselben Baum und Ablehnungen zur Build-Zeit für alles, was eine E-Mail nicht kann. Vor uns: die Matrix echter Clients (ein erzeugtes Beispiel gegen Gmail, Outlook und Apple Mail) und die HTML-Pins, sobald die Ausgabe sich setzt. Entwurf und Zäune stehen auf E-Mail-Rendering.

Track I: Intelligenz im Editor (CodeEditor)

Das Framework liefert einen echten Code-Editor aus (Dokumentmodell, Auswahl, Historie, Highlighting, Klammerpaarung, Suche, Schlängellinien), und er kann Ihnen beim Schreiben noch nicht helfen. Die fehlende Hälfte ist die Intelligenz, und das Stück, das sie möglich macht, ist bewiesen: Roslyn beantwortet semantische Vervollständigungen über derselben Compilation, die die Seite baut (im Playground bewiesen, der das C# der Besucher mit dem echten eqc kompiliert) (context. bietet Theme; Col bietet Column, weil die using static-Oberfläche Teil dieser Compilation ist).

•

I1, das Vervollständigungsmodell in Primitives, neben CodeEditorController: die Einträge, die Auswahl, die Spanne, die ein Commit ersetzt, öffnen/filtern/bewegen/annehmen/verwerfen. Write-once, kopflos testbar.

•

I2, die Tasten und die Liste in Components: Die Liste wird am Caret aus den Metriken platziert, die der Editor schon berechnet (ContentTop, LineHeight, ContentLeft, ColumnWidth), so wie die Suchleiste schon über dem Code schwebt.

•

I3, Signaturhilfe: das Parameterpanel bei (, auf der Verrohrung von I1 und der Platzierung von I2.

Das echte Problem ist die Latenz, nicht die Vervollständigungen: bei einem Auslöser holen (. oder Strg+Leertaste), lokal filtern, während weiter getippt wird, veraltete Anfragen abbrechen. Lebende Diagnosen, Schlängellinien beim Tippen, haben dieselbe Form.

Track E: die VS-Code-Erweiterung "eQuantic UI"

Ein hauseigener visueller Editor auf dem SDK selbst: lebende Bildschirmvorschau (der ECHTE Web-Realisierer in einer Webview), Klicken zum Auswählen im Betrachter, ein Eigenschaftenpanel, das den C#-Quellcode über Roslyn-Rewrites bearbeitet, bis hin zur vollständigen visuellen Bearbeitung. Meilensteine E1 (lebende Vorschau) bis E4 (vollständige Bearbeitung).

Korrektur (2026-08-14): Die V3-Source-Maps können die Auswahl nicht tragen. Der ganze Build-Körper wird über einen einzigen Aufruf ausgegeben, die feinste Position, die eine Map nennen kann, ist also der Anfang der Methode, und ein ausgeliefertes Modul hat eine Zeile mit 942 Zeichen. Die Identität kommt stattdessen aus einem zielneutralen VisualNode.Origin, von einer Ausgabe im Entwurfsmodus eingestempelt, die exakt statt korreliert ist und die die native Spur umsonst erbt.

E1 (lebende Vorschau des nicht gespeicherten Puffers), E2 (Klicken zum Auswählen und Sprung zum Quellcode), E3 (das Eigenschaftenpanel) und die strukturelle Hälfte von E4 (einfügen, bewegen, entfernen) sind gelandet. Siehe Visueller Editor.

Dauerhafte Direktiven

•

Null Fremdabhängigkeiten, wo die Plattform die Fähigkeit bereitstellt (Systemframeworks, eingebettete Toolchains, das Bun-/slangc-Modell).

•

Laut scheitern: Alles, was das SDK nicht treu realisieren kann, ist ein Build-Fehler, nie eine stille Abweichung.

•

Alles gepinnt: die Konformität differenziell, die Styles durch byte-identische Kreuz-Pins, die Pixel durch Goldens, die Hydration durch Klassenidentität (e2e).

PREVIOUSLottie

ON THIS PAGE