Why many developers prefer Swift to Objective-C

Generics, protocols, and optionals come out on top

Paul Hudson    October 11th 2017    @twostraws

Last week I published an article where developers outlined some of the reasons they prefer Objective-C in a world where Swift is increasingly dominant.

It won’t surprise you to learn that the article generated a huge amount of discussion (which is no bad thing!), including a great many people getting in touch asking to present the opposing case: why they switched from Objective-C to Swift and are loving it.

I received many responses from a wide range of developers, so strap yourself in – this is going to be long!

Sponsor Hacking with Swift and reach the world's largest Swift community!

What made you move to Swift in the first place?

Aleksandar Vacic: Curiosity mostly, but I did not jump immediately on it. Only with 3.0 after the Big Rename and the promise of future source compatibility. This was crucial to be eligible for client projects.

Harlan Haskins: I’m not ashamed to admit it was the shininess and the ensuing hype train. Swift came out while I was an intern on the Wireless Software Engineering team at Apple and I started using it from 1.0 beta 1. I battled my fair share of skepticism that wasn’t entirely unwarranted, and after using Swift in personal projects later, I never looked back.

Louis D'hauwe: Back in June 2014, when the first beta of Swift came out, I took a quick look at the language to see what the hype was about. I didn’t actually write a decent project in Swift until 2015 with the Swift 1.2 release. The main reason I wrote that project in Swift is because I was in college and wanted to learn a new language. In the summer of 2015 I started working full time as an iOS developer and ever since I’ve been writing new projects in Swift.

Lucas Farah: When Apple first launched it, I saw that it was going to be the future of iOS development, so I decided to learn and start coding in the early days because I’d have to update my projects to Swift later anyways.

Josh Adams: I changed my profession in mid-2015 from lawyer to iOS developer. I may have realized in early 2015, when I began learning Swift, that this language was the way forward for professional iOS developers. As a former Java developer, I was primed for Swift's lack of headers and bracket-free method-invocation syntax.

Joachim Bondo: It looked simpler and more typesafe. I think I misused Objective-C’s laxness to compensate for my own shortcomings as a programmer. Isn’t this just a nice feature of a programming language, you ask? Yes, but after three or so decades as programmer, I felt I was ready to take it to the next level.

It seemed more lightweight, and closer to the metal because more stuff takes place at compile time. The capable enums were also very intriguing. And that you can make your own types conform to protocols to make them behave like built-in types. I could go on…

Ritesh Gupta: Given that almost everything was already sorted/defined with Objective-C, Swift came as a fresh beginning for me. It allowed me to rethink not only the way we made iOS apps but also how to structure a solution in a more modern way using optionals, protocols, generics, enums with associated types, functional aspects etc. Now after 3 years I'm glad I made the transition.

From a practical and business standpoint, it was immediately obvious this was Apple’s new direction and that this was an opportunity to be in on the ground floor. It reset the playing field to a degree.

Michael Mayer: There were a number of reasons. I liked the clean look of Swift – there was so much less language clutter in how you wrote code. Closures were a huge improvement over Objective-C as far as punctuation clutter and it was so much more consistent with other execution blocks in the rest of the language. Even removing the parentheses from around the boolean expression in an if-statement met my minimalist aesthetic.

I liked that structs and enums were now first class entities. The deemphasis on classes now made the value vs. reference semantic a more rational choice. I liked how the language seemed like a consistent whole, whereas Objective-C started as something grafted onto C. It was hard not to see this after using Swift for a while and then going back.

From a practical and business standpoint, it was immediately obvious this was Apple’s new direction and that this was an opportunity to be in on the ground floor. It reset the playing field to a degree.

Patrick Smith: At first (Swift 1) it just took a while to learn, but it was pretty clear how key use cases from writing apps have their own feature in Swift.

Blocks in Objective-C are pretty painful, as their syntax is faithfully inspired by the C function pointer syntax. Blocks are so much nicer in Swift. Plus variables to be changed with blocks don’t need the __block syntax. The more modern features that Objective-C gained feel like they have been designed into the Swift language from the start, because it has!

Bruno Scheele: I felt increasingly annoyed and frustrated with the need to runtime check every piece of code that I write, so the promise of a type-safe language was enough to get me on board. Also, I liked Apple's goals of making a nicer, safer language for everyone to learn.

