Ask HN: How many of you Apple developers still use Objective C?
Anyone developing macOS, iOS, iPadOS, etc. are still using Objective C in there personal or work projects?
I wrote a Swift app for a hobby/free project a few years ago and regretted it. They changed the language and deprecated some of my code, which isn't easily replaceable without a significant rewrite. The project now compiles only in Swift 4 and will die when Swift 4 support is removed from Xcode.
I see no reason to use Swift. The compiler is slower and buggier. The debugger is slower and buggier. C interoperablity, while it exists in Swift, can be very painful. And I don't actually ship any bugs that Swift could have theoretically saved me from. I see no gain in switching.
People have been telling me since 2014 that every line of code I write in Objective-C is "technical debt". I continue to laugh at them and ask them to compile Swift code they wrote in 2014.
Of course if I had to get a job, it would be a different story, but I own my company, so I can do whatever I want.
For example OCR - you can use the old low quality Vision API but the new ImageAnalyzer can’t be accessed via ObjC and requires custom bridging. More and more new APIs will be Swift exclusive
Interesting, that hasn't been my experience. I'm curious, what have you ran into that was painful?
You don't need to justify op with old anecdotes, people want to know what the issues are today, if any. At least that's what makes this website valuable for me.
In any case, this particular observation is timeless: language bridges always have trolls under them. Maybe your project can get away with using the bridge anyway, but maybe a highly critical API gets locked out because the bridge deals poorly with variadic arguments or object lifetimes or templates/generics or nested objects or latency/overhead assumptions or.... whatever, and the troll conks your schedule on its head. Try to minimize exposure and prioritize steps to de-risk the bridge.
Not OP, and I for one don't, but noting the age of the reported experience would be valuable. I have also noticed the "stale cache" problem. It leads to confusion and misunderstanding.
The second is that it's a lot of code and files to make when we only have one import to hack something quickly. For a full library it's probably a very cool feature though.
The third one is more related to my use case. I made a binding with a non-C codebase, and Swift cannot directly import C functions AFAIK, so I had to write C code in addition to the Swift one to make headers. It's not impossible, but it does take time to write all of that in a third programming language.
The fourth problem is related to library imports. In SPM, you either import a system library, or an xcframework. If your app targets any non-Apple platform, xcframeworks are not an option, so if you made a binding to your own lib that's annoying as it is probably not installed while you're building. And even if you're targeting Apple platforms, making an xcframework without Xcode is not well documented.
I probably missed a few problems as my experience is not very extensive, and there are probably better ways to achieve some of the things I wanted to do, but there isn't much documentation about all of that online anyway as far as I saw.
I solved that through importing the dependency with Conan, and having extra steps running afterwards that would perform some quick and dirty lipo, xcodebuild and PlistBuddy stuff. It just wasn't that complicated, and only a few headscratches, but then it'd work and there was no need to touch that again, but situations may vary and I get that it could be painful in some cases.
the problem with Swift is that it is a systems programming language and not an app-development language. far to cumbersome, complicated and unproductive for writing apps.
Huh? As compared to Objective-C, with Swift you generally get more done with less boilerplate, less repetition, and certainly far less semi-colons and square brackets.
If you consider ObjC to be an app-development language, I can’t really imagine how Swift can’t be one?
You see this as a consumer, too. Apple very much moves on from old hardware compared to Microsoft.
Maybe I’ve had a good experience because I’m not working on a FAANG project with a million lines of code, but that’s all to say there are shades of grey, and you have to consider what you get in exchange for Swift’s compiler and evolution overhead.
Personally, I’ve found Swift helps avoid entire categories of bugs that crop up in ObjC, like accidental nil messaging. Generics have allowed me to avoid duplicate implementations. Now SwiftUI has allowed me to implement things in hours what would have taken me days in UIKit. I could go on for a while, but those are off the top of my head.
If you find yourself enjoying ObjC, by all means keep using it. Or C. Or Pascal. Or Lisp. There are tons of different ways to accomplish the same thing, but that doesn’t account for extra-hours and bugs it takes to get there.
I didn't say I enjoyed ObjC. That's not really how I choose my tools. It's a job. The choice is utilitarian.
> Or Pascal.
I seem to recall enjoying Pascal somewhat, though that was a very long time ago.
> Or Lisp.
I definitely recall not enjoying Lisp. Not at all. Yuck.
> that doesn’t account for extra-hours and bugs it takes to get there.
If Swift helps you, that's great. I'm just writing about my experience. For me, it doesn't help. I'm certainly not deliberately avoiding a tool that would help me. I do write my share of bugs, but I rarely write the type of bugs that the Swift compiler would catch, and I never ship them. YMMV
I'm not intending to offer advice of any kind to others. I'm not much for giving or taking advice. And like I suggested, if I needed to find a job, then I'd probably have to go all-in on Swift. My goal, though, is to never get another job for the rest of my life. ;-)
Given C is faster and more mature than ObjC, why aren’t you writing everything in pure C and objc_msgSend?
TBH your question feels trollish, but I'll respond anyway.
Objective-C code does compile to objc_msgSend calls. Perhaps you meant getting the method implementations directly and calling them instead?
Objective-C is 40 years old. How much more mature does it need to be?
In the previous comment you said I should use objc_msgSend, now you say I shouldn't. Make up your mind. ;-)
Anyway, I'm using AppKit and UIKit to write apps. The API is Objective-C. That's why I write Objective-C.
Whatever the heck you're talking about—you appear to be confused, so I don't know what exactly you mean technically—it certainly sounds like premature optimization, which is a waste of time and not the correct utilitarian choice. My Objective-C code is not "slow". Could it be infinitesimally "faster" in way that's not even perceivable by the user? Perhaps, but who cares?
Then I built an iOS app for a consumer-electronics company alone, from the ground up. I learned Swift and wrote the whole app in it. I liked it a lot. Once I had the language down, I was very productive and able to implement almost any change that management requested in a few days at most.
SwiftUI, however, is a very different story. It's a half-assed, often brain-dead environment that has made building my own application from the ground up PAINFUL. Not only has it taken months to do what should have taken weeks, but SwiftUI and the attempted "reactive" paradigm it's supposedly optimized for are so full of holes that Apple's recommended practices simply don't work. "One source of truth" my ass; SwiftUI and the absurdly incomplete observation framework it relies on make that impossible.
I usually blame myself for just not having read enough, but with SwiftUI my research has far too often concluded with a finding that, "Oh yeah, that doesn't work."
--- Rant - With Swift Apple shifted dev power to themselves. Having gotten fat on the open world, they've backed away from every 'Open' technology they can, and replaced it with their own, ( presently all the way to CPU architecture). Yes, they are giving tremendous powers, but have they also crafted the One Ring.
Surely it's a good thing that a young language evolves, you can't improve without changing. And Apple were very clear about the fact that there would be breaking changes.
You can of course insist on using Objective C if you prefer it, but that closes the door to most of the new APIs that are being added by Apple, which seems like a very steep price to pay for the privilege of using a legacy language.
You, knowing absolutely nothing about my code: "you should be able to migrate it to Swift 5 before lunch time"
(In this respect, yours is such a sterotypical HN comment. "I could build [whatever] over a weekend.")
Moreover, even if your baseless, overconfident assertion were true, it's now about 6 hours until lunch time, and I'd rather not waste that time on a free hobby project just to make the damn Swift compiler happy.
> that closes the door to most of the new APIs that are being added by Apple, which seems like a very steep price to pay
I haven't needed anything that requires Swift, so there's been no price paid. I'm doing great. No problems! Swift proponents seem to have to tell themselves that I'm suffering in some way by continuing to use Objective-C, but I'm not suffering at all.
Regardless of language, I usually avoid new Apple API, because it tends to be half-baked and buggy.
Moreover, if I needed help with a Swift issue, I would go to my many friends and associates in the Apple developer community. In fact, I've discussed the issue with some members of the Apple Swift engineering team, and I have an open bug report that Apple hasn't addressed. The very last person in the world I would consult about a programming issue is a random, condescending HN replier.
Wow, you just won't stop with the condescension. You won't even accept that it is difficult.
> I am just saying that I never had any problems migrating to Swift 5.
Good for you. Guess what, people have different code and different experiences.
> you found so overwhelming
I didn't say it was "overwhelming". I said that it's more trouble than it's worth for a free hobby project. It's not even a real problem yet, because as I already said, "The project now compiles". The problem will occur "when Swift 4 support is removed from Xcode", which hasn't happened yet. Even when that does happen, I can keep around an older copy of Xcode for quite some time.
The reason I brought this up in the first place is that unlike with Swift, I can still compile very old Objective-C code, and sometimes I need to. Objective-C generally doesn't break stuff (with the notable exception of Objective-C Garbage Collection). I'd rather not deal with the hassle of tool breakage if I don't need to.
It's important to note that there's still tons of Objective-C written inside Apple to this day, perhaps more than Swift.
What Apple pushes as what you should be using is often not what they are using internally, FWIW. Third-party developers are its true beta testers.
I can completely see why people would think the opposite, though.
E.g. there was a Flickr API library that directly translated the message names into API calls. Very neat, but now a typo stops being a compiler error and becomes a failed API call.
Mostly it was used to bypass Apple's private API App Store restrictions by obfuscating message names in rot13 or something.
I don’t know if this is true or not, but Apple certainly isn’t writing its own end-user applications with good macOS technologies and support (which means it’s not using Objective C and Cocoa). Apps like Reminders, Notes, Photos and others on macOS seem and behave like poorly ported versions of an iOS app.
Someone posted a great analysis breaking down how many binaries used which language in iOS through the years
Sometimes an old code sample is only available in ObjC. Sometimes you need to interop with a legacy API that wasn’t bridged cleanly. Sometimes it’s helpful to fiddle at runtime in debugging.
It’s kind of like how you probably shouldn’t write C nowadays, but C is still an important language every developer should be able to navigate.
The common wisdom was; nobody will take you seriously as an engineer unless you learn Objective-C. I was also trying to understand the book "High Performance iOS Apps", all in ObjC, so had to take a lengthy segue through an ObjC tutorial book.
While this was useful for expanding my horizons somewhat, I have never in my career had to use ObjC in production.
I have, however, used it a little in the last 6 months, though ironically this was when writing a blog post about Apple's Animation APIs through history - to ensure I was authentic, I wrote the Quartz, OpenGL, and CoreAnimation sections in Objective-C. To this date, this is the only ObjC I have written which has done anything of value.
The blog post is here - https://jacobbartlett.substack.com/p/through-the-ages-apple-... The GitHub project is here (all open source!) - https://github.com/jacobsapps/animation-through-the-ages
Method swizzling is also an important tool for any aspiring macOS developer, unavailable/onerously painful in Swift.
All in all, I don't think there's anything wrong with continuing to write new things in modern Obj-C as long as you're conscious of the tradeoffs and interoperability is a concern.
I use swizzling in Swift. Can't see why it's more painful than in Objective-C. It's also not something you do all the time. It's basically write once code for me.
Funny enough I mostly use it so swizzle UIViewController lifecycle methods and then just pass closures in instead of subclassing UIViewController. Yes, I don't subclass UIViewController and haven't for years and years. (I mostly don't subclass that much nowadays - take that Objective-C!)
No, the platform vendor promotes a lot of shit.
I remember when they were heavily pushing Objective-C Garbage Collection. The fools who adopted it got burned when Apple removed GC entirely, killing their apps. I'm not suggesting that Apple will remove Swift, but it's a mistake to listen to Apple's hype and what Apple says. Their PR is not trustworthy. Make your own decisions.
Please don't violate the HN guidelines. https://news.ycombinator.com/newsguidelines.html
Interoperability between Swift and ObjC works really well for the most part, so I tend to write any new files/modules in Swift, and older apps end up being a hybrid of both. I rarely see justification in rewriting existing ObjC code in Swift unless the code needs a rewrite anyway.
Unless you do anything for MacOS and care about MacOS. Most Swift UI apps I've seen feel foreign on MacOS in innumerable ways.
Because of that I've seen people discuss that they have to reach for AppKit and/or ditch SwiftUI and got all in with AppKit, and that is easier to do from Obj-C.
You can fairly easily port UIKit apps to macOS now with Mac Catalyst[1] No need to use SwiftUI to get those mobile-isms.
My previous job was all Obj-C at a fairly large and well known company. When I left in 2019 they were beginning to experiment with adding Swift.
I started coding iOS apps around version 5 which was right before the addition of ARC. I've grown to miss the simplicity of Obj-C and have a love/hate relationship with Swift but likely in a few years there won't be much of it left except at big companies who have very old apps.
Got my start in Objective-C back in the 2000s tinkering with OS X apps and used it at work for writing iOS apps from 2015-2017, but I embraced Swift pretty quickly (IIRC I started to take it seriously around 2.x).
It required significant shift in mental models, but having so much more built into the language (needing fewer dependencies is never ever a bad thing, especially when using CocoaPods), less silent breakage, optionals, no awkwardness from having to maintain C compatibility, no need to maintain header files, etc was a big deal for me.
These days if I’m using it it’s in personal projects to swizzle or access private APIs or in super simple projects that don’t really benefit from Swift’s frills. Aside from that, some projects still have Obj-C dependencies which I’ll need to delve into the source of to debug issues occasionally.
Newbie material for Obj-C and Cocoa was truly slim pickings at that point, particularly if your local library was too small to carry those books and you couldn’t afford to buy them yourself. All I had to go off of was the odd blog post I’d run across and later on, patient AIM friends (who I am still grateful to) who’d explain things if I asked, so it took a while to become able to write anything significant.
That being said, we are going to refactor from Google's Closure Compiler to TypeScript on the JS side of the project: surprisingly, we've seen more discomfort with developing with Closure Compiler than we've had complaints with developing with Objective-C.
Objective-C is a really neat, old language. Initially I was very gungho about switching to Swift, but all of my pain points are with the Apple APIs that we're accessing (and not Objective-C itself). If Objective-C had dot-syntax for calling methods, some more modern typing, and the less verbose Apple APIs, I would have been very happy sticking to Objective-C.
I recently got into a client project that has some large swaths of Objective-C code. It’s a joy again, as the compiler is fast and the in-progress writing compile-ahead isn’t always shouting at me.
It’s really making me nostalgic. That said, I’ve been programming in C a lot lately, so there’s obviously a kinship there.
And note: unbelievably, its 2024 and Apple is able to still fuck up drawing in very recent versions of macOS. How an organization with the history and resources that they have can get such basic stuff wrong is really beyond me.
https://developer.apple.com/forums/thread/738042
(this appears to be fixed as of 14.3)
While we tend to add less new Obj C, we don't go out of our way to replace old Obj C with new Swift if the old code is working. If it makes sense to replace some of the Obj C, we do, and this happens on a case by case basis.
At the end of the day code is just a tool, and if it's doing its job it's worth a sober look at whether the opportunity cost to replace it is really worth it beyond some perceived notion of newer == better.
Some things that I really like about Obj C more than Swift:
easier to explicitly manage memory
clear separation of declaration and implementation files
faster to compile
easier to interop with C
Resources: Obj C is old, and there's a ton of info out there on how to solve your specific problem
Yeah, that's the thing you always squint at, but start missing when it's gone. Working with modern languages without declarations quickly makes you feel like the declarations are missing.
I have some stuff that has zero Swift and likely never will. Most other things are a mix.
If I'm writing any ObjC code in a new app today it's probably because either I'm working with some funky low-level API designed for C, my Swift code triggered some kind of compiler bug, or I got pissed off at the way Swift mangles the AppKit or UIKit APIs. Otherwise, I'm probably using Swift for most other things.
Early Swift adapters got the arrows in the back. I was not an early adapter.
Objective-C gets a bad wrap (unfairly, IMO), but it's a neat language, and compilation is so much faster than Swift.
I make the bridges from Cordova to Swift using Objective C wrappers around functions, but choose to write the actual implementations in Swift. Kind of like I code HTTP handlers as the "controller", and then call from there to PHP classes as a "model".
I tried to download that but the file was damaged
I maintain some other code that is a mix of Swift, Objective-C and C. I'd happily rewrite the Objective-C components in Swift (except there's no reason to, as it works).
Nobody makes Cocoa (AppKit) learning resources anymore, especially not in modern Swift, but Objective-C ones still work to this day.
I'm sure I'll switch to Swift eventually, but even macOS Sonoma is still 53% Objective-C code, so if I really want to grok it, I have to have at least some knowledge of the language. Even if Swift is better, this will still help me learn why it is better.
All of Apple's new APIs will be Swift-friendly or Swift-exclusive, no reason to actively use anything else unless your personal preference overrides.
As I’ve been doing Mac/iOS programming since the retain release days, ObjC has a place in my heart, but swift is a decade old now (was announced 10 years ago this WWDC) and is pretty much the app language of choice.
Now that the ABI stabilized, even binary library authors are getting in on it.
Newer stuff like SwiftUI and SwiftData you might want to wait on, but Swift is pretty much most of what I’m up to these days.
(edit: typo)
It is _insanely good_ to my eyes since I’ve done ObjC since the NeXT days and find Swift full of weird corner cases and limited functionality.
Though in the FAANG world - Objective C reigns supreme
I write my Apple stuff exclusively in Swift, and don't bridge to C. I have been doing that, since 2014. Before that, I wrote in ObjC.
I still use UIKit/AppKit/WatchKit for my shipping apps, though. I do not believe that SwiftUI is ready yet, for the scope of my work (I just tried again, this week, and it's still a nope).
For now though, the bulk of my UIs will continue to be built with code-only (no storyboards/XIBs) UIKit.
I tend to use storyboards, because of some of the fancy auto-layout stuff I do.
The problem is in the way that the binding and the observable stuff works (or doesn't). If the design is the basic text-layout stuff, it works great. Better than great. Having come from a device control background, the reactive/observable model is one I have no problem with.
However, whenever you have a complex interaction, like a map that can be modified from a number of directions and data sources, things go a bit pear-shaped.
I spent four days, trying to get the map to do what I needed it to (something that takes a day, in UIKit), and gave up.
I suspect that it would not have worked cross-platform, anyway, which is why I was interested in SwiftUI.
This is a typical complaint that I've heard. It's really difficult to stray from the beaten path in SwiftUI, and folks don't figure that out, until they have already invested a lot of time into it.
All relevant obj-c libraries provide an auto-generated native swift interface, and you can even ‘import objc’ if you fancy doing some obj-c runtime stuff – such as swizzling – and still write in Swift.
I wouldn’t expect to see and/or use it for anything but the most esoteric of use cases these days.
I mainly chose it for the c interoperability and I don't have any interest in swift.
This allows me to use existing code bases and SDKs, such as the AWS one.
My god, sit down and just nod and say to totals "oh you like ObjC, neat ", or better yet try to understand what they're saying. You do not have to offer your trite condescension.
ObjC is a fantastic language, Swift is fine too but the compiler is slow and breaking changes to the language are painful.
The migration assistant? FFS it only goes so far, and only when it works.
Also, I hate it.