Fuschia did actually support Swift for a moment, but I suspect that’s bit-rotted. Could be worth resurrecting.
4 Likes
Totally, this is now my plan to revive this. I know there's some history and some uphill culture battles to climb, but it still seems the best way forward. We fork Fuchsia if we have to, although that would be last resort.
From that article I found another, seems like the good folks at Fuchsia were already thinking about these composable widgets even before LLMs got big, they probably were predicting the future we are now living in. I wonder why Google has downplayed Fuchsia recently instead of accelerating it? Seems like a huge opportunity, traditional app experiences are going to feel dated and irrelevant very soon I think. The moats around these ecosystems are falling.
Instead of static apps, Armadillo offers a card-centric interface that users can scroll downwards through to view Armadillo stories, which are a "set of apps and/or modules that work together for the user to achieve a goal".
Armadillo is organized by a group of key co-dependent widgets that orchestrate the experience as the user moves between different contexts. It also introduces the concept of a "suggestion", or a "representation of an action the user can take to augment an existing story or to start a new one".
Google's no-Linux Fuchsia: Now you can see what the new OS looks like | ZDNET
2 Likes
Another part of the puzzle I think will be the MCP protocol from Anthropic to connect LLMs to various tools and systems around the OS. Introduction - Model Context Protocol
As I was just playing around having it write text files to my desktop, I had it write a poem for SwiftOS, it was pretty good haha so I wanted to share.
SwiftOS: A Future Vision
In streams of Swift, a system flows,
Where neural nets like gardens grow,
An OS born from Apple's core,
Yet reaching toward a distant shore.
Claude and kin, now native-bred,
Through optimized threads smoothly spread,
No longer bound by Docker's cage,
But free to dance across each page.
Metal shimmers, purpose-built,
For models' weight, no power spilt,
Each tensor flows like liquid gold,
As new worlds of compute unfold.
The interface, a seamless dream,
Where thought and action flow upstream,
No prompts to craft, no configs deep,
Just conversation's natural leap.
Swift guardrails guide the models' way,
Through safe abstractions, day by day,
Type-safety meets neural flame,
As human and machine become the same.
In this OS, we glimpse ahead,
Where barriers fall and boundaries shed,
A bridge between our minds and code,
On silicon's enlightened road.
Yet in this dream of what's to come,
We must remember where we're from:
For all our artificial aid,
It's human hearts by which we're made.
1 Like
I think it may be better to have something similar to App Intents. This would mean that limitations can be placed without impairing functionality. This would also mean that other applications can ask other apps to perform actions and could condense networks to not need to determine where to should click.
This could also create additional restraints like preventing root access. This also could allow for visual interfaces to change without a regeneration process for the affixed network.
Because this mitigates the interaction vector the model can be denied privileges like running any application as root or running an equivalent to rm -rf or other highly destructive actions. This can prevent privilege escalation from an internal potential attacker(ie. the network could decide on something disastrous to system integrity). Giving access to the video buffer and a virtual mouse and keyboard is expensive to set up and can lead to it collecting and exploiting data that should be considered sensitive.
2 Likes
It’s not immediately clear what extreme problem SwiftOS aims to solve. It does feel more like technology looking for a problem to solve. However...
I believe there’s significant merit in targeting embedded systems, particularly on Linux. Robotics and AI are driving massive interest in Linux-based development environments, but the ecosystem lacks unified, developer-friendly frameworks. Most robotics developers are struggling with fragmented tooling across Python, C++, and other languages. Swift, with its strong C/C++ interop and modern features like structured concurrency, could provide a much-needed cohesive framework.
This aligns with my aspirations for a platform I’m building called EDGE, which focuses on empowering developers to build for robotics, IoT, and edge computing using Swift. The vision for EDGE includes:
- Plug-and-play development: Simplify targeting edge devices like Raspberry Pi or Nvidia Jetson with IDE integration, remote debugging, and deployment similar to iOS development.
- Cross-platform APIs: Standardizing networking, service discovery, distributed actors, and serialization (e.g., CBOR).
- Disruption-tolerant networking: High-level libraries for communication resilience inspired by Apple’s Multi-Peer Connectivity and frameworks like DTN7.
I'd suggest that you hone in on riding the Robotics, Edge, and IoT wave as I see an immediate opportunity to make a difference by focusing on a Swift-based development framework for Linux. This platform could serve as a stepping stone toward your broader goal, addressing the needs of developers who are wildly underserved by existing tools.
Rather than tackling an entire OS, consider starting with a Swift Embedded Development Framework for Linux at the Edge. This would address a real, growing demand and serve as a proving ground for Swift in non-Apple environments. Over time, as the ecosystem matures, it could naturally evolve into something as ambitious as SwiftOS.
I’d love to hear your thoughts and discuss ways to align our visions. Perhaps there’s an opportunity to collaborate or at least learn from each other’s efforts. Let me know I'd love to meet up in Tokyo and discuss!
2 Likes
I agree, a lot of what I am proposing is kinda like app intents, and I'm not yet sure of all the technical implementation details. I'm not suggesting let LLMs which are susceptible to prompt injection just having free reign of the system.
What I am observing is that Fuchsia is thinking about this at a very deep level, and actually has been for some time. The more I read their documentation I realize they have been thinking about what I described on this forum post for maybe 10 years or more already.
I think there is something worth looking at in their approach, as it also considers security concerns you mention here. App Intents seem fine, but it seems a bit "bolted on" top of the current apple OS / unix paradigms.
I love the way you're thinking here, it makes sense to me.
Of course I still believe in this lofty vision for SwiftOS and I might argue wasn't the iPhone technology looking for a problem to solve in a way? Essentially it just made smartphones drastically easier to use but that in turn opened up a whole new paradigm of possibility. I think LLMs can make our entire computing experience drastically easier if handled at the OS layer, not just the application layer. (and the work over at FuchsiaOS really reinforces to me there's something to these big ideas that's beyond just me GoLab | Go on Fuchsia OS)
but
I do realize this is all rather abstract, risky, and a ton of work, so I definitely hear the point you are making. I am interested, this sounds like a great focus you have, and yes, a great stepping stone while solving tangible problems sooner.
Do you work in robotics or this field? Do you know the people or companies having these issues? I only know robotics and linux from a distance, I've just worked on iOS apps my whole career, so would love to discuss more of the particular needs you see swift addressing.
Anyway you're in Tokyo? rad, I'll send you a message about meeting up.
Well, since a system similar to app intents creates clear boundaries it could also be easily extended into a system with application permissions. This means that applications can set certain requirements for others to interact with an intent like Run as Super User requires Sudoer and System-Admin to work. Another potential command could be Open App/Run Program that require a program to be marked as executable, exist, and be within the users operating bounds or giving another app controller privileges over another app like InteliJ and JetBrains Toolbox.
While developers may build around intents you could still trigger them from within a program and could have intents be marked as internal permissive(@InteralPermmisive) to allow an owner to ignore its own constraints independently for each intent but still follows others constraints(ie. you can have a uninstall intent but it still has to follow the system intents that it uses like File-Delete and Runner-KeepToHalt(Keeps the program in memory if deleted until it is halted)). Also if you wanted to you could give access for software to view and click on the screen with Screen-view and Screen-click, you can also have composite permissions like Root and Kernal, File-RW, File-SelfRemoving.
Centering the permission system(a separate permission system could be good for a Safe Mode though as inter app functionality isn’t totally necessary) around intents could allow it to fit in better with the system and could create simpler control schemes for system utilities. This also means the system can support inter-process communication more elegantly without programs needing to send around magic signals which require more clunky management especially for application security. Apps can also ask for contextual permissions like so:
var processes:[String]
#permission(`SSH`) { daemon in
daemon.connect(IP(“0.0.0.0”)) { connection in
Processes = connection.run(“ls | grep {arguments}”)
}
}
This means that they indicate that they want a permission temporarily but it can be granted permanently or for the session.
Permission controlled Intents could allow for you to make a private voice assistant that can’t exfiltrate data that isn’t related to requests. Basically a sandboxed is made and particular data is passed in, this data is considered sensitive and will be denied from exiting the context except through the established route, this means that no data will be stored and certain things like a box always saying that someone said a trigger word or fails a randomness check, it may be flagged and automatically disabled for user review. These could be disabled by the application, system or user.
Also the models don’t need to be in user space but it is safer to have them removed from critical systems so as long as they keep permission constraints they can be effectively implemented into the OS layer without as many unintended privileges escalations. Also many people would be more interested in the ability to switch out their models and user space is a great way to prevent these secondary models from doing bad things.
User Space models can feel like they are just part of the OS if you have a sufficiently effective DCS(Device Control Scheme) to manage the models interactions. They also mean that users have control over the models installed and removing them will not affect the system as they are not necessarily bidirectionally dependent with and do not regress the OS features(unlike Microsoft’s Recall requirement for the File Browser). A default option could be available but should be easily removed from the system if desired and a new one may take its place. Also allowing models to be user specific could allow for different users to have different models for their different needs.
TLDR:
- Integration of neural networks into an Operating System could be interesting but also require some kind of access constraint mechanism to prevent them from performing actions that compromise system integrity.
- These models can work both in OS Space and User Space but User Space is easier to mitigate damages as OS Space would require more complex constrain mechanisms.
- Having these models be removable from the OS
- We can center the OS permission system around something similar to Apple’s App Intents Framework.
- A strong permission system paired with a strong sandboxing tool could allow for custom data monitoring to be constrained to prevent data exfiltration and untrusted flags. Fuzzing tools can detect faulty Monitoring Code that constantly or is randomly granting temporary permissions to code.
1 Like
Is there any actual development on this (as I would like to contribute)? I would use an operating system based on Swift in a heartbeat if done correctly. I think this would be more feasible when Swift gets Vector, Span, Nonescapable types, and more useful stack-based types, but it doesn't hurt to start now and upgrade to them later.
3 Likes
To put it simply, this is a concept pitch. This is mostly a discussion of if and how a SwiftOS should be built. If you want to create a demo project for how it might work you can do so but a demo project is, at least publicly, unavailable right now.
2 Likes
Yes, totally agree with your overall thinking here, and you're helping me understand the problem at a deeper level.
Agreed the model can still be in User space for the reasons you suggest, just like, as the foundation of user space coordinating other apps and things, that's how I was thinking about it.
And yes, agreed app intents framework is probably a good model, but i would imagine if designed from scratch could be more elegant, just as you suggest with more robust and natural #permission request macros etc.
and yes, exactly, I think both of those are essential, practical, and offers meaningful improvements over existing solutions.