11 ms·

Apple's use of Swift and SwiftUI in iOS 17

346 points by ingve 3y ago

mrtesthah 3y ago
One takeaway from these charts is that the great majority of binaries in iOS are still written in Objective-C.
- sbjs 3y ago
  Having written ObjC since 2009 or so, honestly it's a fine language, and although I wrote a fair bit in Swift, I don't really see it as a significant improvement over ObjC, which is Good Enough™ to keep using. Something has to cause serious friction to be replaced with something significantly better, and ObjC/Swift just don't fit that pattern.
  - sneakymichael 3y ago
    Oof, hard disagree. I absolutely hated writing Objective-C for years– I felt like I had to write unnecessary 'glue' with header files, handling of 'nil' was always jarring, and square brackets at the start and end of every call felt horrendous, to me at least. I relished the day Swift was announced, and have been using it ever since.
    - Dig1t 3y ago
      I love the square brackets. I find them aesthetically pleasing for some reason.
      - Apocryphon 3y ago
        With Xcode or any modern IDE the autocomplete "snap" of square brackets closing is a very satisfying code feel.
    - lapcat 3y ago
      > I felt like I had to write unnecessary 'glue' with header files Headers are a feature, not a bug. They're the API. They help document the API and also keep it separate from the implementation.
      - glhaynes 3y ago
        Objective-C programmers say this, but I note that I've never once heard a Swift developer complain that it's too hard to discover API interface or keep things non-`public`.
        jshier 3y ago
        Only access control I wish Swift had is typeprivate so I could hide private things but make them available for subclasses (or perhaps protocol conformers). Unfortunately Apple has only added a package level so far, which seems fairly useless (you're either too big for it to be useful or too small to need it). Obj-C didn't really have ACLs at all, you just hid stuff in interfaces. Once found, those interfaces were no protection at all.
        ninkendo 3y ago
        > never once heard a Swift developer complain that it's too hard to discover API interface Xcode presents the equivalent of a “header” when you follow a symbol to a framework you don’t have the source for… it’s a swift file full of definitions only and no implementations. The compiler emits this for you automatically as a .swiftinterface file > or keep things non-`public` I definitely am a swift developer that would complain about this. It’s way too easy to be cavalier about using the “public” keyword and making things part of the public API when they probably shouldn’t be. It’s like engineers have muscle memory from Java and just type “public class” without really questioning why first.
        lapcat 3y ago
        > The compiler emits this for you automatically as a .swiftinterface file It's so incredibly slow, though, which is frustrating. It would be ok if only this were as instantaneous as checking a header file. Ironically, almost everything about "Swift" is slower than Objective-C.
    - kevinsync 3y ago
      Agree -- my experience with Swift is that it's far more readable and closer to my personal aesthetics than Obj-C, but I actually struggled a lot figuring out how to write things the way that felt intuitive to me (ex. maintaining an observable global state + config that you can access from anywhere, easy declaration of and access to arbitrary/deeply-nested associative array keys, JSON handling, declare-once-use-anywhere icons and colors, that kind of stuff). Once I had all the convenience guts in place, writing actual functionality has been a delight though (outside of the overly-verbose let/guard and type casting) That said, I'm pretty sure I'm also probably just hard headed and doing it wrong, and could've learned the accepted patterns/methodologies lol
    - randomdata 3y ago
      I always thought the square brackets were clever. Like wrapping a letter in an envelope – which is a great metaphor for the message sending the syntax denotes.
    - deleted 3y ago
      [deleted]
    - jwells89 3y ago
      In the whole I don’t mind Objective-C, but when I have to write it these days I definitely get annoyed by having to navigate and maintain header files. It’s more extra overhead than one might realize. My other complaint with it compared to Swift is how one needs to pull in a bunch of utility libraries to do many things that come stock with Swift.
    - vor_ 3y ago
      I find modern Swift to be increasingly ugly and difficult to read. Reading classic Objective-C code is refreshing.
  - jhatemyjob 3y ago
    I've had a similar experience, and generally agree with what you're saying. But I am glad Swift was created. All the plebs gravitate towards that language, so Objective-C remains unpolluted. I shudder to think how Objective-C would have deteriorated without Steve around.
    - wahnfrieden 3y ago
      ObjC is often no longer an option for building on new platform functionality
      - jhatemyjob 3y ago
        Can always use a shim
        MBCook 3y ago
        Yeah but that’s a losing battle. As we go forward you’re going to have to shim out more and more of the new APIs that you need to use. Possibly in ways that are very inconvenient/hard to use in Obj-C.
        deleted 3y ago
        [deleted]
        jhatemyjob 3y ago
        It's been 10 years and I haven't had any issues. Maybe in another 10 years this will be enough of a problem to switch, but by that point I'll be retired
      - pjmlp 3y ago
        Metal is a counterexample of that.
        saagarjha 3y ago
        Metal is not a new framework
  - happytoexplain 3y ago
    I agree that ObjC is nice, and proven ObjC codebases probably don't benefit enormously from being re-written in Swift, but that has little to do with how much better Swift is (and it is much better, IMO).
    - randomdata 3y ago
      Swift is an improvement over C for the problem domain. Something akin to Swift as a modern C replacement with keeping of the 'Objective' bits of Objective-C layered on top of it would have made for the ultimate language, though.
      - MBCook 3y ago
        I don’t know how doable that would be. Objective-C does just about everything it can to make sure you can mess with it at runtime and confuse the ever living hell out of any type checker that wants to be strict. And the additional strictness is one of my favorite parts of Swift.
        randomdata 3y ago
        In theory, you are only reaching for the 'Objective' parts of Objective-C when your code actually benefits from being object oriented (in the Kay sense). Otherwise you can stick to pure C. Of course, C has a lot of ugly traps which makes it less than ideal for this domain. This hypothetical subset language addresses those issues. While, again, you would only reach for the 'Objective' parts when your code benefits from being object oriented. It is true that the inherit dynamism of message passing makes static analysis impossible to cover all cases, but as with all things in life there are tradeoffs. You lose the nice aspects of object oriented systems if you do not allow for that, and OO is particularly well suited to UI code. Of course, Swift abandoned the object oriented model completely. Which is fine. But Objective-C showed that you can have your cake an eat it too, offering OO where appropriate, and a non-OO language for everything else. Objective-C's downfall was really just in that C didn't age well – which, among other things, I am sure contributed to seeing the use of the 'Objective' bits where they weren't really appropriate.
  - mpalczewski 3y ago
    I’m in a similar boat. Header files typically led to faster compile times. OCMock worked like magic. Where both languages are poor is how large the binaries they produce are.
  - koito17 3y ago
    Yup, Objective-C's object system was really flexible and powerful to use. Dynamic mixins, swizzling, etc. were all useful tools for me. Having messages as first-class citizens was probably the most important part to me. It helps make the object system expressive enough that I don't remember writing much design patterns ;) But seriously though, CLOS and Smalltalk-style OOP is probably the only flavor of OOP I really enjoy to use, and Objective-C gets you way closer to that than C++ and Java do. (e.g. the way KVO is implemented relies on "isa-swizzling", or dynamically changing classes at runtime)
    - sbjs 3y ago
      It's a false dichotomy to dislike OOP or prefer it. It's like saying I prefer hammers over screwdrivers. Just learn how the tools you have should be used and use them well. The only app I'm currently maintaining and proud of[1] makes tons of use of "traditional" OOP. It uses lambdas and FP when necessary. I think it makes absolutely no use of JavaScript's dynamic features. I'm fairly sure this code would port easily to ObjC. After 15-20 years, you just get bored of doing things in novel or "pure" ways, and do the bare minimum needed to get the job done that's in front of you. [1] https://github.com/sdegutis/immaculatalibrary.com https://github.com/sdegutis/immaculatalibrary.com
      - koito17 3y ago
        I am not sure if you understood my post. I am in no way saying "OOP is bad in general" or even "OOP is good in general". What I am saying is "I strongly prefer Objective-C's object system over that of other languages." Then I provided examples of other object systems I liked, and how Objective-C feels close enough to them that I don't miss them when writing Objective-C. Maybe saying "flavor of OOP" was too vague, but I am talking about implementations of object systems, not the (ill-defined) notion of OOP. Using your analogy with hammers and screwdrivers, my post is less "I prefer screwdrivers over hammers" and more "I prefer screwdrivers with bit holders over screwdrivers without bit holders"
        balder1991 3y ago
  - deleted 3y ago
    [deleted]
  - woadwarrior01 3y ago
    Message passing goodness and flexibility (almost!) of Smalltalk, coupled with C for all things low level and perf related. It's a great language! I've switched to Swift for all things Apple these days, but I still miss coding in ObjC.
  - MBCook 3y ago
    I really like Obj-C, but I much prefer Swift. It’s less verbose (even if I’m not a square bracket hater. It has some really nice new abilities like async (way easier/cleaner than callbacks in many situations) and now actors. But honestly 90% of it is true type safety. The type system is so much more powerful and expressive compared to Obj-C. There is only one downside, and it’s real. Compiling Obj-C was instantaneous. Swift is MUCH slower, which also slows down error messages and hints. And the fancy type stuff can even timeout the compiler. Combined with some Xcode issues (stale info anybody?) and it can be a pain. But I’m happy we have Swift.
  - pjmlp 3y ago
    Sure if one loves typing []@ all over the place, and I know Objective-C since NeXTSTEP days.
- sebazzz 3y ago
  Objectively a full rewrite had rarely led to anything good.
  - Affric 3y ago
    Yeah but the number of objective C binaries are still increasing.
    - RandallBrown 3y ago
      That could be because many apps that are mostly written in Swift are still using Obj-C frameworks.
      - OnlyMortal 3y ago
        Or core code is written in another language that’s cross-platform and the UI is done in AppKit.
        meepmorp 3y ago
        We're talking about iOS binaries supplied by Apple here, so cross platform support isn't hugely important.
        pjmlp 3y ago
        In the context of Apple and Microsoft, cross-platform means across their own platforms, macOS, iOS, iPadOS, watchOS, and Windows x86, Windows ARM, Windows x64, XBox, Azure managed apps.
  - agambrahma 3y ago
    I (objectively) see what you did there
- wiremine 3y ago
  And seems to be growing? I'm not close to this space, but it feels like Objective-C should be decreasing. I'd be curious to know why it's increasing.
  - initplus 3y ago
    From the article: > Again please note that a single binary can be counted multiple times, so the sum of the binaries in this graph is greater than the total number of binaries So even if a binary only uses a small shim of Objective-C, it'll still count towards the Objective-C number.
  - MBCook 3y ago
    Apple is all in on Swift. Everything is Swift first, with some new things Swift only. You can still call new Swift only APIs from Obj-C, but you’ll have to write your own glue layer.
khana 3y ago
[dead]
jshier 3y ago
Something not noted in the article is that any binary which links Foundation, even if otherwise written entirely in Obj-C, now uses Swift. This is due to the Foundation Swift rewrite effort (https://github.com/apple/swift-foundation https://github.com/apple/swift-foundation) that is rewriting Foundation is Swift while maintaining Obj-C ABI compatibility.
- glhaynes 3y ago
  I don't believe the new Foundation is shipping with any released versions yet, is it?
  - jshier 3y ago
    Yes, it has shipped this year, even in the partial state. https://developer.apple.com/wwdc23/10164?time=1187 https://developer.apple.com/wwdc23/10164?time=1187
    - glhaynes 3y ago
      Oh, very cool. I’d missed that somehow. Thanks for the link!
      - bt4u 3y ago
        [dead]
- xxpor 3y ago
  What's the downstream effect of that?
  - jshier 3y ago
    Bit better performance, fewer bugs, updated implementations.
    - xxpor 3y ago
_jcrossley 3y ago
Really look forward to this every year, Timac is a legend. The rate of SwiftUI adoption and decrease in UIKit-only binaries feels significant. Thanks!
kridsdale3 3y ago
Having cert failures, and can't actually view this pace.
- codetrotter 3y ago
  Loads fine for me.
explaininjs 3y ago
Shame they didn’t look at the “Fitness” app. It’s first party but requires a separate download. Probably because it’s some of the worst quality software I’ve ever seen. Its UI becomes desynchronized and self-inconsistent in ways I wouldn’t have believed are possible. The very fact that it exists and is capable of presenting as incoherent UI as it does is damning evidence against whatever UI framework it uses.
- turdprincess 3y ago
  SwiftUI exists to solve exactly this problem - the ui is declarative and state driven. However, its predecessor UIKit is mostly imperative and it takes a lot of manual code to keep the UI reflective of the underlying data model. For this reason I find many IOS apps, and especially apple’s own, to be always mildly broken. Programming in UIKit is like programming in JQuery, or maybe Backbone at best. SwiftUI brings us to the modern age of react (but with less capabilities and more bugs) IOS developers though tend to be pretty resistant to such “modern” paradigms. If you read the rest of the discussion on this post, you fill find that even using Swift, let alone SwiftUI is still a very debated issue. Maybe the grass is greener, but I don’t find the same resistance for new ideas in the web (typescript) or Android (kotlin) communities. I do wonder if this resistance is combing from an objective evaluation of the new tech, or the lack of desire/time to learn something new.
  - jwells89 3y ago
    As a mobile dev, so far the biggest issue keeping me from adopting SwiftUI stems from its greenness and UIKit being so well fleshed out. The newness is an issue because new SwiftUI revisions ship with new iOS releases, which means that big chunks of it are gated by the oldest iOS version you support. Jetpack Compose on Android gets this more right since it’s independent of the OS, but suffers from other tradeoffs (Java ecosystem and the rest of Android dev gives me a headache sometimes). SwiftUI is also just missing various things that are present in UIKit, and so if you’re using those things it’s easier to write the whole app in UIKit instead of bridging those controls to SwiftUI. I absolutely foresee going SwiftUI exclusive but realistically that’s still a few years down the road.
tpmx 3y ago
Judging from SwiftUI uses in macOS: various things will become noticably slower for older devices for no apparent reason. This is bad for the planet and consumers but great for Apple. Edit: I see much interaction with this comment, but no response.
- xyst 3y ago
  What makes you think SwiftUI is slower than UIKit?
  - tpmx 3y ago
    One such example: In macOS 13, the system settings was rewritten to use SwiftUI instead of UIKit. I had a 2019 Intel MBP. Before the rewrite, it was super swift (sorry). After the rewrite it took almost a second to go from section to section. Now I'm on an M2 machine so it's fast again. Congrats Apple.
    - boxed 3y ago
      On the other hand, the continued use of Swift by Apple will mean they feel the pain too and will improve the performance, which will make all apps faster as most new apps use Swift.
      - lapcat 3y ago
        > On the other hand, the continued use of Swift by Apple will mean they feel the pain too and will improve the performance LOL have you used Xcode lately? It's painfully slow, and getting worse. Apple engineers use all of the same crappy Apple software that we all do. The problem is that Apple executives have decided they don't care and are unwilling to invest the time and resources in performance optimization or good design. The relentless yearly update cycle will continue until morale improves. Steve Jobs is gone not only physically but also in spirit. It's Tim Apple now.
        boxed 3y ago
ruuda 3y ago
The pictures in this article don't load without Javascript enabled even though there appears to be no interactivity.
- xyst 3y ago
  I don’t think they are images. Looks like graphs rendered with some js library. I’m on mobile.
  - Timac 3y ago
    See the previous blog post on creating Charts in Markdown using Apache ECharts: https://blog.timac.org/2023/0627-charts-in-markdown-using-apache-echarts/ https://blog.timac.org/2023/0627-charts-in-markdown-using-ap...
    - biehl 3y ago
      Thanks for the great posts. Will you also do a post about MacOS this year?
simonw 3y ago
I loaded these all into a SQLite database so I could explore them with Datasette Lite (Datasette running in WebAssembly). Here's the result: https://lite.datasette.io/?sql=https://gist.github.com/simonw/0b8a2ddaeab76fe407b08a2b2041292a#/data/ios?_facet_array=languages&_facet=ios https://lite.datasette.io/?sql=https://gist.github.com/simon... You can use this to answer questions like which binaries are new in iOS 17 compared to iOS 16: https://lite.datasette.io/?sql=https://gist.github.com/simonw/0b8a2ddaeab76fe407b08a2b2041292a#/data?sql=select+rowid%2C+ios%2C+path%2C+parent%2C+filename%2C+languages+from+ios+where+%22ios%22+%3D+%3Acurrent+and+path+not+in+%28select+path+from+ios+where+ios+%3D+%3Aprevious%29+order+by+rowid+limit+101&current=iOS17&previous=iOS16 https://lite.datasette.io/?sql=https://gist.github.com/simon... Or here's just the binaries in the /System/Library/VideoDecoders folder - it's interesting to compare iOS 1 (just H264H1 and MP4VH1) to iOS 17 (AppleProResHWDecoder, AppleProResSWDecoder, AV1SW, AVD, H264H8, JPEGH1, MP4VH8, VCH263, VCPMP4V) https://lite.datasette.io/?sql=https://gist.github.com/simonw/0b8a2ddaeab76fe407b08a2b2041292a#/data/ios?_filter_column_1=&_filter_op_1=arraynotcontains&_filter_value_1=Objective-C&_filter_column_2=&_filter_op_2=arraynotcontains&_filter_value_2=Swift&_filter_column_3=parent&_filter_op_3=exact&_filter_value_3=%2FSystem%2FLibrary%2FVideoDecoders&_filter_column=&_filter_op=exact&_filter_value=&_sort=rowid&_facet_array=languages&_facet_size=max&_facet=ios&_facet=parent https://lite.datasette.io/?sql=https://gist.github.com/simon... Details on how I built this here: https://gist.github.com/simonw/0b8a2ddaeab76fe407b08a2b2041292a?permalink_comment_id=4732049#gistcomment-4732049 https://gist.github.com/simonw/0b8a2ddaeab76fe407b08a2b20412...
- Timac 3y ago
  Really nice, thanks for sharing!
mrcwinn 3y ago
I really enjoy working with Swift. (Although I'm old school and enjoyed ObjC just as much.) I wish I had more time to work with. React Native is stealing all the fun!
- perfopt 3y ago
  I learnt Swift several years ago for a App project Haven't really used it since. My impression is that it is useful only in the Apple ecosystem. It that correct? Is it worth learning for things other than iOS and macOS applications?
zoogeny 3y ago
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.
lolinder 3y ago
These charts are almost meaningless. They're double- and triple-counting binaries: the slope of the Objective-C line and the slope of the Swift line are identical because nearly every added binary uses both languages. That doesn't provide any meaningful information except that Apple is still using both. It gets worse when they get to the percentages: they list 61% as Objective-C's number for iOS 17, but 61% of what? According to the raw data, Objective-C is used in 88% of all binaries on iOS 17, with Swift used in 25% (instead of the 17% they list). Their calculated numbers are derived from a denominator of 8723 binaries, even though they only have 6030 in their data set, because they wanted the numbers to add up to 100%. That makes a nice chart, but it has no meaningful interpretation.
- mplewis 3y ago
  You're essentially looking at a series of pie charts, and it does tell a useful story: that there is more code being written in Swift and SwiftUI year over year.
  - lolinder 3y ago
    The problem is that the pie chart is lying—it makes it look like the percentage of binaries containing Objective-C is going down over time, but it's actually going up just as rapidly as Swift is, because almost all added files contain both Objective-C and Swift. The only languages that are going down as a percentage of binaries are C and C++, because fewer new modules are being added using those. The reason why it looks like Objective-C is losing ground is that every Objective-C+Swift+SwiftUI binary increments the denominator by 3 instead of by 1, and there are more of those added every single year. Since each of those binaries only adds 1 to the numerator, Objective-C's share of the binary pie seems to be decreasing even though it's actually keeping up with Swift. It's entirely possible and even likely that Swift is increasing faster than Objective-C in terms of lines of code, but this data can't be used to show that.
    - boxed 3y ago
      I would guess that Swift isn't increasing in lines of code as fast as ObjC, because Swift gets more done per line of code. But "per feature" I'd guess Swift is slowly inching out ObjC.
p-e-w 3y ago
> iOS 17 contains 6030 binaries, up from 5403 in iOS 16. That’s 627 new binaries. That's... insane. Even worse, the graph appears to show a superlinear trend. For comparison, iOS 2 had only 278 binaries. With such out-of-control software bloat, secure computing is never going to happen. There isn't enough brainpower on the entire planet to secure a system that grows to the tune of hundreds of components per year.
xvilka 3y ago
Hopefully Google will do the same with Android and Rust[1][2] [1] https://arstechnica.com/gadgets/2021/04/google-is-now-writing-low-level-android-code-in-rust/ https://arstechnica.com/gadgets/2021/04/google-is-now-writin... [2] https://security.googleblog.com/2023/10/bare-metal-rust-in-android.html https://security.googleblog.com/2023/10/bare-metal-rust-in-a...
thrdbndndn 3y ago
> In iOS 16, only 4 apps used the SwiftUI-based app lifecycle. In iOS 17, this figure has grown to 14 apps What does this mean (what is app lifecycle)?
- jshier 3y ago
  Presumably it means the root of the app is a SwiftUI App-conforming type rather than a UIApplication. Of course SwiftUI can bridge into UIApplication so it's entirely possible for apps to be using both (though you can't really bridge the other way).
pjmlp 3y ago
On the same subject, some talks from Apple folks, "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw "Swift as C++ Successor in FoundationDB" https://www.youtube.com/watch?v=ZQc9-seU-5k https://www.youtube.com/watch?v=ZQc9-seU-5k
jbverschoor 3y ago
Apple needs to start polishing their UI again all the way from the start. Preferences is such a mess. Many apps are simple backports of touch-only apps. I don't think Apple requires all developers to have read the HIG.
- Dennip 3y ago
  Agreed. So many settings now are hidden away 5 levels deep and not easily searchable. Why is updating apps hidden away 2/3rd's down in some profile section on the app store.
  - brainzap 3y ago
    actually that one makes sense since apps automatically update during the night
  - jbverschoor 3y ago
    It's not just that. Search for "shortcuts" for example. Or something with networking. You can't click half of the items, some items are inaccessible from normal navigation. The whole thing is a mess and has no structure, it's basically a tag cloud of random items. vpn -> The menu makes NO difference in all options in the search results. performance -> on an M1, it takes about a second to switch each pane. Looking for a way to change the background image on your desktop? Better remember to type wallpaper.
    - guestbest 3y ago
      That’s because the new preferences app on macOS was rewritten in SwiftUI which had known performance issues
Alifatisk 3y ago
Someone once told me "SwiftUI is Flutter but for Apple devices only", can't get that out of my head.
- amnell 3y ago
  Just like Android Compose is Flutter but for Android devices only? Now you've got two things to get out of your mind.
  - Alifatisk 3y ago
    Oh my god...
    - Apocryphon 3y ago
      You’re both wrong. Flutter is just Unity for apps.
      - flakiness 3y ago
        I'd say you all are right ;-)
praseodym 3y ago
Does anyone happen to know what the `HomeEnergyUI` mentioned in the article does? As far as I know the Home app doesn't have any energy UI at this point.
- fingerlocks 3y ago
  My Home.app has an energy button in the top right that details my current household consumption and local grid forecast

346 points by ingve 3y ago

mrtesthah 3y ago

One takeaway from these charts is that the great majority of binaries in iOS are still written in Objective-C.

sbjs 3y ago
Having written ObjC since 2009 or so, honestly it's a fine language, and although I wrote a fair bit in Swift, I don't really see it as a significant improvement over ObjC, which is Good Enough™ to keep using. Something has to cause serious friction to be replaced with something significantly better, and ObjC/Swift just don't fit that pattern.
- sneakymichael 3y ago
  Oof, hard disagree. I absolutely hated writing Objective-C for years– I felt like I had to write unnecessary 'glue' with header files, handling of 'nil' was always jarring, and square brackets at the start and end of every call felt horrendous, to me at least. I relished the day Swift was announced, and have been using it ever since.
  - Dig1t 3y ago
    I love the square brackets. I find them aesthetically pleasing for some reason.
    - Apocryphon 3y ago
      With Xcode or any modern IDE the autocomplete "snap" of square brackets closing is a very satisfying code feel.
  - lapcat 3y ago
    > I felt like I had to write unnecessary 'glue' with header files Headers are a feature, not a bug. They're the API. They help document the API and also keep it separate from the implementation.
    - glhaynes 3y ago
      Objective-C programmers say this, but I note that I've never once heard a Swift developer complain that it's too hard to discover API interface or keep things non-`public`.
      - jshier 3y ago
        Only access control I wish Swift had is typeprivate so I could hide private things but make them available for subclasses (or perhaps protocol conformers). Unfortunately Apple has only added a package level so far, which seems fairly useless (you're either too big for it to be useful or too small to need it). Obj-C didn't really have ACLs at all, you just hid stuff in interfaces. Once found, those interfaces were no protection at all.
      - ninkendo 3y ago
        > never once heard a Swift developer complain that it's too hard to discover API interface Xcode presents the equivalent of a “header” when you follow a symbol to a framework you don’t have the source for… it’s a swift file full of definitions only and no implementations. The compiler emits this for you automatically as a .swiftinterface file > or keep things non-`public` I definitely am a swift developer that would complain about this. It’s way too easy to be cavalier about using the “public” keyword and making things part of the public API when they probably shouldn’t be. It’s like engineers have muscle memory from Java and just type “public class” without really questioning why first.
        lapcat 3y ago
        > The compiler emits this for you automatically as a .swiftinterface file It's so incredibly slow, though, which is frustrating. It would be ok if only this were as instantaneous as checking a header file. Ironically, almost everything about "Swift" is slower than Objective-C.
  - kevinsync 3y ago
    Agree -- my experience with Swift is that it's far more readable and closer to my personal aesthetics than Obj-C, but I actually struggled a lot figuring out how to write things the way that felt intuitive to me (ex. maintaining an observable global state + config that you can access from anywhere, easy declaration of and access to arbitrary/deeply-nested associative array keys, JSON handling, declare-once-use-anywhere icons and colors, that kind of stuff). Once I had all the convenience guts in place, writing actual functionality has been a delight though (outside of the overly-verbose let/guard and type casting) That said, I'm pretty sure I'm also probably just hard headed and doing it wrong, and could've learned the accepted patterns/methodologies lol
  - randomdata 3y ago
    I always thought the square brackets were clever. Like wrapping a letter in an envelope – which is a great metaphor for the message sending the syntax denotes.
  - deleted 3y ago
    [deleted]
  - jwells89 3y ago
    In the whole I don’t mind Objective-C, but when I have to write it these days I definitely get annoyed by having to navigate and maintain header files. It’s more extra overhead than one might realize. My other complaint with it compared to Swift is how one needs to pull in a bunch of utility libraries to do many things that come stock with Swift.
  - vor_ 3y ago
    I find modern Swift to be increasingly ugly and difficult to read. Reading classic Objective-C code is refreshing.
- jhatemyjob 3y ago
  I've had a similar experience, and generally agree with what you're saying. But I am glad Swift was created. All the plebs gravitate towards that language, so Objective-C remains unpolluted. I shudder to think how Objective-C would have deteriorated without Steve around.
  - wahnfrieden 3y ago
    ObjC is often no longer an option for building on new platform functionality
    - jhatemyjob 3y ago
      Can always use a shim
      - MBCook 3y ago
        Yeah but that’s a losing battle. As we go forward you’re going to have to shim out more and more of the new APIs that you need to use. Possibly in ways that are very inconvenient/hard to use in Obj-C.
        deleted 3y ago
        [deleted]
        jhatemyjob 3y ago
        It's been 10 years and I haven't had any issues. Maybe in another 10 years this will be enough of a problem to switch, but by that point I'll be retired
    - pjmlp 3y ago
      Metal is a counterexample of that.
      - saagarjha 3y ago
        Metal is not a new framework
- happytoexplain 3y ago
  I agree that ObjC is nice, and proven ObjC codebases probably don't benefit enormously from being re-written in Swift, but that has little to do with how much better Swift is (and it is much better, IMO).
  - randomdata 3y ago
    Swift is an improvement over C for the problem domain. Something akin to Swift as a modern C replacement with keeping of the 'Objective' bits of Objective-C layered on top of it would have made for the ultimate language, though.
    - MBCook 3y ago
      I don’t know how doable that would be. Objective-C does just about everything it can to make sure you can mess with it at runtime and confuse the ever living hell out of any type checker that wants to be strict. And the additional strictness is one of my favorite parts of Swift.
      - randomdata 3y ago
        In theory, you are only reaching for the 'Objective' parts of Objective-C when your code actually benefits from being object oriented (in the Kay sense). Otherwise you can stick to pure C. Of course, C has a lot of ugly traps which makes it less than ideal for this domain. This hypothetical subset language addresses those issues. While, again, you would only reach for the 'Objective' parts when your code benefits from being object oriented. It is true that the inherit dynamism of message passing makes static analysis impossible to cover all cases, but as with all things in life there are tradeoffs. You lose the nice aspects of object oriented systems if you do not allow for that, and OO is particularly well suited to UI code. Of course, Swift abandoned the object oriented model completely. Which is fine. But Objective-C showed that you can have your cake an eat it too, offering OO where appropriate, and a non-OO language for everything else. Objective-C's downfall was really just in that C didn't age well – which, among other things, I am sure contributed to seeing the use of the 'Objective' bits where they weren't really appropriate.
- mpalczewski 3y ago
  I’m in a similar boat. Header files typically led to faster compile times. OCMock worked like magic. Where both languages are poor is how large the binaries they produce are.
- koito17 3y ago
  Yup, Objective-C's object system was really flexible and powerful to use. Dynamic mixins, swizzling, etc. were all useful tools for me. Having messages as first-class citizens was probably the most important part to me. It helps make the object system expressive enough that I don't remember writing much design patterns ;) But seriously though, CLOS and Smalltalk-style OOP is probably the only flavor of OOP I really enjoy to use, and Objective-C gets you way closer to that than C++ and Java do. (e.g. the way KVO is implemented relies on "isa-swizzling", or dynamically changing classes at runtime)
  - sbjs 3y ago
    It's a false dichotomy to dislike OOP or prefer it. It's like saying I prefer hammers over screwdrivers. Just learn how the tools you have should be used and use them well. The only app I'm currently maintaining and proud of[1] makes tons of use of "traditional" OOP. It uses lambdas and FP when necessary. I think it makes absolutely no use of JavaScript's dynamic features. I'm fairly sure this code would port easily to ObjC. After 15-20 years, you just get bored of doing things in novel or "pure" ways, and do the bare minimum needed to get the job done that's in front of you. [1] https://github.com/sdegutis/immaculatalibrary.com https://github.com/sdegutis/immaculatalibrary.com
    - koito17 3y ago
      I am not sure if you understood my post. I am in no way saying "OOP is bad in general" or even "OOP is good in general". What I am saying is "I strongly prefer Objective-C's object system over that of other languages." Then I provided examples of other object systems I liked, and how Objective-C feels close enough to them that I don't miss them when writing Objective-C. Maybe saying "flavor of OOP" was too vague, but I am talking about implementations of object systems, not the (ill-defined) notion of OOP. Using your analogy with hammers and screwdrivers, my post is less "I prefer screwdrivers over hammers" and more "I prefer screwdrivers with bit holders over screwdrivers without bit holders"
      - balder1991 3y ago
- deleted 3y ago
  [deleted]
- woadwarrior01 3y ago
  Message passing goodness and flexibility (almost!) of Smalltalk, coupled with C for all things low level and perf related. It's a great language! I've switched to Swift for all things Apple these days, but I still miss coding in ObjC.
- MBCook 3y ago
  I really like Obj-C, but I much prefer Swift. It’s less verbose (even if I’m not a square bracket hater. It has some really nice new abilities like async (way easier/cleaner than callbacks in many situations) and now actors. But honestly 90% of it is true type safety. The type system is so much more powerful and expressive compared to Obj-C. There is only one downside, and it’s real. Compiling Obj-C was instantaneous. Swift is MUCH slower, which also slows down error messages and hints. And the fancy type stuff can even timeout the compiler. Combined with some Xcode issues (stale info anybody?) and it can be a pain. But I’m happy we have Swift.
- pjmlp 3y ago
  Sure if one loves typing []@ all over the place, and I know Objective-C since NeXTSTEP days.
sebazzz 3y ago
Objectively a full rewrite had rarely led to anything good.
- Affric 3y ago
  Yeah but the number of objective C binaries are still increasing.
  - RandallBrown 3y ago
    That could be because many apps that are mostly written in Swift are still using Obj-C frameworks.
    - OnlyMortal 3y ago
      Or core code is written in another language that’s cross-platform and the UI is done in AppKit.
      - meepmorp 3y ago
        We're talking about iOS binaries supplied by Apple here, so cross platform support isn't hugely important.
        pjmlp 3y ago
        In the context of Apple and Microsoft, cross-platform means across their own platforms, macOS, iOS, iPadOS, watchOS, and Windows x86, Windows ARM, Windows x64, XBox, Azure managed apps.
- agambrahma 3y ago
  I (objectively) see what you did there
wiremine 3y ago
And seems to be growing? I'm not close to this space, but it feels like Objective-C should be decreasing. I'd be curious to know why it's increasing.
- initplus 3y ago
  From the article: > Again please note that a single binary can be counted multiple times, so the sum of the binaries in this graph is greater than the total number of binaries So even if a binary only uses a small shim of Objective-C, it'll still count towards the Objective-C number.
- MBCook 3y ago
  Apple is all in on Swift. Everything is Swift first, with some new things Swift only. You can still call new Swift only APIs from Obj-C, but you’ll have to write your own glue layer.

khana 3y ago

[dead]

jshier 3y ago

Something not noted in the article is that any binary which links Foundation, even if otherwise written entirely in Obj-C, now uses Swift. This is due to the Foundation Swift rewrite effort (https://github.com/apple/swift-foundation https://github.com/apple/swift-foundation) that is rewriting Foundation is Swift while maintaining Obj-C ABI compatibility.

glhaynes 3y ago
I don't believe the new Foundation is shipping with any released versions yet, is it?
- jshier 3y ago
  Yes, it has shipped this year, even in the partial state. https://developer.apple.com/wwdc23/10164?time=1187 https://developer.apple.com/wwdc23/10164?time=1187
  - glhaynes 3y ago
    Oh, very cool. I’d missed that somehow. Thanks for the link!
    - bt4u 3y ago
      [dead]
xxpor 3y ago
What's the downstream effect of that?
- jshier 3y ago
  Bit better performance, fewer bugs, updated implementations.
  - xxpor 3y ago

_jcrossley 3y ago

Really look forward to this every year, Timac is a legend. The rate of SwiftUI adoption and decrease in UIKit-only binaries feels significant. Thanks!

kridsdale3 3y ago

Having cert failures, and can't actually view this pace.

codetrotter 3y ago
Loads fine for me.

explaininjs 3y ago

Shame they didn’t look at the “Fitness” app. It’s first party but requires a separate download. Probably because it’s some of the worst quality software I’ve ever seen. Its UI becomes desynchronized and self-inconsistent in ways I wouldn’t have believed are possible. The very fact that it exists and is capable of presenting as incoherent UI as it does is damning evidence against whatever UI framework it uses.

turdprincess 3y ago
SwiftUI exists to solve exactly this problem - the ui is declarative and state driven. However, its predecessor UIKit is mostly imperative and it takes a lot of manual code to keep the UI reflective of the underlying data model. For this reason I find many IOS apps, and especially apple’s own, to be always mildly broken. Programming in UIKit is like programming in JQuery, or maybe Backbone at best. SwiftUI brings us to the modern age of react (but with less capabilities and more bugs) IOS developers though tend to be pretty resistant to such “modern” paradigms. If you read the rest of the discussion on this post, you fill find that even using Swift, let alone SwiftUI is still a very debated issue. Maybe the grass is greener, but I don’t find the same resistance for new ideas in the web (typescript) or Android (kotlin) communities. I do wonder if this resistance is combing from an objective evaluation of the new tech, or the lack of desire/time to learn something new.
- jwells89 3y ago
  As a mobile dev, so far the biggest issue keeping me from adopting SwiftUI stems from its greenness and UIKit being so well fleshed out. The newness is an issue because new SwiftUI revisions ship with new iOS releases, which means that big chunks of it are gated by the oldest iOS version you support. Jetpack Compose on Android gets this more right since it’s independent of the OS, but suffers from other tradeoffs (Java ecosystem and the rest of Android dev gives me a headache sometimes). SwiftUI is also just missing various things that are present in UIKit, and so if you’re using those things it’s easier to write the whole app in UIKit instead of bridging those controls to SwiftUI. I absolutely foresee going SwiftUI exclusive but realistically that’s still a few years down the road.

tpmx 3y ago

Judging from SwiftUI uses in macOS: various things will become noticably slower for older devices for no apparent reason. This is bad for the planet and consumers but great for Apple. Edit: I see much interaction with this comment, but no response.

xyst 3y ago
What makes you think SwiftUI is slower than UIKit?
- tpmx 3y ago
  One such example: In macOS 13, the system settings was rewritten to use SwiftUI instead of UIKit. I had a 2019 Intel MBP. Before the rewrite, it was super swift (sorry). After the rewrite it took almost a second to go from section to section. Now I'm on an M2 machine so it's fast again. Congrats Apple.
  - boxed 3y ago
    On the other hand, the continued use of Swift by Apple will mean they feel the pain too and will improve the performance, which will make all apps faster as most new apps use Swift.
    - lapcat 3y ago
      > On the other hand, the continued use of Swift by Apple will mean they feel the pain too and will improve the performance LOL have you used Xcode lately? It's painfully slow, and getting worse. Apple engineers use all of the same crappy Apple software that we all do. The problem is that Apple executives have decided they don't care and are unwilling to invest the time and resources in performance optimization or good design. The relentless yearly update cycle will continue until morale improves. Steve Jobs is gone not only physically but also in spirit. It's Tim Apple now.
      - boxed 3y ago

ruuda 3y ago

The pictures in this article don't load without Javascript enabled even though there appears to be no interactivity.

xyst 3y ago
I don’t think they are images. Looks like graphs rendered with some js library. I’m on mobile.
- Timac 3y ago
  See the previous blog post on creating Charts in Markdown using Apache ECharts: https://blog.timac.org/2023/0627-charts-in-markdown-using-apache-echarts/ https://blog.timac.org/2023/0627-charts-in-markdown-using-ap...
  - biehl 3y ago
    Thanks for the great posts. Will you also do a post about MacOS this year?

simonw 3y ago

I loaded these all into a SQLite database so I could explore them with Datasette Lite (Datasette running in WebAssembly). Here's the result: https://lite.datasette.io/?sql=https://gist.github.com/simonw/0b8a2ddaeab76fe407b08a2b2041292a#/data/ios?_facet_array=languages&_facet=ios https://lite.datasette.io/?sql=https://gist.github.com/simon... You can use this to answer questions like which binaries are new in iOS 17 compared to iOS 16: https://lite.datasette.io/?sql=https://gist.github.com/simonw/0b8a2ddaeab76fe407b08a2b2041292a#/data?sql=select+rowid%2C+ios%2C+path%2C+parent%2C+filename%2C+languages+from+ios+where+%22ios%22+%3D+%3Acurrent+and+path+not+in+%28select+path+from+ios+where+ios+%3D+%3Aprevious%29+order+by+rowid+limit+101&current=iOS17&previous=iOS16 https://lite.datasette.io/?sql=https://gist.github.com/simon... Or here's just the binaries in the /System/Library/VideoDecoders folder - it's interesting to compare iOS 1 (just H264H1 and MP4VH1) to iOS 17 (AppleProResHWDecoder, AppleProResSWDecoder, AV1SW, AVD, H264H8, JPEGH1, MP4VH8, VCH263, VCPMP4V) https://lite.datasette.io/?sql=https://gist.github.com/simonw/0b8a2ddaeab76fe407b08a2b2041292a#/data/ios?_filter_column_1=&_filter_op_1=arraynotcontains&_filter_value_1=Objective-C&_filter_column_2=&_filter_op_2=arraynotcontains&_filter_value_2=Swift&_filter_column_3=parent&_filter_op_3=exact&_filter_value_3=%2FSystem%2FLibrary%2FVideoDecoders&_filter_column=&_filter_op=exact&_filter_value=&_sort=rowid&_facet_array=languages&_facet_size=max&_facet=ios&_facet=parent https://lite.datasette.io/?sql=https://gist.github.com/simon... Details on how I built this here: https://gist.github.com/simonw/0b8a2ddaeab76fe407b08a2b2041292a?permalink_comment_id=4732049#gistcomment-4732049 https://gist.github.com/simonw/0b8a2ddaeab76fe407b08a2b20412...

Timac 3y ago
Really nice, thanks for sharing!

mrcwinn 3y ago

I really enjoy working with Swift. (Although I'm old school and enjoyed ObjC just as much.) I wish I had more time to work with. React Native is stealing all the fun!

perfopt 3y ago
I learnt Swift several years ago for a App project Haven't really used it since. My impression is that it is useful only in the Apple ecosystem. It that correct? Is it worth learning for things other than iOS and macOS applications?

zoogeny 3y ago

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.

lolinder 3y ago

These charts are almost meaningless. They're double- and triple-counting binaries: the slope of the Objective-C line and the slope of the Swift line are identical because nearly every added binary uses both languages. That doesn't provide any meaningful information except that Apple is still using both. It gets worse when they get to the percentages: they list 61% as Objective-C's number for iOS 17, but 61% of what? According to the raw data, Objective-C is used in 88% of all binaries on iOS 17, with Swift used in 25% (instead of the 17% they list). Their calculated numbers are derived from a denominator of 8723 binaries, even though they only have 6030 in their data set, because they wanted the numbers to add up to 100%. That makes a nice chart, but it has no meaningful interpretation.

mplewis 3y ago
You're essentially looking at a series of pie charts, and it does tell a useful story: that there is more code being written in Swift and SwiftUI year over year.
- lolinder 3y ago
  The problem is that the pie chart is lying—it makes it look like the percentage of binaries containing Objective-C is going down over time, but it's actually going up just as rapidly as Swift is, because almost all added files contain both Objective-C and Swift. The only languages that are going down as a percentage of binaries are C and C++, because fewer new modules are being added using those. The reason why it looks like Objective-C is losing ground is that every Objective-C+Swift+SwiftUI binary increments the denominator by 3 instead of by 1, and there are more of those added every single year. Since each of those binaries only adds 1 to the numerator, Objective-C's share of the binary pie seems to be decreasing even though it's actually keeping up with Swift. It's entirely possible and even likely that Swift is increasing faster than Objective-C in terms of lines of code, but this data can't be used to show that.
  - boxed 3y ago
    I would guess that Swift isn't increasing in lines of code as fast as ObjC, because Swift gets more done per line of code. But "per feature" I'd guess Swift is slowly inching out ObjC.

p-e-w 3y ago

> iOS 17 contains 6030 binaries, up from 5403 in iOS 16. That’s 627 new binaries. That's... insane. Even worse, the graph appears to show a superlinear trend. For comparison, iOS 2 had only 278 binaries. With such out-of-control software bloat, secure computing is never going to happen. There isn't enough brainpower on the entire planet to secure a system that grows to the tune of hundreds of components per year.

xvilka 3y ago

Hopefully Google will do the same with Android and Rust[1][2] [1] https://arstechnica.com/gadgets/2021/04/google-is-now-writing-low-level-android-code-in-rust/ https://arstechnica.com/gadgets/2021/04/google-is-now-writin... [2] https://security.googleblog.com/2023/10/bare-metal-rust-in-android.html https://security.googleblog.com/2023/10/bare-metal-rust-in-a...

thrdbndndn 3y ago

> In iOS 16, only 4 apps used the SwiftUI-based app lifecycle. In iOS 17, this figure has grown to 14 apps What does this mean (what is app lifecycle)?

jshier 3y ago
Presumably it means the root of the app is a SwiftUI App-conforming type rather than a UIApplication. Of course SwiftUI can bridge into UIApplication so it's entirely possible for apps to be using both (though you can't really bridge the other way).

pjmlp 3y ago

On the same subject, some talks from Apple folks, "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw "Swift as C++ Successor in FoundationDB" https://www.youtube.com/watch?v=ZQc9-seU-5k https://www.youtube.com/watch?v=ZQc9-seU-5k

jbverschoor 3y ago

Apple needs to start polishing their UI again all the way from the start. Preferences is such a mess. Many apps are simple backports of touch-only apps. I don't think Apple requires all developers to have read the HIG.

Dennip 3y ago
Agreed. So many settings now are hidden away 5 levels deep and not easily searchable. Why is updating apps hidden away 2/3rd's down in some profile section on the app store.
- brainzap 3y ago
  actually that one makes sense since apps automatically update during the night
- jbverschoor 3y ago
  It's not just that. Search for "shortcuts" for example. Or something with networking. You can't click half of the items, some items are inaccessible from normal navigation. The whole thing is a mess and has no structure, it's basically a tag cloud of random items. vpn -> The menu makes NO difference in all options in the search results. performance -> on an M1, it takes about a second to switch each pane. Looking for a way to change the background image on your desktop? Better remember to type wallpaper.
  - guestbest 3y ago
    That’s because the new preferences app on macOS was rewritten in SwiftUI which had known performance issues

Alifatisk 3y ago

Someone once told me "SwiftUI is Flutter but for Apple devices only", can't get that out of my head.

amnell 3y ago
Just like Android Compose is Flutter but for Android devices only? Now you've got two things to get out of your mind.
- Alifatisk 3y ago
  Oh my god...
  - Apocryphon 3y ago
    You’re both wrong. Flutter is just Unity for apps.
    - flakiness 3y ago
      I'd say you all are right ;-)

praseodym 3y ago

Does anyone happen to know what the `HomeEnergyUI` mentioned in the article does? As far as I know the Home app doesn't have any energy UI at this point.

fingerlocks 3y ago
My Home.app has an energy button in the top right that details my current household consumption and local grid forecast