Joe Fabisevich: If we're being honest, it was new and shiny. I started reading the Swift book that Apple put out the day the language came out and fell in love almost immediately.

I always want my code to be as provable as possible because I don't trust myself to write correct code. Swift's type system and a plethora of other language features enable the compiler to tell me what I'm doing wrong before having to discover it in production.

Rob Norback: My move to Swift was all about timing. The startup I was working for had just raised a seed round and we had an opportunity to green field the app. As a newer iOS developer at the time, I knew all the great tutorials online were in Swift, so I’d be able to get farther faster learning swift. I also knew a lot of iOS developers felt like me and would jump at the chance to work on an all Swift code base. That meant we’d be able to attract great talent a lot more easily as we grew.

What was it like when you tried going back to Objective-C code?

Aleksandar Vacic: For a year I did both, almost daily, switching between client projects. It was pretty jarring in both directions but that year actually solidified my love for Swift expressiveness over Objective-C. I could still use all the dynamism I needed but in a much nicer language to write, read and scan. Every time I needed to replicate map() in Obj C, I felt like pushing stone up the hill.

Every time I’m forced to deal with pointers, everything-being-a-reference-type, and defensive copying, I die a little on the inside.

Harlan Haskins: It’s not nearly as bad as many make it seem, but it’s definitely nowhere near perfect. There are a lot of parts of Objective-C that encourage people to shrug and ignore what might be bad behavior, like silently passing messages to nil and those weird block parameter subtyping rules. Every time I write a separate header file, I yearn for the days of proper access control and automatic interface generation from Swift. Every time I’m forced to deal with pointers, everything-being-a-reference-type, and defensive copying, I die a little on the inside.

Louis D'hauwe: Every once in a while I need to update a project that’s written for the majority in Objective-C. When doing so I try to write any new features in Swift. Although when doing a one line bug fix I will stay in Objective-C, the urge to just rewrite the whole project in Swift is very tempting (albeit not realistic).

Lucas Farah: Hell? It was kinda easy to move back, but it is so ugly! I’m a freelancer, so sometimes I get Objective-c projects and it just make me wanna go back to Swift as soon as possible.

Josh Adams: I maintain affection for Objective-C, a language I sometimes still encounter in the work setting and in useful Stack Overflow answers. Objective-C's positive influence on Swift is evident in, for example, named parameters, reference counting, and single inheritance.

Joachim Bondo: It’s frightening how quickly you loose the touch! I never had problems with the square brackets, but it’s suddenly just this foreign language to look at. I have to read the method declarations a few times to decipher what’s going on. But if I had to, I’m sure I could brush it off in no time.

Ritesh Gupta: I just couldn't go back to Objective-C. It's not like I can't understand Objective-C any more or don't remember the syntax, but the feeling is not right when I touch it. I try to finish off any Objective-C maintenance as soon as possible so that I could go back to Swift.

I resented having to do header files and its closure syntax.

Michael Mayer: It was eye-opening. Objective-C was my language but after using Swift for a few months, going back felt labored. I started resenting all the little things Objective-C made me do that Swift didn’t. I resented having to do header files and its closure syntax. I missed implicit type declarations, and not being able to use dot syntax to call methods and optional chaining.

Patrick Smith: It feels much slower for a quite a few common tasks. The biggest things are lack of powerful structs and enums, and more natural block syntax. (Mostly) everything being an object is also a pain, when say you want an array of values. Swift’s type inference is so much nicer than having to write the type twice.

Bruno Scheele: Mostly easy. I've had no real problems going back to the older paradigms. Though the smaller syntax errors always trip me up. no ; at the end of lines, if-statements without (), string declarations without @, that kind of stuff.

Joe Fabisevich: It was, and still is somewhat difficult. I love learning languages, either for pragmatic purposes or personal growth reasons. I never was one to truly appreciate the beauty of Objective-C's dynamic message passing (sorry Alan Kay!), and focuses heavily on Object-Oriented programming. I would argue it's a lot closer to Java than it is to Haskell, C++, or even Swift. That comes with a lot of trade offs, and once I was given opportunities to use a more extensive language in my day to day, it made it hard to go back.

