Sincronizado con ROADMAP.md en el repositorio principal (la fuente de verdad). Esta página lista lo que está por delante; lo que el producto ya hace está documentado en las páginas de producto.

Vía web

•

Estado global (señales, contexto).

•

Benchmarks en el momento de la hidratación y verificación del tree-shaking, el resto del pilar de rendimiento: el runtime servido y el frame de Photon ya tienen presupuestos que fallan en CI.

•

Eventos de servidor, las siguientes porciones: una Server Action que hace streaming (IAsyncEnumerable<T>), la presencia, el replay desde el id del último evento, un transporte por WebSocket, un paquete de backplane con Redis y la realización en Photon. Los topics tipados sobre un solo stream por página están en Eventos del servidor.

•

API Navigator programática y tipada para la navegación en el cliente (el router mismo está completo, y es conducido por enlaces).

Vía nativa (Photon)

•

Decodificación de imágenes en el shell de Android (Apple decodifica hoy a través de CoreGraphicsImageLoader hacia texturas RGBA8).

Vía de componentes

•

Extensiones de elemento variables en el ListView (medición incremental); la v1 es vertical con extensión fija.

•

Spreadsheet: scroll en 2D (hojas anchas), motor de fórmulas, formato por celda, combinaciones, paneles congelados, todo fuera del alcance de la v1.

•

Renderizado de texto marcado en línea en las superficies de código durante la composición con IME.

Track D: las capacidades de un teléfono en C#

Una capacidad es un servicio: un contrato en el vocabulario, una declaración como builder.Capabilities.UseCamera("why") que el SDK escribe en el Info.plist y en el manifest de Android, una realización por shell, y null donde un host no la tiene (Capacidades). Ese modelo está en su sitio; lo que queda por delante es el resto de lo que ofrece un teléfono. Medido contra lo que las plataformas ofrecen hoy a quien programa (355 capacidades en iOS 26 y 27, y 323 en Android 16 y 17 con Jetpack y los servicios de Play, 129 de ellas de IA), la mitad de iOS y el 60% de Android ya están enlazados por los workloads de .NET y solo necesitan un contrato.

•

Los contratos que no necesitan puente: la cámara en Android, los deep links en los teléfonos, abrir un enlace, compartir, las notificaciones, un selector de documentos, la información de dispositivo y de energía, la cámara completa, los códigos de barras, las caras y el texto, guardar en la galería, los contactos, el sonido, los otros sensores y la háptica. Cuatro declaraciones que escriben un permiso que todavía ninguna API usa vuelven con la API que las usa.

•

El puente: conectores en Swift que el SDK compila en un framework, y conectores en Kotlin en un .aar, los dos entregados dentro de los propios paquetes del SDK. Tu máquina no necesita nada nuevo, y nada viene de MAUI.

•

IA y agentes en el dispositivo: un contrato sobre los Foundation Models de Apple y Gemini Nano; habla, traducción y herramientas de texto; App Intents y AppFunctions desde una declaración en C#; superficies de pantalla de inicio y de bloqueo, Live Activities y Live Updates alimentadas desde C#.

•

Mantenimiento: llegar a la API 37 de Android 17 desde .NET 10, cada capacidad ejecutada en dispositivos físicos, y el catálogo de la plataforma refrescado después de cada WWDC y Google I/O.

•

Valla, con la razón: lo que el sistema dibuja en otro proceso (WidgetKit, la Dynamic Island, Glance) y lo que existe solo en tiempo de compilación (App Intents, @Generable, KSP, Compose) no puede ejecutar C#; el plan nombra la ruta de cada uno.

Track F: factores de forma (tableta, reloj, TV)

Un factor de forma no es un segundo proyecto aquí: el mismo C# ya corre en macOS, iOS y Android desde un solo equantic-native. Lo que difiere es el SHELL a un ancho dado, y lo que un dispositivo puede hacer y un teléfono no.

La tableta ya funciona. WindowSizeClass (Compact <600dp, Medium 600-839, Expanded ≥840) y AdaptiveNode están realizados en los dos destinos, y NavigationRail completó el vocabulario: una lista de NavItem, una barra bajo un teléfono y un raíl por el borde inicial de una tableta; ListDetail es el patrón de dos paneles como componente (el primero adaptativo del catálogo).

•

Shells prefabricados en las plantillas, entregados: `dotnet new equantic-native --shell blank|tabs|drawer| list-detail (y --shell blank|topnav|dashboard` en la plantilla web), un parámetro de ELECCIÓN en las dos plantillas existentes en lugar de una plantilla por forma; cada forma es adaptativa.

•

Wear OS: área segura redonda, una clase de tamaño por debajo de Compact (un reloj tiene unos 200dp), entrada rotatoria desde la corona o el bisel, swipe para descartar. Valla: los Tiles y las Complications no son Activities, así que el write-once cubre la aplicación del reloj y no el tile.

•

Android TV: la pieza central, la navegación de foco con las flechas, existe desde la pasada del teclado; lo que falta es el manifest de leanback, un área segura contra el overscan, la escala tipográfica de 10 pies y un anillo de foco legible a tres metros.

•

Fuera de alcance, con la razón: Android Auto y AAOS hacen que la aplicación ensamble las plantillas aprobadas de Google en lugar de dibujar lo que quiere, lo contrario de este motor. La XR está en el mismo estante.

Track W: Photon en el escritorio

Las vallas entre el Photon de hoy y una plataforma de aplicaciones de escritorio entregable, cada una verificada en el código: ningún path arbitrario en el motor (nueve comandos SDF/textura, y el noveno, FillAnnularSector, salió en la 0.2.0-preview.45), un IClock deliberadamente periódico cuya propia valla nombra el reloj de frames como lo que todavía no está construido, hit-testing solo rectangular, ninguna superficie de shell de escritorio (menús, bandeja, diálogos de archivo, notificaciones, deep links), la firma ad-hoc que rompe las concesiones de TCC de macOS en cada build, y una ventana por proceso.

