Is Swift Ready For The Enterprise?

What About Swift Migrations?

Migrating to Swift has been a challenge for many developers. Early on, the language was inconsistent, and compile-time errors were difficult to interpret and often marked nowhere near the call site where the actual error occurred. So far, Xcode’s refactor has not been available in Swift files and its misbehavior is starting to become an issue in Objective-C.

With Swift 3.0, the authors of the language decided to make sweeping language changes now, which would (hopefully!) result in fewer changes in the future. As an example, look at What’s New in Swift 3.0.

This “jump” has become known as the Great Renaming. Method signatures are now more concise and readable, and various redundancies have been taken out as well. A few common, key Objective-C foundation classes have been renamed in Swift to remove legacy naming issues, and enumeration cases are now lowercased.

These and other updates in Swift 3.0 are definitely breaking changes. The work to migrate existing Swift code to 3.0 was quite challenging. Xcode 8 does include a very good migration tool, but it doesn’t cover every nuance of the language. To some, the changes in Swift are still considered harmful. Check out this article by Craig Hockenberry for another take on contentious Swift changes.

Enterprise developers echoed these concerns about Swift migration efforts:

“The biggest challenge was migrating our codebase from Swift 2.2 to Swift 3.”

“Migrations. Migrating from one version to the next has been painful. But I still feel that using Swift is a net gain. If you take a step back and consider the safety features of Swift and the number of bugs that can be reduced by using it, the time spent on migrating is likely less than the impact that your users will feel and the time spent debugging production issues and deploying patches.”

“Co-mingling Obj-C and Swift has made our lives full of pain with various bugs and compilation slow downs.”

“Every. Freaking. Update.”

“The worst part has been making sure all of our teams and dependencies upgrade Swift versions at the same time.”

Managing Dependencies Across the Enterprise

Coordinating versions of Xcode with versions of third-party tools, such as CocoaPod versions, is much like performing a fine ballet. You need to plan carefully when you have a team of 20 to 30 developers working on a number of related features and products. Throw in a build server and staggered releases, and any incompatibility issues can wreak havoc on the team. When the build server gets stuck on a build failure, nobody’s happy.

The cumulative economic and psychological cost of downtime or delays adds up quickly in a team. Some developers shared their frustrations with lost productivity:

“The worst experience I had was when I wasted a few hours trying to figure out a particular compilation problem. As it turned out, I simply didn’t understand what the compiler was trying to tell me because it did so in a very obtuse sort of way.”

“We’ve had experiences of multiple clients using different versions of Swift, which from a framework provider perspective is a maintenance nightmare. We’ve gone down the route of acting as Swift evangelists to persuade clients using older versions of Swift to upgrade. Sometimes, this isn’t feasible due to budget or time constraints, at which point we look at how we can back port libraries to older Swift versions.”

“The natural argument to this is if we used Objective-, all these versioning issues would go away. Whilst that is the case, we don’t want to be left behind from a technology standpoint, and feel that the issues we’re facing are worth the pain to make sure we as developers and our third-party clients developers are using the latest and greatest Apple has to offer.”

Where Has Swift Succeeded in the Enterprise?

Despite the challenges and setbacks of Swift, it somehow seems easier to deal with these issues on a large team, than when you’re working as a small indie developer. The ability to share knowledge in a group is great; enterprises by their nature have to move cautiously and weigh each decision with care. In spite of some of the hurdles of Swift, there are some notable success.

Apple announced its desire to work with enterprises back at WWDC 2015. They partnered with IBM MobileFirst to bring mobile technologies to mega corporations. In 2015, IBM also brought Swift to the enterprise with their Cloud Tools for Swift, and created an online Swift Sandbox, where users can write and compile Swift right in a browser. Most recently, IBM introduced BlueMix Runtime for Swift for writing server-side microservices in Swift 3.

In the spring of 2016, I attended an enterprise presentation at Apple where they covered enterprise management tools and services as well as iOS Security. Jamf, a provider of data protection services, made a presentation of their tools, and Apple shared some of their notable deployments on their web site iPad in Business. As an example of the success between Swift and mobile devices in the enterprise, check out this article on British Airways transformation with the use of iPads.

Swift Success Profile: Harry’s

Gemma Barlow, the team lead at Harry’s, shared her experiences with Swift:

“Now that we are all familiar with the basics, we’ve seen some really nice abstractions start to be worked into our daily grind; keeps things challenging!”

“We’ve just completed the upgrade from Swift 2 to 3, and it was gnarly. The migrator didn’t work in some places, and littered the code with useless bits we are still cleaning up. We are lucky enough to be featured regular in the Shopping category on the App Store — and have worked with Apple prior to launch. Doubt that would have happened if it was all Obj-C.”

Swift Success Profile: American Airlines

American Airlines was one of the enterprises who adopted Swift 1.0. They were also one of the first Watch apps on the App Store.

Matt Klosterman from American Airlines shared the following:

“We adopted Swift 1.0 on a “for all green field view controllers” basis. With Swift 2.0 we adopted Swift on a “for all new or modified code” basis. We did this because the language features in Swift 2.0 made code from team members of varying skill level on the team more consistent and reliable. We achieved this by writing extensions on any legacy Objective-C classes to implement new functions. All new classes were written in pure Swift.”

Matt continues:

“The Great Renaming of Swift 3.0 went very smoothly for us. We started tracking the open source toolchain snapshots in March of 2016 and converting as changes dropped in a separate branch. Our Swift 3 conversion was complete on the first day of WWDC. We followed this same process as Xcode 8 betas progressed.

“Our 7-year-old app with lots of legacy code is now more than 50% Swift.”