Announcement on XAML.io Blog

Migrate Your WPF App to the Web, From Your Browser

Mon, 06 Jul 2026 04:00:00 -0400

XAML.io v0.8 introduces Migrate from WPF, a set of free, in-browser tools for bringing an existing WPF application to the web. You can (1) point them at a compiled build and get an instant, feature-by-feature compatibility report, (2) import a project and run it in the browser, or (3) hand a production application to our team for an end-to-end migration. The technology underneath is OpenSilver, the open-source framework that runs WPF-style C# and XAML on the web by compiling C# to WebAssembly and rendering XAML as real HTML DOM elements.

WPF developers are right to be skeptical of the phrase “runs in the browser,” so this post is deliberately heavy on code, screenshots, and a reference migration you can open and inspect yourself. The aim is to show how the tooling works and where its limits are, not to win you over with an adjective.

A one-minute look at Migrate from WPF, from importing a WPF app to running it in the browser.

New to XAML.io? XAML.io is a free, browser-based IDE for building .NET apps with C# and XAML: a drag-and-drop designer with 100+ controls, a code editor, and in-browser .NET compilation via WebAssembly. No install, no signup. Built by Userware, powered by open-source OpenSilver. Try it →

What “Migrate from WPF” is

It is a single window in the IDE, organized around three tasks that correspond to three different starting points:

Check compatibility. Drop in your build output and get a report. Free, works at any size, no signup, and your code never leaves your computer.
Import and run. Import a project and see it compile and run in the browser. Self-serve, currently a Technology Preview, best suited to small and mid-size projects today.
Have us migrate it. For a production application, our team handles the migration end to end at a fixed cost.

The rest of this post follows the path a developer actually takes: run the analyzer, import the source, review what the tooling changed, and decide what remains. First, the reasonable question that comes before any of that.

Why move a WPF application to the web

WPF is a mature, capable framework, and it is not going away on the desktop. The reason teams put these applications on the web has to do with delivery, security, reach, accessibility, and compliance, not with the language or the UI model.

A Windows-only application has to be installed and kept current on every machine that runs it. On the web, it is deployed once and updated for everyone in a single step, and it is reachable from any device with a browser rather than only from a managed Windows PC. It also runs inside the browser’s security sandbox instead of as a desktop process with full access to the user’s machine, which is a meaningful change in regulated environments. And because OpenSilver renders real HTML rather than painting to a canvas, a migrated app inherits genuine accessibility: screen readers, keyboard navigation, find-in-page, browser zoom, and translation all work, which is the foundation that standards such as Section 508 and EN 301 549 require. The same C# and XAML can keep shipping as a desktop build in parallel for as long as you need it.

If none of that applies to your situation, the sections below still work as a technical tour of how far OpenSilver’s WPF compatibility has come.

Does your code actually run, and is it fast enough?

This is the question most WPF developers ask first, so to be precise about it: OpenSilver is not a XAML-only trick, and it is not a transpile-to-JavaScript layer. It compiles your C# to the .NET runtime for WebAssembly. Your code-behind, your view models, your services, and most non-UI NuGet packages, meaning anything that already runs on Blazor WebAssembly, execute as real .NET, unchanged. The part that gets reimplemented lives inside the framework, not in your code: OpenSilver provides the UI layer, so each XAML control knows how to render itself as DOM. Your own C# and XAML stay as they are.

Performance follows from that. After a one-time download of the runtime, the application runs as compiled .NET in the browser, and production builds can use AOT compilation. For the software that is usually written in WPF, forms, data grids, navigation, and reporting, it is comfortably responsive. It is not a native game engine, so if your application does heavy real-time rendering, benchmark it before you commit. We would rather you measure your own app than take a number from us. In practice, though, performance has not been a wall: modern browser engines are heavily optimized for laying out large amounts of text and complex DOM, and OpenSilver is a thin layer on top of that. The easiest way to judge it for yourself is to try two live examples. XAML.io itself is built on OpenSilver: the drag-and-drop designer, IDE, and in-browser compiler at xaml.io are one demanding OpenSilver application running in the browser. And familyshow.xaml.io is a migrated WPF app you can open and use. As you interact with it, you are running compiled .NET code that renders to real DOM in the browser.

Step 1: the free compatibility report

Drop in the contents of your bin folder: the .exe, the .dll files, and any third-party libraries you ship. XAML.io reads the compiled IL with Mono.Cecil, walks every method, and classifies what your application actually uses across 34 WPF and platform feature areas:

Two design choices make the report useful:

Your code never leaves your computer. The analysis runs entirely in your browser: XAML.io reads your assemblies locally, and the only thing sent to our server is an aggregated list of the unsupported features it found, which is a list of API names, not your code. Your binaries, your IL, and your source stay on your machine, and you can export the full report to .xlsx.
It works for an application of any size. This is the honest answer to “how big is this job?” before you commit to anything.

The score is a map, not a verdict. A “blocking” item may be a single Win32 call you can swap out, and many “needs adaptation” items have a one-click fix, which is the subject of the next step.

Step 2: import the source, and review every change

Import a .zip or a folder, and XAML.io builds a solution, switches to the WPF theme automatically (more on that below), and attempts to compile and run it on OpenSilver.

The most important design decision in the tooling is what it does not do: it does not rewrite your code with AI. A tool that regenerates your UI can silently change behavior, and for a working business application that is exactly the risk you are trying to avoid. Instead, the approach is to keep your original code and make the framework support it. Wherever possible, we implement the WPF feature directly in OpenSilver; for everything else, a compatibility layer called OpenSilver.WpfCompat fills in the gaps. Both live under the original WPF namespaces, so your type names and using directives do not change. When the tooling does have to modify your code, it does so with small, mechanical, visible edits that you can review, not a regenerated file you have to trust.

