13 ms·

JetBrains had a recent survey that showed half of all iOS developers were using Swift only. https://www.jetbrains.com/lp/devecosystem-2019/swift-objc/ https://

JetBrains had a recent survey that showed half of all iOS developers were using Swift only. https://www.jetbrains.com/lp/devecosystem-2019/swift-objc/ https://www.jetbrains.com/lp/devecosystem-2019/swift-objc/ How about HN devs?

oflannabhra 7y ago
I spend most of my time in Swift. All new features are developed in Swift. We've slowly been doing a conversion, since about Swift 3, and are about 95% of the way there. We also have several legacy apps that are all ObjC, or 50% ObjC. There's not a ton of new feature development, but still updates. If I had my druthers, I'd be Swift exclusive.
ASalazarMX 7y ago
Objective C is good once its philosophy "clicks" with you, but any new development I would start in on Swift. Swift is a much nicer language, feels like compiled Python. Same with Android, I would choose Kotlin before Java if it was my choice. People still working with Objective C might be like I recently was: maintaining a sizable codebase which, unless Apple breaks something, porting to Swift is not justifiable to management.
- gigatexal 7y ago
  You don’t think the swiftisms they added like trying to get rid of conventional looping constructs is odd?
  - oflannabhra 7y ago
    I don't. I much prefer a chain-able functional approach to multiple mutating loops.
  - mnem 7y ago
    Do you mean the c style for loops? The were removed in favour of iterator style loops (for foo in bar { ... }). Or are there some others I haven't noticed?
    - ShamelessC 7y ago
      It's actually more curious that they didn't have iterator style loops from the beginning. It's a pretty standard feature in newer languages and even plenty of older languages are adding support for it.
      - NobodyNada 7y ago
        Swift had iterator-style loops from the beginning. It also initially supported C-style "for (i = 0; i < j; i++)" loops, but they were removed very early on (because in practice, they're rarely used for anything except iteration, and iterator-style loops are much more readable and less error-prone).
        jmnicolas 7y ago
        I never looked at Swift, but for example how do you wright 10 times "hello world" on the command line if you don't have for loops ? You could do it with a while loop (if it exists in Swift) but I'm at a loss as to why you would remove a for loop from a programming language.
        NobodyNada 7y ago
        Iterator-style loops are much clearer and more concise in almost all cases. In this case you can iterate over a range: for i in 0..<10 { print(i) }
  - ASalazarMX 7y ago
    To be fair, no language is going to be perfect. I don't mind them, but I remember how odd enumerations and mappings felt at first in Python. IMO, overall, the pros of Swift vastly outnumber the cons, when the alternative is Objective C.
  - matthewmacleod 7y ago
    Absolutely not. These are among the best features; in any language that has modern control flow, I rarely if ever use old-fashioned loops.
    - ken 7y ago
      What are "old-fashioned loops"? Does that mean C-style? As an also Lisp programmer, I find Swift's limited (and fixed!) set of control flow constructs downright ancient. They added for-each loops, but that's it. We had more "modern control flow" in the 1980's.
      - kccqzy 7y ago
        Diversity in control flow constructs isn't necessarily a good thing. In imperative languages you see goto being discouraged and removed. In functional languages you see things like call-with-current-continuation discouraged.
        ken 7y ago
        It is to me. The alternative is implementing them ad-hoc in every function. (Or perhaps waiting another few decades for Swift to add them to its compiler.) Having used many languages at different points on the power spectrum, I remain unconvinced that there's any advantage to omitting abstraction capabilities and forcing programmers to deal with it. Besides, both of those examples are essentially non-local jumps, and I'm not sure I'd describe them as "modern". In a sense, Swift already allows diversity in control flow constructs, via closures and the trailing closure syntax. It's just somewhat awkward, and not flexible enough to implement, say, most of Lisp's ITERATE library. That's packed full of exactly the kinds of control flow constructs that I have to write out by hand in Swift every day.
  - favorited 7y ago
    There's nothing unconventional about for/in loops on Apple's platforms. Even in Objective-C, NSFastEnumeration has been the recommended default loop mechanism for a decade+ now.
  - gameswithgo 7y ago
    Thats kind of the thing to do in C# as well, and Java Streams, and in Rust the fastest way to do loops is not to do them but use iterators.
  - AJRF 7y ago
    You can always pass in an iterator tracker via the following, much cleaner!; for (value, index) in arr.enumerated() { // Loop body }
regera 7y ago
Pure Swift for the new apps. We freak out when we see @ObjC or NSObject usage in our codebase. On a long enough timescale when Apple converts away from using Objective-C under the covers, our code will not need any modification.
- saagarjha 7y ago
  > We freak out when we see @ObjC or NSObject usage in our codebase. …how are you interacting with UIKit?!
  - favorited 7y ago
    You rarely have to add @objc annotations or use NSObject directly. You only need it for target/action, KVO, etc. I rarely see that annotation or class name in my codebases too.
    - dep_b 7y ago
      UIButton only? Maybe binding UITextField events?
      - favorited 7y ago
        Buttons, selector-based Notifications (though the block version is finally good, so we mostly just use that now), & gesture recognizers look like our biggest users of @objc. Basically all to support target/action. A quick search through one of my apps shows that about 4% of functions are marked as @objc (and we're not using the old compatibility mode where more methods were implicitly @objc either).
        regera 7y ago
        @IBAction can replace @ObjC for all selectors. We put it a mandate in our code reviews. There is also NSObjectProtocol which forces (in most cases) devs to subclass NSObject.
gregkerzhner 7y ago
As a language itself, I love Swift. Optionals, the guard statement, protocols and protocol extensions standout as awesome productive features. However, (at least 1 year ago, I'm on React Native now), the tooling around Swift was still crappy. Expect longer compile times, occasional hair tearing issues, broken autocompletion and a flickering syntax highlighting. Overall though these issues aren't enough to make me want to go back to Objective C.
- jimcsharp 7y ago
  It's a testament to how crappy my code is, but I find myself having to give it type hints too often, and it'll give up on spitting out warnings if the file gets too large. There's a perverse thought. I can bypass warnings-as-errors by making my code bad enough ;)
  - ericlewis 7y ago
    This typically happens at the layers where interop isn’t so good. Like using really old obj-c stuff. It’s worth reporting this to the swift project on github.
    - saagarjha 7y ago
      I'm sure https://bugs.swift.org/ https://bugs.swift.org/ will appreciate it much more.
skohan 7y ago
I started using Swift around 5 years ago, and I have barely written a line of Objective-C since. I like the philosophy of the language a lot, and I use it on other types of projects at well. I'm frustrated by the tooling and the cross-platform story. It's a great language to program in, but it can be painful to work with in terms of project fragility and dependency management.
- cerberusss 7y ago
  Yeah, it looks like the Apple team has trouble keeping up with Linux distribution, and nobody seems to have picked up the slack. By the way, what is painful in terms of project fragility?
vbezhenar 7y ago
For personal projects Objective C (Java for Android). I like them more. For commercial projects, I guess, Swift/Kotlin is the way to go, as it's new hotness.
- billylo 7y ago
  Same here.
ctdonath 7y ago
Pure Swift now. It wasn't viable as v1, but now it's solid & clean. Seems like it was a good opportunity to take a well understood language (C/C++/Obj-C) and after 30 years rebuild it ground-up into what it should be. Some constructs & workarounds just weren't going away without a clean-slate industry-wide fully-compatible restart. Top problem now is getting developers to not force-unwrap optionals unless unless able to prove it won't cause a crash.
- zapzupnz 7y ago
  Even when they can prove it, they shouldn't do it. It's not hard to conditionally unwrap optionals.
- saagarjha 7y ago
  Force unwrapping optionals is quite useful: it's great syntactic sugar for what often just gets rewritten as guard/assertionFailure.
  - ctdonath 7y ago
    That’s fine IF they can prove it won’t crash or that a crash is appropriate (a la forced exit). Too many developers use it as a happy path shortcut, not considering the compiler is warning of possible serious problems. Crashes & exits are not acceptable in production code, and I’ve had to fix too many of them.
    - saagarjha 7y ago
      I strongly disagree. I would rather an application crashed and provided me with an actionable crash report rather than it continuing on in some random state. (This isn't to say that you should ignore errors; it's just that if you don't think there should be an error at a certain location, I would really want to know about it if there is one.)
      - ctdonath 7y ago
        That's why force-unwrap is so bad: the compiler is telling you there's a risk, at a time you can do something sensible about it, and force-unwrap puts solving the problem off to the worst possible scenario. My production user base can't afford "actionable crash reporting" as a debugging tool vs compiler warnings; even 0.01% of users experiencing it would get very expensive.
Klonoar 7y ago
I do some contract work for a company I sold an app to awhile ago, and the codebase is mixed Objective-C/Swift. Anything new I do in Swift, but there's a few rare new view controllers and the like where Objective-C is used because it's just easier/faster to copy/paste infrastructure. Some crypto code is also still Objective-C due to easier linking, but that'll probably change soon enough. I don't consider ObjC to be a bad language in the slightest; in fact, I'll offer the (probably contrarian) opinion that it's one of the greatest languages of the past few decades.
- dlivingston 7y ago
  Can you explain why you like Objective-C? I've never used it, but have seen many code snippets in API documentations, and it just looks so...unnecessarily obfuscated and verbose, and with a syntax so wholly unique to Obj-C that my brain can't make sense of it like I would looking at, say, Java code from a C++ background.
  - Klonoar 7y ago
    All of the following: - As malleable as JavaScript when you need it to be - As typed as your favorite language when you need it to be - Able to drop to much more arcane levels if you need to for certain performance-intensive places, without requiring some crazy setup (e.g, C/C++ are right there if you need them) - ARC is IMO one of the best approaches to memory management out there - The verbosity can be annoying at first, but it forces you to think hard about everything, and when I come back to Objective-C code years later, I've no issue remembering what the hell I was doing there - People complain about brackets, but they just... don't matter. It's a syntax. You either deal with it or don't - you don't see me writing Lisp because I find the syntax annoying, which is fine. - Message passing in ObjC is so optimized that it probably can't get much faster, and anyone acting like it's slow has a potentially skewed understanding of this Swift is nicer for me in only two distinct ways: - No more header files, because man was that annoying - The stricter nil handling is overall better, if not a mental shift from some ObjC counterparts
    - jchb 7y ago
par 7y ago
Been using pure swift for quite some time now. There used to be some libs for which I'd have to make a bridging header, but lately there's fewer of those.
pier25 7y ago
We're using Swift 5 on our iOS and macOS apps.

oflannabhra 7y ago

I spend most of my time in Swift. All new features are developed in Swift. We've slowly been doing a conversion, since about Swift 3, and are about 95% of the way there. We also have several legacy apps that are all ObjC, or 50% ObjC. There's not a ton of new feature development, but still updates. If I had my druthers, I'd be Swift exclusive.

ASalazarMX 7y ago

Objective C is good once its philosophy "clicks" with you, but any new development I would start in on Swift. Swift is a much nicer language, feels like compiled Python. Same with Android, I would choose Kotlin before Java if it was my choice. People still working with Objective C might be like I recently was: maintaining a sizable codebase which, unless Apple breaks something, porting to Swift is not justifiable to management.

gigatexal 7y ago
You don’t think the swiftisms they added like trying to get rid of conventional looping constructs is odd?
- oflannabhra 7y ago
  I don't. I much prefer a chain-able functional approach to multiple mutating loops.
- mnem 7y ago
  Do you mean the c style for loops? The were removed in favour of iterator style loops (for foo in bar { ... }). Or are there some others I haven't noticed?
  - ShamelessC 7y ago
    It's actually more curious that they didn't have iterator style loops from the beginning. It's a pretty standard feature in newer languages and even plenty of older languages are adding support for it.
    - NobodyNada 7y ago
      Swift had iterator-style loops from the beginning. It also initially supported C-style "for (i = 0; i < j; i++)" loops, but they were removed very early on (because in practice, they're rarely used for anything except iteration, and iterator-style loops are much more readable and less error-prone).
      - jmnicolas 7y ago
        I never looked at Swift, but for example how do you wright 10 times "hello world" on the command line if you don't have for loops ? You could do it with a while loop (if it exists in Swift) but I'm at a loss as to why you would remove a for loop from a programming language.
        NobodyNada 7y ago
        Iterator-style loops are much clearer and more concise in almost all cases. In this case you can iterate over a range: for i in 0..<10 { print(i) }
- ASalazarMX 7y ago
  To be fair, no language is going to be perfect. I don't mind them, but I remember how odd enumerations and mappings felt at first in Python. IMO, overall, the pros of Swift vastly outnumber the cons, when the alternative is Objective C.
- matthewmacleod 7y ago
  Absolutely not. These are among the best features; in any language that has modern control flow, I rarely if ever use old-fashioned loops.
  - ken 7y ago
    What are "old-fashioned loops"? Does that mean C-style? As an also Lisp programmer, I find Swift's limited (and fixed!) set of control flow constructs downright ancient. They added for-each loops, but that's it. We had more "modern control flow" in the 1980's.
    - kccqzy 7y ago
      Diversity in control flow constructs isn't necessarily a good thing. In imperative languages you see goto being discouraged and removed. In functional languages you see things like call-with-current-continuation discouraged.
      - ken 7y ago
        It is to me. The alternative is implementing them ad-hoc in every function. (Or perhaps waiting another few decades for Swift to add them to its compiler.) Having used many languages at different points on the power spectrum, I remain unconvinced that there's any advantage to omitting abstraction capabilities and forcing programmers to deal with it. Besides, both of those examples are essentially non-local jumps, and I'm not sure I'd describe them as "modern". In a sense, Swift already allows diversity in control flow constructs, via closures and the trailing closure syntax. It's just somewhat awkward, and not flexible enough to implement, say, most of Lisp's ITERATE library. That's packed full of exactly the kinds of control flow constructs that I have to write out by hand in Swift every day.
- favorited 7y ago
  There's nothing unconventional about for/in loops on Apple's platforms. Even in Objective-C, NSFastEnumeration has been the recommended default loop mechanism for a decade+ now.
- gameswithgo 7y ago
  Thats kind of the thing to do in C# as well, and Java Streams, and in Rust the fastest way to do loops is not to do them but use iterators.
- AJRF 7y ago
  You can always pass in an iterator tracker via the following, much cleaner!; for (value, index) in arr.enumerated() { // Loop body }

regera 7y ago

Pure Swift for the new apps. We freak out when we see @ObjC or NSObject usage in our codebase. On a long enough timescale when Apple converts away from using Objective-C under the covers, our code will not need any modification.

saagarjha 7y ago
> We freak out when we see @ObjC or NSObject usage in our codebase. …how are you interacting with UIKit?!
- favorited 7y ago
  You rarely have to add @objc annotations or use NSObject directly. You only need it for target/action, KVO, etc. I rarely see that annotation or class name in my codebases too.
  - dep_b 7y ago
    UIButton only? Maybe binding UITextField events?
    - favorited 7y ago
      Buttons, selector-based Notifications (though the block version is finally good, so we mostly just use that now), & gesture recognizers look like our biggest users of @objc. Basically all to support target/action. A quick search through one of my apps shows that about 4% of functions are marked as @objc (and we're not using the old compatibility mode where more methods were implicitly @objc either).
      - regera 7y ago
        @IBAction can replace @ObjC for all selectors. We put it a mandate in our code reviews. There is also NSObjectProtocol which forces (in most cases) devs to subclass NSObject.

gregkerzhner 7y ago

As a language itself, I love Swift. Optionals, the guard statement, protocols and protocol extensions standout as awesome productive features. However, (at least 1 year ago, I'm on React Native now), the tooling around Swift was still crappy. Expect longer compile times, occasional hair tearing issues, broken autocompletion and a flickering syntax highlighting. Overall though these issues aren't enough to make me want to go back to Objective C.

jimcsharp 7y ago
It's a testament to how crappy my code is, but I find myself having to give it type hints too often, and it'll give up on spitting out warnings if the file gets too large. There's a perverse thought. I can bypass warnings-as-errors by making my code bad enough ;)
- ericlewis 7y ago
  This typically happens at the layers where interop isn’t so good. Like using really old obj-c stuff. It’s worth reporting this to the swift project on github.
  - saagarjha 7y ago
    I'm sure https://bugs.swift.org/ https://bugs.swift.org/ will appreciate it much more.

skohan 7y ago

I started using Swift around 5 years ago, and I have barely written a line of Objective-C since. I like the philosophy of the language a lot, and I use it on other types of projects at well. I'm frustrated by the tooling and the cross-platform story. It's a great language to program in, but it can be painful to work with in terms of project fragility and dependency management.

cerberusss 7y ago
Yeah, it looks like the Apple team has trouble keeping up with Linux distribution, and nobody seems to have picked up the slack. By the way, what is painful in terms of project fragility?

vbezhenar 7y ago

For personal projects Objective C (Java for Android). I like them more. For commercial projects, I guess, Swift/Kotlin is the way to go, as it's new hotness.

billylo 7y ago
Same here.

ctdonath 7y ago

Pure Swift now. It wasn't viable as v1, but now it's solid & clean. Seems like it was a good opportunity to take a well understood language (C/C++/Obj-C) and after 30 years rebuild it ground-up into what it should be. Some constructs & workarounds just weren't going away without a clean-slate industry-wide fully-compatible restart. Top problem now is getting developers to not force-unwrap optionals unless unless able to prove it won't cause a crash.

zapzupnz 7y ago
Even when they can prove it, they shouldn't do it. It's not hard to conditionally unwrap optionals.
saagarjha 7y ago
Force unwrapping optionals is quite useful: it's great syntactic sugar for what often just gets rewritten as guard/assertionFailure.
- ctdonath 7y ago
  That’s fine IF they can prove it won’t crash or that a crash is appropriate (a la forced exit). Too many developers use it as a happy path shortcut, not considering the compiler is warning of possible serious problems. Crashes & exits are not acceptable in production code, and I’ve had to fix too many of them.
  - saagarjha 7y ago
    I strongly disagree. I would rather an application crashed and provided me with an actionable crash report rather than it continuing on in some random state. (This isn't to say that you should ignore errors; it's just that if you don't think there should be an error at a certain location, I would really want to know about it if there is one.)
    - ctdonath 7y ago
      That's why force-unwrap is so bad: the compiler is telling you there's a risk, at a time you can do something sensible about it, and force-unwrap puts solving the problem off to the worst possible scenario. My production user base can't afford "actionable crash reporting" as a debugging tool vs compiler warnings; even 0.01% of users experiencing it would get very expensive.

Klonoar 7y ago

I do some contract work for a company I sold an app to awhile ago, and the codebase is mixed Objective-C/Swift. Anything new I do in Swift, but there's a few rare new view controllers and the like where Objective-C is used because it's just easier/faster to copy/paste infrastructure. Some crypto code is also still Objective-C due to easier linking, but that'll probably change soon enough. I don't consider ObjC to be a bad language in the slightest; in fact, I'll offer the (probably contrarian) opinion that it's one of the greatest languages of the past few decades.

dlivingston 7y ago
Can you explain why you like Objective-C? I've never used it, but have seen many code snippets in API documentations, and it just looks so...unnecessarily obfuscated and verbose, and with a syntax so wholly unique to Obj-C that my brain can't make sense of it like I would looking at, say, Java code from a C++ background.
- Klonoar 7y ago
  All of the following: - As malleable as JavaScript when you need it to be - As typed as your favorite language when you need it to be - Able to drop to much more arcane levels if you need to for certain performance-intensive places, without requiring some crazy setup (e.g, C/C++ are right there if you need them) - ARC is IMO one of the best approaches to memory management out there - The verbosity can be annoying at first, but it forces you to think hard about everything, and when I come back to Objective-C code years later, I've no issue remembering what the hell I was doing there - People complain about brackets, but they just... don't matter. It's a syntax. You either deal with it or don't - you don't see me writing Lisp because I find the syntax annoying, which is fine. - Message passing in ObjC is so optimized that it probably can't get much faster, and anyone acting like it's slow has a potentially skewed understanding of this Swift is nicer for me in only two distinct ways: - No more header files, because man was that annoying - The stricter nil handling is overall better, if not a mental shift from some ObjC counterparts
  - jchb 7y ago

par 7y ago

Been using pure swift for quite some time now. There used to be some libs for which I'd have to make a bridging header, but lately there's fewer of those.

pier25 7y ago

We're using Swift 5 on our iOS and macOS apps.