jlaban-uno

Uno Platform is a cross platform implementation of the WinUI+WinRT APIs. That cross-platform implementation never used the official WinUI/WinAppSDK implementation on Windows.

When running on Windows, which this is where some confusion may lie, you can choose to use the Uno implementation (the netX.0-desktop TFM), or the original WinAppSDK by Microsoft (the netX.0-windows10.YYY TFM), since both implementations share the same API, making user code compatible with either ones.

On the other platforms, Wasm/Linux/iOS/Android/Catalyst/macOS, only the Uno implementation can be used.

Uno Platform Dev here.

Uno currently uses some native controls on mobile iOS/Android/Catalyst (text input, mostly) to provide platform features, but the rest is rendered using graphics primitives. On Web, the same happens where CSS is used for most of the rendering. Input interactions are managed entirely by Uno. This allows to have a visually identical UI across platforms, unless the developer chooses otherwise.

On Desktop targets, Uno is rendering everything on an HW accelerated Skia canvas, with GL/Metal backends.

This was fixed in .NET 8 with WebCIL. Uno Platform since .NET 9 is also using it.

Indeed, text selection is a specific behavior that was chosen to be disabled by default in order to be closer to the original behavior of WinUI on desktop. This is a configurable behavior on the TextBlock control, though.

Uno Maintainer here - Thanks for trying out Uno! At this time, the default render mode is provide a uniform look across platforms, and it's possible to alter the theme using Material, Fluent or Cupertino, or to design your own theme using control template styling, or even use native controls directly where applicable.

On Linux, we've just released our support for X11, removing the need for GTK. As we're drawing the whole app surface, we're always interested in adjust the UX of our controls on individual platforms. If you have examples, let us know.

Finally, for WebAssembly, our current rendering backend is using the HTML DOM, which means that accessibility and other native behaviors are functional. Same here, if anything accessibility related is missing, we're all ears!

Uno Platform maintainer here - We're maintaining production apps ourselves, like NuGet Package Explorer [1], or Uno Calculator [2], and many third-party apps are in production, with some shown in case studies [3]. You can also find some other tech Wasm demos [4] on our repo.

1: https://nuget.info

2: https://calculator.platform.uno

3: https://platform.uno/case-studies

4: https://github.com/unoplatform/uno#live-webassembly-apps

Uno Platform maintainer here - Uno is compatible with both WinAppSDK/WinUI and UWP API sets. Our default project templates have been on WinUI for two years now, UWP mainly being supported for temporary upgrade scenarios to WinUI.

Thanks for the details! We do have lower-end devices to try with, and it's definitely not the best experience. We're currently pinning on the JIT, but troubleshooting is still difficult... much to do in that area.

The native app version of the app generally fares better, even we still have some improvements to make here (the new Android 13 JNI improvements are likely to help us a lot).

Uno CTO here - We're always chasing performance issues in WebAssembly and I'm curious, are you still seeing the 5 second delay when the app has been loaded once and refreshing? We know that mobile browsers are not particularly efficient with Wasm on mobile devices (particularly iOS), but you may be in a different scenario and/or device.

Uno Platform CTO here - About the Xaml Controls Gallery on Wasm, the issue is on our side and we'll update our websites. This specific demo webapp has not been updated in a very long while, and a very recent one to try Uno out is https://gallery.platform.uno for a more accurate representation of the perf/size/features characteristics.

About the payload size of the app, this is still very much a work in progress on all fronts, whether it being missing WebAssembly features, size optimizations on the dotnet front, or linking/trimming (IL and native) opportunities on Uno's generated code side.

On the performance side, threading is coming, AOT (IL to Wasm) is improving significantly in .NET 7 and more coming in .NET 8 to reduce the size of the payload by using newer WebAssembly features (albeit at the expense of older browsers).

As for the menus and toolbars, you can take a look at some our our live samples here: https://playground.platform.uno/#menubar

We know that Wasm-only apps will still be at a disadvantage for while when compared to JS frameworks simply because browsers are offering a lot out of the box (standard JS library, GC, Runtime, HTML layouting/rendering, more advanced JIT, etc...) but that gap may eventually narrow down as Wasm evolves, making the porting and development of webapp using many established language ecosystems an attractive choice.

Hi, Uno Platform dev here. We're not fine with the current payload size of the application, really.

