Back before Swift, the top reason why apps submitted to the App Store got rejected was crashes on launch and during the short period the app would be looked at during review. Most of these crashes were caused by simple programming errors that are easy to make in (Objective-)C: forgotten nil-checks and type mismatch. Turns out many developers never test their apps at all, and never run them on a device (only in the simulator). Not the most obvious way to solve this problem, and certainly not the easiest way, was to introduce a language with a stronger type system that would flag these problems at compile time. If you can choose between (a) trust developers that they learn what they need to learn, write their tests, and ship quality software, or (b) build an infrastructure that categorically makes such errors impossible, a rather large company chose to go with (b). And the top reason for rejections now is App Completeness, basically an app doesn’t do everything the marketing description says it does. A lot of Objective-C developers complain about how they lose flexibility with Swift in hacking something together quickly because they have to satisfy the type system, that the compiler diagnostics aren’t always helpful, and compile times are much longer. These are all valid criticisms and part of the trade-off, but also things that are being addressed and will likely only get better in the future. If you’re interested in a less academic and very practical and business-oriented environment where a transition from dynamic to static typing is taking place right at this moment, Swift and iOS development are an interesting case study to look at. Also interesting: the effects this has on API design for libraries and frameworks — after five years Apple just released the first Swift-only frameworks designed to take advantage of Swift’s unique features. The new Swift APIs are fundamentally different from the old Objective-C ones: favoring composition, value types over reference types, static over dynamic, protocols over inheritance hierarchies, etc. — it’s super interesting to see the design, and the feedback. Of course, not everybody is happy with such change. And it’s a big bet on a (more type-safe) future and nobody knows how it’ll work out…

I still have a hard time buying into the Swift hype train. At a glance it looks 0.3% different than C# or maybe Kotlin or Dart. What am I missing that makes it such a "revolution in languauge design". The one language to rule them all. Etc.. I feel like I asked this before but I guess the answer didn't stick in my brain. It's hard to glance at it, see the hype from Apple devs, and not feel like they were stuck in ObjC land for 15 years and never used anything else. Their hype about Swift seem so out of touch the last 15+ years of non-apple dev. Are there any blog posts with like "I use to love C# but then I touched Swift and it's 1000% better. I can't believe I ever used anything else!" type of posts with some concrete "this is what used to have to do and look now! 75% less code and all these bugs avoided!" I'm sure the new tools make an amazng system but those tools are not impossible for many other languages so what's so special about the language itself?

@gman True, but this doesn’t at all matter for the point that Stefan is making. His anecdote happens to compare Swift to ObjC, and is not necessarily meant as Swift hype but rather as a very interesting anecdote for the static/dynamic discussion in general. As for what differentiates Swift from Kotlin (which again isn’t related to his point) you are right they seem very similar. However IIUC Swift uses ARC while Kotlin uses tracing garbage collection.

Thanks Stefan, I have a sense of the what your saying. But being blunt, studies don't find less bugs programs written in static languages. If haskell was hands down safer then clojure, purely based on types, then shouldn't it have shown? Instead the opposite is found. Many other factors seem to be at play. I think it's perfect possibly to build a language that has the checks you just mentioned and keep it dynamic in that devs aren't responsible for specifying types. If academics and type theory pureist are going to stand on a hill and discard other approaches isn't it responsible and reasonable to demand some form of proof beyond anecdotal stories. I think I would have more patience for these things if the tone of the conversation was more academic in nature. Again, that's my fault, I need to take the time to learn the principles and terminology so I can have a more meaningful conversation. Finally, I'm not interested in what works at the lowest common denominator (people unwilling to test) that's not the future of programming for me. That race to the bottom type argument, more then anything, is what drives me away.

Objective-C: The flexibility of Smalltalk combined with the runtime safety of C!

@yairchu, you're right. My bad. Sorry. I'm sure it's pearls before swine, me being the swine 😅 Plenty of languages have features that stick out and have very clear advantages and use cases. So far I haven't seen what that is with Swift. Everything brought up seems old (but presented as new hence my bad reaction). But maybe Swift is the perfect recipe so like a fine chef makes something special out of the same ingredients others have only made bland meals. I just wish it was easier to see by reading about it. Agree 100% with the general premise that a language can make certain problems less likely and possibly just disappear. Several of the F# articles from https://fsharpforfunandprofit.com/ made me wish I was using a language that helped prevent more issues.

@gman I can't speak to Swift 5 – or whatever it is, haven't been writing for iOS, so haven't kept up – but Swift 1 stuck me as language designed by compiler writers: so the clear advantage was opportunities to optimize.

Wow, I had the opposite impression and in fact AFAIK my impression was confirmed in the FoC podcast interview. Basically you can't get around ARC and so there's a big overhead. In the podcast they mentioned being able to mark code as something like "no allocations happen here so turn off ARC checks" but I don't think any of that has made it in yet?

@gman Which podcast episode are you referring to? Did I miss one that talks about Swift? ARC only applies to reference types and there’s a lot happening with value types, for instance SwiftUI’s declarative views are completely based on value types. Also, there’s an ownership model inspired by Rust in the works, for those who need tighter control over memory semantics.

this one https://atp.fm/205-chris-lattner-interview-transcript sorry not FoC

Oh, I see… yeah, I’m familiar with that one.