Lo que encoge el trabajo, encontrado en el mismo barrido: un canal de tiempo determinista ya corre a través del layout nativo (TransitionStore), el driver de 120 Hz y los degradados radiales de dos paradas existen, y la toolchain de shaders se resuelve sola, y la primera forma del motor, el sector anular, está HECHA: un SDF exacto con paridad Reference↔Metal↔Vulkan, probada con un consumidor en un sunburst real de 5,38 millones de archivos.

Siete workstreams: las formas del motor (el sector salió; la decisión entre polígono y textura espera el benchmark de blobs del consumidor), el reloj de frames + la animación + un dispatcher de UI, un nodo de dibujo personalizado con eventos de puntero en coordenadas locales, la superficie de shell de macOS, el empaquetado real (firma, notarización, bundles basados en publish, un updater mínimo, secuenciado primero; el bundle ad-hoc ya se reconstruye desde el payload, pone los RIDs en lista de permitidos y hace fallar el build con una firma mala, vea Photon), el ciclo de desarrollo (ejecuciones en simulador y emulador con un comando, perfiles de IDE, redespliegue al guardar), y los shells de Windows y Linux que quedan después de M5. Nacido de una migración de aplicación real (un producto de escritorio en Electron), y cada pieza es genérica: el primer consumidor compila contra el SDK desde paquetes LOCALES (vea Flujo de build) y renderiza byte a byte igual desde los paquetes y desde el código.

Plan completo: docs/DESKTOP-PLAN.md en el repositorio principal.

Track M: renderizado de email

Escribe un email en C# con los mismos componentes con los que se escribe una página, y recibe HTML que un cliente de email va a renderizar de verdad. El email es un tercer realizador al lado de la web y de Photon: un destino cuyo motor es simplemente muy restrictivo, lo que tiene la misma forma arquitectónica que un destino sin DOM.

Entregado en la 0.2.0-preview.45: eQuantic.UI.Email, con tablas anidadas y celdas espaciadoras para los gaps, estilos inline, colores literales, una guarda de URL absoluta, una casca de 600px, un gemelo en texto puro desde el mismo árbol, y rechazos en tiempo de build para todo lo que un email no puede hacer. Por delante: la matriz de clientes reales (un ejemplo generado contra Gmail, Outlook y Apple Mail) y los pins de HTML una vez que la salida se asiente. El diseño y las vallas están en Renderizado de email.

Track I: inteligencia del editor (CodeEditor)

El framework entrega un editor de código de verdad (modelo de documento, selección, historial, resaltado, emparejado de llaves, buscar, subrayados ondulados) y hoy no puede ayudarte a escribir. La mitad que falta es la inteligencia, y la pieza que la hace posible está probada: Roslyn responde completados semánticos sobre la misma compilación que construye la página (probado en el playground, que compila el C# de quien lo visita con el eqc de verdad) (context. ofrece Theme; Col ofrece Column, porque la superficie de using static es parte de esa compilación).

•

I1, el modelo de completado en Primitives, al lado de CodeEditorController: los items, la selección, el span que reemplaza un commit, abrir/filtrar/mover/aceptar/descartar. Write-once, testeable sin interfaz.

•

I2, las teclas y la lista en Components: la lista se coloca en el caret a partir de las métricas que el editor ya computa (ContentTop, LineHeight, ContentLeft, ColumnWidth), igual que la barra de buscar ya flota sobre el código.

•

I3, ayuda de firma: el panel de parámetros en (, sobre la plomería de I1 y la colocación de I2.

El problema real es la latencia, no los completados: descargar en un disparador (. o Ctrl+Espacio), filtrar localmente mientras se sigue escribiendo, cancelar las peticiones viejas. Los diagnósticos en vivo, los subrayados mientras escribes, son la misma forma.

Track E: la extensión "eQuantic UI" de VS Code

Un editor visual de primera parte sobre el propio SDK: vista previa de la pantalla en vivo (el realizador web DE VERDAD en un webview), clic para seleccionar en el visor, un panel de propiedades que edita el código C# a través de rewrites de Roslyn, hasta la edición visual completa. Hitos de E1 (vista previa en vivo) a E4 (edición completa).

Corrección (2026-08-14): los source maps V3 no pueden llevar la selección. Todo el cuerpo de Build se emite a través de una única llamada, así que la posición más fina que un mapa puede nombrar es el inicio del método, y un módulo ya entregado tiene una línea de 942 caracteres. La identidad viene en su lugar de un VisualNode.Origin neutral respecto al destino, estampado por una emisión en modo diseño, que es exacta en lugar de correlacionada, y que la vía nativa hereda gratis.

E1 (vista previa en vivo del buffer sin guardar), E2 (clic para seleccionar y salto al código), E3 (el panel de propiedades) y la mitad estructural de E4 (insertar, mover, quitar) ya aterrizaron. Vea Editor visual.

Directivas permanentes

•

Cero dependencias de terceros siempre que la plataforma provea la capacidad (frameworks del sistema, toolchains embebidas, el modelo de Bun y slangc).

•

Fallar ruidosamente: todo lo que el SDK no puede realizar fielmente es un error de build, nunca una divergencia silenciosa.

•

Todo fijado: la conformidad de forma diferencial, los estilos por cross-pins idénticos byte a byte, los píxeles por goldens, la hidratación por identidad de clase (e2e).

PREVIOUSLottie

ON THIS PAGE