I still had a few open source projects I wanted to maintain, but ultimately gave up. It's not that I couldn't go back to Objective-C, but I actually found it more personally interesting, and easier to maintain by rewriting it in Swift (even with all the upgrades).

Rob Norback: The readability is just dramatically lower in Obj-C. I could read the code just fine because the APIs for UIKit are essentially the same. It was just much slower. I had to slow down and parse all those brackets.

What part of Swift did you find was hardest to learn?

Aleksandar Vacic: Oh - generics, no doubt. It’s easy to grasp the basics but to actually use them efficiently took a lot of time.

Harlan Haskins: Pattern matching. Specifically, I think the syntax around cases and all the little places in the language where pattern matching can occur is not very discoverable, and I hope we can improve it as the years go on.

Louis D'hauwe: Embracing compile time safety. Coming from Objective-C, a dynamic language where the compiler will happily let you set nil to any pointer (although it might warn you with the nullable attributes), it takes a while to fully master compile time safety. Properly using (or not using) optionals and avoiding implicitly unwrapped optionals certainly comes with a learning curve.

Josh Adams: Three aspects of Swift posed special challenges. The first is the concept of optionality. The second is the layers of syntactic sugar in which closures are optionally encrusted. The third is the syntax of enums with associated values in switch statements. I am comfortable with all three, but I found the learning curves steep.

Ritesh Gupta: There was nothing hard as such but certainly some new techniques which were abused or wrongly used like Optional. Initially I remember, everyone was using bang (!) operator almost everywhere without having deeper understanding of the consequences. But now we understand how to use it optimally so we get the best of it. Protocols, I would say, are another feature of Swift which is little mysterious or hard to adopt by someone who is coming from OOP background like Objective-C.

Michael Mayer: To be honest, I am still trying to grok portions of the generics system when it involves protocols. While optionals are sort of the first hurdle, they are easy and natural now.

Patrick Smith: I probably find protocol-oriented programming hardest to design well against. I don’t find myself using it as much as I like. Also found it hard to contribute to Swift Evolution, but the people getting stuff done there really put the effort in with proposals, etc.

Bruno Scheele: When not to use the fancier language features. It's hard to recognize when a language feature is overkill or actually unhelpful in a particular situation (custom data types as structs or classes, for example). And generics or associated types… those are tough.

I’d seriously dread doing interviews in Swift because of how poor the string APIs are. And you know how everyone loves asking string questions!

Joe Fabisevich: Generics were probably the most difficult part of learning Swift for me. At first I tried to write code any way I could to avoid using them, and only once I realized there was no other choice, I would use them.

Once it clicked though, it finally clicked, and I was able to start writing code thinking about how it could be written to leverage generics. I still treat it as a last resort vs. using enums, protocols or structs because I think the barrier to entry for using generics is pretty high.

And really when there's an UnsafeMutablePointer involved, I'm still quite gun shy.

Rob Norback: Oh, actually the string manipulation. That’s been in flux since the beginning of swift. Not a fun thing to deal with. I finally think they have a reasonable solution for Swift 4, but I’d seriously dread doing interviews in Swift because of how poor the string APIs are. And you know how everyone loves asking string questions!

Do you think Swift has helped you write safer code?

Aleksandar Vacic: Absolutely. I have two client projects which I rewrote from Objective-C into Swift. The amount of stuff compiler caught me doing is quite helpful and crash count should be 5-10x lower than with previous incarnation of the same app.

Harlan Haskins: Absolutely, 100%. By forcing you to handle things like nullability or type mismatches (which would frequently be painted over with id in library code in Objective-C), the set of invalid Swift programs that compiles is far smaller than the set of Objective-C programs that compiles.

Additionally, the lack of perfect C backwards compatibility removes categories of undefined behavior like NULL dereferencing and stack corruption in idiomatic code. There are just a lot of little places where Objective-C will bite you, like inserting nil accidentally in an array or serializing nil to a string and seeing “(null)”.

Louis D'hauwe: Not when I first started out, but after a couple years of learning how to dance with the type system it definitely has. When first starting out with Swift it can be easy to just make everything an implicitly unwrapped optional. This will silence the compiler in many cases but comes at a safety cost.

Lucas Farah: Yes. I love how optionals work and I’ve definitely seen less crashes because Xcode tells me about a lot of problems beforehand.

