A question out of curiosity. What are your thoughts on re-writing in Swift?
If it were me, I am sure my tech-fingers would itch for a rewrite, but my business hands would slap those thoughts away.
I probably would have to do it at some point if Apple decides to completely deprioritize it.
For now, Objective-C even has some benefits. It's more low-level and more hackable. And I think some older APIs are not even available in Swift.
Also - how did you do the visuals in the "Gnarly Bits" section that split the page/components out into verticals? That is such an amazing way to display the internals of a thing like a page.
If these elements could be packaged into a blog theme for whatever blog hosting platforms are popular these days I bet you'd get a bunch of people to purchase. Nice work!
The component split is done by hand in Figma with regular screenshots and cropping. I also used a plugin for skewing.
IMO customizing scrollers is almost always a disservice to users.
It's a single form-over-function thing that I could not resist not to add. :)
I've expanded it by default on bigger screens now. :)
Just look at the Microsoft equivalent: yes, C# is good and all, but the hardcore Windows apps are still using (lightly-skinned) VC++ APIs - after almost 25 years since they started flogging .NET.
Swift is for the new rubes, bootcamp graduates and so on.
C# is a totally different story.
Interesting. Can you share more details?
C# was created as a Java competitor. Although it had great C interoperability, the underlying .NET Framework was still a VM-based runtime with a garbage collector and all the disadvantages that brings. You can probably find various articles (https://longhorn.ms/the-reset/ is one) discussing attempts to adopt C#/.NET code for Windows Longhorn, which ultimately had to be walked back completely. .NET wasn't purpose-built for writing OS components or working deep inside existing Windows code.
Apple learned from this and other examples. The Swift team actively works with teams at Apple deep in native code to make sure they can handle their use cases without performance penalties, and with minimal ergonomic issues.
The difference is really about what the stated goals of the language were/are.
Sure, Apple cares less about backward compatibility, but still, it's unlikely Objective-C is going anywhere, under the hood.
That's a mult-year project in its very early stages, yet we're already almost 10 years into Swift (more than 10 years of Swift internally to Apple).
> All new code is in Swift.
False.
> All new frameworks are Swift-only.
False.
It has already shipped, replacing parts of Foundation in the 2023 OS versions. It continues to grow, and it's a rewrite, so it certainly proves your assertion wrong.
My other points were a bit hyperbolic. Feel free the replace "all" with "the vast majority of". Apple obviously still writes Obj-C in their existing Obj-C frameworks, and doesn't arbitrarily rewrite into Swift, but their internal barriers to use Swift are now almost entirely gone. And I can't think of an entirely new framework that wasn't Swift-only recently.
Which assertion was wrong? I was paraphrasing from the project page itself:
"It is in its early stages with many features still to be implemented." https://github.com/apple/swift-foundation
Your original assertion that Apple wasn't rewriting anything.
I have no idea what you're talking about. I made no such assertion.
Perhaps you're confusing me and "toyg"?
My point, as always, is the truth. You said two false things, which you subsequently admitted were hyperbole. Truth is valuable in itself, and more important than "points", i.e., arguments or motives.
If I were to make a point, though, it's that Objective-C still has a very long life ahead of it, and its complete replacement, if that ever occurs, will be an arduous process, given the amount of extant Objective-C code in the operating systems and first-party apps (not to mention third-party apps). It's not just Objective-C either: C++ is also used quite a bit in the OS. Think of WebKit, for example.
By the way, we could be hired, for the right compensation. Nonetheless, companies almost never try to recruit me, but they still whine about how "hard" it is to find ObjC developers. They're not even looking.
Besides, experienced engineers can learn a new programming language. Do you think that every engineer Apple hired before 2014 had Objective-C experience?
Sonoma is 13% Swift (up from 11% in Ventura), 53% Obj-C (down from 55% in Ventura). The priority actually appears to be eating away from the C/C++ parts of the codebase (currently 33%, down from 42% just two releases ago).
https://blog.timac.org/2023/1128-state-of-appkit-catalyst-sw...
That was a bit rude and unnecessary.
Why do you say that? Do you have experience backing up that estimate?
I would think if the C/C++ developers didn't have their head up their **[1] that could be a standard out of the box feature. There isn't any reason a program couldn't spit to stderr, 'seg_fault: file boots.c, line 1043'
In C++ I'm dubious you couldn't throw an exception instead of dumping.
[1] Got rid of frame pointers because they were sure that would make their dog slow C++ compilers run faster. Voice over. But it didn't make them faster. It made programs impossible to profile.
I definitely wouldn’t call Swift a 10x improvement in efficiency, and I like coding in Swift. I do advent of code in it each year, but spend a fair amount of time just fighting with the compiler–after all these years, it still emits strange or just flat out incorrect diagnostics.