SwiftOS, a proposal

Community Showcase
, , ,
22

Just wanted to say, @corbeling and @dima_kozhinov I think there are multiple things required for something like this to become anything more than a dream, including a passion, i.e. shiz and giggles, but also real use case, real benefits it would provide over existing systems, a skilled team / community to execute on the idea, and ultimately low expectations so obstacles do not drain morale.

Part of why I'm asking and what I'm asking is, will a SwiftOS device run faster and be more stable than an Android device on the same hardware? (as iOS generally is) Can it be even faster and more efficient than iOS? My intuition is yes, and thats why it would be worth building, but that's what I'm exploring. Users don't care about OS, but they do care about devices crashing, overheating, not enough ram, not enough storage for large OS updates, etc. If those things can be improved, then it becomes more than just a cool Swift science project.

Also, while of course a GUI is required, funny enough in the age of AI a human readable command line OS could be an interesting UX concept to explore. Talk to the computer, and it can respond in text but also UI "cards" or other visual elements as needed to best convey the information. Files and folders can be categorized automatically. Apps can share a common API between each other, so individual silo apps become a thing of the past and instead little widgets talk to each other, for example Maps and Uber blend together as needed depending on what you ask the OS LLM.

1 Like
23

Have I mentioned any estimates on time or effort?

So if Darwin is good enough, then we should bring it to more systems / devices via Swift. If Darwin can be improved with Swift, then we should. If not, then this work is redundant. That's what I'm trying to figure out.

Apple can decide what to borrow, steal or ignore, and either would be fine.

I guess what I was trying to say was this project should be as Darwin like as possible, while still being free enough to make meaningful improvements to Darwin, such that if Apple wanted to, they could use it.

Agreed they are in a pretty good spot already though, so "don't fix what ain't broke" is probably their perspective.

24

@hassila @Philippe_Hausler @codafi @Jean-Daniel @Slava_Pestov

Thank you for the various resources, links and comments, its really helping me clarify my thoughts. Lots for me to think about still, I have my reading homework set out for me.

I just wanted to touch on two things, kernel + user land + GUI, and redoxOS + hubrisOS

Firstly, (kernel + user land + GUI)
I agree, this is really multiple problems with even more possible solutions. The problems as I see it are,

  1. how can we make the most efficient, most stable OS? It starts with the kernel right? So even if they don't know it, users might care about the kernel after all. (No one wants BSODs from a bad printer driver) So can a Swift kernel offer meaningful improvements over existing kernels? Can a Swift user land also improve these things? Can either the kernel or kernel + user land enable better low-cost smartphones in developing countries compared to Android? Can it save cloud infrastructure money and energy compared to Linux?
    Also agreed there's overlap here with swift on server and embedded swift, I don't know enough about these spaces, so this is why I'm curious.

  2. For the GUI, how does SwiftUI actually become "SwiftUI"? ie multi-platform on platforms Swift supports, not just AppleUI.)
    What I am wondering, is if, for example, the effort to get swift and SwiftUI on Android is already difficult, and a swift kernel would outperform Android anyway, let's skip Android and build the swift kernel with SwiftUI support along with it. Let's think 30 years ahead, not 3.

Secondly, (redoxOS, rust)

I looked through RedoxOS and Oxide / Hubris documentation and marketing, and yes, I think this is exactly the kind of philosophy I am going for. They both list tangible benefits from their kernel over Linux etc. from rethinking with Rust at the beginning, while also listing their inspiration from the past. (I think we just add BeOS and Darwin to the list)
With all the language enhancements in Rust (or Swift), what does that mean for kernel and architecture design? How can we be inspired by the best ideas of the past, but also have new ideas and push for improvement, even at the expense of compatibility. For example, POSIX would not be required, for the same reason Redox lists as not a priority or partial compatibility. OpenZFS would be modified, again for the same reasons. This is the right kind of thinking for this kind of project, I believe.
I am curious, historically the XNU hybrid kernel has lots of benefits, would this still hold true with Swift or would a microkernel approach as they took in Rust be the better approach? I would think this project would want to be inspired by XNU and Darwin as much as possible, but be free to make different choices (like async kernel interactions) as it makes sense.

The final question I have would be, would it make sense to just create a UI layer to bring SwiftUI to RedoxOS? Would that be a simpler path forward? A Swift / Rust hybrid OS? Rust in the kernel and Swift in user land and / or the GUI? (I saw they are working on a Rust GUI, Orbital) Or is there still a reason / benefit to a Swift kernel? Maybe just each community's preference?

