They are currently only targeting desktop but I wonder how would you port something like this to iOS, I don't think iOS let's you run a WASM AOT/JIT or similar on iOS. Would you AOT compile WASM to ARM64 and ship that?
a-Shell [1][2] has WebAssembly (and WASI) support and ships with a compiler that compiles to, you guessed it, Wasm. Though there are limitations on what can be done, such as no sockets, no forks, and etc...
around 2020 Apples iOS added technical support for JIT, but the chances that your app gets approved are slim
you can AOT wasm to a normal dynamic library and ship that
various wasm runtimes support an interpreter mode, this slow but might still be fast enough
JavaScripCore supports WASM so you can make apple run the WASM for you ... but more or less in a browser sandbox.
The app store still has rules forbidding any form of dynamic execution of code which wasn't either shipped with the app or typed by the user independent of technical solution.
I had to dig around to find out what language these apps are written in… it appears to be C.
Still interesting though, I’m always fascinated to see what uses come from the WASM sandbox. But I personally won’t be hand crafting UIs in C if I don’t have to.
Designing the platform APIs around C is generally the right move in our opinion. Of course we want Orca to support multiple languages, but we also want APIs that will bind well to many languages and that will be flexible and performant. Furthermore, WebAssembly today is a great fit for C-like languages, and...less of a great fit for other paradigms.
We already have strong WIP bindings for Odin and Zig, and intend for our documentation to strongly feature all three of C, Odin, and Zig when we launch the next major version.
Well, they could at least help to improve the world safety and use Zig instead, which is also part of the community, and at least bring us back to 1978's Modula-2 in terms of safety in systems programming.
Sadly this only supports wasm3 (WebAssembly 1.0) and doesn't yet have a Linux installation (Windows and Mac only). So no WasmGC (modern garbage collection included version).
JVM and the CLR are great, but what WASM offers that those do not is sandboxing. Being able to load in external plugins without having to worry about them opening random files they shouldn't, or starting network connections is some extremely useful functionality.
For this case, where the entire application is WASM you could get benefits if you for some reason have a malicious dependency. Instead of it being able to run with full user permissions, it will be limited by the interface offered.
If you think using containers provides improved security over WASM I don't think you understood the paper. At no point did they demonstrate compromising the host of the WASM program, just corrupting the state of POC's. There are obviously risks associated with that, but nothing that improves by going with isolated/containerized native code.
Yes currently lacking ASLR and read-only memory sites increase some risks, but strongly typed function pointers, control flow restricted to function entry points and call stack isolation more than make up for it
It's a 4 year old paper, and the biggest issue it brought up, malleable read-only data, is currently being addressed with the memory control proposal. The fact that a virtual environment can't prevent all types of erroneous program behavior is not particularly noteworthy. The fact of the matter, in particular when comparing WASM against containers, WASM is a generational step forward in terms of permissioning and isolation.
To a degree, everything can be exploited, for sure. Memory safety always remains an issue. The sandboxing I was referring to however was the sandboxing from arbitrary syscalls. While some operating systems have functionality to do so (for example OpenBSD's pledge), this is unfortunately still very much a niche feature.
Containers solve this problem to a degree, but running GUIs or plugins within them is non-trivial for end users.
> but what WASM offers that those do not is sandboxing
The OS's themselves offer sandboxing, not the app platform. Mac has a locked down permissioning system and Windows has App Containers. Linux has a few sandboxing options available, like flatpak
Personally I've been running native apps on Windows / Linux for ages. No problems so far. I do not see any real value in sandboxing in my environment. What I do see is how crippled sandboxed apps are comparatively to native desktop apps.
In that case: or transpile to Go. Just as cross-platform, but native binaries, fast build, and probably simpler code-gen. Still get GC, still get a fine ecosystem & stdlib, still can make wasm from the generated Go code, still can use boxing/unboxing (`any` instead of `object`) if the source lang is not-statically-typed.
Unless you have C deps or "native GUI" needs (ie. C deps) of course =)
It's pretty bloated and slow compared to alternatives. This may improve if WasmGC gets integrated instead of part of the payload, but it's still not a great solution, especially on constrained devices. The flip side, is running in server mode means the laggy round trip actions that feel somewhat painful in contrast, reminding me of ASP.Net WebForms and how painful that was in practice.
Maybe replacing containers...I had a better developer experience and a better overall quality of life when I deployed war files into a servelet container (tomcat). I wasn't patching operating system vulnerabilities across a jagged sea of micro service images or patching vendor supplied images either (literally had to do that with Kafka). I deployed a fucking war file. That's it. And I'd also imagine that a WASM module\app would have a much snappier start time without having to lug around the overhead of a container...And "Alpine Linux" can go ahead and kiss my ass (no offense).
Must be me, but the page shows nothing now except for an 'empty' page (logo and the statement: "web assembly apps without the web" and top nav "blog", "code", etc. Navigated to https://github.com/orca-app/orca and at least can see what this is all about. Perhaps something was removed or edited?
it shows "latest posts" for me maybe they changed it recently or maybe your ad-blocker remove that "news feed" due to classifying it as ad or unwanted noise
I would totally compile wasm3 to wasm to support wasm experimental features my wasm host is not supporting because they are experimental. And them app itself will include another copy of wasm3 to support plugins. And plugins will have plugins too. And the will all make asynchronous HTTP calls that don't handle timeouts, never retry and assume all operations making three HTTP calls in a row (to have a cleaner API design) assume they fail atomically.
And then I have a cup of coffee enjoying the glow of a nuclear power plant supplying the energy needs of this. And the power plant control interface will also run WASM. And then somebody will do experimental shutdown procedure after the plant was put into operation using this control interface. And that's how I know to celebrate my birthday
We badly need something like this but mature.
Cross-platform UI development is a total mess with literally zero solutions ticking all the boxes.
If you want to write an app which will target all the major platforms (3 desktops and two mobiles), want a native look and minimal effort for every platform you target, there is nothing apart from QT. And it's a real pain to deal with unmanaged memory. Also, QT is a mess, you cannot define your interfaces declaratively (with QML) and easily interact with them from C++ code, you won't have any typings. So, you either have to go the ancient way of imperative UI definitions or do everything in QML which is total mess.
If you drop native look requirement, some small things like https://www.egui.rs/ might work for you.
If you drop the minimal effort requirement, all the webivew based mess might help you but it won't be easy due to multiple reasons.
IMO this is an impossible dream and folks need to stop chasing it. Particularly when you’re trying to do desktop and mobile in one, they’re just totally different paradigms.
The alternative, which I have found far more preferable: code app logic in Rust, which can be mapped to Swift, Kotlin and JS (via WebAssembly). I’m sure Go, Zig or whatever is capable of similar, I’ve never explored it. Then map that shared code to native UI.
SwiftUI and Android Compose are far from perfect but they’re 100x more understandable than what came before and have a lot in common with the React model of UI. It’s more work upfront but in the longer term I think it’s better to be using OS UI frameworks directly rather than adding a dependency between you and the OS.
As much as it sucks in a lot of ways, I think Tauri and similar embedded browser control options may be the best option today for cross-platform mostly native application logic. The browser's support of HTML+CSS is just that good. I would like to see tighter integration into at least platform configurations for the primary background, activity and accent colors and typography/fonts. Beyond this approaches, such as Material, etc are common enough that they don't feel too alien in applications. Maybe more so on mac, but still.
At this point, if a tool doesn't support Windows, Mac AND Linux, I'm pretty unlikely to touch it. I know Linux is a minority here, but it's disproportionately large for developers on their own hardware at this point. I'm tired of working with things that don't advance what I can use on my own.
Yeah. The more time I've spent writing code, the more I'm convinced that a largely agnostic core and a thin UI per target is the only reasonable option.
That "thin UI" can leverage a cross-platform toolkit for the long tail of lower value targets, that's completely reasonable because that's what they excel at. But you'll pay (a lot) for it later if it's not aggressively simple and disconnected from your internals, because those tend to have very painful major version migrations.
As a bonus: doing it this way generally gets you MUCH simpler and more testable core systems, and MUCH better accessibility.
> will target all the major platforms (3 desktops and two mobiles), want a native look
This is always a very serious pain point no matter what solution you pick: the native platforms all have different controls and ideas about what your UI should look like. It's inherently not possible to have a cross platform true native UI - the best you can get is reuse of models and controllers, with a different UI layer on top.
> It's inherently not possible to have a cross platform true native UI
QT does a relatively good job at that. It is possible. Of course there will be severe limitations, but in any case it would be better than total impossibility of building good looking multiplatform apps single-handedly.
> want a native look and minimal effort for every platform you target
IMHO this is impossible (through a bit dependent on how you would interpret the previous sentence)
the way you would properly structure a app from a UI and especially UX perspective on mobile is often fundamental different then for desktop. Partially due to one group being mainly keyboard+mouse and one being mainly touch, partially due to one being mainly on "small screens" and one being mainly on at least 13" screens (tablets and very small Laptops are in a unlucky in-between spot)
to make things worse iOS and Android have diverged quite a bit wrt. "what is intuitive/expected"
through you can ease that issue by having just a slightly native look, but that can easily fall into a uncanny valley, and for proper UX you need to at least follow the native input handling, as in keyboard shortcuts, gestures, navigation patterns
this is why IMO "Cross-platform UI development is a total mess with literally zero solutions ticking all the boxes." is a mess because solutions end up either in a uncanny valley by being somewhat but not quite native for all platforms or in a good for one but not other platforms corner or you need to add a lot of manual platform specific customization. Worse it's often a mix where for some features some of the points above apply but for other features others...
through this doesn't mean you can't share stuff, e.g. sharing app business logic is quite viable, sharing complicated UI/UX logic for unusual custom elements is harder but should also work, but in the end (if you can afford it) using a platform specific UI library for Android, iOS is probably the right way to go. Through for desktop IMHO outside of having to have different Keyboard shortcuts you probably could use a mostly one size fit's all solution with at most slight tweaks.
It’s not that we don’t want to dream. I’m right there with you. The issue with your examples is that they aren’t political but UI design languages are. Imagine if the UN appointed one ambassador to unilaterally represent every Slavic country simply because they all happen to speak similar languages or be located close to one another.
The issue lies not with the implementation but the requirements themselves. Each platform has its own design philosophies that either conflict with other platforms or, in some cases, are simply so vague as to be incoherent. Sometimes it even looks like competitive subterfuge.
>Imagine if the UN appointed one ambassador to unilaterally represent every Slavic country simply because they all happen to speak similar languages or be located close to one another.
That would immediately bring the world one step closed to the peace in the Middle East
It depends on who you ask whether software development is like agriculture or like some other types of work. Building a cathedral still takes about a 100 years like it did half a millenium ago.
I think tailoring each app to the platform you're targeting will always look better than cutting corners. Especially if you can integrate your app into the native styles of the target platform rather than just embedding custom CSS into every application so the target platforms lose all character entirely
There is one solution and it's Lazarus IDE, and I'm yet to see a better/easier solution that delivers what it delivers.
- Native and easy UI on the three major platforms along with many more.
- Self-contained executable. (Zero dependency)
- Completely free and open-source.
- No restrictions on commercial products (unlike Qt).
Assuming no specific OS calls (or contained within IFDEF checks), you get your project you created on Windows and simply compile it on any Linux distro and you get a self-contained that will work for any other distro by simply publishing the executable.
It's a shame that this tool isn't mainstream for what it can deliver. Most complains I see are of those "old is bad, new is good" or "I want mah curly braces", referring to Pascal.
Flutter has all platforms (at least when it comes to pure UI) with native appearances. It won't take you very far though, mainly because a desktop app is wildly different in usage to a mobile app. I don't know why people keep insisting on having everything in the same codebase, which not have a page for Desktop and a page for mobile, with the business logic in common only ?
Don't get me wrong, I like Flutter... but it isn't exactly native UX on any platform. And it's a large part of why my own take is that embedded browser platforms (Tauri, Electron, etc) aren't actually so bad for a UI rendering surface and that you can go a long way with component styling that is at least closer to what the platform is doing (colors, fonts, etc).
You can use a Material approach, and enough apps are similar enough to this, even in the various platforms that it can look "close enough" for many or even most things. Though Mac will be more oddly out as their apps tend to be far more consistent than with Windows or Linux.
One might also argue that we badly need just one desktop OS. For some reason this is not reality. Zooming in on the Linux platform, there is not even one native user interface to target for.
If you really want this, then your best option is probably a web-based user interface.
Quit naming projects after endangered species. When people search for "orca", they shouldn't be pointed to random software projects but instead research and advocacy groups fighting for orca rights and wellbeing.
This was downvoted, and tbf it is a rather niche complaint.
But fwiw its something I've been thinking about a bit recently. Naming something, parodying something, etc. all siphon off the legitimacy and good will of the thing they're referencing.
Kinda like how Bill Waterson never made Calvin and Hobbes spinoffs, so anyone who experiences C&H does so through the comics first and not ads or shirts or movies. Having those would devalue the comic.
Anyways no real conclusion, other than to be mindful of what you crib & to be offended when big marketing firms try to degrade the Mona Lisa into a Coke marketing vessel.
Is it really a niche complaint? I'm getting confused with the minimum effort generic names too. Orca. Fork. Cursor. Apple. Wheat. There's probably thousands of AI projects named Jarvis out there too. At work, we use Localize and Lokalise, two different products that get confused a lot.
I liked it when we were at minimum variation. Call it Mega Dolphin or something.