Here is what those edits look like in practice.

A supported-but-different API becomes a one-click fix. A synchronous WPF file dialog becomes its asynchronous OpenSilver equivalent:

// before
var dlg = new OpenFileDialog();
if (dlg.ShowDialog() == true)
 LoadDocument(dlg.FileName);

// after the code fix (OS0001 → FileDialogAsync)
var dlg = new OpenFileDialog();
if (await dlg.ShowDialogAsync() == true)
 LoadDocument(dlg.FileName);

Going async has consequences, and the tooling accounts for them: a companion fix marks the method async and propagates await up the call chain, so you are not left with a half-converted method that will not compile.

Opening a URL with Process.Start becomes a browser navigation:

// before
Process.Start(helpUrl);

// after the code fix (OSWC0015 → ProcessStartUrl)
HtmlPage.Window.Navigate(helpUrl, "_blank");

Something that genuinely cannot run in a browser is wrapped, not deleted. Your original line is preserved behind a compiler directive, and the browser build gets a non-fatal notice instead:

#if !OPENSILVER // workaround to compile, address this later
 NativeMethods.SetWindowComposition(_hwnd, ref data);
#else
 OpenSilver.WpfCompat.Porting.AlertCodeWasDisabled(
 "Win32 window composition isn't available in the browser.");
#endif

Unsupported XAML is commented out, not silently dropped:

<!-- XAML_IO: Unsupported attribute removed: TickFrequency="2" -->
<Slider Minimum="0" Maximum="10" />

Every one of these edits appears in the IDE as a Warning, so you get a complete, reviewable list of everything the tooling touched. Nothing is hidden in a file you will never reopen. Two Roslyn analyzers, OSWC0004 and OSWC0005, exist specifically to flag this migration scaffolding so you can clean it up before you ship.

Runtime porting alerts: what breaks when you run it

Compile-time lists are useful, but the question that matters during a migration is what breaks when the app actually runs. So when execution reaches code that was disabled, or a method that is still a stub, OpenSilver reports it as it happens, with the message, the method, and the file and line:

[OpenSilver Porting] Code was disabled during migration:
 Win32 window composition isn't available in the browser.
 at MainWindow.ApplyBlur() in MainWindow.xaml.cs:line 142
 (execution continued, the app did not stop)

It reads like an exception with a stack trace, but it does not propagate and does not stop the application. You can run a half-migrated app immediately and work through these one at a time, instead of facing a wall of compile errors before you can see a single screen. The mechanism is Porting.AlertCodeNotImplemented and AlertCodeWasDisabled; the output channel is configurable (debug output, the console, an in-app notification, or a .NET event carrying a full stack trace), and it de-duplicates to one alert per location per session. It only ever appears in a migrated application, never in one you build from scratch.

Status: in-browser source import is a Technology Preview. It works best on small and mid-size, self-contained projects; on a large application with third-party UI suites you will hit gaps. That is exactly why the analyzer in Step 1 exists: run it first so there are no surprises. We add WPF features, analyzers, and fixes every week, so the set of projects that “just import and run” keeps growing.

A reference migration you can inspect: Family.Show

Family.Show is the family-tree application Vertigo built for Microsoft shortly after WPF shipped, and it has served as a canonical WPF reference sample ever since. It is a real, polished application with custom controls, animations, data templates, drag-and-drop, and photo handling, which is what makes it a fair test rather than a rigged demo. It runs in the browser on OpenSilver with only minor changes, with 97% of the original code untouched, measured as a line-by-line diff of the C# and XAML between the original and migrated codebases.

We have published every artifact so you can verify that instead of trusting the number:

Run the migrated app: familyshow.xaml.io
Open the migrated source on XAML.io and fork it: xaml.io/s/Samples/Source/FamilyShow
Diff it against the original WPF source: Family.Show on GitHub

The migrated app is also light for what it is. The running application, including the entire .NET runtime, is 8.1 MB compressed, with no plugin to install, so over a CDN it loads in a few seconds and is then cached for return visits.

Open the original and the migrated source side by side, and diff them. That diff is the most honest specification we can offer for “minimal changes.”

Your app should still look like your app

XAML.io ships three themes, which are the default styles and control templates its built-in controls use:

Modern: contemporary and flat; the default for new projects.
WPF: the classic Windows (Aero2) look, ported from WPF’s own default templates.
Silverlight: the original Silverlight defaults, for pixel-faithful Silverlight migrations.

When you import a WPF solution, XAML.io applies the WPF theme automatically, so the app looks like itself on the first run. If the classic look feels dated, you are not stuck with it: switch to the Modern theme, adopt responsive layouts, and restyle individual controls to modernize the UI incrementally, all on the same C# and XAML, with no rewrite. All three themes are open source; the WPF theme lives in OpenSilver.Themes.Wpf under the MIT license, so you can retheme everything or override a single control template.

Common questions, answered directly

If you are evaluating this seriously, you have objections. Here are the ones we hear most.

What about my Telerik, DevExpress, or Syncfusion controls? Third-party UI control suites do not work out of the box in the self-serve tools yet. This is the real ceiling on fully automatic WPF migration today, and we are not going to pretend otherwise. There is a path forward: a Telerik Compatibility Pack exists now (contact us), a ComponentOne port is underway, and in managed migrations we port or replace vendor controls as part of the project. It is worth knowing that non-UI libraries that already run on Blazor WebAssembly generally run on OpenSilver as-is, so the work concentrates in the UI controls. We are also in active conversations with the major component vendors, and we expect broader out-of-the-box compatibility over time.

