5 ms·

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

by lapcat 3y ago

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 3y ago
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 3y ago
  I'll cross that bridge when I come to it.
  - troupo 3y ago
    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 3y ago
    *bridging headers
Ragnarork 3y ago
> 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?
- lapcat 3y ago
  Sockets come to mind.
- tarentel 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
      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.
dinkblam 3y ago
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 3y ago
  What makes it a systems language and not an app-development language?
  - deleted 3y ago
    [deleted]
  - Suppafly 3y ago
    different buzzwords
- askafriend 3y ago
  What's an example of an app development language?
- Reason077 3y ago
  > “Swift is … not an app-development language.” 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?
- Grustaf 3y ago
  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.
flippy_flops 3y ago
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 3y ago
  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 3y ago
    > 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 3y ago
    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!
- Grustaf 3y ago
  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.
sandofsky 3y ago
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 3y ago
  > 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 3y ago
    > 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?
bkdbkd 3y ago
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.
- wahnfrieden 3y ago
  Foundation is now open source at least
- Tagbert 3y ago
  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.
  - ryanar 3y ago
    Go wasn’t that way, in some respects it is a language design choice whether you want to retain compatibility
Grustaf 3y ago
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.
- lapcat 3y ago
  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.
  - Grustaf 3y ago
    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.
    - lapcat 3y ago
      I already know exactly what the issue is. I don't need your condescension.

by lapcat 3y ago

wahnfrieden 3y ago

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 3y ago
I'll cross that bridge when I come to it.
- troupo 3y ago
  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 3y ago
  *bridging headers

Ragnarork 3y ago

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

lapcat 3y ago
Sockets come to mind.
tarentel 3y ago
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 3y ago
  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 3y ago
    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 3y ago
    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.

dinkblam 3y ago

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 3y ago
What makes it a systems language and not an app-development language?
- deleted 3y ago
  [deleted]
- Suppafly 3y ago
  different buzzwords
askafriend 3y ago
What's an example of an app development language?
Reason077 3y ago
> “Swift is … not an app-development language.” 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?
Grustaf 3y ago
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.

flippy_flops 3y ago

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 3y ago
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 3y ago
  > 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 3y ago
  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!
Grustaf 3y ago
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.

sandofsky 3y ago

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 3y ago
> 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 3y ago
  > 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?

bkdbkd 3y ago

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.

wahnfrieden 3y ago
Foundation is now open source at least
Tagbert 3y ago
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.
- ryanar 3y ago
  Go wasn’t that way, in some respects it is a language design choice whether you want to retain compatibility

Grustaf 3y ago

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.

lapcat 3y ago
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.
- Grustaf 3y ago
  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.
  - lapcat 3y ago
    I already know exactly what the issue is. I don't need your condescension.