It's definitely too large, and that is the current state of .NET running on WebAssembly, where missing WebAssembly features (like exception handling) are forcing the compiler to generate a lot of code to compensate.

Still, we have one issue in this build where the PWA webworker doubles parts the payload, but even at ~25MB, it is still too big even if it is downloaded once and cached. For reference, the original windows version is around 13MB on disk for x86.

The point of the Calculator exercise is to show the ability to port the Windows calculator as-is (though translated from C++ to C#) to multiple non-Windows platforms. We continue working on that to improve the payload size and performance further, following WebAssembly, browsers and the .NET runtime advances.

- Uno dev here

The Safari Support for large WebAssembly binaries is not particularly great at this point. We hope that the Safari team will improve the performance aspects of WebAssembly, but it does not seem to be a priority at this point (see the Wasm feature map here: https://webassembly.org/roadmap).

For the iPad, the iOS built version of the same app works lots better (https://apps.apple.com/us/app/uno-calculator/id1464736591).

- Uno dev here

If anything, the BCL or common libraries are too "static", where some pieces of code reference statically all features available.

One great example is JSON.NET: That library has basically one big method that type-checks all possible inputs, making unconditionally reachable every dependency for all features of the library. In this case, JSON.NET pulls the XML reader, DataSets, and many huge libraries that are generally not needed. In Uno, we generally don't AOT those libraries and use the interpreter for that (otherwise the payload would explode).

Such libraries need to be changed to be configurable, and dynamically enable dependencies as per the user's needs.

Conversely, many pieces of code are excluded by configuration because of reflection uses, but the .NET team is improving that scenario (https://devblogs.microsoft.com/dotnet/performance-improvemen...) with attributes to tag dependencies and hint the linker.

That would be a question for the Edge and .NET team, but unfortunately that does not seem to be an option. The IL Linker (tree shaking) is removing unused parts of the binaries for the purpose of removing very large portions of code in the final binary. If binaries were to be bundled, or CDN hosted, we'd end up downloading extremely large unnecessary portions of code.

Yet, this simple fact that a WebAssembly app needs to download everything its needing to run puts it at disadvantage with Javascript (you download a browser with all the base libraries only once, and that's not lightweight).

For now, WebAssembly apps (in general and not just .NET ones) are more similar to mobile apps than websites, just because of this significant difference.

- Uno dev here

Accessibility is high on our feature list; we have added aria base support in recent builds of Uno, which the calculator will start using soon (the iOS https://apps.apple.com/us/app/uno-calculator/id1464736591 and Android https://play.google.com/store/apps/details?id=uno.platform.c...) versions of the same app are screen-reader enabled). The Linux one (Snap https://snapcraft.io/uno-calculator, AppImage https://github.com/unoplatform/calculator/releases/tag/1.2.4...) is not yet enabled, but will also be.

The WinUI framework provides great accessibility support, and we intend to port it fully in the coming months.

- Uno dev here

Fair comment.

Here are some other live Wasm apps examples: https://github.com/unoplatform/uno#live-webassembly-apps.

Note that .NET for WebAssembly is still in its early stages and the .NET team is likely to continue working on AOT compilation in the coming months, and the Uno team is going to help. This will be improving the payload size and performance that is currently very much lacking in that mode. Interpreted IL mode (the UADO app) is used where the AOT engine is not yet working properly, providing a base to get the framework itself progressing, while the infrastructure rest is improving.

Many of the .NET constructs are expecting exception handling (https://github.com/WebAssembly/exception-handling), which has to be emulated as it is not yet available in WebAssembly, adding significant code to the payload. Same for other features like null reference checking or indirect invocations (some may know more on that last one). Other features like lazy WebAssembly loading (for more than 4KB at least) and Interface Types to remove any Javascript (https://github.com/WebAssembly/interface-types/blob/master/p...) will also improve the actual and perceived performance significantly.

The immediate goal of the project is to provide the ability for new and existing C# apps (and not Web sites, not yet at least) to be available for non-walled garden environments. We expect the field to progress significantly in the coming years on many fronts, making this kind of apps more useful and viable.

Finally, you'll find that the Windows Calculator port to Uno is actually stretching thin the browsers resources because of the size of the Wasm payload (browser's memory and CPU is going really high because of the internal WebAssembly management). Yet, once the tiered compiler has cached the result, the load time goes down significantly.