4 ms·

Maybe someone will explain this to me. Does Swift use this confusing "rapid release" versioning? Does Swift 4 break backwards compatibility with Swift 3? In my

Maybe someone will explain this to me. Does Swift use this confusing "rapid release" versioning? Does Swift 4 break backwards compatibility with Swift 3? In my company people are looking for a language to rewrite some legacy Objective-C to. Swift is often discarded as "unstable" because of these major version bumps. Compare this to Go, which, seven or so years after the initial release is still 1.x and still doesn't break code. I just don't get breaking the language so often. Do people enjoy rewriting code?

saagarjha 9y ago
> Do people enjoy rewriting code? No, of course not. The way I see it, Swift is scared to go the "Java" route where backwards compatibility is valued above all else, leaving the language an antiquated mess.
- jorgemf 9y ago
  I want to know the opinion of managers about what they think when they have to rewrite the app everytime there is a new release. I remember all the time the iOs developer spent with every iOs release. He didn't look any happy
  - eridius 9y ago
    You don't have to "rewrite the app". You run the migrator, then fix up what it didn't migrate. Swift 3 was notorious for having migrator issues, largely due to the fact that it was a pretty radical change and a huge number of method names were changed. Personally, on our hybrid app, the migrator did about 1/3rd of the work, and I did the rest, without any other engineers' involvement. Overall it took maybe 3 days to migrate the whole app.
    - jorgemf 9y ago
      It was a way of talking. I said it that way because the migration to swift and from swift 1 to swift 2 we had the double of developers for iOs than Android and still have to wait for them because of so many issues they were having. Seems like things are not that bad now. But stills scares me that with every new version you lose a developer for some days (or weeks).
      - saagarjha 9y ago
        It really doesn't take all that long. I've migrated apps consisting of 20K-30K lines of code in a couple hours–mind you, many of the changes were not due to Swift 4, but those in the Cocoa/Cocoa Touch Swift overlays.
        jorgemf 9y ago
        I said to swift, I meant from objective-c to swift. And also from swift 1 to swift 2, where problems weren't only the language but the apis an integration with the old objective-c library. I doubt it takes a couple of hours do that stuff (hour project was close to 100k lines, to one day for you), but If it really takes you that short time companies are going to fight hard to hire you!
      - dep_b 9y ago
        The whole 1.x to 2.0 stretch was a rough ride. I had to maintain software without From 2 to 3 was pretty OK since very little changed in the language only API's got updated. From 3 to 4 mainly adds stuff and doesn't break much.
  - s73ver 9y ago
    Saying "rewrite the app" is pure hyperbole. You have a few things to update, but that's it.
adamnemecek 9y ago
Xcode has a migration plugin that's not too bad. The biggest changes are generally for the better so I'm like meh. It's kinda annoying if you have dependencies but maintained dependencies generally migrate very quickly.
Osmium 9y ago
Swift has a clear policy on this, but basically: it's worth breaking things early on rather than freeze in bad design decisions. They provide a code migrator to help with this pain. However, this was only in the early releases. The plan is to stop breaking changes soon and freeze the ABI. They're a little behind schedule for this, but it should happen soon.
- nathcd 9y ago
  To expand on this, from the linked post: > First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a requirement of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the language, and it cannot be delayed any longer. > ... > Module stability is a stretch goal for Swift 5, but even without module stability we can still achieve the primary value of ABI stability.
  - ancarda 9y ago
    >In Swift 5, [ABI stability] is a requirement of the release. Once Swift 5 comes out, does that mean it's "safe" for people to write things in Swift? My company still has apps stuck on Swift 2.x because we simply can't give people the time to fix the hundreds of issues that happen when we try to upgrade the project to Swift 3. Unfortunately the migration tools just don't work and we end up having to either fix almost every line of code or revert the repo. Everyone is frozen on a specific version of Xcode as Swift 2.x isn't supported anymore. It's a complete mess, and hearing year on year "this is the last time we'll break everything" is getting very tiring. For a variety of reasons we're likely to rewrite our app in the coming months. I'm very seriously considering pushing for writing it in Objective-C because it's just more stable than Swift. We can't do a yearly rewrite, especially as mobile is going to be a bigger focus for us this year and next year. Can you promise me if I push for the rewrite in Swift 5 it will be the last time we need to do that (for a reasonable amount of time, say 5 years? Or that changes will be far far more gradual and can incorporate it with our workflow?). If not, we're going to abandon Swift because it's already left a horrible taste in our mouths.
