Skip to main content
ExodeUI

EXODEUI DESKTOP

A little space for good ideas.

Choose your platform to get the official ExodeUI installer.

Looking for Intel Mac or other builds? Explore the web studio or check all download options.

Prefer the browser? Try for free in your browser →
Multi-Platform UI8 min læst·Updated oktober 2026·Af ExodeUI-teamet

Design én gang, kør overalt: Én UI-fil på tværs af internettet, iOS og Android

Hvad det virkelig kræver at designe én gang og køre en brugergrænseflade på web, iOS og Android: delt layout og bevægelse, platformspecifikke dele, test og hvor ExodeUI passer.

Direkte Resumé & Definition

Core Takeaway

Design én gang, kør overalt betyder, at én kildefil beskriver en UI-komponent, og hver platform afspiller den med en runtime i stedet for at genopbygge den samme bevægelse i React, SwiftUI og Flutter. Det fungerer, når layout, tilstande, bevægelser og input findes i den delte fil, og det forbliver ærligt, når navigation, tilgængelighed og systembevægelser forbliver platformspecifikke. ExodeUI understøtter denne model med runtime-pakker til React, Vue, Svelte, Angular, Solid, React Native, SwiftUI og Flutter.

Hvad "design én gang, løb overalt" faktisk kræver

Det kræver mere end en eksportknap. Den delte fil skal beskrive, hvordan komponenten lægger sig ud i forskellige størrelser, hvordan den ser ud i hver tilstand, hvordan den bevæger sig mellem tilstande, og hvordan appen driver den med input. Hver platform har også brug for en runtime, der kan afspille filen og forbinde disse input til virkelige begivenheder. Hvis nogen af ​​disse brikker mangler, bliver løftet til endnu en overdragelse.

Delt fil versus genopbygning pr-platform

Den traditionelle rute er at designe én gang og genopbygge tre gange: web i CSS og JavaScript, iOS i SwiftUI og Android i Kotlin eller Flutter. Hver genopbygning introducerer små forskelle i timing, afstand og gestushåndtering. En delt filrute holder komponentdefinitionen på ét sted og lader hver platform afspille den. Afvejningen er, at en runtime sidder mellem filen og platformen, så du opgiver en vis direkte kontrol over platformsspecifik gengivelse.

Hvad skal forblive platformsspecifikt

En delt komponent bør ikke foregive, at hver platform er ens. Navigationsmønstre, tilbagebevægelser, systemdialoger, tilladelser og tilgængeligheds-API'er er forskellige. Den delte fil bør eje den interaktive visuelle komponent; værtsappen skal eje platformens chrome og de semantiske kontroller omkring den. For eksempel kan en delt animeret knap sidde inde i et indbygget knapelement, der afslører den rigtige rolle og etiket.

Sådan fungerer køretider

En runtime læser filen, bygger det visuelle træ og opdaterer det, efterhånden som input ændres. Din applikationskode indstiller input, såsom trykket, deaktiveret eller indlæsning, og lytter efter begivenheder, såsom bekræft eller afvis. Fordi den visuelle definition er data snarere end håndskrevet kode pr. platform, er kørselstiden det, der gør den samme fil bærbar. Kørselstiden er også en afhængighed, så mål dens effekt på din egen build i stedet for at antage, at den er gratis.

Tester den samme fil i alle miljøer

Test filen, hvor den vil køre, ikke kun i editoren. Tjek layoutet ved de mindste og største understøttede størrelser, bekræft hver stat med ægte indhold, og test berørings-, mus- og tastaturinput separat. Tjek derefter tilgængelighed: fokusrækkefølge, etiketter, reduceret bevægelse og skærmlæseradfærd. En delt fil reducerer visuel drift, men det fjerner ikke behovet for at teste hver platform.

Hvor ExodeUI passer

ExodeUI gemmer en komponent i en åben .exode-fil og leverer runtime-pakker til React, Vue, Svelte, Angular, Solid, React Native, SwiftUI og Flutter. Filen kan omfatte layout og brudpunkter, tidslinjer, tilstandsmaskiner, forårsfysik, input og begivenheder. Den samme fil kan redigeres i browser- eller desktopeditoren, og AI-kodningsværktøjer kan arbejde på den via MCP-serveren.

Hvornår skal man ikke bruge én delt fil

En delt fil passer dårligt, når grænsefladen i høj grad afhænger af platform-kun API'er, når du har brug for kontrol på pixelniveau over native rendering, eller når komponenten for det meste er en video- eller 3D-scene. Det er også en dårlig pasform, hvis dit hold ikke kan teste hvert mål. I disse tilfælde er platformsspecifik kode det ærlige valg, og en delt fil bør kun dække de dele, der virkelig har gavn af den.

Snippet til produktionsimplementering

Interaktiv komponentimplementering
import { ExodeUICanvas } from 'exodeui';

// The same component file can be played by the runtime your app already uses.
// Web, React Native, SwiftUI and Flutter packages read the same .exode source.
export function ShareSheet({ open, progress, onClose }) {
  return (
    <ExodeUICanvas
      src="/share_sheet.exode"
      inputs={{ open, progress }}
      onTrigger={(name) => name === 'close' && onClose()}
    />
  );
}

Tast Principles for at huske

  • Design én gang og kør overalt kræver delt layout, tilstande, bevægelse og input, plus en runtime pr. platform
  • Navigation, tilladelser og tilgængeligheds-API'er bør forblive platformspecifikke
  • En runtime er en afhængighed; måle dens effekt på din opbygning
  • Test hvert mål for layout, input, bevægelse og tilgængelighed
  • ExodeUI giver køretider for React, Vue, Svelte, Angular, Solid, React Native, SwiftUI og Flutter

Ofte stillede spørgsmål

Relaterede vejledninger og eksempler

Design interaktiv UI én gang. Lever den samme fil.

Byg tilstande, fjederfysik og logik visuelt i ExodeUI, og afspil den samme fil i React, SwiftUI, Flutter og mere. Kom gratis i gang.

Prøv gratis