25

Last week, I migrated an iOS static library to visionOS. It was straightforward because the systems and hardware are the same; I only had to adjust the binaries. This experience inspired me to think about the future of Apple systems.

Once the transition to Apple Silicon is complete for Macs, I believe Apple will introduce a unified operating system, which I’ll refer to as appleOS (good OS name? :smiley:). However, we will need to be patient for this development.

The integration could begin with iOS, iPadOS, and visionOS, followed by tvOS and watchOS, and ultimately culminating with macOS, which will be the most significant part.

1 Like
26

This is not a language issue, but a design issue. Nowadays, most drivers run in userspace and cannot crash the kernel. This is especially true on micro kernel, which try to run most of the services in userspace.

Porting Darwin which is mostly C and C++ in Swift will not improve performances.

Android is not slower than iOS because of the language either, but because UIKit is the result of decade of UI Framework designing (CoeAnimation, 3D acceleration, 
), while Android UI framework has a very basic design.

Part of why I'm asking and what I'm asking is, will a SwiftOS device run faster and be more stable than an Android device on the same hardware

Concerning stability, most probably not. The high level android frameworks are using a memory safe language. Swift would not greatly help at detecting and preventing more bugs than Kotlin already does.

4 Likes
27

It won't work. But the real reason it won't work is the exact reason why it should probably be attempted anyway: Swift currently has poor to no ability to interact directly with linear memory, registers, and other low-level intrinsics necessary to make an OS work. I've recently made a post about the issues of telling Swift to a specific string of bytes in a program's data section.

Swift leans too much on the existence of C as a backbone. Not in the sense of interoperating with C libraries, but rather, linking C code directly into the program. To wit, not only does the standard library delegate several functionalities to the C standard library, many of these functionalities couldn't be rewritten in pure Swift even if you tried. The necessary language features are just not there.

And yet, trying to build an OS kernel using Swift would actually create a good map of which low-level features Swift is missing for said kernel to not end up 90% in C.

For inspiration for kernel design, though, I'd suggest something more minimal, like minix, rather than XNU.

I also saw Rust mentioned, and just want to point out Rust has a nostd mode. Swift does not. Swift requiring reference counting for its most basic composite, pretty much shoots it out of the water. Situation might gradually improve with the evolution of noncopyable structs. But there's still years ahead of it.

As for possible use of such an experimental OS in the wild, especially as a potential alternative to Android: Not going to happen. First off, when it comes to cross-device compatibility, which is VERY important to app devs, you can't beat a VM. The JVM (and Dalvik) may not be particularly good, but the only viable replacement for it at the moment is WebAssembly. And Swift targeting of WebAssembly is in its infancy.
The second river Swift will have to swim up in this case, is the poor reputation it has been given for initially targeting the walled garden that is iPhone, where side-loading isn't an option. The optics alone would be enough to drive a company like Daylight away. Yes, Swift is gradually getting cross-platform support, and even cross-compilation. But both are still super-experimental.

Until you can compile a Mac program from Windows using Swift, there's no point even considering it as an option. For comparison, with Java, you can compile a program on Windows that would run on a Mac. Swift might eventually get there, but it's still several years away, at least.

10 Likes
28

I think the new embedded mode is close to no-std, and now that we have non-copyable generics we could avoid reference counting for low-level code. We're still missing things like fixed size arrays, borrowing iterators, and the ability to precisely control the layout and alignment of structs, but Swift is a lot closer to being suitable for kernel development now than it ever has been.

9 Likes
29

I am so glad that this discussion is happening though. We might not NEED an OS written in Swift but man would it be awesome and invigorating for morale. It also allows us to think about what needs to happen in Swift to make projects like this happen. This alone makes it important.

4 Likes
30

Isn't it both a design and a language issue? e.g. the language informs the design. And isn't there a benefit to memory safe language usage in the kernel? Isn't that why Rust is now in parts of the Linux and Windows kernel? Or am I mistaken?

I see, aren't there inefficiencies inherent in the JVM that Kotlin relies on, however?

So, from what you're saying, the major benefits would come from extending an open source SwiftUI framework that replicates all the benefits of UIKit (CoreGraphics, CoreAnimation, etc.) to other platforms? Obviously this is no small task, I'm just trying to understand where the big wins would be.