Josh Adams: Absolutely. When I first learned Swift, I found optionality irritating. I was continually adding and removing !s and ?s to fix compilation errors. But after I grokked the purpose and use of optionality, I perceived a benefit. Optionality forces me to consider whether a value can ever be nil during ordinary execution and, if it cannot, what I should do about the unexpected nilness.

Often the presence of a nil value is evidence of programmer error. In my Objective-C days, I might have messaged an unexpectedly nil pointer, and execution would have continued in an indeterminate state, greatly complicating the post-bug-report search for the incorrect assumption of non-nilness. But in Swift, whenever I unwrap an optional value, I ask myself, "Does it ever make sense for this value to nil? If not, should I fatalError() or report an error to the user?" This fail-fast approach cabins incorrect assumptions of non-nilness.

I’ve been writing Cocoa production code on a daily basis for more than a decade, and I hardly ever see a crash in my Swift code. And I’m not that much better of a programmer.

Joachim Bondo: Without doubt. I’ve been writing Cocoa production code on a daily basis for more than a decade, and I hardly ever see a crash in my Swift code. And I’m not that much better of a programmer.

Ritesh Gupta: Yes, certainly it has enabled me to write safer code. Here by safe I'm referring to type safety and memory safety. With the help of structs, protocols, enums, one can really enjoy the benefits of types which allows the compiler to warn you at type mismatch. On the other hand, Optional gives you control over the existence of a variable so that we can wisely decide whether to safely unwrap it or do a force unwrap as per requirement.

Michael Mayer: Absolutely. There are whole classes of errors that have been eliminated from my code by the type-checker. I use value semantics more when it makes sense. I also think that they are less hidden errors in how I express my intentions in Swift code.

Patrick Smith: Running custom code in Objective-C when a property changes in our class meant either creating a custom setter method and then setting the instance variable directly (often remembering to copy the incoming value with say an NSString) or using key value observation on our own object, which gets messy. In Swift, we can simply add a didSet section to our property (var) declaration.

Bruno Scheele: Yes. No doubt about it.

Joe Fabisevich: Without question. The type system is much better than Objective-C's, but I think the biggest improvement comes from the different tools that Swift gives you to model your code.

Knowing that a type is an enum gives any developer reading your code certain assurances about how it will behave. The same is true for the expectations when choosing a struct, a protocol, or even a class.

These kinds of things may seem like a cherry on top rather than the cake, but the truth is that when you're trying to keep a large code base in your head being given as many clues as possible is the best thing someone can do for you.

Rob Norback: Definitely. I’m writing Javascript with React Native some these days and man, I often don't even know what parameters are required for a component to function properly. And forget type safety, I can easily make the mistake of passing an integer for a string. In Swift, I know exactly what types and parameters are expected from me and when. Swift is the closest to "compiling = it’ll work" I’ve come across.

Have you found compile times to be a problem?

Aleksandar Vacic: Yes, but not enough to hinder day to day to development. SourceKit hangs and crashes are more annoying than compile times.

Harlan Haskins: I have admittedly not worked on large enough projects that would make compile times a significant concern. I am aware that many projects hit gigantic compile times, and I hope that can be improved.

Louis D'hauwe: In the past, yes. But recently not really. Although I’ve come across some specific cases that can take a while when doing a clean build, I don’t notice long compile times when doing day-to-day development. One disclaimer: I recently switched from a 2014 MacBook Air to a 2017 MacBook Pro, so my compile times seem pretty good at the moment.

Lucas Farah: Yes. Worked for a big bank and we had 25+ minute compile times. We had to split the project in a lot of schemes to reduce it, but it was still bad.

Josh Adams: No, but I have never worked on a Swift codebase of the magnitude of, say, Lyft's. That said, I appreciate Apple's continuing efforts to improve compilation times and am mindful of certain techniques.

Joachim Bondo: In the early Swift days I worked at Black Pixel, and I remember colleagues complaining about having to recompile the whole project every time they changed just a single line of code. With version 1.2, when I jumped the boat, Xcode did incremental builds. I rarely find it a problem (but I also have a fast Mac.)

Ritesh Gupta: This has been a major concern in the Swift community. But since I don't deal with apps having very huge codebase, it hasn't been a blocker for me.

