Hacker News Reader

Comment by adastra22 | Hacker News Reader

This looks like not a reskin of an existing FreeBSD or Linux windows system, but an actual reimplementation of macOS. Very interesting if they can pull it off!

I wonder though, why start with old Objective-C cocoa APIs instead of Swift?

View on HN

Objective-C is the ABI of all UI-related macOS frameworks and it would probably always be. Even if you're writing in Swift, as long as you're using AppKit, you're using Objective-C classes under the hood. There's no such thing as "Swift Cocoa APIs". And SwiftUI is an abstraction layer on top of, again, AppKit/UIKit/WatchKit, which are themselves all written in Objective-C.

That used to be true. https://developer.apple.com/documentation/realitykit/ https://developer.apple.com/documentation/GroupActivities

Then a question: how does one call these APIs from another language? You can use Objective-C frameworks from anything that can call C functions, by manually doing objc_msgSend and all the related stuff. But will you have to write a Swift wrapper for these?

I would guess that's the linker's job?

I don't need to do that in my day to day job, but I do remember that as part of an OS class at school (some 20+ years ago) one of the tasks we were assigned was that we had to work in pairs of teams, where one team would implement a function and another team would implement code that called that function, the only requirement being that both teams had to use different languages. The point of the exercise was to show how, provided you had a defined API, thanks to linking you could use the best language for each job.

In many languages you need to somehow define the symbols you import before the linker comes into play. How would you define Swift symbols for C++? For Java? For Rust? And that's provided their linkers would actually know what the Swift ABI is — and they most probably don't. So I guess your only option would be to descend all the way down to assembly and shove the right things into the right registers and then jump to the right place.

On macOS, the Swift ABI is stable. It is different from the C or C++ ABI. Somebody would need to implement the Swift ABI for another language. Which is kinda tricky because Swift has many features that other languages don’t have. Rust could probably do it, or C++ with a ton of templates I guess.

Yes, just like on Android you will need to write Java or Kotlin, and the NDK only exposes game development APIs.

Objective-C is done, see WWDC 2022.

The greater bulk of the macOS userland is still written in Objective-C.

Yeah but they expose the same ABI. If you can write in Objective-C, you could write it Swift and externally it'd be no different. And since they're reimplementing this stuff from scratch, I'm surprised they didn't just do that.

(I'm saying this as someone who would be more inclined to contribute if it was written in Swift.)

I imagine they are using either GNUStep or Cocotron as the basis for their Cocoa support, not starting fully from scratch.

Looks like they have copied and pasted large amounts of code from Cocotron.

It's a BSD. (Knowing that, you probably wouldn't ask them, "Why C and not C++?") As a language (and ecosystem*) Objective-C is mature and lacks complexity in a way that doesn't apply to Swift.

* They definitely did not start with Objective-C and a blank slate here; they're folding in monumental amounts of third-party code

I wonder if Cocoa is that language specific or if it’s become legacy tech. When Swift was announced and when I explored it for personal projects, I was very much calling Cocoa APIs. They definitely catered to ObjC-isms, but my impression was that all of the underlying UI frameworks were being preserved even if they might gain additive APIs to be used less awkwardly in Swift.

This year Apple made the point Objective-C is done, time to move on, for those that were still wondering.

Around minute 4, or go through the transcript.

https://developer.apple.com/videos/play/wwdc2022/102/

“Objective-C is done, time to move on” … except for Apple themselves, where we still see a steep rise in ObjC year over year with no visible sign of slowing that incline.

Likewise for AppKit.

Apple, the “do as we say, not as we do” company.

Interesting, I wonder if that is for technical reasons (low level stuff; performance?) or just inertia?

Mostly inertia, the only new subsystem where Objective-C plays a major role is Metal, and even there most examples make use of the Swift bindings.

Except several systems have been rewritten in Swift for Ventura, also mentioned in other talks.

Besides this is nothing new in the industry, some Android business units and Windows ones, are quite adverse to touch anything besides C++, regardless of the guidelines to the rest of us.

It’s also funny to think of companies like Apple, MS, etc. as having 1 opinion or even tactic.

I know they say it. But they’re made up of 100s-1000s of groups. And at Apple especially, many of these groups are not allowed to talk to each other.

From the outside it’s easy to see companies that way. But if you’ve ever been inside a large company, you know what I’m talking about. That’s not unique to tech, either.

And rewriting software in a new language is always going to get back burnered by delivering new features. Until there’s a fundamental change they want that justifies a rewrite, a codebase is staying in its current language due to inertia.

Heck, companies will lie to themselves about these things. My favorite is this pattern

Execs: We’re all going to X!

