Docs

Playground

GitHub

DocsDesenvolvimento

Roadmap do projeto

Editar esta página

9 min de leitura

Sincronizado com o ROADMAP.md do repositório principal (a fonte da verdade). Esta página lista o que está pela frente; o que o produto já faz está documentado nas páginas de produto.

Trilho web

•

Estado global (signals, contexto).

•

Benchmarks de tempo de hidratação e verificação do tree-shaking, o resto do pilar de performance: o runtime servido e o frame do Photon já têm orçamentos que falham no CI.

•

Eventos do servidor, as próximas fatias: um Server Action que transmite (IAsyncEnumerable<T>), presença, replay a partir do id do último evento, um transporte WebSocket, um pacote de backplane Redis e a realização no Photon. Os tópicos tipados sobre um stream por página estão em Eventos do servidor.

•

API Navigator programática e tipada para navegação no cliente (o roteador em si está completo, e guiado por links).

Trilho nativo (Photon)

•

Decodificação de imagens no shell Android (o Apple já decodifica pelo CoreGraphicsImageLoader em texturas RGBA8).

Trilho de componentes

•

Extensões variáveis de item no ListView (medição incremental); a v1 é vertical com extensão fixa.

•

Planilha: rolagem 2D (folhas largas), motor de fórmulas, formatação por célula, mesclas, painéis congelados, tudo fora do escopo da v1.

•

Renderização de texto marcado inline nas superfícies de código durante a composição por IME.

Trilho D: as capacidades de um telefone em C#

Uma capacidade é um serviço: um contrato no vocabulário, uma declaração como builder.Capabilities.UseCamera("why") que o SDK escreve no Info.plist e no manifesto do Android, uma realização por shell, e null onde o host não tem nenhuma (Capacidades). Esse modelo está de pé; o que vem pela frente é o resto do que um telefone oferece. Medido contra o que as plataformas oferecem hoje a quem desenvolve (355 capacidades no iOS 26 e 27, e 323 no Android 16 e 17 com Jetpack e Play services, 129 delas de IA), metade do iOS e 60% do Android já estão vinculados pelos workloads do .NET e só precisam de um contrato.

•

Os contratos que não precisam de ponte: a câmera no Android, deep links nos telefones, abrir um link, compartilhar, notificações, um seletor de documentos, informações do aparelho e de energia, a câmera completa, códigos de barras, rostos e texto, salvar na biblioteca, contatos, som, os outros sensores e háptica. Quatro declarações que escrevem uma permissão que nenhuma API usa ainda voltam junto com a API que as usa.

•

A ponte: conectores Swift que o SDK compila num framework, e conectores Kotlin num .aar, os dois entregues dentro dos pacotes do próprio SDK. A sua máquina não precisa de nada novo, e nada vem do MAUI.

•

IA no aparelho e agentes: um contrato sobre os Foundation Models da Apple e o Gemini Nano; fala, tradução e ferramentas de texto; App Intents e AppFunctions a partir de uma declaração em C#; superfícies da Tela de Início e da Tela Bloqueada, Live Activities e Live Updates alimentadas pelo C#.

•

Manutenção: chegar à API 37 do Android 17 a partir do .NET 10, toda capacidade rodada em aparelhos físicos, e o catálogo de plataforma atualizado depois de cada WWDC e de cada Google I/O.

•

Cerca, com a razão: o que o sistema desenha em outro processo (WidgetKit, a Dynamic Island, Glance) e o que só existe em tempo de compilação (App Intents, @Generable, KSP, Compose) não roda C#; o plano nomeia a rota de cada um.

Trilho F: fatores de forma (tablet, relógio, TV)

Um fator de forma não é um segundo projeto aqui: o mesmo C# já roda em macOS, iOS e Android a partir de um único equantic-native. O que muda é o SHELL em cada largura, e o que um aparelho faz que um telefone não faz.

Tablet já funciona. O WindowSizeClass (Compact <600dp, Medium 600-839, Expanded ≥840) e o AdaptiveNode são realizados nos dois alvos, e o NavigationRail completou o vocabulário: uma lista de NavItem, uma barra embaixo no telefone e uma rail na borda inicial do tablet; o ListDetail é o padrão de duas colunas como componente (o primeiro adaptativo do catálogo).

•

Shells prontos nos templates, entregues: `dotnet new equantic-native --shell blank|tabs|drawer| list-detail (e --shell blank|topnav|dashboard` no template web), parâmetro de ESCOLHA nos dois templates que já existem, em vez de um template por formato; todo formato é adaptativo.

•

Wear OS: safe area redonda, uma classe de tamanho abaixo de Compact (um relógio tem ~200dp), entrada rotativa da coroa ou do bezel, swipe-to-dismiss. Cerca: Tiles e Complications não são Activities, então o write-once cobre o app do relógio e não o tile.

•

Android TV: a peça central, navegação por foco com as setas, existe desde o passe de teclado; o que falta é o manifesto leanback, uma safe area de overscan, a escala de tipo de 10 pés e um anel de foco legível a três metros.

•

Fora de escopo, com a razão: o Android Auto/AAOS obriga o app a montar os templates aprovados da Google em vez de desenhar o que quer, o oposto deste motor. XR fica na mesma prateleira.

Trilho W: Photon no desktop

As cercas entre o Photon de hoje e uma plataforma de app desktop publicável, cada uma verificada no código: sem paths arbitrários no engine (nove comandos SDF/textura, e o nono, FillAnnularSector, saiu na 0.2.0-preview.45), um IClock deliberadamente periódico cuja própria cerca nomeia o relógio de frames como a coisa por construir, hit-testing só por retângulo, sem superfície de shell desktop (menus, tray, diálogos de ficheiro, notificações, deep links), assinatura ad-hoc que quebra os grants de TCC do macOS a cada build, e uma janela por processo.