Michael Mayer: No, not at all, not since they added incremental builds. It has also been a while since I got the “expression too complex to parse” error. Maybe it is my coding style or that I don’t have any individual projects with over 100K lines of Swift code.

Patrick Smith: I haven’t found them to be a problem, but I’m working mostly on solo projects or libraries, and try to keep the code size down. I would love it to be faster though!

Bruno Scheele: Only on the level of a small, but constant annoyance. Nothing on the level of wanting to go back to Objective-C. My projects are usually small, so I'm not waiting too long on code.

When I'm trying to go through the code-compile-debug cycle for something simple like changing a color or font, having to wait 10 seconds instead of 2 really adds up.

Joe Fabisevich: Definitely. I am very happy that I spend less time debugging these days thanks to how powerful the type system is, but at the same time when I'm trying to go through the code-compile-debug cycle for something simple like changing a color or font, having to wait 10 seconds instead of 2 really adds up.

Rob Norback: Ah yes, compile times. Waiting 20 seconds for your code to compile is definitely a pain. Initial compiles can take up to 2 minutes, but there are solutions for this. There’s an app called Injection that allows you to swizzle code onto the simulator using the Objective-C runtime. It’s great for cutting down on swift compile times when you’re developing UIs.

If you had to pick one favorite Swift feature, what would it be?

Aleksandar Vacic: General clarity and expressiveness while staying succinct enough to read. If I really have to choose one: ability to use extension with system classes. So great and useful. I know about Objective-C categories of course, but this is so much better.

Enums with associated values are the kind of feature you don’t know you need until you use it.

Harlan Haskins: Enums with associated values. I cannot overstate how important it is, when writing predictable code, to have a finite set of disjoint structures that can be exhaustively enumerated. The equivalent code in Objective-C is usually written as a set of subclasses tested using -[NSObject isKindOfClass:], which can never be more than a shaky foundation. Enums with associated values are the kind of feature you don’t know you need until you use it.

Louis D'hauwe: Protocols, because of everything you can do with them: extensions, generics, inheritance, composition. When buying in to the whole “protocol-oriented programming” paradigm, Swift shows its true potential. There’s a great WWDC talk from 2015 about shifting a traditional programming mindset to being protocol-oriented.

Josh Adams: Enums with associated values. Different states can be closely associated with appropriate datatypes. In Objective-C, values associated with enum types would need to be declared in entirely separate data structures. The close association, in Swift, of enum states and associated values prevents them from drifting apart.

“It’s nice you can send messages to nil”. Yes – until it’s not.

Joachim Bondo: Only one? Probably optionals (including optional chaining). It’s fantastic how it forces you to think about whether your variable is required to have a value or not. And how a seemingly innocent change from optional to required (or vice versa) cascades through your code and reveals weaknesses in your architecture. That’s nice. That little feature alone makes me a better programmer.

Most bugs I’ve seen in Objective-C, including my own, have been variables silently being nil. “It’s nice you can send messages to nil”. Yes – until it’s not.

Ritesh Gupta: For me it's undoubtedly protocols. It's not like they were completely missing in Objective-C but the ability to write extensions on them is the game changer. Protocol-oriented programming really helps you abstract out common behavior which entities can adopt and thus have that trait easily.

I have been so inspired by this concept that now I don't think in terms of entities but rather in terms of traits and behaviors. These behaviors are composable as well, which doesn't restrict unlike multiple inheritance. Not to forget, protocols could also have generic aspect via associated types or Self which really adds extra power into the language.

Michael Mayer: I love so many features, so I’ll pick something a little bigger: Protocol-Oriented Programming. What a great additional abstraction that gives me the power and precision to specify exactly what goes into my type.

Patrick Smith: The value types. Enums in Objective-C are simply namespaced constants. Swift lets them have String representations or associated values. This lets you do a lot of modelling you can’t do without creating a class and many subclasses in Objective-C. Swift makes this code more elegant and natural, and simpler.

Structs in Swift are first class siblings to classes. Structs in Objective-C were always limited, and were difficult to use with Automatic Reference Counting (nested objects).

So in Objective-C you’d usually use a class for what you’d implement using an Enum or Struct in Swift. And then you’d have to decide whether it would be mutable or immutable, or even both. And so you’d have to implement -copyWithZone: and -mutableCopyWithZone: and copy each property across manually to a newly created instance. With Swift value types (enum and struct) this is all taken care of for you! Copy-on-write means our types handle both immutability and mutability, it’s just so much better.

