7 ms·

What is interesting to me is the decline in C, from 52% in iPhone OS 1 to 5% in iOS 17. I am a bit surprised to see Objective-C still dominating. It goes to sh

What is interesting to me is the decline in C, from 52% in iPhone OS 1 to 5% in iOS 17. I am a bit surprised to see Objective-C still dominating. It goes to show that transitioning languages is extremely difficult, even when you are applying the impetus to yourself. Consider the Python 3 transition in this light. Python 3 came in 2008 and I don't think it could be said the transition completed prior to 2020, so 12 years conservatively. Swift picks up in iOS 10 at 1%. So, perhaps one could estimate by iOS 22 some large majority of Swift in Apple codebases? And then maybe by iOS 30 Objective-C is down to 5% or les?

keyle 3y ago
A lot of the low level code is working code in ObjC. 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 :)
- zoogeny 3y ago
  Sure, but "working code" written in C is declining. So some choices are being made. 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.
  - tambourine_man 3y ago
    > Sure, but "working code" written in C is declining 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.
    - Wowfunhappy 3y ago
      Can Swift even be used for kernel development?
      - balder1991 3y ago
        I believe you’d need a subset of Swift, there’s a thread about this on the forum: https://forums.swift.org/t/introduce-embedded-development-using-swift/56573 https://forums.swift.org/t/introduce-embedded-development-us...
        glhaynes 3y ago
        Additionally, until very recently, there was no (practical) way to reach the performance potential of manual memory management in pure Swift: all heap management was done via Automatic Reference Counting (ARC). A series of "ownership" features have been getting integrated into the most recent versions of the language that let you avoid that runtime cost while retaining memory safety (at the expense of more complex code — the vast majority of code should still use ARC). That makes Swift much more suitable for lots of "systems programming" than it was just a few months ago. https://www.swift.org/blog/swift-5.9-released/#ownership https://www.swift.org/blog/swift-5.9-released/#ownership
        balder1991 3y ago
        Thanks, I had never read something about this.
      - tambourine_man 3y ago
        It was Lattner’s vision, a language that would scale from scripts to kernel. Oh yeah, and one that’s easy for a beginner to learn. 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.
- MBCook 3y ago
  Working code can hold unknown bugs, including those Swift could help prevent. There are reasons to rewrite it, though I’m sure it will take a long time and they’re prioritizing risk vs reward.
  - brailsafe 3y ago
    Prioritizing expense and risk vs nebulous reward
    - MBCook 3y ago
      It’s not nebulous. 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.
      - bobbylarrybobby 3y ago
        Swift doesn't need a runtime, but if it runs alongside Objective C code, doesn't it? On iOS wouldn't much of what Swift is doing be to calling down into Objective C? In other words, I think that unless you get rid of all of the Objective C in iOS, Swift will still be sitting on top of a runtime.
        astrange 3y ago
        Swift does need a runtime. The language design is kind of accepting of implementation complexity in a way that interpreted languages often are but compiled languages usually aren't, so there's a lot of implicit heap allocations.
      - brailsafe 3y ago
        What is nebulous is the actual return on the investment of time and money, just the same as it would be in any rewrite of any code ever, when the same resources could be allocated differently. The possibility that some hypothetical bugs might be avoided isn't a compelling argument for spending dollars and time on doing the work, if it's measurably doing it's job now.
- gumby 3y ago
  > There is no reason to replace perfectly working code that is battle tested if the requirements don't change. Are you familiar with Apple's MO? Take a perfectly good, working app and replace it with a total rewrite with half the features.
  - aalimov_ 3y ago
    Genuinely curious to know which apps you are referring to.
    - gumby 3y ago
      Off the top of my head here are some notorious examples you can look up from the Jobs era: 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!
      - flakes 3y ago
        I feel like this was a trend. Windows Movie Maker from XP was tremendously better than all of their replacements. I remember using that heavily when I was in middle-school, making stop motions and stupid videos with my friends.
