If I could wave a magic wand, I’d push Swift 3.0 out by a year or even better three years and fix Swift 2 as the standard App Store language (and for Linux, and upcoming Windows) exactly as is, barring a few tweaks and fixes over this time.
[tl;dr summary: Make big breaking changes later and once rather than sooner and multiple times. If a delay allows a single stable language transition, it is to be preferred. Aim for post-3.0 language updates to be additive not transformative.]
Swift 2.2 is a great language. It’s amazing to work in. It offers utility and concepts that Objective-C cannot provide. It pushes iOS and OS X development forward in an important and exciting way, affecting development not just on Apple platforms but wherever Swift touches. From first class structure and enumeration types to protocol oriented programming, Swift 2.2 delivers the goodies.
If you need just one compelling single example, take CGRect: Swift 2.2 lets you expand this essential structure with methods and properties that let you center on a zero origin, or scale and transform, or add math to combine instances. It’s so practically useful that going back to ObjC to work in geometry metaphysically hurts.
Swift 2.2 gets it right in so many ways, that it seems ridiculous to throw it away at the end of the year. A language this good should have a lifetime longer than 8 or 10 months. I’d be really happy if at the WWDC keynote, Tim Cook said, “We got it so right, we’re going to stick with Swift 2, let you build your code for long term use, and make sure the transition to Swift 3 will be perfect.”
The move to Swift 3.0 isn’t just going to be disruptive. It’s going to be traumatic. With its expansive renamification and redesigned core types and APIs, Swift 3 is going to be a tidal wave of retraining and refactoring. And with a list of objectives that didn’t quite make the cut, and a laundry list of of items that should have, Swift 3 just doesn’t have enough time or scope to be perfected.
So why not just push it back? Let us devs use Swift 2.2, which is terrific, for a few more years and get Swift 3 right the first time?
It’s not as if Swift Evolution needs to be fast paced and hectic. The bikeshedding, the simple natural discussion overhead, the need to foster a courteous open source community means the natural speed of development has taken a huge hit.
These arbitrary “update every year” advances that Apple has bought into are more than a little ridiculous when it comes to firmware and OS updates; for languages it pushes beyond the practical.
Orson Welles promised that Paul Masson would sell no wine before its time. Apple should take a lesson from Welles and ship no language before the follow-up version has properly evolved.
I want to see Apple slow down, take some deep breaths, and seriously consider letting Swift 2.2 come into its own rather than cutting it down after a few months of use.
As it is, I am constantly having to answer “Is it time yet to switch to Swift?” As this breakneck development continues, I’ve been hesitant to recommend jumping aboard the Swift train for simple practical reasons.
I’d be far more confident with my advice if I could see a 2-3 year window with stable code that could benefit from Swift’s modern language features, and a payoff of investment in training and refactoring that won’t have to be re-addressed with each new beta and each new release.
To paraphrase a line from Aesop, slow and steady really does win the language race.
Like my posts? Consider buying a book or two or three. Thanks!
26 Comments
100% agree, Swift 1.2 was deficient in many ways, but Swift 2.2 is not, it’s terrific.
I concur. Delaying the Swift 3 update will also give Jetbrains devs some much needed breathing room to bring AppCode up to date without fear that their updates will be obsolete by the time they ship.
Well said, Erica.
Oh I disagree. What you are describing is swift 3, a language that fixes many quirks of swift 2, and is intended to be stable and compatible for many years. Staying longer with swift 2 would breed bad habits of relying on those quirks (some of witch where described as “baffling to newcomers”, I mean come on what’s with that first parameter external name crap ?). We can’t let a big corpus of swift 2 grow for years and then hope everyone will go to swift 3, with all the changes.
I would concentrate on making swift 3.0.0 the last big breaking change of the language (for some time), and then iterate with potential additive features or smaller refinements in 3.1, 3.2 etc. (I mean: “lazy” or “@lazy” can wait, it’s not an error-prone transition). By the way I’m kind of sad every time I see a proposal on swift-evolution for a “purely additive” change, and other non breaking changes that really should be pushed back to after 3.0
Slow and steady, yes, but start from the right place.
As things stand, Swift 3 will not be the last version to make breaking changes. One of the goals that has just been pushed back is the overhaul of generics. I can’t see how that will be implemented without being a breaking change.
I would too, but it looks like the Swift development team have decided that it can’t be done within the currently slated time frame for Swift 3. I think Erica is right. Swift 3 should not be released until the team is happy that there will not be more breaking changes in the near future. The only problem is that, in non-Appleland, Swift 2.2 is not production ready, so there would need to be some development effort to get it there. In Appleland, Swift 2.2 is a great language and joy to program in. I used to love Objective-C, but I can’t see myself using it ever again.
This is an excellent idea! ?? I am seriously concerned about the consequences of pushing another major release with subsequent breaking changes in point releases. Swift 2.2 is plenty ready for prime-time. Fine-tune it, yes. But no breaking changes, please! The time for stability is now.
Twitter poll: https://twitter.com/scotteg/status/733012120627875840
Swift 2.2 is awesome except for a few compiler crashes and I agree with you on that. I just wish they improved the compilation performance. For us this is a huge drawback.
[…] Erica Sadun: […]
Objective-C hardly moved for decades and look at all the amazing things Apple and developers have accomplished with it. I really don’t understand why Swift has to move so fast. I just don’t.
Some excellent points here Erica, but given this statement:
> The move to Swift 3.0 isn’t just going to be disruptive. It’s going to be traumatic.
I have to ask… Do you think that because of this fact, it makes more sense to do it sooner while there is less source code to migrate? What happens to 3.0 adoption when there are mountains of Swift 2.2 code out there?
Did the Python community experience this going from v2 to v3? I’m not a Python developer but I recall hearing that it was a massively painful transition that still plagues people even though v3 was released Dec 2008.
What she means is do it once, not twice.
I really like Swift 2.2, but I am absolutely looking forward to all the renamifications and stuff in Swift 3. I’d like some period of stabilization afterwards, though.
I think it’s reasonable to ask whether Apple should take a more slow-and-steady approach at times.
But, isn’t Swift 3.0 going to be the most source-breaking Swift release ever? Would it not be best to make that transition while there is less existing code and training to be invalidated?
I think the core team has done well already by deferring ABI stability. However, I also think the language transformation Swift 3.0 will bring is a more pressing matter at this time, not just because I think the changes bring great immediate benefit to the language but also because I don’t think it’s good to drag out the time we spend writing code that we know will become invalid.
The biggest speed boost to every Swift application will come when core Apple frameworks are refactored, rewritten or replaced with Swift, not Objective-C. Delaying Swift 3.0 directly impacts that long term effort.
No, make the big breaking changes as soon as possible. The longer you wait, the worse it gets, and the more pushback there is against changing something to be better but backwards-incompatible. Look at Python, where 3.0 came out in 2008 and most code is still in 2.7 because upgrading a working system is so painful. Xcode has been great about handling syntax changes automatically for the most part, so churn isn’t much of an issue. The bigger problem is needing to coordinate multiple developers on a single codebase to all upgrade at the same time.
Between the alternative of getting used to 2.2 and then making an even bigger change down the line, versus changing to 3.0 as soon as possible and then still having to do some incremental language fixes latter, I far prefer the latter. That way, all the experience and familiarity that we build up will be far more future-minded, instead of needing to be discarded and relearned.
I appreciate the sentiment but what should actually happen is that Apple should start tightening the valve on evolution proposals. (I understand will happen soon.) I pretty sure a large contingency of the core team does not see Swift as complete without the API guidelines. Holding off on those would be pretty devastating. We would certainly start seeing code bases littered with #if swift(>=2.2) everywhere. If they actually were going to delay by a year, I think even a bevy of currently accepted proposals would need to be reconsidered.
100% agreed. There is no good reason for Swift 3 to come out so soon. It took Objective-C decades for it to advance so far, so I’m not sure why there is such a rush on Swift.
Put those resources in to getting it right. Or, better yet, put those resources in to Xcode and creating new, modern APIs that are designed around Swift.
What I would like is a moratorium on the addition of keywords in Swift. It runs the risk of becoming a language designed by committee, like modern C++. Sometimes, less is more.
“The move to Swift 3.0 isn’t just going to be disruptive. It’s going to be traumatic.”
I think its a bit of an exaggeration. Apple devs have been quite good with writing the migration assistants for migrating from swift 1.0. to 1.1. to 1.2. to 2.x. I don’t think migration to 3.0 will be difficult or very different from migration between previous versions. Granted it will take some time to retrain finger muscle memory when writing API calls, but it’s definitely for the better and I believe the brain will like and stick to it far quicker than forgetting to type brackets and do dot-method-calling when trying to migrate from ObjC to Swift.
On the other hand, I would definitely be scared if Apple brought yearly release cycle to Swift.
if there are painful changes to be done, let’s do them as soon as possible. The language should be more stable afterwards, so Apple should not have any excuses for lack of refactoring in Xcode and stability issues of the compiler and playground. This should also provide a better environment for people like JetBrains and PaintCode, if they know that everything is not going to fall apart again in a year or two.
I agree that Swift 2.2 is a good programming language, but I don’t agree with the idea of postponing Swift 3.
Whoever starts a Swift-2-project today knows he/she will have to change almost every single line of code later — whenever this ‘later’ will be. Some changes Xcode will be able to do automatically, but certainly not all. Is’s only logical *not* to use Swift 2 for a new project right now. Even Apple itself is apparently rather reluctant at using Swift for real world projects.
Developers need a stable Swift 3, and they need it soon. From then on, changes have to be done the Java way, incrementally and with a focus on compatibility — even if the result is somewhat less than perfect.
To make a perfect language, perfect libraries, perfect tools will take forever. And there are always ways to do it even more perfect 🙂
I believe the Swift development needs to be a little more pragmatic. Many changes already done or still planned are certainly fine, but they won’t change the day-to-day use of Swift for app developers. From my point of view, the most important point in Swift 3 is a stable integration between Swift and the existing libraries/frameworks. This will change dramatically from Swift 2 to Swift 3, but it really should not change again afterwards. On the other hand, some super cool generic extensions can certainly wait for Swift 4, 5 or 6.
Apropos refactoring: Xcode 8 really should include refactoring tools for Swift, we will need them urgently quite soon …
PS: Erica, many thanks for you consistent reporting on Swift 3 progress!!
Couldn’t agree more.
I see a lot of comments on this thread expressing the sentiment
I don’t think anybody disagrees with that. The problem is not with doing that but when “as soon as possible” is. In my opinion, “as soon as possible” is “when all the currently identified source code breaking changes are implemented”. This will not be this summer.
If Swift 3 is released on time, I will have to go through all my code and fix the breakages this summer and then again in six months when all the breaking changes that missed Swift 3.0 get put into 3.1. I’d rather do it all once, thank you.
Yes, exactly.
Totally agree.
As my dad would say “measure twice, cut once”, he’s a carpenter.
I’m working on a big project right now and the idea of swift 3 dropping somewhere round October scares me as I’ll probably have to repeat the work twice and wait/pray for third parties to catch up in time.
I’d prefer a nice long 9 month grace period before the official go-ahead for 3.0 just to get it right and make sure all the ducks are in a row.