Joe Fabisevich: If I had to choose just one, I'd have to choose protocol extensions. Protocol extensions allow you to model your code in a way that does not tie it to a specific object or struct.

This becomes really powerful when you want to create a generic behavior, similar to how you would mixins in a dynamic language like Ruby. It takes a while to figure out the right balance, because as Spiderman says "with great power comes great responsibility." They can easily lead you to a very dynamic environment where you're back in the land of making assumptions about your code.

Rob Norback: Not gonna lie, I kind of love optionals. I think it’s a great way to afford more type safety. And there are so many ways of handling them that it makes your code very flexible. Guards, if-lets, and nil-coalescing operators to name a few.

What areas of Swift do you think could be improved most?

Aleksandar Vacic: The debugging is often broken and with more complex apps that becomes more and more important. So Swift itself is fine for me now, I would love a focus on tooling. Second in line is more magic to cooperate with iOS SDKs, like finding a way to declare stored properties in extensions.

The fact that one of the questions asked is “Have you found compile times to be a problem?” means there is a lot of work to be done to make compile times acceptable.

Harlan Haskins: The fact that one of the questions asked is “Have you found compile times to be a problem?” means there is a lot of work to be done to make compile times acceptable. I hope that the focus on ABI stability will allow for new build practices that focus on prebuilt libraries to avoid rebuilding dependencies, and I’m sure there will be improvements to the type checker that cut down on some of the exponential compile times.

Louis D'hauwe: Setting tooling aside for a moment and focusing on actual language features: extensions need some love. One specific example is adding properties in an extension, which as of Swift 4.0 is not possible. Another area that could be improved is error handling. Typed throws would be nice, although there are some good arguments against it.

Lucas Farah: I’d say JSON parsing but Apple fixed that in Swift 4. Now I’d say ABI stability.

Josh Adams: As a relatively new language, Swift is not fully baked, but the openness of the Swift Evolution process reassures me that features currently missing, such as ABI stability and first-class concurrency, will eventually be implemented.

Any dissatisfaction I feel as an iOS developer, and I do not feel much, stems from policy decisions that are unrelated to Swift, for example the absence of free trials and paid upgrades for App Store apps. These have stunted and will continue to stunt the app ecosystem unless Apple addresses them. Nevertheless, the developer-App Store experience has improved greatly since Phil Schiller assumed the reigns, and he inspires cautious optimism.

Joachim Bondo: I’d love to see KVO carried over in a light-weight fashion (not just the new Swift 4 syntax which still requires NSObject and Objective-C compatible types), but I have no idea about if it’s even feasible.

And as much as I like optionals, I hate the if let same_variable = same_variable {} style of coding to unwrap an optional. Wasn’t there talk about an if unwrap(variable) {} syntax at some point?

Ritesh Gupta: I think Swift Evolution has done a great job for the language – I don't think there's anything major which I could point out. Though there are few finer improvements which could be part of future changes, e.g. resolving overriding conflicts in case of multiple conform of protocols (Kotlin has it), or the concept of behaviors from Elixir (similar to protocol but on module level).

I have been wearing programming big boy pants for quite some time so it feels a bit overbearing.

Michael Mayer: I really dislike how using pointers is so much more complicated and “dirty” feeling than Objective-C. Yes, I got the whole “unsafe” thing, but I have been wearing programming big boy pants for quite some time so it feels a bit overbearing. In this area at least, Swift’s type system is more like a straight jacket than a helpmate.

I am very happy with the new GCD API, but I understand why others (Linux, etc.) are eager for a built-in concurrency model. I would like something that echoes GCD, but it looks like we are going down a path much more akin to C#.

I’d like Apple to add debugging capabilities to playgrounds in Xcode. What the hell? Why does Swift Playgrounds on the iPad have better debugging than Xcode?

Patrick Smith: In some ways I wish Swift’s syntax could be even simpler. The pattern matching, while a pleasant addition compared to Objective-C, often doesn’t feel very elegant compared to the richness and naturalness of something like Elixir. Having to type both case and let gets tedious.