- inopinatus 3y ago
  I really do enjoy working in Swift too, but the anemic cross-platform story is a colossal hurdle to selection as the primary development language in many commercial cases. 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.
  - cageface 3y ago
    The vision of Swift as a truly cross platform, modern language Apple laid out in the initial announcement was genuinely exciting. Unfortunately it seems like they didn't really mean it.
  - pjmlp 3y ago
    Hardly any different from going with .NET (many stuff is still Framework only), or C++ with OS specific SDKs like MFC/WinUI/...
  - varjag 3y ago
    If cross-platform is your thing 'fraid Objective-C isn't a great sell either.
    - mpweiher 3y ago
      At least two open-source compilers, several runtimes, several Foundations. What more do you want?
      - pjmlp 3y ago
        Both lagging behind what Objective-C on XCode actually means, and without the libraries that make Objective-C actually relevant.
        mpweiher 3y ago
        I find that not to be the case in practice.
- eviks 3y ago
  The reason is those battle tests showed time and again that the code is vulnerable, so it's not working perfectly
- corbezzoli 3y ago
  > the new binaries on it are written in Swift 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.
  - pjmlp 3y ago
    Most of the new code written in Objective-C tends to be related to Metal, or new features being added to existing Objective-C frameworks like UIKit.
JKCalhoun 3y ago
I think that is a case where the percentage chart is deceptive. My take is that C has probably remained steady — all the new binaries in iOS are made up from the other three.
- yreg 3y ago
  There is a chart for that as well and it is as you say. In iOS 17 the amount of binaries using C even grew a bit. For C++ the amount has been growing steadily with every release, but it went from 14% in iPhone OS 1 to 12% in iOS 17.
deleted 3y ago
[deleted]
mjmsmith 3y ago
> What is interesting to me is the decline in C, from 52% in iPhone OS 1 to 5% in iOS 17. Note that most of this change is between iOS 1-9, where Objective-C rose from 34% to 70% (+36) and C declined from 52% to 14% (-38).
- pasc1878 3y ago
  Yes but is any of that a simple rename from .c to .m chnages the language but no need to change the code.
cellularmitosis 3y ago
Herb Sutter has a talk where he makes a pretty convincing argument that making a backwards incompatible change in your language costs you about 10 years in adoption
lolinder 3y ago
One thing to note about the data is that the way the author counts a "Swift" binary and an "Objective-C" binary is a bit misleading, as it dual-counts binaries that feature both, and most new binaries feature both languages. That's why the slopes of the two languages look essentially the same: because they're the same binaries. By my rough count [0], the number of strictly Objective-C binaries increased by exactly 4 between iOS 16 and 17. The number of strictly Swift binaries increased by 9 [1], and the vast majority of binaries added use both languages. It's not clear from the data if there are substantial amounts of ObjC code in these binaries or if there are just one or two functions in each. EDIT: The percentage tallies are calculated weirdly too—because they double- and triple-counted binaries that have multiple languages, they calculated all the percentages out of a total of 8723 binaries (for iOS 17) even though there are only 6030 in their data set. The correct percentages should be: SwiftUI: 6% Swift: 25% C: 7% C++: 17% Objective-C: 89% This is less satisfying because it doesn't add up to 100%, but the metric they used doesn't have any useful meaning. [0] Using the following regex on the raw data files: / \|Objective-C\n/ [0] Using the following regex on the raw data files: / \|Swift(\|SwiftUI)?\n/ and
- Pulcinella 3y ago
  SwiftUI shouldn't be counted as it's own language. It's a UI framework written in Swift.
- saagarjha 3y ago
  Consider using a regex like “objc” or similar, very few places in the code will include “Objective-C” spelled out
  - lolinder 3y ago
    I'm just relying on the raw data provided in the article, I have neither the time nor the interest in re-doing the analysis myself.
