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.
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.
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!'
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.
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.
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-...
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.