deleted 9y ago
[deleted]
eridius 9y ago
Swift 3 was a major backwards-incompatible change. It came with an automatic migration tool, but the tool only kind of worked. Swift 4 is a much smaller change. There are backwards-incompatible standard library changes, but not on the scope of Swift 3. Again, it comes with an automatic migration tool. I haven't tried it myself, but I'm optimistic that it will work much better, both because they've had a year to fix what went wrong the first time, and because the changes are much much smaller. But Xcode 9 also supports Swift 3.2, which is the same language as Swift 3.1 with some miscellaneous bugs fixed and with the iOS 11 / macOS High Sierra SDKs. Your Swift 3.1 code will likely run under Swift 3.2 with no changes, and any changes that are necessary are going to be strictly due to SDK changes rather than language changes. Xcode 9 also supports mixing Swift 3.2 and Swift 4 modules. You can have your application written in Swift 3.2 and use a library written in Swift 4, or vice versa. This means you have a full year to migrate to Swift 4 (since I assume Xcode 10 will drop Swift 3.2 support, though this is pure speculation).
- randyrand 9y ago
  My biggest issue would be compiled libaries. I come from c++ so updating and recompiling all the libs would be a huge pain. How is it in Swift?
  - eridius 9y ago
    The major goal of Swift 5 is ABI stability. Until then, libraries written in Swift do have to be recompiled with each new version of the compiler.
xenadu02 9y ago
The Swift 4 compiler has a Swift 3.2 mode that is 99.9% source compatible with Swift 3.x. Further you can link 3.2 and 4.0 binaries together. This allows a phased upgrade approach that was not possible in earlier releases. Swift 5 is about having a stable binary interface so you can link against pre-compiled code going forward. In other words a Swift 6/7/8 binary can link against one compiled with Swift 5. The bar for source breaking changes is also much higher than the already high bar in Swift 4. We may not see any source breaking changes in Swift 5.
- kibwen 9y ago
  > Further you can link 3.2 and 4.0 binaries together. Do you have a source for this? This would imply ABI stability, which isn't being promised until Swift 5.
  - slavapestov 9y ago
    Swift "3.2" and 4.0 are really the same compiler, run with -swift-version 3 and -swift-version 4 flags, respectively.
    - kibwen 9y ago
      I get that they're the same command-line tool, but as a bystander that doesn't tell me whether it's implemented underneath as two separate incompatible compilers that are toggled between with a flag. And even if it's a single compiler with mostly shared components, that doesn't have to imply that the binaries that are produced are ABI-compatible between the two. I'm not implying that I cannot believe that this use-case will work, only asking for some assurance from the compiler devs that it does.
      - lyinsteve 9y ago
        -swift-version 3 really just turns on some different paths through the parser and type checker to allow previously-valid Swift 3 code to survive to code generation time. They're both compatible
melling 9y ago
Go has had breaking changes. You had to run a program to fix your source. https://blog.golang.org/introducing-gofix https://blog.golang.org/introducing-gofix Swift 4 had very few changes. Most Swift 4 code “upgrades” without any changes. I’ve got two dozens Swift examples that were easy to convert to Swift 4. https://github.com/melling/ios_topics/blob/master/README.md https://github.com/melling/ios_topics/blob/master/README.md
- comex 9y ago
  Your Go link is from before 1.0. AFAIK, since 1.0 breakage has been very rare.
paulddraper 9y ago
By that logic, Chrome and Firefox are unstable platforms, with major version updates every 6-8 months. Probably no one develops with them.

saagarjha 9y ago

> Do people enjoy rewriting code? No, of course not. The way I see it, Swift is scared to go the "Java" route where backwards compatibility is valued above all else, leaving the language an antiquated mess.

jorgemf 9y ago
I want to know the opinion of managers about what they think when they have to rewrite the app everytime there is a new release. I remember all the time the iOs developer spent with every iOs release. He didn't look any happy
- eridius 9y ago
  You don't have to "rewrite the app". You run the migrator, then fix up what it didn't migrate. Swift 3 was notorious for having migrator issues, largely due to the fact that it was a pretty radical change and a huge number of method names were changed. Personally, on our hybrid app, the migrator did about 1/3rd of the work, and I did the rest, without any other engineers' involvement. Overall it took maybe 3 days to migrate the whole app.
  - jorgemf 9y ago
    It was a way of talking. I said it that way because the migration to swift and from swift 1 to swift 2 we had the double of developers for iOs than Android and still have to wait for them because of so many issues they were having. Seems like things are not that bad now. But stills scares me that with every new version you lose a developer for some days (or weeks).
    - saagarjha 9y ago
      It really doesn't take all that long. I've migrated apps consisting of 20K-30K lines of code in a couple hours–mind you, many of the changes were not due to Swift 4, but those in the Cocoa/Cocoa Touch Swift overlays.
      - jorgemf 9y ago
        I said to swift, I meant from objective-c to swift. And also from swift 1 to swift 2, where problems weren't only the language but the apis an integration with the old objective-c library. I doubt it takes a couple of hours do that stuff (hour project was close to 100k lines, to one day for you), but If it really takes you that short time companies are going to fight hard to hire you!
    - dep_b 9y ago
      The whole 1.x to 2.0 stretch was a rough ride. I had to maintain software without From 2 to 3 was pretty OK since very little changed in the language only API's got updated. From 3 to 4 mainly adds stuff and doesn't break much.
- s73ver 9y ago
  Saying "rewrite the app" is pure hyperbole. You have a few things to update, but that's it.

adamnemecek 9y ago

Xcode has a migration plugin that's not too bad. The biggest changes are generally for the better so I'm like meh. It's kinda annoying if you have dependencies but maintained dependencies generally migrate very quickly.