O que encolhe o trabalho, achado na mesma varredura: um canal de tempo determinístico já corre pelo layout nativo (TransitionStore), o driver de 120 Hz e os gradientes radiais de 2 stops existem, e a toolchain de shaders resolve-se sozinha, e a primeira forma do engine, o setor anular, está FEITA: um SDF exato com paridade Reference↔Metal↔Vulkan, provado por um consumidor real num sunburst de 5,38 milhões de ficheiros.

Sete workstreams: formas no engine (o setor saiu; a decisão polígono-vs-textura espera o benchmark do blob do consumidor), relógio de frames + animação + um dispatcher de UI, um nó de desenho custom com eventos de ponteiro em coordenadas locais, a superfície de shell do macOS, empacotamento de verdade (assinatura, notarização, bundle a partir do publish, um updater mínimo, sequenciado primeiro; o bundle ad hoc já se reconstrói do payload, allowlista RIDs e falha o build numa assinatura má, veja Photon), o loop do desenvolvedor (correr no simulador/emulador com um comando, perfis de IDE, redeploy ao salvar), e os shells Windows/Linux que continuam pós-M5. Nasceu de uma migração real de app (um produto desktop em Electron), e cada peça é genérica: o primeiro consumidor constrói contra o SDK a partir de pacotes LOCAIS (veja Fluxo de build) e renderiza byte-idêntico por pacotes e por source. Plano completo: docs/DESKTOP-PLAN.md no repositório principal.

Trilho M: renderização de email

Escreva um e-mail em C# com os mesmos componentes com que uma página é escrita, e receba HTML que um cliente de e-mail realmente renderiza. E-mail é um terceiro realizer ao lado da web e do Photon: um alvo cujo motor é apenas muito restritivo, que é a mesma forma arquitetural de um alvo sem DOM.

Saiu na 0.2.0-preview.45: eQuantic.UI.Email, tabelas aninhadas com células espaçadoras para os gaps, estilos inline, cores literais, guarda de URL absoluta, shell de 600px, gêmeo em texto puro a partir da mesma árvore, e recusas em tempo de build para tudo que um e-mail não consegue fazer. À frente: a matriz de clientes reais (um sample gerado contra Gmail, Outlook e Apple Mail) e os pins de HTML quando a saída assentar. O design e as cercas estão em Renderização de e-mail.

Trilho I: inteligência de editor (CodeEditor)

O framework publica um editor de código de verdade (modelo de documento, seleção, histórico, realce, casamento de parênteses, busca, rabiscos) e ele hoje não consegue ajudar você a escrever. A metade que falta é a inteligência, e a peça que a torna possível está provada: o Roslyn responde completações semânticas sobre a mesma compilação que a página constrói (provado no playground, que compila o C# dos visitantes com o eqc de verdade) (context. oferece Theme; Col oferece Column, porque a superfície using static faz parte daquela compilação).

•

I1, o modelo de completação em Primitives, ao lado do CodeEditorController: itens, seleção, o span que um commit substitui, abrir/filtrar/mover/aceitar/dispensar. Write-once, testável sem tela.

•

I2, as teclas e a lista em Components: a lista é posicionada no cursor a partir das métricas que o editor já calcula (ContentTop, LineHeight, ContentLeft, ColumnWidth), do jeito que a barra de busca já flutua sobre o código.

•

I3, ajuda de assinatura: o painel de parâmetros no (, sobre o encanamento do I1 e o posicionamento do I2.

O problema real é latência, não completações: buscar num gatilho (. ou Ctrl+Space), filtrar localmente enquanto a digitação continua, cancelar requisições velhas. Diagnósticos ao vivo, rabiscos enquanto se digita, são a mesma forma.

Trilho E: a extensão "eQuantic UI" para VS Code

Um editor visual de primeira parte sobre o próprio SDK: preview de tela ao vivo (o realizador web DE VERDADE numa webview), clique para selecionar no visualizador, um painel de propriedades que edita o código C# por rewrites do Roslyn, até a edição visual completa. Marcos E1 (preview ao vivo) → E4 (edição completa).

Correção (2026-08-14): os source maps V3 não conseguem carregar a seleção. O corpo inteiro do Build é emitido por uma única chamada, então a posição mais fina que um mapa consegue nomear é o início do método, e um módulo publicado tem uma linha de 942 caracteres. A identidade vem, em vez disso, de um VisualNode.Origin neutro de alvo carimbado por uma emissão em modo de design, que é exato em vez de correlacionado, e que o track nativo herda de graça.

O E1 (preview ao vivo do buffer não salvo), o E2 (clique para selecionar e pular para o código), o E3 (o painel de propriedades) e a metade estrutural do E4 (inserir, mover, remover) já saíram. Veja Editor visual.

Diretrizes permanentes

•

Zero dependências de terceiros onde a plataforma fornece a capacidade (frameworks do sistema, toolchains embarcadas, o modelo Bun/slangc).

•

Falhar alto: qualquer coisa que o SDK não consiga realizar fielmente é erro de build, nunca divergência silenciosa.

•

Tudo pinado: conformidade diferencialmente, estilos por cross-pins idênticos byte a byte, pixels por goldens, hidratação por identidade de classe (e2e).

ANTERIORDepuração

PRÓXIMAAtualizar de versão

NESTA PÁGINA