15 ms·

Apple’s Use of Swift in iOS 13

174 points by Timac 7y ago

melling 7y ago
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.
steveklabnik 7y ago
The site is infinitely redirecting for me; https://web.archive.org/web/20190926183124/https://blog.timac.org/2019/0926-state-of-swift-ios13/ https://web.archive.org/web/20190926183124/https://blog.tima... is the archive.org version.
- Timac 7y ago
  Are you visiting this page https://blog.timac.org/2019/0926-state-of-swift-ios13/ https://blog.timac.org/2019/0926-state-of-swift-ios13/ ? Which browser are you using? The site has been tested on a couple of platforms and different browsers. I can't reproduce such a redirecting problem.
  - steveklabnik 7y ago
    Yep, same page. Chrome 76.0.3809.132 (Official Build) (64-bit) (cohort: Stable), Windows 10. That said, I guess I needed to update Chrome, so I just did to 77.0.3865.90 (Official Build) (64-bit) (cohort: Stable) , and same error. Here's a "copy as cURL" for the request, maybe that can help? curl 'https://blog.timac.org/2019/0926-state-of-swift-ios13/' https://blog.timac.org/2019/0926-state-of-swift-ios13/' -H 'authority: blog.timac.org' -H 'cache-control: max-age=0' -H 'upgrade-insecure-requests: 1' -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36' -H 'sec-fetch-mode: navigate' -H 'sec-fetch-user: ?1' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3' -H 'sec-fetch-site: cross-site' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9' --compressed
aloer 7y ago
Anyone here using Swift on the server? Perhaps something in production even?
- Redoubts 7y ago
  Yes, but it can be a pain, and I wish more people were part of the ecosystem.
  - chrstphrhrt 7y ago
    Very interested in this. Would like to try it out for an AI framework that combines knowledge graphs with word embeddings and expert systems, and although the Python ecosystem is the de facto standard (despite lack of safety and performance), and Rust seems theoretically the best, Swift seems to check all the boxes in terms of safety and expressiveness for me. Swift even has a relatively huge community, but it's so focussed on iOS stuff. I know Chris Lattner did something with TensorFlow though. Is anyone into this?
    - guessless 7y ago
      IIRC, Chris is leading the Swift for Tensorflow team at Google. I run a startup that utilizes CoreML pretty heavily in mobile apps, and I'm eager to eventually build out a web app with the backend entirely in Swift. Being able to do everything in one language is really enticing.
- ctas 7y ago
  I do, without good reason. I never programmed for iOS. I learned it for fun and now it's my favorite language. I use IBM Kitura for server-side development because of it's well designed API. The ecosystem is indeed the greatest downside. A lot of the existing libraries are also polluted with UIKit code making them unusable on Linux. Just recently wanted to use an existing API client of some social network, but couldn't, because it contained UIKit code. Forking it and fleshing out the parts needed feels kinda wrong.
- prewett 7y ago
  I was thinking about it, however I've found that String performance is horrible (at least with Japanese strings) if you do anything like hasSuffix() or hasPrefix(). I think the problem is that String converts to unicode code points as soon as it seems useful, instead of keeping everything in UTF-8 (or whatever, really) and doing memcmp for hasSuffix() and hasPrefix() specifically, which would work much faster. Using NSString everywhere is faster, but then string concatenation involves a bunch of casting. I'm not much of a server guy, so I might be wrong here, but dealing with strings seems like something a server is likely to need to deal with. Although, maybe the strings are short enough that it's not much of a problem, or maybe strings that are almost always ASCII are fast. Anyway, something to keep in mind.
ehsankia 7y ago
I wish they showed percentages, or the total number of binaries. It doesn't really tell me much that 141 binary use Swift. I want to know what proportion of iOS uses swift.
- saagarjha 7y ago
  From a very rough check, there are on the order of a couple thousand binaries in iOS.
losvedir 7y ago
On paper, Swift is my perfect language. It's like a slightly higher level rust. For a while I was enamored of Haskell and its famed "if it compiles it works" saying, but I think I've realized that the features that contribute to that are: non-nullability and algebraic data types. Turns out I don't particularly like the extreme functional nature or (especially) the lazy aspect of it. Rust is almost there, but then I'm dealing with lifetimes and working a little lower than I usually need. But I found I _love_ its exhaustiveness checking for enum variants. The ML family is pretty much in my sweet spot, for some reason it doesn't really get the love that it seems it deserves, and last I heard Ocaml had an issue with being single threaded. So that leaves Swift, with its non-nullability, algebraic data types, and exhaustive enum pattern matching. The only downside is its focus on Macs! I'm holding my breath, waiting for it to run just as smoothly on linux, and developing some developer cultural cachet and libraries for servers. I hope it does! I'm glad to see in this article that it's being used more and more at Apple. And with SwiftUI, which looks pretty promising, I have to imagine it will only continue to grow in popularity.
- novok 7y ago
  The funny thing is, those are not expensive or difficult things to implement in a compiler.