1 Like
31

Just wanted to add this here, as it seemed potentially relevant, though it is also a bit beyond me GitHub - below/HelloSilicon: An introduction to ARM64 assembly on Apple Silicon Macs

32

I am planning to implement a toy-level operating system using Swift for my Advanced Operating Systems course assignment. Once completed, I intend to upload the project to GitHub.
While this operating system may not be practical, it will serve as a proof-of-concept project.
If you have any concepts you would like to explore or suggestions to enhance the project, please let me know. I will do my best to integrate your ideas.
Additionally, I would appreciate any recommendations or resources on optimizing Swift code for better performance. Thank you!

3 Likes
33

Is this going to run on some real hardware, or on top of a host OS?

You would be better off building a virtual machine first, then an OS that runs on that virtual machine.

34

Is this going to run on some real hardware, or on top of a host OS?

If you were replying to me: real hardware. Currently I am targeting QEMU virt machine but I am planing to add support for raspi as well.

35

I am not sure whether I have fully understand your meaning. I agree that starting with a VM is a good idea. Indeed I am testing on an open-source virtual machine software, QEMU, now.

QEMU is able to emulate all kinds of CPUs and boards, including some variant of raspi.

2 Likes
36

The hardware emulator which you have is the virtual machine.

37

Very cool, how's that been going?

38

So I have been processing what many of you have said plus doing my own continued research in my spare time these past few months.

I believe advances in LLMs are totally destroying the moats around big tech such as search (Google) and OS ecosystems who historically relied on large catalogs of Apps to remain dominant (Windows, macOS, iOS, Linux, Android etc.) meaning small companies or the open source community can meaningfully compete.

Apps are about to become irrelevant as they are replaced with "agentic AI" or "smart widgets."

This is our opportunity. An OS for AI agents and digital sovereignty. Here's what I would propose.

Goals

  1. Provide a “next level” consumer OS experience that also promotes digital sovereignty
  2. Meaningfully improve core OS functionality across server, embedded, and AI inference use cases
  3. Showcase the Swift language and push it forward

Provide a next level consumer OS experience providing digital sovereignty

Meaningfully improve core OS functionality across server, embedded, and AI inference use cases

  • Server applications should run better on SwiftOS than they do Linux
  • Embedded devices and AI inference should run better on SwiftOS than they do Linux (either with Swift or Mojo)

Showcase the swift language and push it forward

  • showcase: Swift can thrive outside Apple’s ecosystem; it doesn’t mean we’re afraid of C or Mojo though.
  • LLM inference should be noticeably faster with either Swift or Mojo Differentiable Swift
  • push it forward: help improve the languge with lessons learned from the OS development
  • bring SwiftUI to other platforms, expanding this work Swift.org - Writing GNOME Apps with Swift

Where do Apple and other companies fit in all this?

Apple is a luxury brand built on exceptional services and ease of use, both hardware and software. I do not think SwiftOS will change that, nor the value they provide. I do not intend to compete with them.

I do intend however, to compete with free, junky, android devices, complicated linux distros, and unreliable windows systems. Hopefuly we can have a symbiotic relationship with Apple, FreeBSD, Redox, and the Linux community.

As far as Google and Microsoft are concerned, it may be more competitive. As an aside, it would be compelling if we could include Valve’s gaming efforts on Linux with SteamOS to also be available on this hypothetical new SwiftOS.

1 Like
39

Approaches

I want to take a pragmatic approach that favors the project actually getting built, and actually having a meaningful impact rather than a pure Swift science experiment. It's not that expanding swift or a pure swift implementation is not important, but I don't believe it's the only thing that matters here.

I hope this doesn't rub anyone the wrong way in this community, that's not my intent. Also it's not that I’m against radical thinking or the joy of a pure Swift code base or building from scratch, I just want to be practical about it to maximize our chances of success and to prevent burnout rather than live and die based on unnecessary programming language dogma.

To this end, maybe it should be renamed “Swift + C + Mojo OS” or "AgentOS" but, alas, SwiftOS has a nice ring to it. I think any 3 of these languages (or C++) should feel at home in this OS. As Swift matures, we can replace more and more C code where it makes the most impact, but let’s not let it block us from moving forward.

  • What about Rust? I’m not against Rust, in fact I hope we learn from that community as much as possible, but without clear Swift - Rust interopt I don’t know if it makes sense to write code in Rust for this project. (same for Zig)
  • As for mojo, if you’re not familiar, take a look Mojo đŸ”„: Programming language for all of AI seems like a safe bet to me, as the worst case if it doesn't take off it just means we have python support which is not a bad thing

