Now Reading
Ask HN: What number of of you Apple builders nonetheless use Goal C?

Ask HN: What number of of you Apple builders nonetheless use Goal C?

2024-02-20 09:18:50

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 bug renaming with Swift 3, so the language migrations haven’t been a big deal. The compiler is slower, but I can still do a clean build in under a minute.

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/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. Anyway, I could on for a while about my positive experiences.

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.

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.

absolutely the same here.

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.

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.

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.

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

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.

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 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.

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.

https://developer.apple.com/forums/thread/738042

(this seems to be mounted as of 14.3)

I do, but not often.

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.

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 old 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.

> There probably isn’t any reason to start a new app or library with anything other than Swift.

Unless you do anything for MacOS and care about MacOS. Most Swift UI apps I’ve seen feel foreign on MacOS in innumerable ways.

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 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.

The blog post is here – https://jacobbartlett.substack.com/p/through-the-ages-apple-…
The GitHub challenge is right here (all open supply!) – https://github.com/jacobsapps/animation-through-the-ages

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.

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.

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.

See Also

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.

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.

(edit: typo)

My company still has some legacy Objective-C code, but most stuff is in Swift (plus SwiftUI) now.

Objective-C gets a bad wrap (unfairly, IMO), but it’s a neat language, and compilation is so much faster than Swift.

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++.

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.

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.

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.

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 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.

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.

Still have some in work projects, as they’re old, but gradually moving on to Swift whatever we can.

Though in the FAANG world – Objective C reigns supreme

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 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.

I just modified some Obj-C code 2 days ago. Part of a RubyMotion app I migrated to Swift. The core was written in Obj-C for performance reasons.

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.

Yes very much so. I maintain an established Mac app and it’s almost entirely Objective-C (and the bits that aren’t are in C and JavaScript)

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”.

Source Link

What's Your Reaction?
Excited
0
Happy
0
In Love
0
Not Sure
0
Silly
0
View Comments (0)

Leave a Reply

Your email address will not be published.

2022 Blinking Robots.
WordPress by Doejo

Scroll To Top