Crowd: Yaaay. [Some project leads look at each other with a mix of sarcasm and fear.]

Initiative kicks off. Swag is distributed. Projects are identified.

Exec: [Looks at $] Well, except this one. And that one… Ok, we’ll replace all of these [waves arms] in 3-5 years.

Narrator: 3-5 years continues to be relative to the current date.

.net being a good example of this

I'm sure I still have CD case with 'Windows .net' printed on it which contains Windows 2000 and SQL Server... .net?

The marketers really went to town on that one, would have loved to be in the creative pitch meetings for that swag.

'.net, what is it??'

'Who knows??! But if we print .net in multicolour on enough stuff, somebody might figure it out!'

> The marketers really went to town on that one,

To be fair, the developers at Microsoft went to town on it as well, adopting C# for parts of Windows Blackcomb, including the File Manager, the Desktop Manager, and (some of) WinFS. It turned into a fiasco and the .NET adoption was mostly dropped, as far as I remember, when they did the "reset" and pivoted to Vista.

Because the WinDev team sabotaged, the effort, instead of doing an Android or ChromeOS with everyone roaming into the same managed direction, they made sure they pretty Windows APIs would win..

So since Vista all new APIs follow Longhorn ideas, while using COM, followed by Windows Runtime, with the caveat that tooling is just as bad as before .NET was invented, but hey they are happy fellows on their little turf.

While there are parts of Swift that I like, I am more and more convinced as time goes on that Swift in general, and specific sub areas of Swift (like SwiftUI or Swift Charts) are destined to follow the trajectory of .NET as decried by Spolsky in How Microsoft Lost The API War [1]. To the extent this is true, it is likely smarter long term to avoid Swift except in cases where Apple has enforced its usage (like the watch).

For problem areas where Apple's frameworks provide a useful or necessary solution, accessing them from Objective-C instead of Swift is more stable. Examples like Accelerate, HealthKit, and StoreKit come to mind.

For problem areas where Apple has no advantage but you want to ship code there, oft derided but broadly usable solutions like C++ (which connects to Objective-C better than it does to Swift) or Javascript dominate.

Even Apple appears to struggle at drinking its own koolaid, given the recent criticism of the Settings port to SwiftUI. [2]

[1]: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

[2]: https://daringfireball.net/linked/2022/08/15/ventura-system-...

The more I use Swift, the more I miss Objective-C. I tend to like opinionated languages that take firm stances - all method calls are messages, everything really is an object, fail early, etc.

Swift seems to be more and more a kitchen sink language. Compile time linking, v-tables, and dynamic dispatch? Sure! There’s so much syntactic sugar masking seemingly unchangeable implementation details (throws/try/catch) and odd implementation choices (protocols associated types vs structs and classes generics). Builder methods are just plain weird, imho.

I had a lot of hope for Swift early on, but it seems like a rudderless ship.

All new projects I was involved in over the past three years or more were in Swift. I would say it is considered in bad form to start a new project in anything other than Swift.

Further, I saw many legacy projects move from Objective-C to Swift (Podcasts comes to mind). (Some legacy Objective-C apps like iTunesU, sadly, were "sunsetted".)

Until recently, I believe there were issues with frameworks written natively in Swift so I saw a few smaller frameworks thrown together in Objective-C. I believe that, whatever the issues were, are no longer pertinent.

I can say too that there are many engineers that don't even know how to code in Objective-C. The younger engineers learned on Swift and are even hostile to writing in Objective-C (ha ha).

Of course Apple is a big company and I can't speak for the whole of engineering - only the teams/orgs I was involved with. And since I left Apple last year I can only guess at the current state. But the direction was clearly away from Objective-C.

As you can imagine, the biggest hurdle to 100% adoption is going to be bringing over legacy projects. Porting to Swift will probably always take a back seat to features, bug fixes. If the pace at Apple were more leisurely, not a suite of new OS releases every year, perhaps we could have our cake and eat it.

They can't be the ones to turn the lights off if they're not the last ones in the room. iTunes was famously Carbon for long after Apple said "use Cocoa now", but it came around. It's fine to tell everyone else "stop doing ObjC now", then to slowly strangle it out of their code as well.

SwiftUI is an intermediate step in this transition. Expect the UIKit/AppKit bits to eventually disappear.

Except SwiftUI is itself built on top of AppKit/UIKit.

Many of the views are, but some do not bind to AppKit/UIKit and instead are drawn directly (I think maybe Image is one?). The idea is you could keep SwiftUI's API stable while deprecating AppKit/UIKit piecemeal underneath.

This is what I meant

Reply on news.ycombinator.com