I’m really looking forward to where Swift’s web server abilities go. I find it a friendlier language than Go or Rust or even Ruby or JavaScript. I hope what the web server working group produces is a good mix of powerful with approachable.

Bruno Scheele: Testing and support for referencing generics or associated types in other classes. Creating the AnyGeneric gets tedious.

Joe Fabisevich: Tooling is the biggest downfall. I'm not pushing for ABI stability, because not having it means we can still change the underlying infrastructure, and the problem affects only a small percentage of overall Swift users, but we need to be building towards a better future for our tools.

Rob Norback: As I said before, string manipulation. But Swift 4 solves a lot of that by making them collections again!

What's your advice for people learning Swift today?

Aleksandar Vacic: Use playgrounds - there was no such thing previously and it’s immensely helpful in quickly testing any assumption you may have.

Harlan Haskins: Find something simple you want to make, then something bigger, then something bigger. Nothing is going to teach you quite as well as making mistakes, and nothing will motivate you quite like a project you’re passionate about.

Louis D'hauwe: It’s tricky to recommend Swift as someone’s first programming language. Contrary to the way Apple markets it, Swift is not an easy language to learn. So if you want to learn Swift (and all its complexity with it) I would advice you to already have some programming experience. Or at the very least, if you really want to start from zero programming experience, ignore most of the language’s advanced features (generics, copy-on-write behavior, etc.).

For more seasoned programmers that want to learn Swift: face the fact that Swift is unofficially still a beta. It’s gotten a lot better in recent releases (the Swift 2 to 3 conversion was awful, although very necessary in retrospect) but you should be prepared for frustrations with Swift’s tooling (e.g. compiler errors being confusing or just plain wrong).

Don’t get mad over optionals. You will learn how to use them properly and they will become your best friends!

Lucas Farah: Don’t get mad over optionals. You will learn how to use them properly and they will become your best friends! If the person is coming from Objective-C: pay attention not to write Swift like you write Objective-C.

Josh Adams: Choose a learning resource tailored to your background. Different approaches are appropriate for learners who have never programmed, who have programmed but not in Objective-C, and who have programmed Objective-C.

Joachim Bondo: Start simple. Write dead-simple code (which is easy in Swift) and build from there. Forget generics and fancy protocols to begin with. Add them when you understand what they are and what benefits they bring. And then keep writing dead-simple code.

Ritesh Gupta: I would say write a lot of code as you start reading the documentation/blogs! It's a combination of both, you need to feel and understand what you can achieve with Swift and that's only possible once you start writing it for real. Initially your Swift code will follow your previous language's style but that's very normal.

Ask senior team members to do code reviews on daily basis and understand why they want you to make those changes. Slowly dive into blogs, otherwise you may be intimidated by various options of solving or approaching a problem. Don’t use external frameworks until you have become comfortable with the language otherwise you will get too dependent on them.

Just remember, Swift is great language with a lot of modern features. Embrace the changes, be part of the evolution and keep coding!

Don’t try to learn it all at once. Swift is a huge language, and it will likely expose you to concepts that are new to you

Michael Mayer: Don’t try to learn it all at once. Swift is a huge language, and it will likely expose you to concepts that are new to you. Find a path that will progressively expose more and more of the language. Take the Swift tour in Apple’s Swift Language Book and mess around in the associated playground. Playgrounds are awesome – I use them frequently when developing new functionality.

Patrick Smith: Use value types as much as possible. Declaratively architect the structure of your app with data and the type system. Enums with associated values are the bees knees. I’ve thought about doing an Enum-Oriented Programming tutorial, as I think they are just such a handy building block.

Bruno Scheele: New developers; Just start and write a small app. It's great! Objective-C devs; Just start and use your Objective-C brain. You'll get the hang of Swift features and will replace your old thinking naturally.

Joe Fabisevich: Start small. The language is so deep and complex that it's easy to get discouraged if you dip your toe in the water and discover that it's actually an ocean.

If you're coming from Objective-C, it's OK to write Swift that looks like Objective-C at first while you're getting accustomed to all the new goodies. If you're coming from any language that isn't C++, it's OK to write Swift that isn't idiomatic at first too, because the mental model truly is closer aligned with something like Rust or Scala than it is JavaScript.

Sponsor Hacking with Swift and reach the world's largest Swift community!