swingingFlyFish 3y ago
"What is interesting to me is the decline in C, from 52% in iPhone OS 1 to 5% in iOS 17." Take this all with a grain of salt as a lot of C++ code is really just C-With Classes. As well if i remember correctly you can wrap objective-C in C++ or vice versa. "Consider the Python 3 transition in this light. Python 3 came in 2008 and I don't think it could be said the transition completed prior to 2020" To be fair, yes Python3 came out but there were still a lot of Python2 libraries that had to be migrated to 3, so for most people it didn't make sense to use 3 when it came out.

keyle 3y ago

A lot of the low level code is working code in ObjC. 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 :)

zoogeny 3y ago
Sure, but "working code" written in C is declining. So some choices are being made. 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.
- tambourine_man 3y ago
  > Sure, but "working code" written in C is declining 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.
  - Wowfunhappy 3y ago
    Can Swift even be used for kernel development?
    - balder1991 3y ago
      I believe you’d need a subset of Swift, there’s a thread about this on the forum: https://forums.swift.org/t/introduce-embedded-development-using-swift/56573 https://forums.swift.org/t/introduce-embedded-development-us...
      - glhaynes 3y ago
        Additionally, until very recently, there was no (practical) way to reach the performance potential of manual memory management in pure Swift: all heap management was done via Automatic Reference Counting (ARC). A series of "ownership" features have been getting integrated into the most recent versions of the language that let you avoid that runtime cost while retaining memory safety (at the expense of more complex code — the vast majority of code should still use ARC). That makes Swift much more suitable for lots of "systems programming" than it was just a few months ago. https://www.swift.org/blog/swift-5.9-released/#ownership https://www.swift.org/blog/swift-5.9-released/#ownership
        balder1991 3y ago
        Thanks, I had never read something about this.
    - tambourine_man 3y ago
      It was Lattner’s vision, a language that would scale from scripts to kernel. Oh yeah, and one that’s easy for a beginner to learn. 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.
MBCook 3y ago
Working code can hold unknown bugs, including those Swift could help prevent. There are reasons to rewrite it, though I’m sure it will take a long time and they’re prioritizing risk vs reward.
- brailsafe 3y ago
  Prioritizing expense and risk vs nebulous reward
  - MBCook 3y ago
    It’s not nebulous. 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.
    - bobbylarrybobby 3y ago
      Swift doesn't need a runtime, but if it runs alongside Objective C code, doesn't it? On iOS wouldn't much of what Swift is doing be to calling down into Objective C? In other words, I think that unless you get rid of all of the Objective C in iOS, Swift will still be sitting on top of a runtime.
      - astrange 3y ago
        Swift does need a runtime. The language design is kind of accepting of implementation complexity in a way that interpreted languages often are but compiled languages usually aren't, so there's a lot of implicit heap allocations.
    - brailsafe 3y ago
      What is nebulous is the actual return on the investment of time and money, just the same as it would be in any rewrite of any code ever, when the same resources could be allocated differently. The possibility that some hypothetical bugs might be avoided isn't a compelling argument for spending dollars and time on doing the work, if it's measurably doing it's job now.
gumby 3y ago
> There is no reason to replace perfectly working code that is battle tested if the requirements don't change. Are you familiar with Apple's MO? Take a perfectly good, working app and replace it with a total rewrite with half the features.
- aalimov_ 3y ago
  Genuinely curious to know which apps you are referring to.
  - gumby 3y ago
    Off the top of my head here are some notorious examples you can look up from the Jobs era: 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!
    - flakes 3y ago
      I feel like this was a trend. Windows Movie Maker from XP was tremendously better than all of their replacements. I remember using that heavily when I was in middle-school, making stop motions and stupid videos with my friends.
inopinatus 3y ago
I really do enjoy working in Swift too, but the anemic cross-platform story is a colossal hurdle to selection as the primary development language in many commercial cases. 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.
- cageface 3y ago
  The vision of Swift as a truly cross platform, modern language Apple laid out in the initial announcement was genuinely exciting. Unfortunately it seems like they didn't really mean it.