- mruts 7y ago
  How about Scala?
  - rad_gruchalski 7y ago
    It’s a really nice language. I like it a lot. But it has a dependency on a pretty hefty runtime. I understand that packaging nowadays is not really a problem, but still.
    - mruts 7y ago
      You should check out GraalVM. Easy compilation to native code. A total game changer for the JVM, imo.
pier25 7y ago
Do you think Objective C will be phased out some day? (As in not usable for development in the Apple ecosystem)
- bsaul 7y ago
  Objective c probably will be phased out before C will. Objective-C libraries are themselves a wrapper over optimized C, which is what constitutes most of ios core. I don’t think swift will phase out C until a very long time. It still needs to sort its performance issues related to memory automatic reference counting and global lock. Which requires something close to rust borrow checker, but with an even more advanced technology to keep the syntax beginner friendly.
ww520 7y ago
I've waded into Swift recently. It's a surprisingly easy language to pick up, with really nice modern language features. I really hope more platforms support it.
viburnum 7y ago
Is this why the Podcast app has become so buggy?
- saagarjha 7y ago
  Podcasts still appears to be mostly Objective-C.
matchbok 7y ago
Happy to see, it's a wonderfully designed language that's a joy to write. Super powerful enums, pattern matching, etc.
apple_acc 7y ago
The reason why Swift isn't being used more is that the Build and Integration team at Apple forbids the use of Swift for any project that has downstream dependencies. This is because Swift doesn't support sending out its symbols, meaning any Swift project has to be fully built and compiled before beginning compilation of any of its dependencies. They're getting a little more lax on it now but we've wanted to use Swift for years and are totally unable.
- saagarjha 7y ago
  Do the new XCFramework/module stability improvements help here?
lenkite 7y ago
Will start using Swift once they add C++ interop. Right now mixing Objective-C and C++ is easy. This is not the case for Swift.

174 points by Timac 7y ago

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.

steveklabnik 7y ago

The site is infinitely redirecting for me; https://web.archive.org/web/20190926183124/https://blog.timac.org/2019/0926-state-of-swift-ios13/ https://web.archive.org/web/20190926183124/https://blog.tima... is the archive.org version.

Timac 7y ago
Are you visiting this page https://blog.timac.org/2019/0926-state-of-swift-ios13/ https://blog.timac.org/2019/0926-state-of-swift-ios13/ ? Which browser are you using? The site has been tested on a couple of platforms and different browsers. I can't reproduce such a redirecting problem.
- steveklabnik 7y ago
  Yep, same page. Chrome 76.0.3809.132 (Official Build) (64-bit) (cohort: Stable), Windows 10. That said, I guess I needed to update Chrome, so I just did to 77.0.3865.90 (Official Build) (64-bit) (cohort: Stable) , and same error. Here's a "copy as cURL" for the request, maybe that can help? curl 'https://blog.timac.org/2019/0926-state-of-swift-ios13/' https://blog.timac.org/2019/0926-state-of-swift-ios13/' -H 'authority: blog.timac.org' -H 'cache-control: max-age=0' -H 'upgrade-insecure-requests: 1' -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36' -H 'sec-fetch-mode: navigate' -H 'sec-fetch-user: ?1' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3' -H 'sec-fetch-site: cross-site' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9' --compressed

aloer 7y ago

Anyone here using Swift on the server? Perhaps something in production even?

Redoubts 7y ago
Yes, but it can be a pain, and I wish more people were part of the ecosystem.
- chrstphrhrt 7y ago
  Very interested in this. Would like to try it out for an AI framework that combines knowledge graphs with word embeddings and expert systems, and although the Python ecosystem is the de facto standard (despite lack of safety and performance), and Rust seems theoretically the best, Swift seems to check all the boxes in terms of safety and expressiveness for me. Swift even has a relatively huge community, but it's so focussed on iOS stuff. I know Chris Lattner did something with TensorFlow though. Is anyone into this?
  - guessless 7y ago
    IIRC, Chris is leading the Swift for Tensorflow team at Google. I run a startup that utilizes CoreML pretty heavily in mobile apps, and I'm eager to eventually build out a web app with the backend entirely in Swift. Being able to do everything in one language is really enticing.
