iOS Frameworks: To Swift or Not to Swift

Last year we began the Mobile App Services (MAS) project by building foundational API on the back end and started with iOS support as the first supported client SDK.

During that time the decision was made to use Objective-C and not Swift to build our frameworks. The questions came. Why would we do that? Isn’t Swift the great, new, cutting edge language? Isn’t it taking the iOS developer world by storm? Why would you do anything but Swift at this point?

Yes, it is great, new and cutting edge. Yes, it is taking the iOS developer world by storm.

Why would we choose stodgy, old Objective-C when on the surface Swift is the ‘thing’ and has all the momentum?

Swift is a great language. It is the future and a big part of the present for iOS development. It is now open source and it is being targeted for even back end use in several instances.

So why?

It is simple and I will answer the question with another question, or two.

What happened when Swift 1.0 became Swift 2.0 a year later? What is happening now another year on when Swift 2.0 is becoming Swift 3.0?

There were big changes between 1.0 and 2.0, and no backwards compatibility. Developers that embraced 1.0 found their code needed serious rework.

Again, between 2.0 and 3.0 there are huge changes and no backwards compatibility. Again, developers with large Swift code bases are obliged to change their code to keep up.

A year from now, Swift 4.0 will come out. While they say it is planned to have compatibility with 3.0, until that actually happens I don’t think developers should rely on it.

Do you see it?

Like all new software products, it takes time for them to mature to a stable point where it is production grade. In this case production grade in terms of stability and maintainability. In the enterprise space that bar is even higher. Essentially, Swift has not passed that bar at this time.

Another interesting wrinkle with using Swift in iOS frameworks is this:

If you compile your Swift-base framework with one version of the Swift compiler and a user of your framework builds an iOS app in Swift using a different version of the Swift compiler it won’t compile. They need to be identical. And the compiler is changing quickly as well.

That is unacceptable for serious SDKs.

There is a large amount of complicated code in our MAS frameworks. These frameworks need to be solid and maintainable now, not years from now. Our customers rely on our product to be highly stable. If we had to materially alter all this code every year it would seriously degrade our ability to provide that and build the new features customers want. It would also be a huge task for the development team that costs the company a lot of time and money just to maintain the status quo. That is unacceptable to any company.

In short, building your company’s frameworks using Swift would be irresponsible and reckless. It is not in your company’s best interests. It is not in your developer’s best interest, as much as they want to do Swift. It is not in your customer’s best interest.

For our customers, going with Objective-C was the smart way to go to maintain this high level of stability and integrity. For customers that want to develop Swift based applications using our frameworks it is no problem at all. Swift apps can now use Objective-C based frameworks easily, as if they were Swift.

For our developers it was also the smart way to go. They don’t have to do total rewrites of a large code base every year.

Britton Katnich is Mobile Development Manager and Architect at CA Technologies where he is responsible for overseeing the technical team that created the Mobile App Services product.

Prior to joining CA, Britton worked in a variety of mobile client roles including building and managing entire teams of mobile developers, quality assurance and related workers across the iOS and Android operating systems. Britton is also responsible for architecting solutions and remains an active iOS developer at an expert level. Britton has worked on mobile enterprise solutions to widely used commercial apps for such Fortune 500 companies as Staples, Costco, Walmart and Tesco in the United Kingdom. Prior to his life as a mobile developer, Britton spent the first ten years of his tech career architecting and building Network Management middleware solutions at Redback Networks (acquired by Ericsson) for their many Tier 1 telecommunication vendors worldwide.