Orca: WebAssembly Apps Without the Web
orca-app.dev
orca-app.dev
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.
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.
Writing the host in C seems like a bad choice though. Isn't that exactly the kind of software you want to ensure is memory-safe?
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.
If you don't have an answer you can help us all not replying
This is the JVM but using WASM as bytecode, which is to say it is yet another WASM interpreter but this one provides a runtime with a canvas.
I'm not joking, no...
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 =)
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.
"Everything Old is New Again: Binary Security of WebAssembly"
https://www.usenix.org/conference/usenixsecurity20/presentat...
Just one of the papers slowly coming up on USENIX and other security related conferences.
Want a proper sandbox outside the browser?
Use OS processes, containers and OS IPC.
Containers solve this problem to a degree, but running GUIs or plugins within them is non-trivial for end users.
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
Also I explicitly mentioned that is the first paper of many others, that are starting to appear on cyber security conferences.
For my bonafides, this is me discussing this class of vulnerabilities 8 years ago: https://groups.google.com/g/emscripten-discuss/c/gGjklbJiX1c...
I would not like to run stuff with an implicit permission to read my browsing history and all the ssh keys.
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
I don't like this timeline. I can't visit home and I can't have typed continuations in a lightweight wasm interpreter either.
> I don't like this timeline. I can't visit home ...
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
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.
Or that 64kB of RAM was plenty enough to make all the software we needed.
I would rather always dream big and help invent the future.
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.
That would immediately bring the world one step closed to the peace in the Middle East
There was a line from the Onion’s vox pop series that summed the situation up perfectly:
“In these times of division and strife, they should turn to the Bible for help.”
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.
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.
doesn't mean they don't use QT on all platforms
but with different impl. for each with very little shared UI code if any
(but often shared code behind the UI, e.g. business logic, data validation etc.)
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.
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.
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.
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.
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.
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.
- 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.
I think that would be a wonderful way of raising awareness.
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.
I liked it when we were at minimum variation. Call it Mega Dolphin or something.