How much really carries over? The expensive, risky parts come with you: business logic, view models, converters, data binding, styles, resources, and most custom controls. That is the entire reason to stay in C# and XAML rather than rewrite in a different language and UI model. Less work, fewer regressions, and a codebase your team still recognizes.

Will it look identical? When a feature is supported, it renders identically; we are not currently aware of a supported feature that looks different from its WPF original. Visual differences come up only when something is not yet supported and has to be replaced, for example when a complex piece is more easily swapped for a JavaScript library, and cases like that keep getting rarer as coverage grows.

WPF apps look dated. Isn’t a rewrite the only way to modernize the UI? No, and this is a common reason teams reach for a rewrite they do not need. The look and the code are separate concerns. You keep the code and change the styling: move from the WPF theme to the Modern one, add responsive layouts, and restyle controls incrementally. You get a contemporary, responsive UI without rebuilding the application in another framework.

What can never work in a browser? Some things genuinely cannot, and we flag them explicitly rather than stubbing them silently: Win32 and P/Invoke, native interop, and direct hardware access. Where a feature is simply not implemented yet, we say so, and that list keeps shrinking. Where it is a hard browser boundary, we tell you, so you can plan an alternative.

Does my code get uploaded to your servers? It does not have to. The entire self-serve flow (analyze, import, fix, run, and export a Visual Studio solution) runs locally in your browser, with no signup, and your source is never sent to us. Even the compatibility analyzer processes your binaries locally and uploads only an aggregated list of unsupported features. Cloud save, sharing, and AI features are opt-in, and those are the only parts that involve our servers. If your policy forbids handing proprietary code to a SaaS, you can still do the entire migration.

Am I locked into your browser IDE? No. You can download a standard Visual Studio solution at any time and continue in Visual Studio, VS Code, Rider, Cursor, or another editor. XAML.io is as much a migration tool as an IDE: the output is a normal solution you own, and you can use it purely to get your app onto OpenSilver, which is free and open-source, and then work wherever you prefer.

How it works: rendering XAML as real HTML DOM

Among the .NET frameworks that target the web, OpenSilver stays the closest to the WPF API (close enough that Family.Show ports with minor changes) and it is the most browser-native. It renders XAML as real DOM: a TextBox is a <textarea>, an Image is an <img>, a Path is an <svg>. Open a migrated app’s developer tools and you see your actual UI as inspectable HTML.

This is not a cosmetic detail; it is the first thing to check when comparing ways to get a desktop app onto the web. Some approaches paint the UI onto a single canvas or a WebGPU surface. The result looks like a web page but is not one: it is essentially one big pixel buffer, so it gives up most of what makes a browser useful. Because OpenSilver emits real DOM instead, a migrated app keeps everything an ordinary web page has:

Accessibility. Screen readers and ARIA, keyboard navigation, and browser zoom, the foundation for standards such as Section 508 and EN 301 549.
Text that behaves like text. Find-in-page (Ctrl+F), selection and copy/paste, and one-click browser translation.
Discoverability. Content search engines can index, so the app can be SEO-friendly where you want it to be.
The rest of the browser platform. Browser extensions and mobile gestures such as long-press keep working.
Mix and match. Combine XAML with plain HTML and JavaScript, drop Blazor components into a XAML app, and reach the entire ecosystem of web libraries.

You get the WPF programming model and the full web platform at the same time, with effectively no ceiling on how far you can extend through JS interop.

The runtime has also caught up to a large amount of real WPF. The recent OpenSilver 3.4 preview added, among much else:

Layout and geometry: LayoutTransform (long one of the hardest WPF features to bring to the web), CombinedGeometry, StreamGeometry, geometry hit-testing and flattening, and length units in XAML.
Controls: GroupBox, Menu and MenuItem (checkable, with input-gesture text), MultiSelector, AccessText, Button.IsDefault and IsCancel, and an enhanced Window.
Styling and binding: WPF-style triggers, SystemColors keys, ResourceKey and ComponentResourceKey, OneWayToSource, and TemplateBinding converters.
Text and input: AccessKeyManager, TextCompositionManager, and WPF-style keyboard focus and input-device architecture.

The compatibility layer behind the import tooling, OpenSilver.WpfCompat, is 307 source files, a 420-row porting reference, and 8 Roslyn analyzers with 16 code-fix providers, on top of the one-click XAML fixes XAML.io applies in the editor. As pieces of WpfCompat mature, they graduate into OpenSilver itself, and new features and fixes land continuously. You can follow them commit by commit on the OpenSilver develop branch: the 3.4 preview package is rebuilt on every commit there, and XAML.io updates to the latest build regularly.

When you would rather have it done for you

The self-serve tools are free, with no time limit and no feature paywall. They are built to do real work and are well suited to evaluation and to migrating small and mid-size projects yourself.

A production migration of a large application is a bigger undertaking, and it is the work we do for a living. We are the team behind both XAML.io and OpenSilver, and we have spent more than 13 years migrating enterprise XAML applications, across Silverlight, LightSwitch, and WPF, to the web: over 10 million lines of production code for organizations including DENSO, Tata Communications, Symcor, LiveData (surgical software in healthcare), and Repton (education), among many others across financial services, manufacturing, and the public sector.

The engagement model is deliberately low-risk:

It begins with a free compatibility analysis and a fixed-cost quote, broken into milestones with a timeline.
Rather than rewriting your app, we extend OpenSilver itself to support what your app uses, so as much of your original code as possible stays untouched.
You receive milestone deliveries as Visual Studio solutions you can compile and test. Your codebase stays intact, you keep working while we work, and we merge your changes.
We help you ship to production, with optional ongoing priority support.
If you need a WPF feature OpenSilver does not support yet, you can fund its development, and it ships to everyone in the open-source framework, not only to you.

