Every day, more and more developers are being hired based on their Swift skills. Apple is committed to Swift and Swift is the future. Not a day goes by without some developer wandering by for Swift peer support with “I have to use Swift” because it’s in the contract.
I have shipped only one Swift app for live app store sale and I absolutely love Swift. Everything else remains in Objective-C. And, yes, it’s painful to move back and forth between languages. As my brain trains for Swift, my Objective-C reflexes are taking a big hit.
Swift, despite migration support and ever increasing stability of language fundamentals, is not stable or will be for a while to come. So how do you break the news to your client, your boss, or that new guy on your team who saw a few WWDC videos that Swift is better suited for a long-term investment than short-term development tasks?
From a smart manager’s point of view, existing code bases, a known stable development path, and a pool of trained developers is more valuable than a scary new language still in development. The lower the risk of failure the better: deadlines are everything when it comes to bonuses, promotions, and job stability. When you have a stable Objective-C code base, why risk your credibility, your job, and your career for an unstable language and API? Experienced managers are the easy sell.
But more and more, people are coming to me and saying, “It’s next to impossible to explain this and sell Objective-C inside any large group or corporation. They look at you as if you’re crazy. Apple says Swift is now. They don’t get the push back.” Apple’s message of “Swift now. Swift for production” is becoming a big issue for developers.
Unless you can express a strong message of investment, stability, risk, and reward you’re going to be in trouble. I’m not saying “Don’t develop in Swift.” For many developers, the language benefits outweigh the refactoring costs that will be incurred over the next few years. It’s the people who don’t see the full picture and timeline that are and will be struggling, the ones jumping in without properly seeing warning signs.
It takes a good six months or so to retrain your brain into Swift development patterns. It will take several more years for the language to stabilize. When you think “Swift”, you shouldn’t be thinking quick-hit-then-walk-away projects. A Swift project means a long term commitment, unless you never plan to re-use any source code, fix any bugs, or provide any upgrades to your apps.
This isn’t the first time the industry has met this issue: think about how C# developed over its first decade. I’m told that many programmers found little projects, worked through them, and gradually built libraries and codebases to minimize maintenance costs over time. Now, as then, training and acquiring developers in anticipation of language stability is and was a challenge.
It comes down to this. If someone is pushing hard for Swift for full apps or critical production code, make sure they know the commitment they’re buying into with associated migration and core refactoring costs, such. Otherwise, Objective-C is still, and will continue, delivering product.
Thanks Mike Prenez-Isbell, Director of Mobile for Univision Television, and the other unnamed developers who spent time chatting with me about this topic.
18 Comments
Another tangent on this topic to consider; if you are building stuff in Swift for a client now, be more cautious on features you adopt to minimize migration later. I’m on a large project that started using Swift almost at launch, but we were careful about moving into Swift gradually and letting new features bake for a while, and as a result we’ve had no more than a few hours so far of migration between Swift versions.
I think Swift can be a great choice to start with now, just be mindful of how the language will evolve as you build today – even easier now that the evolution is public!
What do you mean by “stable”? It’s a dead language that will not change? You don’t want to deal with migrating Swift 2.x to 3.x code so you’re better off in the dead language because you won’t have to touch the code again?
Stable means that your source code won’t break with new changes and it will keep on compiling. Obj-C has introduced many new features over past few years: properties, literals, blocks, ARC, light generics, etc. These are huge, but none of them broke existing code. Thus ObjC Is live, evolving and stable.
Ok, so we all agree that Swift will have breaking changes. Of course the importance on that debatable. If you are uncomfortable with that then, sure, avoid using Swift. It is certainly not a deal breaker for many developers. I’d rather have 100,000 lines in more safer, more maintainable Swift than in Objective C. Also, my bet is the amount of work writing Swift then porting it to the next version is less work than writing Objective C, which is still quite verbose with all those header files, @properties, and code in general.
NSString *s = @”Swift is the future”;
UIViewController *vc = [[UIViewController alloc] init];
NSArray *names = @[@”John”, @”Paul”, @”George”, @”Ringo”];
NSMutableDictionary *dict =
vs
let s = “Swift is the future”
let vc = UIViewController()
let names = [“John”, “Paul”, “George”, “Ringo”]
You are not factoring in the sheer amount of time it takes to properly convert and maintain code, nor the points that Erica raised about switching mental models. These things take time and effort, and thus money.
OK, so you love Swift. That’s great. But Swift is still essentially in Beta. Meanwhile, our apps have to go OUT of Beta and in to the real world, hopefully on time and on budget.
Of course I factored it in. Converting Objective C to Swift is not difficult. Of course there’s absolutely no need to convert the code. You can simply write new code in Swift:
extension MyViewController {
}
Switching context is painful. You are digging a bigger hole by sticking with Objective C for the next 12 months. You are making the case to switch early or stick with Objective C forever. Since the same functionality in Swift is 30% smaller, the extra code you don’t write in Swift is also money you save.
Simply look at this code:
@import UIKit;
#import “ViewController1.h”
#import “ViewController2.h”
#import “MyDataModel.h”
NSString *s = @”Swift is the future”;
UIViewController *vc = [[UIViewController alloc] init];
NSArray *names = @[@”John”, @”Paul”, @”George”, @”Ringo”];
NSDictionary *ages = @{@”John”: @(1940), @”Paul”: @(1942), @”George”: @(1943), @”Ringo”: @(1940)};
vs
import UIKit
let s = “Swift is the future”
let vc = UIViewController()
let names = [“John”, “Paul”, “George”, “Ringo”]
let ages = [“John”: 1940, “Paul”: 1942, “George”: 1943, “Ringo”: 1940]
Swift is less visually noisy. Now, image 100,000 of code of each language. Which is more maintainable? Less code and more maintainable code directly translate to a cost saving.
I’m going to put my argument in a blog where I can update my answer. I’ve heard it all before. The “old guard” is wrong on this one.
https://h4labs.wordpress.com/2016/02/09/should-i-use-objective-c-or-swift-for-writing-ios-apps
@h4labs I tend to agree with what you have said. I started my first production app with Swift 1.1. I upgraded it first to Swift 1.2. No major issues. I don’t think anything broke. The migration went smooth. Then, I upgraded the app to Swift 2.1. This was a more involved migration, but Apple’s migration tool took care of a large portion of it. I had more manual migration to do, but I expected that. It was a semi-major update to the language. My app does some low-level binary data packing, Bonjour, TCP/IP networking (using CocoaAsyncSocket), and uses a proprietary 3rd party Objective-C dynamic library. I expected any major problems to be in those areas of code. In fact, there were little, if any changes required in that code. It just worked. Now, my opinion might change when Swift 3.0 is out and I have to do that upgrade, but I doubt it. Luckily, the code base size of this particular app is not that large. I can see where chasing Swift version upgrades would be more of an issue with much larger Swift app projects.
TBH, I don’t care if you think in terms of “old guard” or not. I don’t see myself as “old guard”, “new guard” or anything in between. But I develop for a living. I don’t develop FOR Swift or Objective-C. I develop PRODUCTS that use certain languages and tools. I’m in business, therefore I use the tools that are most cost-effective for me, over a range of criteria. These include memory burdens, paradigm shift burdens, the tug of novelty vs the tug of conservatism, dealing with Beta issues, etc.
If you want to use Swift, nobody is stopping you. If it’s right for you, it’s right for you. But unless you want to pay my bills for me, I’m not going to listen to you if you tell me I’m “wrong” without valid reasons beyond “Swift is easier to write”.
if you care about what’s best for you and not for your clients, that’s up to you. When your competition is able to deliver more reliable product in less time, thus costing them less, you might find you’re customers looking elsewhere. They don’t care if you’re too lazy too learn something new. Time is money.
Very good post. Swift is an exciting language, but as I shared in my blog (https://www.mikepolinske.info/blog/2016/02/08/when-your-client-demands-swift-erica-sadun/) I really think Apple should have deprecated the features removed from Swift 1 when they introduced Swift 2 instead of totally removing them.
As someone who has introduced a lot of Swift into a large project over the last year, I disagree; if some of the other stuff had been merely deprecated it would have remained, growing technical debt and making the code harder to maintain in the future. The update tools have by and large worked pretty well to migrate to newer versions of swift, and the parts that did not didn’t take much time to re-work slightly and were better for it.
Just like in app design it’s better not to leave a user with too many ways to do something, in language design I feel like it’s important to clean out cruft early and move forward so that programmers generally have a better codebase.
Can you imagine what it would be like if several variants of range definition were still around? No thanks!
Good points. That’s why it’s important to comment on and document your code. I haven’t used Swift much myself as my day job has been keeping me too busy, but I had just started learning Swift 1 when Swift 2 was released and it was a little hard to really get into it when it’s such a moving target..
I would suggest continuing on your learning path and not worrying too much about the moving target. Each update so far has been incremental and you won’t have to experience the Swift version changes until you update your dev environment (Xcode, iOS). Once you decide to do that, run the migration tool (which, as @ktest098 said, has been very good to date) on your code. This is a good way to learn about Swift version changes and new features. Note, the next migration to 3.0 is going to be a significant. If I were just now learning Swift, I probably would not wait for 3.0. Get going and learn the base language. There’s more to learning Swift than just learning the syntax. With Swift, I am still learning to “think different” (coming from many years of Java).
FWIW, I’ve been using Swift for my own projects since its introduction, and I have yet to encounter a situation where Xcode wasn’t capable of updating it automatically. Not saying it can’t happen, but so far the conversion scripts have worked 100% for me.
-jcr
I have to strongly disagree with this sentiment, mostly because I believe the main thesis of “…is not stable or will be for a while to come” is very misleading and will do a disservice to developers who could greatly benefit from using Swift.
While technically correct on Swift being in flux, the amount of _breaking_ changes an iOS developer can expect are extremely limited. A var++ here or a foo.count there, or in absolute worst case minor grammatical updates to Foundation/UIKit – but nothing that a cup of coffee’s worth of time won’t fix. Shiny new features, of course, can be adopted whenever.
Maintaining an app of over 400 Swift files and 800 Obj-C files, I can attest that the only real pain we ever felt was in the early days of SourceKit crashes and slow build times – which have become non-issues as the toolchain has greatly matured.
Alternatively, I cannot recommend enough the benefits in safety and productivity Swift provides _today_. Generics and protocol extensions in particular have been paying dividends for months.
Here’s another group that happily and successfully started using Swift: http://codevoyagers.com/2016/02/09/transitioning-from-objective-c-to-swift-in-4-steps-without-rewriting-the-existing-code
[…] Source: When your client demands Swift — Erica Sadun […]