- pjmlp 3y ago
  Hardly any different from going with .NET (many stuff is still Framework only), or C++ with OS specific SDKs like MFC/WinUI/...
- varjag 3y ago
  If cross-platform is your thing 'fraid Objective-C isn't a great sell either.
  - mpweiher 3y ago
    At least two open-source compilers, several runtimes, several Foundations. What more do you want?
    - pjmlp 3y ago
      Both lagging behind what Objective-C on XCode actually means, and without the libraries that make Objective-C actually relevant.
      - mpweiher 3y ago
        I find that not to be the case in practice.
eviks 3y ago
The reason is those battle tests showed time and again that the code is vulnerable, so it's not working perfectly
corbezzoli 3y ago
> the new binaries on it are written in Swift 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.
- pjmlp 3y ago
  Most of the new code written in Objective-C tends to be related to Metal, or new features being added to existing Objective-C frameworks like UIKit.

JKCalhoun 3y ago

I think that is a case where the percentage chart is deceptive. My take is that C has probably remained steady — all the new binaries in iOS are made up from the other three.

yreg 3y ago
There is a chart for that as well and it is as you say. In iOS 17 the amount of binaries using C even grew a bit. For C++ the amount has been growing steadily with every release, but it went from 14% in iPhone OS 1 to 12% in iOS 17.

deleted 3y ago

[deleted]

mjmsmith 3y ago

> What is interesting to me is the decline in C, from 52% in iPhone OS 1 to 5% in iOS 17. Note that most of this change is between iOS 1-9, where Objective-C rose from 34% to 70% (+36) and C declined from 52% to 14% (-38).

pasc1878 3y ago
Yes but is any of that a simple rename from .c to .m chnages the language but no need to change the code.

cellularmitosis 3y ago

Herb Sutter has a talk where he makes a pretty convincing argument that making a backwards incompatible change in your language costs you about 10 years in adoption

lolinder 3y ago

One thing to note about the data is that the way the author counts a "Swift" binary and an "Objective-C" binary is a bit misleading, as it dual-counts binaries that feature both, and most new binaries feature both languages. That's why the slopes of the two languages look essentially the same: because they're the same binaries. By my rough count [0], the number of strictly Objective-C binaries increased by exactly 4 between iOS 16 and 17. The number of strictly Swift binaries increased by 9 [1], and the vast majority of binaries added use both languages. It's not clear from the data if there are substantial amounts of ObjC code in these binaries or if there are just one or two functions in each. EDIT: The percentage tallies are calculated weirdly too—because they double- and triple-counted binaries that have multiple languages, they calculated all the percentages out of a total of 8723 binaries (for iOS 17) even though there are only 6030 in their data set. The correct percentages should be: SwiftUI: 6% Swift: 25% C: 7% C++: 17% Objective-C: 89% This is less satisfying because it doesn't add up to 100%, but the metric they used doesn't have any useful meaning. [0] Using the following regex on the raw data files: / \|Objective-C\n/ [0] Using the following regex on the raw data files: / \|Swift(\|SwiftUI)?\n/ and

Pulcinella 3y ago
SwiftUI shouldn't be counted as it's own language. It's a UI framework written in Swift.
saagarjha 3y ago
Consider using a regex like “objc” or similar, very few places in the code will include “Objective-C” spelled out
- lolinder 3y ago
  I'm just relying on the raw data provided in the article, I have neither the time nor the interest in re-doing the analysis myself.

swingingFlyFish 3y ago

"What is interesting to me is the decline in C, from 52% in iPhone OS 1 to 5% in iOS 17." Take this all with a grain of salt as a lot of C++ code is really just C-With Classes. As well if i remember correctly you can wrap objective-C in C++ or vice versa. "Consider the Python 3 transition in this light. Python 3 came in 2008 and I don't think it could be said the transition completed prior to 2020" To be fair, yes Python3 came out but there were still a lot of Python2 libraries that had to be migrated to 3, so for most people it didn't make sense to use 3 when it came out.