This is what funds the free tools and the open-source framework. So if you have a WPF application that needs to be on the web, talk to us.

Also new in v0.8

Example gallery, built into the IDE. A gallery of example projects inside XAML.io: open any of them in the online IDE in one click, run it in the browser, make and test changes, or fork it as a starting point for your own project.
Static web build export. Generate a set of static files, straight from the online IDE, that you can host anywhere: Azure, AWS, GitHub Pages, Netlify, Cloudflare Pages, or any plain HTTP server.
Latest OpenSilver 3.4 preview, with the WPF features listed above and new work landing continuously.
Also soft-launched since v0.7: a revamped New item menu with Class Library projects, incremental compilation, and Navigate Backward and Forward.

What’s next

WPF is where most of the team’s effort goes right now. Ahead: more WPF support every week; more ways to publish a finished app, including one-click deployment to an xaml.io-hosted URL, native iOS and Android apps, and signed desktop apps; and VB.NET support under consideration. Expect a fair amount of IDE polish too, along with a few larger features we are not ready to talk about yet. These are directions rather than promises.

Try it

Open xaml.io, choose Migrate from WPF, and drop in your bin folder for a free compatibility report. It is the fastest way to find out how far your WPF application already is from the web. And if you hit something missing, tell us; there is a good chance it is already on the roadmap.

xaml.io | Free. No install. No signup. · Talk to our migration team →

Writing about this? A press kit with logos, high-resolution screenshots, a fact sheet, and quotes is available at blog.xaml.io/post/press-kit-v0.8.

Powered by OpenSilver. XAML.io is built on OpenSilver, the open-source framework that runs WPF-style C# and XAML in the browser via WebAssembly, and, through MAUI Hybrid and Photino, natively on mobile and desktop. Migrating a WPF, Silverlight, or LightSwitch application? Our team can help →

Compile C#+XAML to a Native Windows, macOS, or Linux App, From Your Browser

Tue, 26 May 2026 10:00:00 +0200

What if you could turn a C#+XAML project edited in your browser into a native Windows, macOS, or Linux desktop app, without leaving the browser, and without your code ever touching a server?

That’s what XAML.io v0.7 can now do. Click Publish, pick a platform, and a self-contained .exe, .app bundle, or Linux executable lands in your Downloads folder in well under a minute on a modern laptop. Everything runs in your browser tab: the compilation, the packaging, and even the Apple Mach-O ad-hoc code-signing pass for macOS bundles.

Preview status. This feature is in Preview / Alpha in XAML.io v0.7 (May 2026). Expect rough edges, occasional breakages, and changes between releases. We’d rather ship the rough version and iterate with you than wait for everything to be perfect. Bug reports and “this is missing X” notes are both welcome.

New to XAML.io? XAML.io is a free, browser-based IDE for building .NET applications using C# and XAML. It includes a visual drag-and-drop XAML designer with 100+ controls, a code editor, and in-browser .NET compilation via WebAssembly. No installation, no signup required. It’s built by Userware and powered by the open-source OpenSilver framework. Try it →

How it works

In XAML.io’s title bar, the Publish dropdown now has a “Download as a desktop app” section with three buttons inside it: one each for Windows, macOS, and Linux. Click a button and a dialog walks through what you’re about to get (format, size, first-launch caveats), then the publish pipeline runs locally in your browser tab. The browser’s native download dialog handles the rest.

There’s no signup. There’s no backend compile queue. The first time you publish for a given OS, the browser fetches a small per-platform launcher template (~30 MB, cached after first publish), assembles it with your compiled assemblies, and hands the result off as a download.

What you get on each platform

Windows

A self-contained .exe packaged in a .zip alongside an app/ folder (your compiled assemblies, sidecar DLLs, and resources) and a README.txt. Recipients extract the archive and double-click the .exe. No .NET install required on the recipient’s machine.

Windows SmartScreen will show a “Windows protected your PC” dialog on first launch because the .exe is unsigned (we haven’t yet shipped support for user-supplied code-signing certificates). The bundled README.txt has the “More info → Run anyway” bypass steps.

macOS

A self-contained .app bundle inside a .zip. The bundle is ad-hoc signed client-side as part of the publish pipeline (more on how that works below). Because there’s no Apple Developer ID involved, macOS Gatekeeper still prompts on first launch, but the bundled README.txt has the right-click → Open path for macOS 12-14 (Monterey, Ventura, Sonoma) and the System Settings → Privacy & Security → Open Anyway path for macOS 15 (Sequoia).

Apple Silicon (arm64) only for now. Intel Mac support is on the roadmap.

Linux

A self-contained ELF executable in a .tar.gz. Recipients extract the archive and run the executable. The UI is rendered via WebKitGTK 4.1, which ships preinstalled on every current LTS or rolling release (Ubuntu 22.04+, Debian 12+, Fedora 38+, Mint 21+, Arch). x86_64 only for now.

These are real native desktop apps

Same project, three OSes, three native processes:

The downloaded artifact is a real native .NET process, not a packaged web page or a WebAssembly container. Your C# runs as native code on the recipient’s machine via the .NET 10 runtime (JIT-compiled, in-process, with full access to threading, sockets, file I/O, and P/Invoke), the same execution model as a WPF or WinForms app.