The way I see it, there are 4 possible approaches to achieve the 3 goals above, each one has tradeoffs and may favor one goal over another.

These will be ordered in least difficulty to most complicated, at least as I understand it.

  1. Make a new linux distro
  2. Build on top of FreeBSD
  3. Build on top of XNU (Darwin)
  4. Build from scratch

Make a new linux distro, rather than a completely new OS

  • Just focus on the first experience above, get to market as quickly as possible as an “Agent AI” distro
  • My preference would be to fork Fedora (or Asahi Fedora https://asahilinux.org for Apple Silicon) and GNOME, of the research I’ve done they stand out as good Linux foundations both technically and aesthetically. (FWIF: I am particular to the default GNOME look since its more like macOS, I don’t like KDE Plasma since it looks like Windows to me; I realize this is all highly subjective, also though utilizing GTK seems like a win)
  • add AnyType, Mojo, and Max, alter the window compositor, add Llama 3.2 1b deep in the system, and see what we get
  • contribute Swift to the Linux kernel or other parts of the Linux stack

Pros

  1. move fast to market
  2. compatible with lots of software and hardware already
  3. Swift runs on GNOME already with the adwaita library Adwaita - Aparoksha
  4. Max already runs on Linux
  5. focus on the LLM UX and inference with Max

Cons

  1. not really “SwiftOS”
  2. lots of legacy and potentially complicated code to deal with, including traditional apps
  3. will the Linux community accept Swift contributions?
  4. It only achieves goal 1 above, not really 2 or 3

Build on top of FreeBSD

  • FreeBSD stood out as a middle ground between some of Apple’s technologies and the broader open source community while having some benefits over Linux. Its also what recent PlayStations and Nintendo Switch OS is built on
  • This is the approach of RavynOS https://ravynos.com and Hello System hello — helloSystem documentation
    • I would prefer to keep things simple as Hello System does rather than trying to get Linux and AppKit compatibility as RayvnOS is attempting
    • However, I would prefer to be forward thinking as RavynOS is rather than focus on legacy compatibility with xorg as HelloSystem is
  • We should use the Hyprland Wayland https://hyprland.org compositor, it already has FreeBSD support, we can alter it to meet our experience goals
  • fork and contribute Swift as necessary, add the above AI inference at a deep level.

Pros

  1. blend of moving fast but more control, building what we need
  2. still has a lot of existing compatible software
  3. focus on the experience, but also work with exiting platforms that have more room for customization

Cons

  1. still not really “SwiftOS”
  2. FreeBSD is still more Linux like than it is macOS like, monolithic kernel, etc.
  3. Will the FreeBSD community accept Swift contributions?
  4. It may or may not be able to achieve all 3 goals above
  5. Hello System and RayvnOS have made some progress, but relatively slow adoption overall

Build on top of XNU (Darwin)

  • Apple’s latest kernel in all their systems is still open source, we could start modifying it and porting it to swift. Apple’s license should allow this work so long as the kernel remains open source. https://www.gnu.org/philosophy/apsl.en.html
  • Probably contributing to and expanding PureDarwin would be a good start https://www.puredarwin.org
  • I would suggest getting it to work with Wayland and use the Hyprland compositor, and ZFS file system rather than HFS+.
    • There are PureDarwin attempts at these endeavors as well, but they did not seem to make much progress.
  • Let’s take the time to make it more of a micro kernel, but I still see the value of a hybrid kernel approach, I may be nostalgic, but can we recapture the magic of OS X Snow Leopard?
  • It should run Vulkan, RayLib https://www.raylib.com, and Clay Clay - UI Layout Library for rendering and UI; and of course add Max, mojo, LLMs, custom widget experience etc.

Pros

  1. More control, more Apple like system. We might be able to get compatibilty with apple apps easier.
  2. Since we will need to go deeper anyway to make it work, more room to innovate and add Swift to the core of the system, and rethink certain design decisions
  3. Still leverage existing C code instead of starting from scratch, get to making meaningful improvements quicker
  4. we can forge a new path forward with a new kind of LLM based widget, instead of traditional apps

Cons

  1. Risk: Would Apple support this work or try to stop it?

  2. Are they working on this already?

  3. See, “with a new operating system: a hardened subset of the foundations of iOS and macOS tailored to support Large Language Model (LLM) inference workloads” Blog - Private Cloud Compute: A new frontier for AI privacy in the cloud - Apple Security Research

  4. no compatible apps from the linux or apple ecosystem will work without significant work

  5. There’s no Quartz, Quicktime, or Metal, we have to fill in all those gaps ourselves

  6. Can XNU, ZFS, Vulkan, and Wayland work together or will it be a huge headache? Are we still inviting too much legacy code?

  7. PureDarwin has been working at this for some time with little success

Build from scratch, following RedoxOS as a guide

  • Start over completely in Swift, using the Rust Redox OS https://www.redox-os.org as a guide
    • perhaps use Oxide Hubris, Minix 3 or seL4 as a starting point
  • They have several influences of the above platforms which we also admire, and have opted for a micro kernel approach
  • they have their own filesystem and window compositor
  • We would start just porting the rust code to swift, and make design changes as needed, including influence from XNU as appropriate
  • If there is better Swift - Rust interopt I don’t mind mixing code, but otherwise just observing Rust patterns and porting to Swift and C seems better for the Swift ecosystem.

Pros

  1. Completely fresh start, free to pursue all the goals above
  2. Redox as a guide gives us a head start
  3. No legacy code or documentation to deal with
  4. Can build a kernel that leverages the strengths of Swift

Cons

  1. Risk: Will we make meaningful improvements, or reinvent the wheel?
  2. Risk: Is Redox a sound guide to follow? e.g. is their file system as solid as ZFS? Is it meaningfully better than FreeBSD?
  3. Lots of work, long time to market. Potential open source project burnout.
  4. No app compatibility with existing sytems, starting with nothing
  5. Lots of design decisions to make

Summary
I have an empty repo setup, if you find this vision compelling, please reach out. GitHub - boldflight/swiftos: An intelligent OS for digital sovereignty

So with all that, what's the best path forward?

EDIT: I was intentionally not voting, because while I have my thoughts I wanted to hear what the community thinks, however, I now strongly believe there is a 5th way forward which I would advocate for: Build on top of FuchsiaOS. https://fuchsia.dev I think its still practical to look at Redox as inspiration, but I think Fuchsia is even more forward thinking, and has the support of Google.
I think this project should start as a desktop environment for Fuchsia, and it could expand further, as I detail in subsequent posts. Of course still happy to see how the vote goes and hear alternative perspectives. IMO "build from scratch" includes building on top of Fuchsia now. (I can't edit the poll)

SwiftOS Approach
  • Make a new linux distro
  • Build on top of FreeBSD
  • Build on top of XNU (Darwin)
  • Build from scratch
0 voters
3 Likes
40

FWIW, these are basic mockups of the kind of experience I'd like to enable.

I feel like it could make computers much simpler and more accessible for non technical folks. It's like the star trek computer, just talk to it and relevant widgets appear.

41

Ok after some conversations with the folks over at Modular, I realize there is a 5th option. Fuchsia OS from google.

When I looked at it, seems to me it is the future OS I imagine, a micro kernel, secure, high performant, replacement for Android (no more Java) and Linux, and curiously enough inspired by iOS (and beOS.) It follows many of the advice people here suggested already. And, even if it lost the "workstation" project status at google, realistically has a lot more weight behind it than even something cool like RedoxOS.

I think the way forward for SwiftOS is that it starts as a Fuchsia desktop environment written in swift and to allow swift applications to run on it.

This is the way: SwiftOS is a desktop environment for Fuchsia written in Swift

  • essentially turn it into a “workstation” OS even though Google cancelled that project
  • allow swift applications to be developed using cross platform tools like SwiftCrossUI
  • build on top of Scenic and Flatland (their window compositor and 2d rendering engine, built on Vulkan) Scenic, the Fuchsia system compositor
  • also develop custom UI for the desktop environment, inspired by composable agentic widgets
    • create a swift (or mojo?) version of streamlit for rapid app widget development drived by data from LLMs
    • bring Orion or Ladybird as the default browser
    • bring AnyType as the file manager
    • bring Max as the inference engine, and run Llama on it

The plan - major stages of possible development

  1. Desktop environment for fuchsia, add swift to official supported languages in user land
  2. Consider modifying or forking core services to swift
  3. Consider modifying or forking the kernel, Zircon, to Swift
1 Like