ctas 7y ago
I do, without good reason. I never programmed for iOS. I learned it for fun and now it's my favorite language. I use IBM Kitura for server-side development because of it's well designed API. The ecosystem is indeed the greatest downside. A lot of the existing libraries are also polluted with UIKit code making them unusable on Linux. Just recently wanted to use an existing API client of some social network, but couldn't, because it contained UIKit code. Forking it and fleshing out the parts needed feels kinda wrong.
prewett 7y ago
I was thinking about it, however I've found that String performance is horrible (at least with Japanese strings) if you do anything like hasSuffix() or hasPrefix(). I think the problem is that String converts to unicode code points as soon as it seems useful, instead of keeping everything in UTF-8 (or whatever, really) and doing memcmp for hasSuffix() and hasPrefix() specifically, which would work much faster. Using NSString everywhere is faster, but then string concatenation involves a bunch of casting. I'm not much of a server guy, so I might be wrong here, but dealing with strings seems like something a server is likely to need to deal with. Although, maybe the strings are short enough that it's not much of a problem, or maybe strings that are almost always ASCII are fast. Anyway, something to keep in mind.

ehsankia 7y ago

I wish they showed percentages, or the total number of binaries. It doesn't really tell me much that 141 binary use Swift. I want to know what proportion of iOS uses swift.

saagarjha 7y ago
From a very rough check, there are on the order of a couple thousand binaries in iOS.

losvedir 7y ago

On paper, Swift is my perfect language. It's like a slightly higher level rust. For a while I was enamored of Haskell and its famed "if it compiles it works" saying, but I think I've realized that the features that contribute to that are: non-nullability and algebraic data types. Turns out I don't particularly like the extreme functional nature or (especially) the lazy aspect of it. Rust is almost there, but then I'm dealing with lifetimes and working a little lower than I usually need. But I found I _love_ its exhaustiveness checking for enum variants. The ML family is pretty much in my sweet spot, for some reason it doesn't really get the love that it seems it deserves, and last I heard Ocaml had an issue with being single threaded. So that leaves Swift, with its non-nullability, algebraic data types, and exhaustive enum pattern matching. The only downside is its focus on Macs! I'm holding my breath, waiting for it to run just as smoothly on linux, and developing some developer cultural cachet and libraries for servers. I hope it does! I'm glad to see in this article that it's being used more and more at Apple. And with SwiftUI, which looks pretty promising, I have to imagine it will only continue to grow in popularity.

novok 7y ago
The funny thing is, those are not expensive or difficult things to implement in a compiler.
mruts 7y ago
How about Scala?
- rad_gruchalski 7y ago
  It’s a really nice language. I like it a lot. But it has a dependency on a pretty hefty runtime. I understand that packaging nowadays is not really a problem, but still.
  - mruts 7y ago
    You should check out GraalVM. Easy compilation to native code. A total game changer for the JVM, imo.

pier25 7y ago

Do you think Objective C will be phased out some day? (As in not usable for development in the Apple ecosystem)

bsaul 7y ago
Objective c probably will be phased out before C will. Objective-C libraries are themselves a wrapper over optimized C, which is what constitutes most of ios core. I don’t think swift will phase out C until a very long time. It still needs to sort its performance issues related to memory automatic reference counting and global lock. Which requires something close to rust borrow checker, but with an even more advanced technology to keep the syntax beginner friendly.

ww520 7y ago

I've waded into Swift recently. It's a surprisingly easy language to pick up, with really nice modern language features. I really hope more platforms support it.

viburnum 7y ago

Is this why the Podcast app has become so buggy?

saagarjha 7y ago
Podcasts still appears to be mostly Objective-C.

matchbok 7y ago

Happy to see, it's a wonderfully designed language that's a joy to write. Super powerful enums, pattern matching, etc.

apple_acc 7y ago

The reason why Swift isn't being used more is that the Build and Integration team at Apple forbids the use of Swift for any project that has downstream dependencies. This is because Swift doesn't support sending out its symbols, meaning any Swift project has to be fully built and compiled before beginning compilation of any of its dependencies. They're getting a little more lax on it now but we've wanted to use Swift for years and are totally unable.

saagarjha 7y ago
Do the new XCFramework/module stability improvements help here?

lenkite 7y ago

Will start using Swift once they add C++ interop. Right now mixing Objective-C and C++ is easy. This is not the case for Swift.