I use Objective-C exclusively (no Swift) in my App Store apps.<p>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.<p>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.<p>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.<p>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.
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.<p>It's important to note that there's still tons of Objective-C written inside Apple to this day, perhaps more than Swift.<p>What Apple pushes as what you <i>should</i> be using is often not what they are using internally, FWIW. Third-party developers are its true beta testers.
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.<p>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.<p>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.<p>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.<p>While this was useful for expanding my horizons somewhat, I have never in my career had to use ObjC in production.<p>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.<p>The blog post is here - <a href="https://jacobbartlett.substack.com/p/through-the-ages-apple-animation" rel="nofollow">https://jacobbartlett.substack.com/p/through-the-ages-apple-...</a>
The GitHub project is here (all open source!) - <a href="https://github.com/jacobsapps/animation-through-the-ages">https://github.com/jacobsapps/animation-through-the-ages</a>
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.<p>Method swizzling is also an important tool for any aspiring macOS developer, unavailable/onerously painful in Swift.<p>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'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.
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 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.<p>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.<p>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.
I do, but not often.<p>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).<p>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.<p>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.
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p><a href="https://developer.apple.com/forums/thread/738042" rel="nofollow">https://developer.apple.com/forums/thread/738042</a><p>(this appears to be fixed as of 14.3)
I work on an app that's over a decade old, and there's a fair mix of Objective C and Swift.<p>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.<p>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.<p>Some things that I really like about Obj C more than Swift:<p>easier to explicitly manage memory<p>clear separation of declaration and implementation files<p>faster to compile<p>easier to interop with C<p>Resources: Obj C is old, and there's a ton of info out there on how to solve your specific problem
I'm comfortable in C, C++, ObjC, and Swift. I like Swift, but I'm not going to contort myself to use it exclusively.<p>I have some stuff that has zero Swift and likely never will. Most other things are a mix.<p>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.<p>Early Swift adapters got the arrows in the back. I was not an early adapter.
My company still has some legacy Objective-C code, but most stuff is in Swift (plus SwiftUI) now.<p>Objective-C gets a bad wrap (unfairly, IMO), but it's a neat language, and compilation is <i>so</i> much faster than Swift.
I use Objective C. And I'm a Web Developer, but I learned it years ago and still use it because Cordova uses it.<p>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.<p>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.
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.<p>Nobody makes Cocoa (AppKit) learning resources anymore, especially not in modern Swift, but Objective-C ones still work to this day.<p>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 <i>why</i> 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.<p>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.<p>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.<p>Now that the ABI stabilized, even binary library authors are getting in on it.<p>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.<p>(edit: typo)
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 <a href="https://github.com/mogenson/lua-macos-app">https://github.com/mogenson/lua-macos-app</a> the other day. It binds LuaJIT directly to Objective-C.<p>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.
Still have some in work projects, as they're old, but gradually moving on to Swift whatever we can.<p>Though in the FAANG world - Objective C reigns supreme
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.<p>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.<p>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).
Beyond reading old code samples, knowing obj-c provides diminishing returns these days.<p>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.<p>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.<p>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.
Still using it when updating my apps written pre swift but 100% Swift now (not SwiftUI though) <a href="https://www.appblit.com/" rel="nofollow">https://www.appblit.com/</a>
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.
I use Obj-C++ so I can mix the two languages ad-hoc. I’ve done it this way since the days of NeXTStep.<p>This allows me to use existing code bases and SDKs, such as the AWS one.
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.<p>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.<p>ObjC is a fantastic language, Swift is fine too but the compiler is slow and breaking changes to the language are painful.<p>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.<p>Also, I hate it.