The rendering model is different: XAML.io builds OpenSilver apps. At build time, OpenSilver’s XAML compiler emits C# that knows how to construct the visual tree. At runtime, that C# runs, and each OpenSilver control attaches its underlying DOM element to the document: a TextBox becomes an actual <textarea>, an Image becomes an <img>, a Path becomes an <svg> (see the v0.6 deep dive for the long version). In the published desktop app that DOM lives inside the OS’s built-in WebView (Edge WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux), embedded into the .NET process via Photino and driven by the OpenSilver runtime directly (no Blazor WASM in the desktop app; that’s IDE-only). So: native .NET execution, DOM-based UI rendering, no bundled browser engine, no WASM at runtime.

Reactions so far

“Fucking hell this is really getting so much better, thanks a whole lot to the team!!”
— Infinite_Track_9210 on Reddit (source)

Under the Hood

There are four pieces worth pulling apart, because each one is the kind of thing that’s often assumed to need a backend.

1. The packaging pipeline runs entirely in your browser tab

No backend compile step. No server upload. No build queue. When you click Publish, the browser:

Compiles your C#+XAML project to .NET assemblies using the same in-browser Roslyn that powers XAML.io’s Run button (see our earlier post on in-browser .NET compilation).
Fetches a per-OS launcher template from XAML.io’s CDN. The template is a pre-built Photino app for that platform, bundled with the .NET runtime. It’s cached after first publish, so subsequent publishes for the same OS skip this step.
Assembles your compiled assemblies + a small manifest.json + resources into the launcher’s expected sidecar layout, on an in-memory filesystem (Emscripten’s MEMFS, the same virtual FS Blazor WebAssembly uses).
Re-packs the result into the right archive format (.zip for Windows and macOS, .tar.gz for Linux) with the correct executable bits, then hands the byte array to the browser’s native download dialog.

Your code never leaves your machine. The only network traffic during a publish is the one-time launcher-template fetch, which is the same pre-built bytes for everyone; the launcher knows nothing about your project.

2. Native .NET execution, DOM-based rendering

This is the part that surprises people, so it’s worth being explicit about: the WebAssembly part is only the IDE itself. The desktop apps it produces are real native .NET 10 processes. Your C# is JIT-compiled by the runtime and runs in-process, with the same execution model as a WPF or WinForms app.

The UI is rendered as real DOM elements (OpenSilver’s design choice; see the v0.6 deep dive), displayed inside the OS’s built-in WebView via Photino. In the published desktop app the OpenSilver runtime is loaded directly by Photino through the OpenSilver.Photino bridge: there’s no Blazor WebAssembly intermediate at runtime, and no client-side compilation either (that’s all IDE-only).

That separation matters in two practical ways:

No bundled browser engine. Photino uses the OS’s built-in WebView (Edge WebView2 / WKWebView / WebKitGTK) rather than bundling Chromium the way Electron does. That keeps the download size to roughly the cost of the .NET runtime alone.
C# / .NET libraries work the same as on any desktop .NET process. All the things WebAssembly normally sandboxes away (file I/O, sockets, threading, P/Invoke, native interop) work normally in the published app, because it’s a normal .NET process. Your code can do things the IDE itself can’t.

3. Even macOS ad-hoc code-signing happens client-side

This was the trickiest part to get working. Apple’s Mach-O format and the CodeDirectory hashing dance that produces a valid .app bundle signature are normally handled by codesign, which is a macOS-only command-line tool. To make publishing a .app from the browser work without a server-side signer, and without requiring you to be on a Mac, we needed an in-WebAssembly implementation of the signing pass.

The answer: we pulled the Mach-O writer and CodeDirectory hasher out of Filip Navara’s CodeSign / Melanzana, trimmed them to the parts we actually use, and run the ad-hoc signing pass entirely in the browser’s WebAssembly runtime. The bundle’s Mach-O binary is re-hashed, the _CodeSignature/CodeResources plist is regenerated, and the LC_CODE_SIGNATURE load command is rewritten. All of that happens on MEMFS, in C# compiled to WASM. The output is a valid ad-hoc signed bundle that Gatekeeper will accept (with the standard first-launch prompt that ad-hoc bundles always trigger).

The Melanzana subset is lazy-loaded: it ships as a separate ~500 KB compressed assembly that’s only fetched the first time you click Download as a macOS app. Windows-only and Linux-only publishers never download those bytes, so the IDE’s first-paint payload is unchanged for them.

Honestly, signing a macOS app from inside a browser tab is the kind of thing we’d have called impossible. Until we got it working.

4. File sizes

The launcher is a .NET 10 self-contained, single-file deployment with compression enabled (EnableCompressionInSingleFile=true) and trimming deliberately off (PublishTrimmed=false). Trimming is off on purpose: the launcher loads your compiled assemblies via Assembly.Load(byte[]) and the trimmer cannot reason about that. Compression brings an untrimmed self-contained .NET 10 app under 40 MB; without it, the same artifact lands closer to 60-80 MB.

Platform	Compressed download	What’s inside
Windows	~30-40 MB `.zip`	Single-file `.exe` with the .NET 10 runtime + OpenSilver runtime + Photino bridge bundled inside, alongside an `app/` folder with your compiled assemblies and a `README.txt`.
macOS	~30-40 MB `.zip`	Ad-hoc-signed `.app` bundle following the same layout as Windows. Apple Silicon (arm64).
Linux	~30-40 MB `.tar.gz`	Single-file ELF executable with the same internal layout. x86_64.

Sizes don’t balloon to Electron’s ~150 MB+ territory because Photino uses the OS’s built-in WebView rather than bundling Chromium. You pay for the .NET runtime, not for a browser engine.

The floor stays flat across platforms because the .NET runtime is the dominant cost. Project assets (images, fonts, media, embedded resources) add to that linearly.

Limitations and what’s missing

We want to be upfront about what isn’t there yet:

