Is Swift Ready For The Enterprise?

For enterprise developers, adopting Swift over Objective-C as a primary language is not an easy decision to make. Stakeholders, budgets and sizeable user bases all affect the direction of enterprise app development. Enterprises must move carefully, and with oversight, as there’s quite a lot at stake. Perhaps the question could be rephrased: “Is the enterprise ready for Swift?”

As a contract developer, I’ve spent decades dealing with various enterprises, architecting, designing and delivering App Store and in-house apps. It’s a tough market to work in, but I still managed to operate at arm’s length without having to deal with enterprise-level details.

Over a year ago, I took the plunge and joined a major corporation as a subject matter expert and, ultimately, a lead iOS developer. Each day, I experience firsthand the challenges of delivering apps inside the enterprise environment.

To get a sense of how large companies are managing with the transition to Swift, I polled a number of colleagues — all of them enterprise developers from around the world — to help judge whether Swift is, truly, ready for the enterprise.

What Defines the Enterprise?

To start, let me be clear on what I mean by “enterprise”. I’m not talking about your usual small to middle-sized development shops.

By Apple’s definition, members of the enterprise program have a minimum of 200 employees. The apps they create may be used internally by hundreds or thousands of employees or delivered through the App Store, and may be installed on millions of devices with millions of daily users.

Adopting new tools and even a new development language requires a lot of forethought, and many checks and balances. A business issue resulting from a bad install or bug could be catastrophic to the company.

Should You Be an Early Adopter?

Working with Swift in the face of a large Objective-C codebase requires careful planning. Apple has done a great job with interoperability between languages. Bridging Objective-C and Swift in the same code base should be straightforward, but there are often gotchas with mismatched types, collections and classes.

The majority of developers I contacted started working with Swift 1.0 as soon as it was out, as they were eager to jump into the new language. The remainder of the developers I polled started developing with Swift 2.0, which was still early in the Swift life cycle. They say that although it was easy to adopt Swift, there was a learning curve to face for those coming from Objective-C. One developer notes although the start was rocky, mastering Swift came quickly:

“[I was a] very early adopter. I found it incredibly difficult to write Swift for the first few weeks coming from writing Objective-C full time for 4+ years. It didn’t take long until I felt efficient in it though.”, said one developer.

When it comes to development teams, the adoption rate is a little different. Around 30 per cent of development teams started in earlier than Swift 1.5. The remainder started in later, with Swift 2.0.

Why Do Enterprise Developers Like Swift?

The majority of the developers I talked to speak highly of Swift. They admit that there were challenges along the way, but their overall experience with Swift is so good that they try to use the language as much as they can. Language features such as type safety, modern idioms like generic and closures, as well as functional programming are highly valued. Here’s what some developers said they like most about Swift:

“It’s safe, clean, easy to write and readable.”

“Swift has greatly improved the clarity, consistency and reliability of our codebase.”

“Learning what a modern language should feel like and the features that they bring. Learning Swift has allowed me to take a step back from day-to-day app development and refocus on some of the basics of Computer Science and Software Development.”

“Swift Playgrounds are so inviting, I find myself using them to implement popular CS algorithms to better understand fundamental ideas and principles.”

“It’s all been good. The type safety, expressiveness, concision, functional programming features, generics, consistency and seamless compatibility with Cocoa/Cocoa Touch have been wonderful.”

Inside the enterprise I work with, we conducted training sessions on Swift. We have a lot of legacy code, so we decided to start with Swift in our unit tests. Since the testing framework was separated from our apps, it provided a safe place for the team to hone their Swift skills.

What Challenges Exist for Swift in the Enterprise?

Adopting Swift would hopefully feel like running gracefully through verdant fields of wheat, but surely it’s not all fun and games?

When I joined my current employer, not many employees suspected that I was to become a champion of Swift, and challenged me on it. I was often cross-examined by teammates asking me what was so great about Swift.

Usually I would fall back on things like type safety and Swift idioms that aid in compiler optimization; using the final keyword as a way to tell the compiler that no more method changes or subclasses were due; using extensions to add functionality and adopt protocols while separating concerns and keeping the code clean; Optional Binding, Nil Coalescing and guard as ways of dealing with nil returns and avoiding crashes. You know, the usual “Swift-y” arguments.

Personally, I could deal with the SourceKit crashes and non-functioning code completion. Those weren’t Swift problems — they were Xcode features, right? For a while, it’s seemed like that was the case. And I could usually tolerate the long compile times and the breaking changes brought on by the Grand Renaming in Swift 3.0 — but not everyone agreed:

“My number one complaint is compile time can be reaaaaaaaally slow. And methods to speed up compile time can hamper debugging and cause a greater loss in productivity than living with a slower compile time.”

At a recent meetup in Toronto, we had a discussion about Jenkins, a continuous integration tool. The question of compile times was raised, and the presenter noted compiling with Objective-C took around a couple of minutes. In contrast, a Swift app might take 20 to 30 minutes.

Another developer commented that their app was a blend of Swift and Objective-C, and they had come to expect 10-minute build times. Long compile times for Swift apps are still one of the most common complaints among enterprise developers. Check out this surprising post from LinkedIn’s study on compile times for more dirty details.