Thoughts on Adopting Swift
A new programming language was by far the biggest conference surprise. Although an interesting development, I think that applying Swift in practice has people asking a lot of interesting questions. Things like, did I just lose my job security? Should I adopt Swift in my project now? Questions that I’m not sure Apple will have direct answers for as I think each team will need to assess their skill and needs when answering the question of timing. Let’s look at the pros and cons of Swift adoption.
Pro: Performant. Granted I’m taking this from the few benchmarks shared during the keynote, it does seem that part of the story behind Swift is that it performs better than Objective-C. Could be a bit early to call this a meaningful benefit, but it probably shouldn’t be discounted - especially since performance can mean so much on a mobile device.
Pro: Accessible. I think this is the truly killer feature of Swift, at least from Apple’s perspective. It brings a truly modern programming language to the platform and gives non-iOS developers reason to take another look at mobile development. For those scared off by C and square brackets, there is a renewed excitement in building out that app idea they’ve been sitting on for a few years. For those developers too proud to use a language without closures and generics, there’s no longer any excuse to stay away. I bet this brings a record year of developer growth on the platform.
Pro: Productive. This is what I’m most excited about. Not sure if it’s my age, but I’m find the most compelling reason to learn a new language is if it can make me more productive. I have spent enough time doing web development to have realized that I don’t enjoy ramping up on new stuff every 5 months - I’d prefer to go rather deep on a killer language and focus on becoming super fast. But I’ve always been about speed. Apple seems to be touting the productivity of Swift, and from what I’ve seen it looks like we’ll be writing a heck of a lot less code.
Con: Context Switching Between Obj-C and Swift. This is big, though it really depends on the situation you’re faced with - more on that below. Again, as a developer trying to ship customer value, I want to be able to write quality code quickly. For my brain, that means I need to stay rather focused on a few things so I can do them well. I think many agree, and that’s probably a big reason why node.js has taken off like it has - javascript everywhere sounds better than writing front ends in a language different from the backend.
I think the pros and cons will carry different weight depending on the situation each developer is facing and the skill set that they carry into their next project. Let’s take a look at some permutations.
New iOS developer; new project. This one is easy. Assuming that it’s just the one project you’re really focused on, then the clear winner is Swift. Apple has sent a strong signal that Swift is the future, so seems silly to start learning Objective-C when you could be getting out in front of the next generation.
New iOS developer; legacy project. This is where things get tricky. If only one dev on the project, it would seem reasonable to assume that the only choice is to learn Objective-C; otherwise you won’t be in a position to refactor old code or fix bugs in the existing code. If part of a team, you could imagine a scenario where the new developer handles more of the new feature work and does so in Swift, but that really opens the team up to risk because the new dev can’t simply jump in and help on the legacy code if required.
Objective-C developer; new project. Like the first case, I think it makes sense to head in the direction of Swift. This will depend on ability and speed of learning, but if you feel you’ll be an iOS developer for years to come, then a new project might be the perfect time to adopt Swift. If you’re part of an experienced team then you’ll need to make it a team decision, but you’ll likely all be excited to check out the latest language to make you move faster. Another consideration here is if you have other legacy apps to support. If so, then you’ll need to make sure you’re up for the context switching.
Objective-C developer; legacy project. This is the toughest scenario of all. What to do with a legacy code base of Objective-C. If you’re part of a team, then it’s important to consider the future of the team members. Are they interested in moving on Swift? Will new hires be easier to grab if Swift is adopted? Will existing team members leave if they’re still writing Objective-C in 2018? It really feels like a good team discussion to have and weigh the pros and cons.
Where do I land?
I end up falling into the category of working on a legacy product with a small team of developers. For me, I think Swift represents a clean new syntax and some new design patterns that hope to make developers more productive. I don’t see it as much more than a speed bump to adopt as I feel that the biggest learning curve in iOS is learning the incredibly vast SDK and mobile programming principles driven by developing on a resource constrained device. I think learning a new language will come along fairly quickly. Although I don’t feel a strong urge to take our legacy apps immediately into Swift, I think I’d be open to deferring to the team (potentially trying Swift as an experiment for a few months to see how we make out).
I do worry about the context switching between Swift and Obj-C, but I think an experimental period will help determine if that’s a real issue. I have had similar context switching in the past where one project was ARC and another wasn’t, or one was iOS 7 only, and one was mostly iOS 6. We also have a rather large app that tends to have some parts which are quite modern and some which have been untouched for years. So we often find ourselves moving between xibs and storyboards or springs/struts versus auto-layout. It has always been my preference to follow Apple’s lead and listen closely to their recommendations. There are usually benefits to adopting the latest tools, techniques and API that they offer. Although not the same kind of context switching, it at least gives me a sense that mixing Swift and Obj-C may not be a major problem.
Interested to hear thoughts from other developers as they think about how they’ll adopt Swift into their projects.