Why rewrite code if it isn't broken?
Currently, Swift is being hurt by incompatible changes between 1.x and 2.x. There are expected more incompatible changes between 2.x and 3.x.
If Apple had significant investment in Swift apps, they would not be making breaking changes so lightly. Because they don't, breaking changes are expected and why should be you the one, who is constantly rewriting the app you have?
TL;DR: it hurts the adoption of the language.
After 3.x, their won't be huge breaking changes thankfully.
Personally, only issue that bugged me was slower compilation time.
About significant investment, this is just how Apple is. They don't stop the train for anyone, it's get on or off. Same goes for SDK you compile against, certain features you must bake in etc.
Objective-C is 33 years old, I don't know for sure but I bet it wasn't that stable at the start!
You generally want to show dedication to a platform with sane means. Not by writing multi-million line codebases, and creating new bugs, cut-down features and delays in the process (a la FCPX, which was in the same language as 7, but still a total rewrite).
>If Apple had significant investment in Swift apps, they would not be making breaking changes so lightly.
And the language wouldn't have fixed its early mistakes and matured. Which is what they did with 2.0 and plan to do with 3.0 -- at which point they promise stability.
In general you want to stop making incompatible changes when you have finalized a good design and fixed all the major pain points from the early releases that the community brought forward.