Hi folks,
I was replying to that big comment thread about SwiftUI for other platforms, and thought that what i've answered there would be a great thing to describe in its own post and get a little feedback from the community, giving i'm about to launch this.
Im about to launch a platform for application development, that is multi-process and multi-os based on a heavily modified Chrome engine.
The primary application SDK is for Swift, that will have direct access to the web layer and even the compositor layers that are gpu accelerated (the ones that the web layer actually uses).
I bet it will be a perfect match for a SwiftUI kind of layer as it can directly draw to the accelerated compositor layers through the Canvas API for instance. (This comment was targeted at the SwiftUI post)
You wont have to worry in binding to many graphics apis because the platform will have this covered for you.
I was trying to keep this to myself until the launch phase (a couple of months from now), but giving i think this will be a perfect target to this and giving i'm almost there, seeing people anxious about stuff that the platform im describing can help, i couldn't hold it.
This platform will be a mix of a browser and a application platform like the ones you see in phones, with the difference that for each app there's an application process running as a service and handler of a RPC service(you can think of it as a application server process) distributed with the application and a application UI process for each UI launched (much like the renderer process in Chrome).
The applications distributions is P2P and the storage is also distributed through P2P, later when the applications are installed on the "nodes" (the host OS) they can serve through RPC over TCP or only IPC if they want to serve it privately only to the local machine.
The storage layer can also be synchronized over the p2p network in a distributed fashion.. so users can have their persisted resources and share them with others or clone to themselves in other machines.
Giving its multi-process, its a good target for multi-platform application sandboxing as important things all go through IPC and can use a permission system that is controlled by the machine/host owner.
The applications will have to be good citizens and define a API that will be used by the RPC service handled by the application logic.. So it will be easy to have a inter-application interface or network between apps in the platform.
I wonder whats the interest of the Swift community in this kind of project, as it would help a lot all of us in developing applications in Swift that could easily run in other platforms with a rich SDK as in smart-phone platforms.
EDIT: Just a detail, that the application will feel as its running on its own (think Visual Studio Code).. the user wont need to know about all of those details, and the developer will have a lot of cool stuff being automatically managed for them.
The application for instance can have a native binary that will launch it, that is actually just a shim calling the RPC method on the host machine that actually launch the application.
As the "application server" process(singleton) runs all the time, the application can manage background tasks and later when the users needs it just show in the UI what it have processed before.