Preview / Alpha in XAML.io v0.7 (May 2026). Behavior, UI, and the on-disk layout of the produced artifacts may change between releases. We’d rather ship the rough version and iterate with feedback than wait for everything to be perfect.
No publisher-identity signing or notarization. Apps are unsigned in the Apple Developer ID / Windows Authenticode sense, so first-launch Gatekeeper and SmartScreen warnings still apply. Support for user-supplied code-signing certificates is on the way; for macOS, apps distributed via the web also need Apple’s notarization step for the smoothest first-launch experience, and we’ll wire that up alongside cert support. Until then, the bundled README.txt walks recipients through the one-click bypass for each OS.
Architecture coverage is partial. macOS publish is Apple Silicon (arm64) only. Linux publish is x86_64 only. Intel Macs and Linux ARM64 are on the roadmap.
Linux distro floor. Modern distros (Ubuntu 22.04+, Debian 12+, Fedora 38+, Arch, Mint 21+) ship WebKitGTK 4.1 preinstalled and run the published app with no setup. On older releases (Ubuntu 18.04 / 20.04, Debian 11) recipients may need a one-time apt install libwebkit2gtk-4.1-0 or equivalent. The bundled README.txt has the per-distro commands.
Publish is best on desktop browsers. The packaging pass uses the WebAssembly heap heavily; mobile browsers may run out of memory on larger projects. Editing and running on mobile is fine, as before.

What’s coming next

Feature	Description
User-supplied code-signing certificates	Upload your Apple Developer ID or Authenticode certificate; published apps then ship with publisher-identity signing and skip the first-launch warning entirely.
Broader CPU coverage	macOS Intel (x86_64) and Linux ARM64 publish targets.
One-click web deployment	Already on the v0.6 roadmap; the desktop publish flow is the local-distribution side of the same story.

Suggest or vote on features at feedback.xaml.io, ask questions on the forums, or contact us directly.

Try it

Open xaml.io, build something, click Publish, pick a platform. In well under a minute on a modern laptop you’ll have a real native desktop app you can hand to anyone with that OS.

xaml.io | Free. No install. No signup required.

XAML.io v0.6: Share Running .NET Code With a Link

Wed, 25 Feb 2026 00:00:00 +0000

What if you could share a running .NET project with a link?

Not a code snippet in a blog post. Not a GitHub repo someone has to clone and build. A live, editable, runnable project. Open it in the browser, click Run, and it works.

Try it right now:

https://xaml.io/s/Samples/Newtonsoft

You’ll see a complete C#/XAML project referencing the Newtonsoft.Json NuGet package in a browser-based IDE. Click Run. The project compiles and executes entirely in your browser via WebAssembly. There is no server-side build step. Edit the code, change things, re-run. Your changes don’t touch the original.

XAML.io v0.6 makes this possible with two new features: NuGet packages in the browser and code sharing via URL.

New to XAML.io? XAML.io is a free, browser-based IDE for building .NET applications using C# and XAML. It includes a visual drag-and-drop XAML designer with 100+ controls, a code editor, and in-browser .NET compilation via WebAssembly. No installation, no signup required. It’s built by Userware and powered by the open-source OpenSilver framework. Try it →

Here’s how code sharing works.

Click the “Share Code” button, choose a name, and XAML.io generates a URL:

https://xaml.io/s/yourname/yourproject

Anyone with that link can:

View the full source code in the XAML.io IDE
Run the project with a single click
Modify the code freely (their changes don’t affect your original)
Fork the project to save their own copy to the Cloud (free account required)

No signup is needed to view and run shared projects.

Attribution is built in. When someone forks your project and re-shares it, the chain is preserved. If Project A is forked as B, and B is forked as C, someone viewing C sees “Forked from B” with a link, and following that shows “Forked from A.” Your work stays credited, no matter how many times it’s remixed.

Auto-run links. Append ?run=true to any shared URL and the app runs automatically when the recipient opens the link. They see the working app immediately, not just source code.

Think about the use cases

Scenario	Before	With XAML.io v0.6
Showing how a library works	Static code snippets in docs	Live, runnable project anyone can try
Teaching a concept	“Clone this repo and run it”	Share a link and the student opens and runs immediately
Sharing a prototype	Screenshots + zip file	Share a link and the stakeholder sees it running live
Answering a question	Paste code into Slack	Share a link that the other person can actually run

NuGet Packages in the Browser

Until v0.6, XAML.io projects could only use the built-in .NET libraries and OpenSilver’s UI controls. Now you can add any compatible NuGet package, with a workflow that should feel familiar:

In the Solution Explorer, right-click the Dependencies node
Click “Add NuGet Package Reference…”
Search for a package and see the icon, description, download count, and version list
Select a version and click Add

The package is immediately available in your C# and XAML code. See it in action: the Newtonsoft.Json sample shows a NuGet package, C# code-behind, and a XAML UI all running together in the browser.

What packages work?

Non-UI .NET libraries: Anything targeting .NET Standard 2.0/2.1 or .NET 5-10 that works with Blazor WebAssembly. This covers the vast majority of popular packages: JSON processing, CSV handling, HTTP clients, validation, data transformation, and more.

OpenSilver-compatible UI libraries: NuGet packages built for or compatible with OpenSilver, usable in both C# code and XAML markup.

If a package relies on APIs unavailable in WebAssembly (direct file system access, certain networking APIs), it won’t work. Most non-UI libraries are fine.

Interactive samples: try them now

We’ve published official sample projects for popular .NET libraries. Each one is a complete, runnable solution with the NuGet package already referenced. Click any link and the app will compile and run automatically:

Fork any of them to start your own project. We’ll be adding more over time.

