4 ms·
One takeaway from these charts is that the great majority of binaries in iOS are still written in Objective-C.
by 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 agoHaving 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 agoOof, 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 agoI love the square brackets. I find them aesthetically pleasing for some reason.
- Apocryphon 3y agoWith 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 agoObjective-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 agoOnly 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.
- ultrarunner 3y agoEveryone's brain is probably different, but when I first started writing swift I definitely missed header files. When I switch back from a c project I miss them again.
- kevinsync 3y agoAgree -- 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 agoI 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 agoIn 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 agoI find modern Swift to be increasingly ugly and difficult to read. Reading classic Objective-C code is refreshing.
- jhatemyjob 3y agoI'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 agoObjC is often no longer an option for building on new platform functionality
- jhatemyjob 3y agoCan always use a shim
- MBCook 3y agoYeah 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 agoIt'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 agoMetal is a counterexample of that.
- saagarjha 3y agoMetal is not a new framework
- happytoexplain 3y agoI 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 agoSwift 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 agoI 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 agoIn 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 agoI’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 agoYup, 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 agoIt'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 agoI 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 agoMessage 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 agoI 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 agoSure if one loves typing []@ all over the place, and I know Objective-C since NeXTSTEP days.
- sebazzz 3y agoObjectively a full rewrite had rarely led to anything good.
- Affric 3y agoYeah but the number of objective C binaries are still increasing.
- RandallBrown 3y agoThat could be because many apps that are mostly written in Swift are still using Obj-C frameworks.
- OnlyMortal 3y agoOr core code is written in another language that’s cross-platform and the UI is done in AppKit.
- meepmorp 3y agoWe're talking about iOS binaries supplied by Apple here, so cross platform support isn't hugely important.
- pjmlp 3y agoIn 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 agoI (objectively) see what you did there
- wiremine 3y agoAnd 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 agoFrom 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 agoApple 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.