RFC: NativeScript Edge — previews on NativeScript's own infrastructure, for phones and, for the first time, desktops

[NathanWalker]

RFC: NativeScript Edge — previews on NativeScript's own infrastructure, for phones and, for the first time, desktops

Status	Proposed. Running in production at preview.nativescript.org/p/ with a free tier; packages on npm under @nativescript/edge-*
Try it	npx @nativescript/edge-cli live (phone), live --desktop (Mac or Windows), live --electron, live --expo
Implementation	Edge, CLI and hosts: nstudio/ns-cloudflare (to move to the NativeScript org, see Unresolved questions) · Preview 3.0: preview#38 · ns live: nativescript-cli#6184
Runtimes	runtimes#102, #103, #104 (macOS Node-API), #105 (@nativescript/react-native on react-native-macos), #112 (on react-native-windows), windows#46 (merged)
Prompted by	nativescript-website#100: two long-standing nativescript.org examples lost to a vendor's storage migration
Related	rfcs#61 (Windows support)

Summary

Today, trying NativeScript without installing anything means a StackBlitz project that runs @nativescript/preview-cli in a WebContainer, builds a webpack bundle in the browser, and relays it to the NativeScript Preview app through a session worker. Every link on nativescript.org, every "Try it" button and every docs snack depends on that chain, and on StackBlitz keeping each saved project intact.

This RFC proposes that NativeScript own the preview loop end to end:

npx @nativescript/edge-cli live               # phone: scan the QR code with NativeScript Preview
npx @nativescript/edge-cli live --ng          # or --react, --vue, --svelte, --solid
npx @nativescript/edge-cli live --desktop     # a native macOS or Windows app, on this Mac or PC
npx @nativescript/edge-cli live --electron    # Electron with native AppKit or WinUI views
npx @nativescript/edge-cli live --expo        # Expo Desktop (React Native for macOS/Windows) with NativeScript's native APIs

1. A project is an address. Its source lives in a Durable Object on NativeScript's Cloudflare account, at preview.nativescript.org/p/<id>. Phones and desktop hosts load its ES modules over HTTP and hot-reload as people, or an AI agent, edit.
2. One loop, every kind of app. The same project model, IDE, CLI and agent serve iOS and Android through NativeScript Preview, and macOS and Windows desktop apps through small host packages, with the desktop window streamed live into the browser IDE. Desktop previews are new to NativeScript; Linux is the next host this design makes room for.
3. Nothing in the chain belongs to someone else's product roadmap. The protocol, the server, the client library and the hosts are Apache-2.0 packages under @nativescript/. The server is one package; everything else speaks a small open protocol to whatever server it's pointed at.
4. Existing StackBlitz links keep working. Preview 3.0 runs classic StackBlitz sessions unchanged, and the IDE has an Open in StackBlitz button. StackBlitz becomes one optional editor rather than the place our examples live.

Motivation

We lost two examples we didn't own

The Angular and Svelte "Try it on StackBlitz" links on nativescript.org opened saved projects (nativescript-battery-example-angular and -svelte) that had been there for years. StackBlitz moved both to new storage, and the files didn't survive the migration. The owner couldn't restore them: saving returned 409 Conflict and the editor crashed. nativescript-website#100 points the links at GitHub-backed branches instead (stackblitz-examples#3), which fixes the symptom.

The cause is structural. Our front door depends on:

• a vendor's storage for the example source, which can be migrated, reset or retired without notice;
• a vendor's in-browser runtime for builds. @nativescript/stackblitz installs @nativescript/preview-cli@latest on every boot, and the templates resolve their dependencies fresh, so they drift. Today the Vue template fails to build against current webpack, the Angular template resolves an @nativescript/angular that needs core 9 while pinning core 8.9, and XML apps on core ≤ 8.7 render blank on Android under webpack 5.112. None of these are bugs in NativeScript, and none can be fixed from the Preview app;
• a session worker with memory-only files and a 10-minute timeout, so a shared preview is a live session, not something you can link to next month.