For Library Authors

If you maintain a .NET library, you can create a live, interactive demo on XAML.io and share it with a single URL. Go to xaml.io, add your NuGet package, write a small demo, sign in (free), and click “Share Code”. Link to it from your README, docs, or NuGet page.

If you create a sample, share it on the XAML.io Forums or let us know. We’d love to feature community-created samples.

Also in v0.6

NuGet and code sharing are the headlines, but this release also includes improvements shipped over recent months:

XAML Autocompletion (IntelliSense): Context-aware suggestions for elements, attributes, and property values while editing XAML.
“Fix with AI” button: Appears next to XAML compilation errors. One click triggers an AI-powered fix attempt.
WPF-style default template: New projects start with MainWindow.xaml and a StartupUri in App.xaml, matching the default structure of WPF applications.
Improved mobile support: View shared projects, make quick edits, and run code on a phone or tablet. Desktop browsers remain recommended for extended sessions.
Error squiggles: Compilation errors are underlined directly in the source code.
Split editor view: Split the workspace vertically or horizontally (e.g. XAML on the left with the designer on the right)
Community forums: The new XAML.io Forums are live. Ask questions, share what you’ve built, and connect with other XAML.io users.

Under the Hood: Client-Side Compilation, No Lock-In

XAML.io compiles and runs .NET code entirely in the browser. The C# compiler itself runs in your browser tab, using the same .NET WebAssembly runtime that powers Blazor WebAssembly applications. When you click Run, your code is compiled locally. Nothing is sent to a server. There is no round-trip, no cold start, and no build queue.

The UI layer uses XAML with the same syntax as WPF, and OpenSilver renders it as real DOM elements rather than drawing to a canvas. A TextBox becomes an actual <textarea>, an Image becomes an <img>, a MediaElement becomes a <video>, a Path becomes an <svg>. Open your browser’s DevTools on a running XAML.io app and you’ll see a real DOM tree, not a single <canvas> element. The compiled output is a set of static files (.wasm, .js, index.html) that can be hosted on any web server or CDN.

You’re not locked in. Every project can be downloaded as a standard Visual Studio solution and continued in Visual Studio, VS Code, or any .NET IDE. The underlying framework (OpenSilver) is fully open-source. XAML.io is a frictionless starting point, not a walled garden.

Getting Started

1. Explore a sample (no signup needed)

Open any of the interactive samples above. Click Run, edit the code, see the results.

2. Create your own project

Go to xaml.io. A new project loads instantly. Build your UI three ways: drag controls from the toolbox, write XAML by hand (now with IntelliSense), or describe what you want and let the AI assistant generate it.

3. Share your work

4. Download for Visual Studio

Click the download button to get a .zip containing a standard Visual Studio solution. No lock-in.

Limitations and What’s Next

XAML.io is a tech preview. We want to be upfront about what doesn’t work yet:

Not a desktop IDE replacement: XAML.io is designed as a companion to Visual Studio, not a substitute. Features like debugging, refactoring, and advanced project tooling are best handled in a desktop IDE. Think of XAML.io as the fastest way to prototype, share, and learn.
One project per solution: multi-project solutions are planned
NuGet compatibility: packages that rely on APIs unavailable in WebAssembly won’t work (most non-UI libraries are fine)
Desktop recommended: mobile works, but the full experience is best on a desktop browser

We’re actively improving the product. Suggest features or vote on others’ ideas at feedback.xaml.io, ask questions on the forums, or contact us directly.

Here’s what’s coming next:

Feature	Description
Improved WPF compatibility	Broader support for WPF APIs and patterns
Multi-project solutions	Class libraries, shared projects, multiple entry points
One-click deployment	Publish running apps online: share a live app, not just source code
VB.NET and F# support	Expanding language options beyond C#
Improved performance	Faster compilation, snappier interactions

Everything you build on XAML.io is yours. Download it, open it in Visual Studio, deploy it wherever you want. The underlying framework is fully open-source. There is no lock-in.

Now you can share running .NET code with a link. Try it. Build something. Share it. See what happens when someone clicks your link and your code just… runs.

Questions? Feedback? Join the XAML.io Forums, reach out on X/Twitter (@xaml_io), or contact us directly. If you’re exploring migrating a WPF or Silverlight application to the web, our team can help with that too.

xaml.io | Free. No install. No signup required.

Introducing XAML.io Preview v0.5: Visual .NET Development, Instantly in Your Browser

Fri, 03 Oct 2025 12:00:00 +0200

Today, we’re introducing XAML.io Preview v0.5, a free, browser-based visual XAML designer and C# code editor that lets you build .NET UI projects without installing anything.

It combines a cross-platform UI framework (powered by the open-source OpenSilver) with a familiar design surface and code editor, making .NET development more accessible than ever. You can start a project in seconds, and if you want to, you can download it as a Visual Studio solution and continue locally, using fully open-source technologies.

Imagine taking a small C# console app and wiring up a UI for it in just a few minutes. No SDKs, no installs, no switching languages.

Why This Matters

Starting a new .NET app often involves installing large SDKs, configuring environments, and setting up tooling before writing the first line of UI code. That friction can be a barrier, especially for newcomers, educators, or teams exploring ideas.

XAML.io changes that. By moving the visual development experience into the browser, it lets you:

Prototype ideas quickly without local setup.
Add a UI to existing console apps in minutes.
Learn and experiment with XAML in a zero-install environment.
Focus on your app logic, not tooling configuration.
Switch to offline development at any time, by downloading a standard Visual Studio project that runs on open-source technologies.

“I must say, I DIG this.”
— ZayLarsson on Reddit (source)

