SwiftOS, a proposal

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

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.

@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?

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

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

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

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.

7 Likes

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

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

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