iOS Frameworks: To Swift or Not to Swift

by January 8, 2018

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.

For our company this saves them huge amounts of money.

It is truly a win-win-win.

Building a framework? Be smart, don’t go Swift. Not yet.

In the meantime, start your App development with the Mobile API Gateway.