“I had dreams about this 10 years ago.”
— Prod_Meteor on Reddit (source)

What’s New in Preview v0.5

Earlier preview versions of XAML.io focused on designing a single XAML file online. Great for layout experiments, but limited for real scenarios.
With Preview v0.5, you can now work with entire projects that combine XAML and C# code-behind, directly in the browser.

Here’s what’s new:

Full project editing: Edit XAML and C# files (using the Monaco editor for code).

Code-behind support: Add event handlers and logic in C#, just like in traditional .NET apps.

Familiar environment: Designer, Solution Explorer, and editor in a VS-like layout.

Instant execution: Click Run to launch your project in the browser.

Cloud saves: Save projects and pick up where you left off.

Download to Visual Studio: Export as a ZIP and continue offline at any time.

Cross-platform: Works on any modern browser, desktop or mobile.

(Mobile support is still early, with improvements planned)

XAML dialect: Uses WPF XAML (subset, growing). MAUI support is under consideration.

You’re Not Locked In

One of the core design principles of XAML.io is developer control.

Every project can be downloaded as a standard Visual Studio solution, and the underlying runtime (OpenSilver) is fully open-source. This means you can start quickly online, then continue locally at any time, without being tied to a proprietary format or service.

Think of XAML.io as a frictionless on-ramp to .NET development, not a walled garden.

Looking Ahead

Preview v0.5 is an early but important step toward a bigger vision:
To make XAML.io the most approachable way to get started with .NET, lowering barriers for beginners, educators, hobbyists, and rapid prototypers.

Here’s what’s coming next:

Project sharing via link: Share your XAML.io projects easily with a single URL.
One-click deployment: Instantly publish and share running apps online.
IntelliSense support: To improve the C# editing experience.
Improved mobile experience: Making it easier to work on the go.
VB.NET and F# support: Expanding language options beyond C#.
Expanded WPF compatibility: Continuing to broaden the supported XAML subset.
Improved performance: Aiming for near-instant loading and snappier interactions.
MAUI support: Being considered for the future (not planned short-term).

Suggest or vote on features: https://feedback.xaml.io

Try It Today

You can try XAML.io right now. It’s completely free. No installation. No setup. No signup required.
https://xaml.io

Welcome to the XAML.io Blog

Fri, 03 Oct 2025 09:00:00 +0200

We’re launching a dedicated blog for XAML.io.

Until now, XAML.io updates were published on the OpenSilver blog, alongside OpenSilver release notes, migration case studies, and framework updates. That made sense when XAML.io was a companion feature of OpenSilver. But XAML.io has grown into its own product with its own community, so it deserves its own space.

This blog is where all future XAML.io news will live.

What is XAML.io?

XAML.io is a free, browser-based IDE for building .NET applications using C# and XAML. It includes a visual drag-and-drop XAML designer with 100+ controls, a code editor, and in-browser .NET compilation via WebAssembly. No installation, no setup, no signup required.

Think of it as the fastest way to go from zero to a running .NET UI app. Open the browser, drag some controls onto a canvas or write some XAML, add your C# logic, click Run, and your app is live. If you want to continue in Visual Studio, download the project as a standard .NET solution. No lock-in.

XAML.io is built by Userware, a Paris-based company that also maintains OpenSilver, the open-source framework that runs WPF-style C#/XAML applications in the browser via WebAssembly. XAML.io itself is a C#/XAML application running on OpenSilver, so the IDE runs on the same technology it lets you develop with.

What to expect from this blog

This is where we’ll share:

Release announcements for new XAML.io versions
Feature deep dives explaining how things work under the hood
Tips and tutorials to help you get the most out of XAML.io
Community highlights showcasing what people build and share
Roadmap updates so you know what’s coming next

Get started

The best way to see what XAML.io is about is to try it:

https://xaml.io

Free. No install. No signup required.

Join the conversation

Have questions, feedback, or want to show what you’ve built? Join us on the XAML.io Forums. You can also reach out via opensilver.net/contact or find us on X/Twitter (@xaml_io).

We’re excited to have you here.

The XAML.io Team

Announcement on XAML.io Blog

Migrate Your WPF App to the Web, From Your Browser

What “Migrate from WPF” is

Why move a WPF application to the web

Does your code actually run, and is it fast enough?

Step 1: the free compatibility report

Step 2: import the source, and review every change

Runtime porting alerts: what breaks when you run it

A reference migration you can inspect: Family.Show

Your app should still look like your app

Common questions, answered directly

How it works: rendering XAML as real HTML DOM

When you would rather have it done for you

Also new in v0.8

What’s next

Try it

Compile C#+XAML to a Native Windows, macOS, or Linux App, From Your Browser

How it works

What you get on each platform

Windows

macOS

Linux

These are real native desktop apps

Reactions so far

Under the Hood

1. The packaging pipeline runs entirely in your browser tab

2. Native .NET execution, DOM-based rendering

3. Even macOS ad-hoc code-signing happens client-side

4. File sizes

Limitations and what’s missing

What’s coming next

Try it

XAML.io v0.6: Share Running .NET Code With a Link

Share Code: Create, Run, Share, Fork

Think about the use cases

NuGet Packages in the Browser

What packages work?

Interactive samples: try them now

For Library Authors

Also in v0.6

Under the Hood: Client-Side Compilation, No Lock-In

Getting Started

Limitations and What’s Next

Introducing XAML.io Preview v0.5: Visual .NET Development, Instantly in Your Browser

Why This Matters

What’s New in Preview v0.5

You’re Not Locked In

Looking Ahead

Try It Today

Welcome to the XAML.io Blog

What is XAML.io?

What to expect from this blog

Get started

Join the conversation