Osmium 9y ago

Swift has a clear policy on this, but basically: it's worth breaking things early on rather than freeze in bad design decisions. They provide a code migrator to help with this pain. However, this was only in the early releases. The plan is to stop breaking changes soon and freeze the ABI. They're a little behind schedule for this, but it should happen soon.

nathcd 9y ago
To expand on this, from the linked post: > First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a requirement of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the language, and it cannot be delayed any longer. > ... > Module stability is a stretch goal for Swift 5, but even without module stability we can still achieve the primary value of ABI stability.
- ancarda 9y ago
  >In Swift 5, [ABI stability] is a requirement of the release. Once Swift 5 comes out, does that mean it's "safe" for people to write things in Swift? My company still has apps stuck on Swift 2.x because we simply can't give people the time to fix the hundreds of issues that happen when we try to upgrade the project to Swift 3. Unfortunately the migration tools just don't work and we end up having to either fix almost every line of code or revert the repo. Everyone is frozen on a specific version of Xcode as Swift 2.x isn't supported anymore. It's a complete mess, and hearing year on year "this is the last time we'll break everything" is getting very tiring. For a variety of reasons we're likely to rewrite our app in the coming months. I'm very seriously considering pushing for writing it in Objective-C because it's just more stable than Swift. We can't do a yearly rewrite, especially as mobile is going to be a bigger focus for us this year and next year. Can you promise me if I push for the rewrite in Swift 5 it will be the last time we need to do that (for a reasonable amount of time, say 5 years? Or that changes will be far far more gradual and can incorporate it with our workflow?). If not, we're going to abandon Swift because it's already left a horrible taste in our mouths.

deleted 9y ago

[deleted]

eridius 9y ago

Swift 3 was a major backwards-incompatible change. It came with an automatic migration tool, but the tool only kind of worked. Swift 4 is a much smaller change. There are backwards-incompatible standard library changes, but not on the scope of Swift 3. Again, it comes with an automatic migration tool. I haven't tried it myself, but I'm optimistic that it will work much better, both because they've had a year to fix what went wrong the first time, and because the changes are much much smaller. But Xcode 9 also supports Swift 3.2, which is the same language as Swift 3.1 with some miscellaneous bugs fixed and with the iOS 11 / macOS High Sierra SDKs. Your Swift 3.1 code will likely run under Swift 3.2 with no changes, and any changes that are necessary are going to be strictly due to SDK changes rather than language changes. Xcode 9 also supports mixing Swift 3.2 and Swift 4 modules. You can have your application written in Swift 3.2 and use a library written in Swift 4, or vice versa. This means you have a full year to migrate to Swift 4 (since I assume Xcode 10 will drop Swift 3.2 support, though this is pure speculation).

randyrand 9y ago
My biggest issue would be compiled libaries. I come from c++ so updating and recompiling all the libs would be a huge pain. How is it in Swift?
- eridius 9y ago
  The major goal of Swift 5 is ABI stability. Until then, libraries written in Swift do have to be recompiled with each new version of the compiler.

xenadu02 9y ago

The Swift 4 compiler has a Swift 3.2 mode that is 99.9% source compatible with Swift 3.x. Further you can link 3.2 and 4.0 binaries together. This allows a phased upgrade approach that was not possible in earlier releases. Swift 5 is about having a stable binary interface so you can link against pre-compiled code going forward. In other words a Swift 6/7/8 binary can link against one compiled with Swift 5. The bar for source breaking changes is also much higher than the already high bar in Swift 4. We may not see any source breaking changes in Swift 5.

kibwen 9y ago
> Further you can link 3.2 and 4.0 binaries together. Do you have a source for this? This would imply ABI stability, which isn't being promised until Swift 5.
- slavapestov 9y ago
  Swift "3.2" and 4.0 are really the same compiler, run with -swift-version 3 and -swift-version 4 flags, respectively.
  - kibwen 9y ago
    I get that they're the same command-line tool, but as a bystander that doesn't tell me whether it's implemented underneath as two separate incompatible compilers that are toggled between with a flag. And even if it's a single compiler with mostly shared components, that doesn't have to imply that the binaries that are produced are ABI-compatible between the two. I'm not implying that I cannot believe that this use-case will work, only asking for some assurance from the compiler devs that it does.
    - lyinsteve 9y ago
      -swift-version 3 really just turns on some different paths through the parser and type checker to allow previously-valid Swift 3 code to survive to code generation time. They're both compatible

melling 9y ago

Go has had breaking changes. You had to run a program to fix your source. https://blog.golang.org/introducing-gofix https://blog.golang.org/introducing-gofix Swift 4 had very few changes. Most Swift 4 code “upgrades” without any changes. I’ve got two dozens Swift examples that were easy to convert to Swift 4. https://github.com/melling/ios_topics/blob/master/README.md https://github.com/melling/ios_topics/blob/master/README.md

comex 9y ago
Your Go link is from before 1.0. AFAIK, since 1.0 breakage has been very rare.

paulddraper 9y ago

By that logic, Chrome and Firefox are unstable platforms, with major version updates every 6-8 months. Probably no one develops with them.