[HN Gopher] Ask HN: How many of you Apple developers still use O...
___________________________________________________________________
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?
Author : TylerJaacks
Score : 125 points
Date : 2024-02-20 15:18 UTC (7 hours ago)
| jakey_bakey wrote:
| 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 project is here (all open source!) -
| https://github.com/jacobsapps/animation-through-the-ages
| EGreg wrote:
| 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".
| steviedotboston wrote:
| do you use WebObjects at all?
| eddieh wrote:
| Later versions of WebObjects used Java.
| cturner wrote:
| Does anyone have an ISO image of WO 4.5? Apple are giving
| away WO 5 (java only) via a dmg on their website, so I
| doubt they would mind.
| mattl wrote:
| I think it's on the Rhapsody install media which is
| floating around.
| steviedotboston wrote:
| >Apple are giving away WO 5 (java only)
|
| I tried to download that but the file was damaged
| akmarinov wrote:
| 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
| dkasper wrote:
| 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.
| legendofbrando wrote:
| 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.
| tiltowait wrote:
| 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.
| sandofsky wrote:
| 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.
| jakespracher wrote:
| In the literal sense of your question the majority employed by
| Apple still do due to the mountain that would need to be
| rewritten
| ldenoue wrote:
| Still using it when updating my apps written pre swift but 100%
| Swift now (not SwiftUI though) https://www.appblit.com/
| Reason077 wrote:
| SwiftUI is so awful. The poor performance and general
| clunkiness of the macOS "System Settings" app should be a
| warning against using it to anyone.
| ironlake wrote:
| 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.
| Reason077 wrote:
| 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.
| troupo wrote:
| > 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.
| ironlake wrote:
| Thanks for that perspective. I haven't done any MacOS
| development.
| troupo wrote:
| 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.
| sumuyuda wrote:
| You can use AppKit in Swift just like you can use UIKit on
| iOS. There is no requirement to use SwiftUI when creating a
| macOS swift app.
| hboon wrote:
| 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.
| zydeco wrote:
| 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.
| skrrtww wrote:
| 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.
| jdmoreira wrote:
| > 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!)
| ryandrake wrote:
| 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.
| lapcat wrote:
| 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.
| wahnfrieden wrote:
| 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
| lapcat wrote:
| I'll cross that bridge when I come to it.
| troupo wrote:
| In these cases I like to use the malaphor _we 'll burn this
| bridge when we get to it_ :) Because that's how these
| changes feel like.
| Doctor_Fegg wrote:
| *bridging headers
| Ragnarork wrote:
| > C interoperablity, while it exists in Swift, can be very
| painful
|
| Interesting, that hasn't been my experience. I'm curious, what
| have you ran into that was painful?
| tarentel wrote:
| 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.
| FanaHOVA wrote:
| 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.
| tarentel wrote:
| 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.
| jdewerd wrote:
| 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.
| lapcat wrote:
| Sockets come to mind.
| dadoum wrote:
| 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.
| dinkblam wrote:
| 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.
| sandofsky wrote:
| What makes it a systems language and not an app-development
| language?
| Suppafly wrote:
| different buzzwords
| askafriend wrote:
| What's an example of an app development language?
| flippy_flops wrote:
| 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.
| sandofsky wrote:
| 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.
| dehrmann wrote:
| > Apple is comfortable launching beta APIs that can undergo
| massive churn
|
| You see this as a consumer, too. Apple very much moves on
| from old hardware compared to Microsoft.
| mavamaarten wrote:
| 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!
| sandofsky wrote:
| 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.
| lapcat wrote:
| > 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. ;-)
| sandofsky wrote:
| > I didn't say I enjoyed ObjC. That's not really how I
| choose my tools. It's a job. The choice is utilitarian.
|
| Given C is faster and more mature than ObjC, why aren't you
| writing everything in pure C and objc_msgSend?
| lapcat wrote:
| > 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?
| sandofsky wrote:
| 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?
| lapcat wrote:
| > 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?
| bkdbkd wrote:
| 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.
| nicky0 wrote:
| 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)
| sackfield wrote:
| 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++.
| jamil7 wrote:
| Compilation speed for an Objective-C project is certainly a
| pleasant surprise after Swift and Rust.
| frizlab wrote:
| 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.
| zerr wrote:
| How is Swift's interop with C++ nowadays? Obj-C's seamless
| interop with C++ was (is?) the key advantage.
| wahnfrieden wrote:
| It's good as of the last year. Has SPM support now
| tcldr wrote:
| 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.
| ksherlock wrote:
| Objective C(++) all the way. I'm sure swift is fine but I'm
| completely uninterested in it.
| jamil7 wrote:
| 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.
| jwells89 wrote:
| 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.
| ChrisMarshallNY wrote:
| 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).
| jwells89 wrote:
| 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.
| ChrisMarshallNY wrote:
| It makes writing trivial apps incredibly easy. It's just when
| I need to stray off the beaten path (most of my projects),
| that I run into issues.
|
| I tend to use storyboards, because of some of the fancy auto-
| layout stuff I do.
| waffletower wrote:
| 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.
| hgs3 wrote:
| 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.
| runjake wrote:
| 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.
| spacemadness wrote:
| 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.
| Apocryphon wrote:
| Message passing is nice. Swift just has function calls like
| any other OOP language.
| runjake wrote:
| It's subjective, but from my viewpoint, the message passing
| and it's relative simplicity and readability, compared to
| Swift.
|
| I can completely see why people would think the opposite,
| though.
| AnonC wrote:
| > 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.
| jakey_bakey wrote:
| In user space perhaps, but the OS is very heavily ObjC (and
| C)
|
| Someone posted a great analysis breaking down how many
| binaries used which language in iOS through the years
| spike021 wrote:
| 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.
| QuercusMax wrote:
| At Google, it's really hard to use GCP for first-party
| products due to all the security lockdowns.
| ooloncoloophid wrote:
| 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)
| Klonoar wrote:
| ...are you maintaining a pre-ARC code base or something? Retain
| and release shouldn't be that big of an issue otherwise.
| tarentel wrote:
| 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.
| thought_alarm wrote:
| 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.
| spieglt wrote:
| 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.
| Klonoar wrote:
| No objc macro? I still use that for cacao and it mostly "just
| works".
| cc101 wrote:
| 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.
| cwoolfe wrote:
| 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.
| incanus77 wrote:
| 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.
| PaulDavisThe1st wrote:
| 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 appears to be fixed as of 14.3)
| egotripper wrote:
| 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.
| asow92 wrote:
| 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
| HaloZero wrote:
| 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.
| OnlyMortal wrote:
| I use Obj-C++ so I can mix the two languages ad-hoc. I've done it
| this way since the days of NeXTStep.
|
| This allows me to use existing code bases and SDKs, such as the
| AWS one.
| hgs3 wrote:
| 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.
| ctroein89 wrote:
| 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.
| ivm wrote:
| 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.
| aetch wrote:
| 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.
| yreg wrote:
| As someone who works with React in his jobby job, I use Swift and
| like SwiftUI. Sometimes I need to use UIKit, but not Objective-C.
| psyclobe wrote:
| 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.
|
| Also, I hate it.
| whartung wrote:
| 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.
| fluffyspork wrote:
| 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.
| raydev wrote:
| 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.
___________________________________________________________________
(page generated 2024-02-20 23:01 UTC)