Conquering Your Fear of Adopting Swift

There’s a mountain of Objective-C code already in place, and it took years of development to get to this point. How do you convince your team that moving to Swift is worth the business and engineering costs? What if you could write new code Swift which could be used by the rest of the app built in Objective-C? What are the risks, and what can you do to minimize them in writing new code in Swift?

What’s Going On With Objective-C? (1:29)

Objective-C is like the superhero you don’t quite expect. It’s been around since NeXT, and the APIs have been around for a long time with a lot of the original functionality and some refinements. Apple says that Objective-C will be around for a while, so it’s not as if you wouldn’t be able to use Objective-C next year.

Objective-C is heavily rooted in C, and has a complex build system with lots of settings and dependencies. Thus, we can do better with Swift.

Why Swift? (2:42)

What should be the reasons for using Swift?

1. Swift can do some powerful things that Objective-C cannot do.
2. Chris Lattner.

Chris worked on LLVM, which has become a lot of the infrastructure that’s being used even by Google, for both Android and the Chrome browser. Chris is currently in charge of the Xcode teams and Swift. Overall, Swift has many advantages over Objective-C.

During the first month I worked with optionals, I didn’t quite understand why they were necessary, but I’ve since learned of their advantages. The if let statement is a good thing. Though it may not look like an operator, it is. Since Apple introduced the guard statement, things have been a bit better as well, allowing you to avoid a lot of common crashes.

Like the introduction of ARC six years ago, which eliminated a lot of the unexpected crashing problems, the Swift language has a lot of features that improves app stability. Swift also provides enhanced modularization, to include compile time and code improvements.

One of the things I like about Swift is the tooling system. You don’t have to deal with header files and search paths, and as a result, it’s more framework oriented. You can also start creating code boundaries, and packaging your code so that only certain parts are accessible.

Frameworks have not been the easiest to work with in Xcode, which is a reason why CocoaPods and Carthage exist, so there have been commitments to build out the Swift Package Manager. In the future, something like CocoaPods can be a module of Swift Package Manager, such that they can coexist.

Business Reasons For Swift? (8:59)

At the moment, it’s difficult to find someone who wants to work with Objective-C. If an employer has a codebase that’s only in Objective-C, and has made it clear that any prospective employee won’t be touching Swift, they won’t be getting many interviewees.

If you want to hire developers in the next five years to work on iOS, Mac, tvOS or watchOS, you’re going to need to start moving into Swift. In terms of saving money, you’ll want to slowly rewrite pieces/introduce Swift that can interoperate with the Objective-C legacy code base. That way, you’re still getting model objects, for example, and you can continue using them without throwing away a lot of code.

I’m a fan of frameworks, like .NET with Visual Studio, and C#. I can have a website and a Windows application, and they can all use class libraries without any issue. Swift is heading toward that point, where the build system works more smoothly.

What are the Risks? (12:56)

Because you have legacy code, you will have to make your Swift code compatible with Objective-C. For example, instead of building out some new features with structs and tuples, you’ll have to building your classes with objects and not structs. This is because certain new features will not work with Objective-C.

Embrace the Fresh Start (14:35)

One of the benefits of going to Swift is the chance to rewrite difficult-to-read-and-maintain code anew. It is an opportunity to attack old code. In doing so, the codebase can get better through a new language.