I use Objective-C exclusively (no Swift) in my App Store apps.
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.
As a counter-anecdote from someone who also runs their own company, I began dabbling in Swift in 2014. I held off on full Swift adoption until after the big API renaming that happened with Swift 3, so language migrations haven’t been a big deal. The compiler is slower, but I can still do a clean build in 43 seconds.
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.
> If you find yourself enjoying ObjC, by all means keep using it. Or C.
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. ;-)
You said you make the utilitarian choice. By using C everywhere, you can use an even faster compiler that doesn’t insert those calls for you. So why don’t you?
> By using C everywhere, you can use an even faster compiler that doesn’t insert those calls for you.
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?
I built an iOS app alone, from the ground up, in Objective-C. This was after I left Apple, where I mostly used C++. I hated Objective-C less than I expected, and the app was functional and reliable.
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."
former Mac dev here, and completely agreed. Refactoring an app because someone else decided to change the language is a bridge to far. And if they do it this time, they'll do it again. Meanwhile the ObjC compiles.
---
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.
Yes, but it is common for new languages and frameworks for there to be lots of change in the first few version. Then it matures and settles down. AFAIK Swift is not regularly making large changes, anymore.
After years of obj-c I wrote a rather larger app on Swift 1.1. I'll never forget the pain of upgrading to each new version of Swift. And my god, the pain of early swift string manipulation. 100% technical debt annually.
If there’s one lesson to take from Swift 1 and 2, it’s that Apple is comfortable launching beta APIs that can undergo massive churn. It’s why I avoided SwiftUI for the first few years, and now why people would be wise to do the same for SwiftData.
Same with Google. When they announced that Compose was now "stable" I laughed out loud and said "they just slapped a 1.0 version on it, didn't they?". And yes they did. We're a lot of releases later and it's still no fun to debug weird-ass issues. Last week I had two textfields, and both of them had focus at the same time!
Honest question: what exactly did you expect when adopting a brand new language? Apple were explicit that they would make breaking changes. Besides, would you rather be stuck with Swift 1 forever? It was pretty meagre in retrospect.
You’ll have an increasingly harder time adopting new Swift-only APIs
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
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.
This is objectively false. It's first and foremost an app development language. In fact this is a common complaint, that Apple pushes too many features that are specific to app development and now SwiftUI.
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?
I started using Swift right away in 2014 and worked on several large projects written in Swift 2, 3, 4. Of the three or four large migrations I had to perform, the worst one still took less than a day - unless your Swift 4 project is enormous, you should be able to migrate it to Swift 5 before lunch time, the differences are really minimal.
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.
Me, knowing my own code: "isn't easily replaceable without a significant rewrite"
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.
The source breaking differences between swift 4 and 5 are very few, and quite mechanical. Most of them should be adequately handled by the migration assistant, did you try that? If it’s open source, I’m happy to take a look.
I offered help, not condescension. In my experience migrating to swift 5 has been exceptionally painless, so if you find it onerous I was offering to assist you.
It's condescension because you continue to refuse to believe what I'm saying, and you keep insisting that something difficult is easy.
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.
I don't doubt that you find it difficult, I am just saying that I never had any problems migrating to Swift 5. That's why I offered help, and because I am genuinely curious what it was that you found so overwhelming.
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.
If I recall correctly you have to make a separate module with the bridging headers, but the first problem is that I can't remember exactly of the syntax of that file.
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.
Alright yeah, I can concur with the packaging of the library so that it would eventually link and be accepted by the App Store which is surprisingly not the same set of requirements. It's just that I didn't completely chalked this up to Swift interop with C specifically but more the fact that multiple things Apple side need some jumping-through-hoops and that's just one of them.
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.
I'm not op and it's been many years since I tried but back in the early days of Swift interop with C worked great until it didn't and it was very difficult to figure out what was going on because the debugger might as well have not existed.
Not aimed at you particularly, but I've noticed more and more of the technical discussion on HN turn into "I don't really use it, but here's my many years old experience / non-user observation", which is mostly just confusing to people trying to leadn.
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.
Do you expect people to periodically repeat failed experiments just so they can provide you with up to date information? You are always free to ignore it.
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.
Do you expect people to periodically repeat failed experiments just so they can provide you with up to date information?
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.
Definitely makes sense. In defense of the previous comment I made though, the debugger is only marginally better than when Swift first came out. That's regardless of whether or not you're interoping with C. It's still a terrible experience compared to what Obj-C provided.
I've given up on Apple platform development, but I strongly prefer Objective-C over Swift for a variety of reasons, including elegance, compatibility, stability, etc.
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.
Elegance. I keep hearing that from obj-c devs and I really don’t understand what is so elegant about it. Maybe it’s more to do with familiarity? I find swift much easier to deal with and more “elegant” to read.
Message passing is neat, but every time I saw someone take advantage of its flexibility, it was a mess.
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.
You could probably say the same about most large public orgs. For instance many Amazon teams don't even use modern AWS internally for their services. At least as of three years ago.
> It's important to note that there's still tons of Objective-C written inside Apple to this day, perhaps more than Swift.
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.
While all of our app are almost entirely Swift and Metal, I’d say it’s still invaluable to be proficient in Objective-C, given how relatively little investment it takes to understand.
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.
I had a weird relationship with ObjC getting into iOS in 2016, just on the cusp of the great renaming of Swift 2 to Swift 3, where my first employer was a little too cheap to get me an updated Big Nerd Ranch guidebook.
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.
Modern Objective-C with ARC is fairly painless, especially compared to the Objective-C of yore. And if you are doing macOS-specific work for a C/C++ codebase, it's still simpler to integrate than Swift is.
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.
> Method swizzling is also an important tool for any aspiring macOS developer, unavailable/onerously painful in Swift.
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!)
I've been programming for 56 years. Over that time if I had changed languages without a compelling reason, it would have been a huge waste of time, energy, and peace of mind. I'll stick with objC until I am compelled by practical reasons to change.
> Isn't the fact that the platform vendor very clearly promotes Swift
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.
There are already many APIs you can’t use, and more or less all APIs in general are now easier to use in swift. But sure, you can still write apps in objc.
I am an iOS developer and I haven't used ObjC in over five years. There probably isn't any reason to start a new app or library with anything other than Swift. So it's just going to depend on the legacy code base.
I agree there's no good reason to write new (iOS) stuff in ObjC now days, but you're likely to still encounter plenty of ObjC if you're maintaining old projects.
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.
Since Swift UI is iOS-first, when the apps get ported to MacOS, they bring a lot of mobile-isms: the views and animations are often wrong, the controls are often wrong (like even the Apple's own settings app breaks a lot of established platform conventions and Apple's own HIGs), integration with system services is often incomplete (like proper keyboard shortcuts, I can't set a shortcut for Conversations->Delete in Messages anymore) etc.
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.
Also AppKit works perfectly well in swift. People just probably remember the ObjC versions of things better since that’s where this all started. But the naming is pretty standard if you remember the old calls.
I work on an app that pre-dates Swift by a year. At this point I'd say about 60-70% of the app is in Swift but there's still large chunks of core functionality that's obj-c. It's mostly stable though and we don't work in that part of the codebase very regularly. It's been a few years since we made any noteworthy modifications to it.
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.
My first contact with Objective-C and Cocoa was somewhere around 2001 or 2002 when I decided to tinker with the contents of the developer disc included in the OS X retail box, and while I toyed with Interface Builder (which resembled REALBasic, which I’d previously been using) quite a lot I wouldn’t write anything functional for another couple of years.
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.
We still default to Objective-C in our SDK. We still support iOS 11, and I don't think we've been bothered enough by Objective-C to check which versions of Swift can be used on the versions of iOS that we support (I last checked a couple of years ago when we supported iOS 8, where the compatibility matrix was a problem for us). However, the examples are in Swift, and we're using Swift wherever the language doesn't matter. iOS's Objective-C support and Objective-C/Swift interoperability is good enough that there aren't business pressures to switch, and the code isn't changing frequently enough that refactoring to Swift would save us in overall time/effort.
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’ve been an Apple platforms developer since 2002, though on and off in the past five years or so. So, 22 years of Objective-C and 10 of Swift.
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.
I have really tried to like Swift, and with new projects I do tend to use it, but legacy projects in Objective-C still make me smile that I get to go back to the old familiar language. I also like its interoperability with C++ through Objective-C++.
The parts of Ardour (ardour.org) that have to interface with several Core* libraries are all written in Objective C(++) and will continue to be so until they can't be. That's not much code, but it's important code. Pretty much all UI stuff - the internal/lower-level stuff uses Apple libs that have C APIs.
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.
I work on an app that's over a decade old, and there's a fair mix of Objective C and Swift.
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
clear separation of declaration and implementation files
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'm comfortable in C, C++, ObjC, and Swift. I like Swift, but I'm not going to contort myself to use it exclusively.
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.
I started a large solo project in late 2019 using Swift. I have no trouble compiling and linking the project today. I have been adding Swift code to an old Objective-C project without issues. There was an open source objc project I tried to modify recently, and was told that a feature was so deprecated that using it was no longer an option, forcing me to consider rewriting a large swatch of objc code; it just got so convoluted that I bailed.
Early Swift adapters got the arrows in the back. I was not an early adapter.
I use Objective C. And I'm a Web Developer, but I learned it years ago and still use it because Cordova uses it.
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".
For a few very specific use-cases (specifically those involving the objective-c runtime usually), I still use objective-c. Otherwise I’ve moved on to Swift fully and I’m very happy with it. I also use Swift on the server BTW.
I'm enjoying Swift, particularly the async/await APIs. I think it would be difficult to write asynchronous code in Objective-C (well, there would be a lot of completion handlers). My present case is the control plane for an embedded application and I don't really have too many complaints. I like the package management system. It would be nice if the compiler was faster.
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).
As objective-c is a true superset of C, it is a much more effective and ergonomic system language -- interfacing with mach, Posix and Carbon APIs -- than Swift in my experienced opinion.
I agree. I wish the Free Software crowd had adopted it - they sorta did with GNUstep - but unfortunately it doesn't receive the attention it deserves. Anecdotally I've noticed many C and C++ GUI frameworks, like Gtk and Qt, reinvent the dynamism of Objective-C in some way or another (signals/slots, property bindings, etc). The whole GObject system could have been a GNUstep alternative.
Sure, still lots of legacy code in my case. I've never really moved to Swift and instead started writing in C# to be able to create cross-platform projects as a solo developer.
I'm learning Objective-C because I want to figure out how Cocoa and macOS work.
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.
I used Obj-C professionally for about 2 years and Swift professionally for about 2 years. I have a slight preference for Swift. I've been doing mobile dev on iOS and Android since 2012 and there have been a lot of language changes and programming paradigm shifts. I think it's become more accessible for new devs. For me, I don't think the time and headache to learn the new ways really had a lot of benefit on the end product. Maybe in larger software shops it did.
Whether you're starting a new app as an individual or a 5-or-15-or-100-or-1000 person team, I don't see why anyone would *not* choose Swift in 2024, unless they are doing game or 3d/VR/AR graphics development, in which case you would augment with C++ probably.
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.
Yes. I maintain some open source Mac apps in my spare time (and even develop new ones from time to time) using Objective-C. I've known and used this programming language for 20 years, and don't really see the point of investing in Swift given the way the Apple ecosystem has developed.
I've been fortunate (or not fortunate based on certain views here) to be working on a fully Swift app for the past 5 years or so. The upgrades have been painful but we've had a team helping for that process. But I don't see a good reason to write Obj-C unless I work at Apple or a huge legacy codebase anymore.
I don't develop for Apple anymore, but tried swift ecosystem once, wasn't impressed. ObjC does its job, and I'm from the camp named "if it does the job and has no obvious limitations, there's no reason to switch". It's a mature language that works, and I know both C and ObjC, and the whole system is native to these two. What else would I need? I think I could answer this question, but the answer isn't Swift. If I'll have to do Apple again, I'll start with ObjC, unless it becomes completely abandoned at the time.
There isn’t a ton of work being done in ObjC anymore. I’ve interviewed quite a few junior iOS developer candidates that didn’t even know it. There are some holdouts, of course.
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.
We're still using a lot of Objective-C, given than more than half of the codebase of our app is 10+ years old. We're trying to transition to Swift, but it's been slow thus far.
My codebase contains a lot of Objective-C but I'm slowly replacing it with Swift. I rarely write Objective-C (largely because it's so easy to introduce bugs with release/retain shenanigans) unless I really have to. Interoperability between the languages does work but is fragile, with Xcode often getting into a chicken-and-egg state where a compilation error in Swift prevents the Objective-C from compiling, and vice versa, stuffing the interface with errors that can make it hard to discover where the problem is.
I do my hobby projects in Objective C (and C++). It still does everything I need it to. Have not had a job programming iOS or macOS projects for a long time, so not sure what I'd use there. Maybe the industry has moved on from me. My impression of Swift is that it's fine but doesn't offer much that is worth the effort of learning and mastering it to the point of proficiency. If Apple suddenly deprecated/removed it, I'd probably just stop programming for their ecosystem.
Yes, because it's easier to mix Objective-C with C and C++ code. Personally I'd lean towards Objective-C regardless because it's a simple and stable language.
I’ve been toying with a few utilities I want to turn into apps, and came across https://github.com/mogenson/lua-macos-app the other day. It binds LuaJIT directly to Objective-C.
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.
Not only objective-c but lots of c++ (useful for cross platform libraries that run on targets besides ios/macos) and that road leads to objective-c++. But at least at Meta many iOS projects use swift now too.
I don't, but know many that do. I'll bet almost all AAA apps are still ObjC, and I know that Apple still uses it, in-house, for a lot of their stuff.
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).
SwiftUI definitely needs more time in the oven, but I’ve found it ok for bite-sized bits of UI where with UIKit boilerplate is as large or larger than the UI code and for screens that aren’t doing anything too interesting (e.g. a typical Settings.app style settings screen).
For now though, the bulk of my UIs will continue to be built with code-only (no storyboards/XIBs) UIKit.
In this case, it was the way that maps are being handled. My stuff tends to be heavily location-dependent, and I go to great lengths, to make my map UI extremely usable.
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.
Beyond reading old code samples, knowing obj-c provides diminishing returns these days.
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.
Over the past couple of weeks I wrote a macos/ios app with objc and c. It's like a 2d game with most code in C which is also used on Linux. Draws the whole view with MTKView and uses udp with bsd sockets.
I mainly chose it for the c interoperability and I don't have any interest in swift.
I learned Objective-C and Cocoa in the days of manual reference counting. I use Swift for new personal projects, I don’t plan to rewrite the old ones in Swift for no reason, but I may add new features in Swift even if not strictly necessary.
Still there for me. Kept meaning to spend the boot up time to migrate to Swift but have always been more keen to just get going. Now finally feeling a bit “forced” as I want to tap into Swift only things like widgets and live activities.
The big question today is could someone new to Mac/iOS get started with Obj-C with all of the modern kit and documentation (seemingly, not having done an extensive audit) to be Swift based.
I haven't seen a project started in it in a long time but there's still quite a bit of code floating around. I get the impression it's still used pretty heavily at Apple too.
I still use objc for all of my apps which are half hobby/business. I don’t have enough time to read the api updates and rewrite my apps every year after a swift language update.
I've been writing Objective-C recently to use macOS frameworks from Rust. I can just write C wrapper functions and compile as a static library. Otherwise I use Swift.
There is a very common thread here- the objc users are happy where they're at, the Swift fans don't understand and want to tell them why their opinion is wrong.
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.
Oh Objective-C, such a weird language. If you know how to use it you are a wizard on the Mac. I think its days are numbered however, no one is extending it and Swift is coming to take over.
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.