When any piece breaks, the first thing a new developer sees is a blank editor or a blank phone.

What changed

NativeScript 9.1 made the runtime a standards-based ES module host. The loader fetches https:// modules, keys its registry on canonical URLs, takes import maps, evicts entries with ns:module's invalidateModules(), and release builds can allow remote modules from an allowlist. A prebuilt NativeScript app can now run code it has never seen, served as plain ES modules by any HTTP server, with full synchronous access to every native API.

Cloudflare made compute addressable per entity. A Durable Object gives one project a single-threaded home with SQLite and hibernating WebSockets, so an idle project costs nothing and a saved one stays saved. Dynamic Workers start isolates from code strings, so a project can carry its own backend.

Together, a NativeScript app's code doesn't have to live on a laptop or in a browser tab. It can live at an address, and phones, desktops, editors and agents are all peers of that address.

Why it matters beyond fixing examples

• Desktop, for the first time. NativeScript now has a macOS runtime (@nativescript/macos-node-api) and a Windows runtime (@nativescript/windows-napi, rfcs#61). Until now there was no way to show someone a NativeScript desktop app without them cloning, installing and building it. With this, a link opens it, in the browser, streamed from a real Mac or PC, and live --desktop runs it locally with hot reload.
• New audiences, on their own terms. Electron developers get native AppKit and WinUI views beside their web UI (electron#52915 and #12437 have working demos linked from this). React Native and Expo developers get NativeScript's direct native API access on macOS and Windows through @nativescript/react-native. Each is one command, without adopting the NativeScript CLI first.
• AI agents need a real device in the loop. Every project is an MCP server and a tools API: screenshot, viewTree, runOnDevice (JavaScript with full native API access on the device), readDeviceLogs. Claude Code, Cursor or the IDE's own agent can write NativeScript and check it on a real screen. The agent is required to confirm each change in a screenshot, so it can't claim success it didn't see.
• Examples become durable, forkable, and runnable everywhere. A project link without its write key opens read-only, with its run command and Fork to Edit. Named samples (live --from expo-settings, gallery at /p/samples) never expire once approved, and their source is also kept in git.

Guide-level explanation

Phones

npx @nativescript/edge-cli live

From an empty folder: creates a project, opens the browser IDE, and prints a QR code. Scanning it opens the project in NativeScript Preview 3.0 (iOS TestFlight build 13; Android on the Play testing track), which shows the app with no chrome over it. Every save hot-reloads it. ns live in the NativeScript CLI forwards to the same command (nativescript-cli#6184).

Frameworks: TypeScript/XML by default, --ng, --react, --vue, --svelte, --solid. Preview loads each framework on demand.

Desktops

npx @nativescript/edge-cli live --desktop     # --mac and --windows are aliases

On an Apple Silicon Mac (macOS 14.4+) or a Windows 10 1903+ / Windows 11 PC, with Node 22.15+. The template is one settings window built twice from shared logic: app/macos.ts with AppKit, app/windows.ts with Windows.UI.Xaml, chosen at run time. The window opens on your machine and streams into the IDE's Device pane, where anyone with the IDE open can click and type into it.

// app/main.ts: the host calls this on boot and after every hot update
export default async function open() {
  const ui = process.platform === 'win32' ? await import('./windows') : await import('./macos');
  return ui.open(); // returns the function that closes its windows
}

// app/macos.ts: AppKit, straight from TypeScript
const win = NSWindow.alloc().initWithContentRectStyleMaskBackingDefer(
  { origin: { x: 0, y: 0 }, size: { width: 600, height: 380 } },
  NSWindowStyleMask.Titled | NSWindowStyleMask.Closable | NSWindowStyleMask.Resizable,
  NSBackingStoreType.Buffered,
  false,
);
win.title = 'My App';

// app/windows.ts: Windows.UI.Xaml through XAML Islands
const win = new XamlWindow({ title: 'My App', theme: 'dark' });
const root = Windows.UI.Xaml.Markup.XamlReader.Load(LAYOUT);
const notifications = root.FindName('Notifications');
notifications.Toggled = () => (settings.notifications = notifications.IsOn);

The IDE and the agent

The IDE at /p/<id>/ is a VS Code-style workbench: Monaco with per-project types (core, every iOS, Android or macOS framework, Node, Electron, the project's framework), Problems, device output, a live device mirror with its view tree, and the agent docked on the right. The agent has a few free turns a day on the hosted model; people can add their own Anthropic or OpenAI key (kept in their browser and never stored), or connect any MCP client.

Your own editor

npx @nativescript/edge-cli pull     # download the project
npx @nativescript/edge-cli watch    # sync your editor's saves to it

Or mirror from a Vite dev server with the CLI's Vite plugin. The project's keys live in .ns-edge.json in the folder.

Sharing

• IDE link (/p/<id>/#key=<writeKey>): edit.
• Device link (/p/<id>#<deviceKey>): run. Opened in a browser, it shows the project read-only with its run command and Fork to Edit.
• Samples: submit a project under a name (edge-cli submit <name>, or Submit as a Sample… in the IDE). Once reviewed, live --from <name> and /p/<name> reach it for good.

Reference-level details

Architecture

            ┌──────────────── preview.nativescript.org/p/ (Cloudflare) ──────────────┐
 browser IDE│ Worker router ─► Project Durable Object (one per project)             │
 CLI / Vite │   │  colo cache   • SQLite file system + module graph                 │
 MCP clients│   │  (immutable   • TS → ESM transform (Hermes CommonJS for Expo)     │
            │   │   ?v= URLs)   • publish gate: only graphs that parse and resolve  │
            │   │               • hibernating WebSockets: devices + editors         │
            │   │               • agent + tools ─► device RPC                       │
            │   ├─► StreamRelay DO: desktop window frames to viewers                │
            │   └─► /api/* ─► Dynamic Worker (the project's server/ code)          │
            └──────────────────────────────▲────────────────────────────────────────┘
                     GET /m/app/x.ts?v=…   │  ws: hello → boot / update / rpc
        ┌───────────────────┬──────────────┴─────┬──────────────────────┐
   NativeScript Preview  edge-desktop        edge-electron        edge-expo-desktop
   (iOS, Android)        (macOS, Windows)    (macOS, Windows)     (macOS, Windows)

Design decisions

• A lean device protocol, not Vite's HMR protocol: hello → boot / update / rpc. Devices pull modules over HTTP; the socket never carries source. Any server or host that speaks it interoperates.
• Content-addressed module URLs. A module's ?v= hashes its source and its imports' versions (cycles hash as one unit). An edit re-versions only that module and its importers, so hot reload is just import(newEntryUrl): the runtime's own registry skips everything unchanged, and untouched modules keep their state. Versioned responses are immutable and cached at each Cloudflare location, so fifty phones on one project cost one transform per change.
• A publish gate. Edits land in a working copy; devices get a new version only when the module graph parses and resolves. Broken code never reaches a phone, and devices that join later boot the last good version.
• A capability manifest. On connect, a device declares the packages linked into its binary. The edge generates re-export shims from that list, so remote code shares the binary's single @nativescript/core, and an import the binary can't satisfy fails at the edge with a readable error instead of a native crash.
• Three capabilities, 128-bit each. The project id reads published modules; the device key joins as a device; the write key edits, runs tools and chats. Socket keys are checked in the router before the upgrade and again in the Durable Object. Device sockets never reach the agent's chat, and device-reported strings are sanitized before the agent sees them.
• Origin hygiene. Project backends and web/ pages are CSP-sandboxed and aren't served for free projects at all; raw files are text/plain with nosniff.
• Platform mismatch is explicit. A device on the wrong platform for a project's template boots a module that explains why, and never joins.

Measured

	Result
Hot update, iOS simulator / Android emulator, one push	re-rendered in 43 ms / 27 ms (device-side, local server)
Edit to a leaf module	only it and its importers re-version; a sibling's state survives
live --mac from an empty folder, production	first render 259 ms after the host started
live --electron, production	first render 2.4 s, streaming at 25 fps
live --expo, production	v0 in 1.6 s, an edit in 431 ms
Cost per user, Cloudflare side	pennies; the hosted agent is the real cost, capped daily

Store policy

Preview runs downloaded code, which App Review allows for educational apps (guideline 2.5.2), and its store listing shows only its own UI with learning-focused copy. Its release build allows remote modules only from https://preview.nativescript.org/p/. The development shell in the repo refuses remote modules in release builds and is never submitted to a store. Nothing here is a way to update a store app's features over the air.

Free tier

Projects created without a token are free: up to 30 per network a day, 20 hosted agent turns per project a day (a global daily cap bounds total model spend), no server/ backend or web/ pages, and deletion after 30 days unused. Turns made with a person's own model key don't count. Accounts (GitHub sign-in, a per-account allowance, then an optional paid plan for backends and non-expiring projects) are designed but not built.

The packages

Every package is Apache-2.0 under @nativescript/edge-*. Only edge-cloudflare depends on where it's hosted.

Package	What it is	Why NativeScript needs it
@nativescript/edge-protocol	Wire types shared by the server, clients, hosts and IDE	The contract. Anyone can write a server (another cloud, an on-prem box, a laptop) or a host (Linux, a new device class) against it without forking anything
@nativescript/edge-cloudflare	The Worker: project Durable Object (files, transform, module graph, publish gate, hot-update hub), router, browser IDE, agent, MCP server, stream relay, samples registry, free-tier quotas	NativeScript's own home for live projects and examples, replacing the session worker and the StackBlitz dependency for new work
@nativescript/edge-shell	Embeds the edge client in any NativeScript 9.1 app: module loading, hot updates, logs, device RPC (EdgeClient, pairing links with consent)	Preview 3.0 is built on it. Teams can also build their own development client with their own native plugins, the way Expo development builds work, which answers "Preview doesn't have my plugin"
@nativescript/edge-cli	live, create, pull, watch, push, qr, samples, submit, --from, and a Vite plugin	The one command that works from an empty folder with nothing installed but Node. ns live forwards to it
@nativescript/edge-desktop	A Node host that runs macos-template projects with AppKit on a Mac or Windows.UI.Xaml on Windows, captures the project's window (ScreenCaptureKit / RenderTargetBitmap) and takes input from the IDE	The first way to preview a NativeScript desktop app, and a daily real-world workload for both desktop runtimes
@nativescript/edge-electron	An Electron host: the project's main process with the NativeScript runtime loaded, web UI in BrowserWindows, native views above it (Liquid Glass on a Mac, a WinUI overlay on Windows)	Brings NativeScript's native access to Electron developers, who today write C++ addons for the same thing
@nativescript/edge-expo-desktop (+ -win32-x64)	A prebuilt Expo Desktop shell (react-native-macos, react-native-windows, Hermes) with @nativescript/react-native linked	Brings NativeScript's native APIs to React Native and Expo developers on desktop, through worklets, without leaving their stack

It also depends on, and has driven fixes into, NativeScript's runtimes:

Runtime	Role	Work it produced
NativeScript 9.1 iOS/Android	ES module loader with https:// imports, import maps, invalidateModules, remote-module allowlists	The foundation; the phone side needed no runtime changes
@nativescript/macos-node-api	AppKit and every macOS framework from Node	runtimes#102 (native callbacks from a host-owned run loop, needed by Electron), #103 (off-thread callbacks without deadlocks, interop.releaseNativeObject), #104 (metadata targets the SDK, not macOS 11, so SCStream and NSGlassEffectView exist)
@nativescript/windows-napi	WinRT and Windows.UI.Xaml from Node	windows#46 (Node-API from host modules, merged); two bugs to report (GUID marshalling, XAML islands after the last one closes)
@nativescript/react-native	NativeScript's native APIs inside React Native worklets	runtimes#105 (react-native-macos), #112 (react-native-windows)

Linux

Linux isn't built yet, and the design is ready for it. A Linux host needs:

1. A NativeScript runtime for a Linux UI toolkit. GTK through GObject Introspection is the natural analog of Objective-C metadata on Apple platforms and WinRT metadata on Windows: generated, complete, typed.
2. A HostPlatform implementation in edge-desktop (device info, window bookkeeping, capture, input). The Mac and Windows ones show its shape.

Nothing else changes: the protocol, the server, the stream relay, the IDE and the agent are platform-neutral. A Linux runtime would get a preview loop, a browser IDE and an agent on its first day.

Drawbacks

• Cloudflare is also a vendor. The difference is in what we'd lose. NativeScript owns the account, the domain and the data; projects export with pull; samples live in git; the server is one package behind an open protocol, so another host is a sibling package rather than a rewrite. StackBlitz's case was the opposite on every count.
• A service to run. Deploys, quotas, abuse handling and the agent's model spend become NativeScript's responsibility. The Cloudflare side costs pennies per user; the hosted agent is capped daily and falls back to people's own keys.
• Two preview paths for a while. Classic StackBlitz sessions and edge projects coexist in Preview 3.0. Bug reports need to say which.
• Preview's plugin catalog is smaller today. Preview 2 shipped about 80 plugins. Preview 3.0 links the docs snacks' plugins plus core ones, and @nativescript/mlkit-* 3.0.4 crashing iOS at launch blocks the in-app QR scanner and the rest of the catalog. Custom development clients through edge-shell are the long-term answer.
• Arbitrary npm packages. Edge projects import what the host binary links. Pure-JS npm dependencies need a bundling step at the edge (planned with Cloudflare Sandboxes); classic sessions remain the path for projects that need them now.
• Gaps: no source maps for remote modules yet; .ios.ts/.android.ts qualifiers aren't resolved yet; desktop streams are JPEG (H.264 is blocked on a VideoToolbox callback deadlock); press-and-hold input isn't possible yet.

Alternatives considered

Alternative	Why not
Keep StackBlitz as the home for examples, backed by GitHub branches (website#100)	The right immediate fix, and it stays. But builds still run in a vendor's runtime with drifting dependencies, sessions still expire, and desktop apps can't run in a WebContainer at all
Improve Preview 2's session worker	It's built around whole webpack bundles uploaded file by file into memory. Per-module pulls, persisted projects, hibernation, immutable caching and real host–device authentication each mean replacing it
Use Vite's HMR protocol to devices	Built for browsers on the same machine, with the dev server doing the work per client. Content-addressed URLs make a CDN do it, and the device needs no HMR client at all
Desktop previews by screen-sharing a remote Mac	Costly per session, and it previews the machine, not the app. Hosts capture only the project's window and inject input into only that app, with no Accessibility permission
A self-hosted server only	Loses the free, zero-install front door that replaces StackBlitz links. The protocol keeps self-hosting possible for anyone who wants it

Adoption plan

1. Move the repository into the NativeScript org and open it, with the packages' npm ownership under the org.
2. Preview 3.0 to the stores (preview#38) once the @nativescript/mlkit-* iOS launch crash is fixed and the QR scanner is back.
3. Merge ns live (nativescript-cli#6184), deciding between following @latest and pinning a version.
4. Port the nativescript.org and docs examples to named samples, one per framework, kept in git and published to the edge. Keep the GitHub-backed StackBlitz links from website#100 beside them as an "edit on StackBlitz" option.
5. Merge the runtime PRs (runtimes#102–#105, #112) and publish runtimes the hosts can pin instead of locally built betas.
6. Accounts (GitHub sign-in, per-account allowance), then decide whether a paid plan is wanted.
7. Next hosts: a standalone desktop host that joins from a link alone, simulators and emulators streamed through the same relay (live --ios, --android), and Linux once a runtime exists.

Unresolved questions

1. Where it lives. One repository (NativeScript/edge?) for the server, CLI and hosts, or split the shell and protocol into their own?
2. Ownership. Who reviews edge PRs, approves production deploys and publishes the packages? Who reviews sample submissions?
3. Examples policy. Should nativescript.org link edge samples first, StackBlitz first, or both side by side?
4. The hosted agent. Keep a small free allowance on a hosted model (today Workers AI), require people's own keys, or seek a sponsor for it?
5. Preview's plugin catalog. Which plugins must Preview 3.0 link before it replaces Preview 2 in the stores, and should we publish a documented recipe for custom development clients built on edge-shell?
6. Linux. Is there appetite for a GTK runtime, and should it target Node-API like the macOS and Windows desktop runtimes?
7. Store builds. The design deliberately stops at development. Is there interest in the release-side ideas it enables (content-addressed release graphs, review notes drafted from the module and native-symbol diff), or should those stay out of scope?

[ammarahm-ed]

My little analysis of this with the help of AI:

The problem is already solved. We lost two examples, and website#100 fixes that by backing the StackBlitz links with GitHub. Edge solves a much bigger problem than the one we actually had.

What StackBlitz gives us that Edge doesn't:

Someone else runs it. Uptime, security, abuse, scaling and cost are StackBlitz's problem. With Edge, every one of those becomes NativeScript's problem, and the RFC doesn't say who owns them.

It works like a real project. It uses real npm packages, a real build, and the same toolchain people use locally. Edge runs remote ES modules with no bundler and no npm, so it teaches a workflow that new users won't use when they build an actual app.
It's mature and familiar. Developers already know it, and it doesn't depend on a Preview 3.0 that hasn't shipped and carries a much smaller plugin catalog.

It's low-risk for us. It doesn't execute remote native code on users' phones or desktops under our name.

What Edge adds in exchange:

A permanent service for a small team to operate. That means deploys, quotas, abuse handling, model spend, incident response and support, with an unclear owner and a single point of failure in whoever maintains it.

A large security and liability surface. Remote code execution on devices, an AI agent with native access, desktop hosts with full user privileges, and anonymous hosting under nativescript.org.

Fragmentation. Two preview paths, two development models, and a second CLI entry point. Bug reports and docs both get harder.
Vendor risk moves rather than disappears. We swap a dependency on StackBlitz for a deep dependency on Cloudflare-specific services, and now we operate it ourselves too.

Store risk to Preview. Remote agent control and paid tiers make the App Store education exception harder to defend.

My view: the GitHub-backed StackBlitz links fix the actual problem at almost no ongoing cost. Edge may have value as an experiment or as a separate nstudio product, but adopting it as NativeScript's official front door commits the project to running a service with real security and maintenance costs. The RFC doesn't show that we can sustain that, or that we need to.

[NathanWalker]

@ammarahm-ed thank you for taking the time to go through this and write it up. I really appreciate the feedback, and this is the pushback the RFC needs.

Some of it lands and should change the plan. Some of it compares Edge against a StackBlitz setup that is cheaper and safer than the one we actually run, and it leaves out the parts StackBlitz can't do at all. It's also early: the RFC describes a working foundation, not the finished product, and several of the gaps you list are ones the production-ready form closes. Taking each in turn.

Where you're right

• Ownership is unanswered. It's Unresolved question 2, and "who deploys, who gets paged, who reviews samples, who handles a takedown" should have names before anything on nativescript.org points at Edge. A runbook exists (deploy, one-command rollback, quotas as config), but a runbook isn't an owner, and one maintainer is a bus factor of one.
• No arbitrary npm yet. Today, Edge projects import what the host binary links. That's a real limit for "bring my existing app", and it's why classic sessions stay. It's a limit of this stage rather than of the design (more below).
• Preview 3.0 hasn't shipped and links fewer plugins. Nothing should move until it's in the stores with the catalog back. That's steps 2 and 5 of the adoption plan, and I'd make it a hard gate.
• Two paths cost something in docs and bug triage.
• A paid tier needs a store-policy check before it's built. It's designed, not built, and it can stay that way.

Where the comparison is off

"Someone else runs it." Only the editor and the in-browser build. NativeScript already operates the rest of that chain: the session worker at preview.nativescript.org (Cloudflare Workers and Durable Objects, on our account), @nativescript/preview-cli, @nativescript/stackblitz, seven template branches, and the Preview app. So Cloudflare isn't a new vendor, and "we run a service" is already true. What we don't control is the part that broke: when StackBlitz lost the two projects, their owner couldn't restore them.

"It doesn't execute remote code on users' phones under our name." Preview 2 does exactly that today: it downloads a bundle from our session worker and runs it with full native access, in an app published by NativeScript. Edge narrows that surface rather than opening it: Preview's release build loads modules only from https://preview.nativescript.org/p/, a link from outside the app needs consent, joining needs a 128-bit device key, and an import the binary can't satisfy fails at the server instead of on the phone. The desktop hosts are new surface, and they do run with your user's access, like anything you npx. They say so and ask before joining a link.

"Anonymous hosting under nativescript.org." Free projects serve no web pages and no backends; raw files are text/plain with nosniff; projects unused for 30 days are deleted; creation and agent turns have daily caps. The agent acts only on devices that joined a project, on behalf of whoever holds its write key, and device-reported text is sanitized before it sees it.

"The problem is already solved." website#100 fixes the two links, and the RFC says it's the right fix and keeps it. It doesn't fix what's broken right now on the same path: the Vue template fails to build, the Angular template resolves a version that needs core 9 while pinning 8.9, and XML apps on core ≤ 8.7 render blank on Android. All three come from dependencies resolving fresh inside a runtime we don't control. GitHub-backing the source doesn't change that.

"No bundler and no npm, so it teaches a workflow people won't use." This judges the current stage as if it were the end state. The production-ready form has the normal project setup: a package.json with npm dependencies and a tsconfig.json, resolved and bundled at the edge (the RFC lists that step as planned). A project will then look like the one you'd create locally, without the in-browser build that drifts today. Even now the code is the same code: the same TypeScript, the same @nativescript/core imports, the same framework flavors. pull downloads it and watch or the Vite plugin syncs it from your own editor. NativeScript 9.1 with Vite also serves ES modules to the device over HTTP in local development, so this is the direction the local workflow already went.

Store risk. Preview's basis for running downloaded code (2.5.2, educational) is the same with or without Edge. The agent lives in the browser IDE, not in the app, and the listing shows only Preview's own UI.

What the analysis doesn't weigh

Measured only as a replacement for two StackBlitz links, Edge will always look like too much. That framing misses what's new here: a native app's code living at an address, with phones, desktops, editors and AI agents as peers of it. I don't know of another native framework that offers this, and it's worth weighing as an advance for NativeScript, not only as a maintenance cost.

• Desktop. There is no StackBlitz option for a macOS or Windows NativeScript app; a WebContainer can't run one. live --desktop, --electron and --expo are the only zero-install way to show the two newest runtimes, and they've already driven six runtime PRs.
• Links that last. A session today is memory-only with a 10-minute timeout. An Edge project is still there next month.
• A device loop for agents. Screenshot, view tree and run-on-device as MCP tools, so an AI tool can check NativeScript code on a real screen.
• Speed and drift. No in-browser webpack build, hot updates in tens of milliseconds, and a project runs against what the binary links, so it can't break because a dependency moved.
• Custom development clients via edge-shell, which is the durable answer to "Preview doesn't have my plugin".

A narrower proposal

"Official front door" is more than the RFC asks for: StackBlitz links stay, and which goes first is Unresolved question 3. To make that explicit:

1. Edge ships labeled experimental. nativescript.org keeps the GitHub-backed StackBlitz links as the default.
2. Edge becomes a default only after: Preview 3.0 is in both stores with the catalog back, at least two named maintainers can deploy and roll back, a written abuse and takedown process exists, and it has run a few months without incident.
3. If Edge is down or abandoned, nothing else breaks: StackBlitz links, classic sessions and local ns run don't depend on it, and the hosted agent can be set to zero turns.
4. Desktop previews go ahead regardless, since they have no alternative.

Does that address the sustainability concern, or is there a cost here you'd still consider too high even as an opt-in experiment?