Swift was conceived and sold as an all purpose language.
To an extreme degree, in fact. Lattner has said many times that it's intended from scripting to system programing[1]. Currently it's good at neither.
I think a language that's simultaneously productive at this two extremes is impossible, but it was their goal.
“In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead.”
> Our primary goal is to achieve implementation parity with Foundation on Apple platforms. This will help to enable the overall Swift goal of portability.
But why are these even two separate libraries? Is it normal for different platforms to have different implementations of the standard library? I'd assumed that most of the library would have been written in Swift itself, which should theoretically make it be as platform-independent as Swift is.
Foundation is not the standard library of Swift. Swift has its own standard library that is bundled with the language on all platforms that are supported.
And Foundation itself isn't written in Swift, a good portion is written in C.
> A significant portion of the implementation of Foundation on Apple platforms is provided by another framework called CoreFoundation (a.k.a. CF). CF is written primarily in C and is very portable. Therefore we have chosen to use it for the internal implementation of Swift Foundation where possible. As CF is present on all platforms, we can use it to provide a common implementation everywhere.
The Apple versions of foundation have to be compatible with the Foundation/CoreFoundation equivalents. They also have more than a decade of binary compat to maintain
Sometimes I think an Objective-C 3.0, that would break with some of more problematic C flaws would have been better, even though I dislike @ and [] everywhere.
The question is, where does ObjC end and where does Swift start? When Apple announced an Objective-C without the C, I assumed they'd keep the Smalltalk object system and message passing. It still boggles my mind that they took a hard turn into the world of value semantics and extremely static types, with all the ABI problems that we know from C++, plus all the interop hacks to bridge both worlds. The syntax almost seems like a superficial detail compared to the new object model.
On the other hand, the Smalltalk model would not have worked for SwiftUI. It really feels like Apple has bet the farm on the next generation of libraries/frameworks.
Came here to post the same. We tend to spin around the shinny and new. These numbers, even if a but inaccurate, are sobering and show who's really running the show.
Every year the supporter of Swift will claim new project are all going to be Swift right down to system level. And every year they have been wrong. It doesn't seems Swift is replacing Object-C in system level usage anytime soon. And only even partly in applications. May be Swift 6, when they finally introduce ownership. But that is looking more like 2023 at the earliest.
It will be worth looking at the stats again in 2024, 10 years after Swift was introduced.
If even Apple is writing more new software in Obj-C than they are in swift, its probably still a fantastic time to learn obj-c and use it to develop applications.
Or at the very least, use Swift + UIKit rather than SwiftUI.
Apple is writing 'more Obj-C' because it's their incumbent language, and they are 'writing a lot more software'. As the basis expands, it's going to expand along the normative vector, which is ObjC.
But for outside devs, Apple has almost frozen ObjC in favour of Swift, and Swift is 100% the future for apps built for iOS/MacOS.
Even externally, ObjC will probably be supported for a 'very long time' and maybe even perpetually at this point, it's really not the future.
Internally, the sands have not shifted, but I suggest that within about 5-7 years Swift will be on even footing with ObjC even within Apple.
So if you're an Apple focused Dev. not working for Apple ... then Swift is probably your #1 focus with a 'Healthy Knowledge' of ObjC - at least enough to access arcane and un-ported APIs as a nice thing to round out your skills.
ObjC is losing popularity, it will be a 'well supported' niche language going forward. You can probably bank on your ObjC skills for a long time to come, but in a more narrow range of opportunities.
> But for outside devs, Apple has almost frozen ObjC in favour of Swift
In my experience, Apple doesn't even have to freeze anything because the iOS developer community (outside of Apple) is full of proud Early Adopters. Sometimes it feels like a race to use the latest tools on day one. I haven't seen anyone looking for ObjC developers from the day Swift was announced.
Nobody is going to do a 'new start' in Obj-C outside of Apple so it's now a language used for 'One Companies Internal Purposes', moreover, swift in just the last 2 releases has gained significantly - they're just starting to use it.
My bet is that even then, most ObjC use is due to legacy - most of those binaries are probably related to apps that are already in ObjC.
I looks like they plan to keep it around for the foreseeable future, but I wonder if it will mostly be eventually replaced by Swift for new starts.
ObjectiveC is slowly dying [1] I think it will flatten out and not go away for a long time but it's going to eventually become and adjunct to Swift 'outside' of Apple.
Within 5-7 years Swift will rival ObjC within Apple, and from then on it's hard to tell.
There are no foreseeable plans to rewrite the OS, and so ObjC has to stay around, but that's in a clearly limited capacity.
I don't think so, it is like the .NET uptake at Microsoft, after 20 years, no matter what, the WinDev is C++ deep down to their bones, nowadays even more since COM has won the Longhorn wars.
Objective-C will be just the same at Apple, specially since their creators decided to go search for other adventures outside Apple.
89% are using Objective-C
17% are using C++
13% are using Swift
8% are entirely written in C
2% are using SwiftUI
Objective C looks healthy.