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.
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.”
What Does the Future Hold for Swift in the Enterprise?
With each version of Xcode, working with Swift gets better, and you could argue that worst is behind us. For instance, Xcode 8 removed the pain of having to delete cached derived data from your build phases. Application Binary Interface compatibilty (or ABI for short), was pegged for Swift 4.0, which would mean Swift code would then be backwards-compatible. Recently, Apple announced that it will be pushed to a later date, but it seems the looming cloud of more breaking changes in Swift may have passed.
“[We’re looking forward to] ABI compatibility; we consume a commercial 3rd party Swift framework in binary form. This requires our Xcode, Swift version, and vendor framework to always be in lockstep.”
“Really love writing [Swift] because it feels smarter than Objective-C is in many ways. The yearly updating to the latest Swift version doesn’t hurt us much at all and we usually plan the migration right around when the GM of the new iOS comes out.”
IBM: “Swift is ready for the Enterprise”
Swift for iOS is great, but what about server-side components? IBM recognized the need for cross-platform Swift implementation quite some time ago and made it a reality. Last fall, IBM added its own open source Kitura web framework to the mix, so that enterprise developers can use one language between Linux and iOS.
The relative stability of Swift 3.0 and Xcode 8, along with support from Apple and IBM, means that enterprises now have the confidence to build new apps and augment existing code bases. According to IBM’s Mike Gilfix, over 70 per cent of enterprises plan to build mobile apps soon. PerfectlySoft Inc has also introduced their Swift server framework, Perfect. Check out our screencasts on Server Side Swift with Perfect: Getting Started. Vapor and Zewo are also popular Swift web frameworks to consider.
Apple has also demonstrated a continuing commitment to Swift: all Apple presentations since WWDC 2015 have been created with Swift. All of Apple’s developer tutorials are in Swift, and there’s even talk of updating the scores of code samples on the Apple Developer site. At raywenderlich.com, we have been writing our courseware in Swift since August of 2014 — and we continue to update with each new release of Swift.
Where To Go From Here?
Of the 20 participants who contributed stories of their experiences for this article, only a few were opposed to using Swift. For them, it was primarily issues with changes between Swift versions and buggy tools that formed their opinions about Swift.
However, the majority of contributors had adopted Swift early, so bringing Swift into their development teams was much easier, and they had many more success stories to share.
Some of the top tips for success with Swift are:
- Use third-party libraries only when necessary to avoid dependency issues.
- Stay mindful of language versions.
- Make use of Apple’s and IBM’s enterprise for smooth Swift integrations.
- Stick it out: when major updates such as ABI become part of Swift, the going will get a lot easier.
- Start small: consider implementing Swift in small ways, such as for your unit tests.
I’d like to thank the many developers who contributed to this article with their honest Swift experiences. Many contributors asked to remain anonymous due to confidentiality reasons.
Some participants I can name, and thank publicly: Aaron Douglas, Rich Turton, Gemma Barlow, Anthony Uccello, Matt Klosterman, Mike Katz, WeyHan Ng, Andy Pereira, and Darryl Bayliss. The developers who gave their insights to this article work in many different capacities and industries; from software agencies, to financial industries, on teams that range from tens to hundreds of developers.
- If you are interested to read more on how Swift can work with the enterprise, check out this Linkedin article on how Duolingo and American Airlines managed their early Swift adoption.
- Check out some in-depth info on security in Apple’s iOS Security Guide
- Find our more about the Apple Enterprise for developers programs.
Share your thoughts on Swift adoption in large, enterprise-based teams below. What kind of experiences have you had with Swift in your organization?
The post Is Swift Ready For The Enterprise? appeared first on Ray Wenderlich.