There is no reason to replace perfectly working code that is battle tested if the requirements don't change.
The fact that the new binaries on it are written in Swift is showing their 100% commitment to Swift, which is great to see. And why wouldn't you, Swift is a joy to work with, especially if you're from Apple :)
It seems to me that Apple's strongly insular instincts serve them well for integrated product design, but for the Swift language, alas, they form a severe hindrance to wider adoption.
What more do you want?
Unfortunately it seems like they didn't really mean it.
It fits in line with how I've seen Apple developers at conferences highlighting the memory safety aspects of Swift. They are maybe hoping to position it as a competitor to Rust on that front. I wonder how they feel Objective-C compares from a safety perspective compared to Swift. I wonder if that might influence decisions on what kind of stuff gets re-written in Swift.
I hope we can see further graphs like this to track what happens. I don't feel MS ever committed to C# in this way but that is due to ignorance at the numbers. I would love to see all of that data for Windows and even macOS.
Perhaps it’s just not increasing much since the value is in percentage and overall code size has increased dramatically.
I doubt they will rewrite Mach/XNU, for example, in the foreseeable future.
I think that’s impossible, Swift should try to be a great language for building Mac/iOS apps and hopefully frameworks.
But what do I know. I wouldn’t think writing a new industry grade C++ compiler in a modular architecture would be feasible. Just use GCC. And yet here we are with clang and LLVM.
There will be language subsets for embedded and kernel development, not all features would be able to be used at the lower levels.
Are you familiar with Apple's MO? Take a perfectly good, working app and replace it with a total rewrite with half the features.
On the consumer side, iMovie was probably the worst, not even being able to read projects made in the prior version. Not just the interface but the whole paradigm was different, only supporting a few features of the original program. I gave up on it.
iPhotos was another example: it had languished, but what came out had less functionality (no more external streams, for example) and simply threw info away (tags, face recognition, added metadata like location was all gone). Links to external tools were no longer available, though added later.
This happened to Pages and Numbers (& Keynote?) as well but I don't know if they count as consumer or pro apps. Consumer I guess.
On the Pro Side, replacing Final Cut Pro with Final Cut X (~2010 or 2011) pretty much drive video production off the Apple platform onto Windows. Like the iMovie case (I guess they didn't learn) it was a completely new interface without most of the features of the old version. I hear a lot of the functionality made it back in over the following decade, but you wonder why.
I think the loss of the pro production side in video (and replacement by Adobe) led to the abandonment of Aperture too. Apple announced that the consumer product Apple Photos was supposed to be the replacement -- what a joke!
But now, the Apple brand has its own status, independently of any particular group. Their products have gone the same way.
There are lots of those apps where they enhanced the generic user's ease of use, while maybe not maintaining features that weren't used.
I wouldn't be surprised if their apps are instrumented to work out what features are needed or used.
Their apps are now effectively cross platform across all of the devices you have, so they have focused on making that more seamless, while, of course, trying to hook you into Apple One to get the shared storage you need in iCloud.
There are reasons to rewrite it, though I’m sure it will take a long time and they’re prioritizing risk vs reward.
There are kinds of bugs that Swift can provably catch that Objective-C can’t.
There are bits of safety that Swift can ensure without needing to do additional boundary checks or something else, leading to faster/smaller code.
Perhaps biggest of all Swift doesn’t need a runtime like Obj-C. Apple has done an amazing job tuning it, but a direct function call is always going to be faster than message passing.
1. The empirical evidence does not support the notion of fewer bugs, even for static typing, never mind Swift
And no, this is not from lack of trying. People have tried to show this time and time again. And time and time again they end up not showing it, with effect sizes tiny and pointing in both directions.
And as an anecdotal example: which way has Apple software quality gone since they started adopting Swift and SwiftUI? System Settings anyone?
2. Swift is slow, not fast
I did fairly extensive research for on this for chapter 9 of my macOS/iOS Performance book. Even those cases where I fully expected Swift to be faster, which were not numerous, it managed to be slower. And there are really egregiously bad examples, like Swift Coding, which despite the overwhelming evidence to the contrary some people still believe to be fast.
Why do they believe it to be fast? Because so much work can be done in the compiler. So it must be fast. But it just is not. In fact, it's ludicrously slow. This is probably lesson #1 from performance optimisation: things are not fast because simply you did something that you believe to be fast. You need to measure to figure out whether they are fast and in order to figure out how to make them fast.
(And those mistaken beliefs actually lead to slow code, because you already did the thing that makes it fast, not need to check or optimise. I am pretty confident that a similar effect happens with static typing and safety.)
Or check out the computer languages shootout. Swift tends to be somewhat on par with Java. Which is not particularly fast.
3. Swift needs loads of runtime
For example, due to the somewhat bizarre idea of having protocols be polymorphic over (pass-by-value) structs and (pass-by-reference) objects, Swift has to dynamically dispatch the copying of individual arguments to a function when protocols are involved. If you're both lucky and not using modular code, the compiler may be able to figure out how to elide that dispatch. But it won't tell you if it managed to figure it out or not.
Oh, and speaking from 30+ years of experience: message passing simply is not the bottleneck in 99%+ of the cases, and if it is it is fairly trivial to remove.
https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...
The Codable stuff was this:
https://blog.metaobject.com/2020/04/somewhat-less-lethargic-...
As shown and discussed in the series, @objc is not an issue. Do you have reason to believe that Swift performance in general or Codable in particular have improved since?
I mean, you can run these sorts of tests yourself, and you probably should. It's not that hard.
Is your book available on Apple Books or some other electronic format besides kindle?
Swift most certainly has a runtime: https://github.com/apple/swift/tree/main/stdlib/public/runti... And most or all of it is written in C++, not Swift last I checked. Whenever you see a `_swift_fooBarBaz` symbol in a stack trace, that's the runtime.
Working code has also squashed a huge number of past bugs though.
It appears to be 50:50 with Obj-C for now. See how the Obj-C line in the "Evolution of the programming languages" chart is still growing steadily. I can see Swift taking the majority of new code for the next year though.