1

I have a project that was started using swift 2 in xcode 7. I am now using swift 2.3 in xcode 8. When I try to migrate to pro 3 I get several errors no project. Both from the libraries and from my code. First I update my pods and then do an automatic conversion of the project. My doubts are: In case some library can give rise to error I can unlock it and convert? Do I have to prepare something before starting the conversation? In the articles I read about it, I did not say anything else about it. In case you continue using swift 2.3 will you have any future problems?

The application is very large, what would be the best option?

5
  • 1
    We recently went through such a conversion. It was horrific to say the least. We followed a mix of approaches to get it done. Auto conversion, manual code changes, bug fixing and a LOT of testing. Commented Mar 2, 2017 at 16:58
  • 2
    Mozilla has done it recently: mozilla-mobile.github.io/ios/firefox/swift/core/2017/02/22/… In a few words, it may be long and complicated. Swift 4 should allow "old Swift code", but I strongly suggest to use Swift 3 at least, as for the future versions too. Check before hand if all your dependencies (pods for instance, have a Swift 3 version). Commented Mar 2, 2017 at 17:06
  • It's a good idea to have a copy of the project. I have used this option to convert a relatively small app an i needed like an hour to fix all the errors (and many had the option to fix them automatically) Commented Mar 2, 2017 at 17:07
  • An excerpt from the XCode 8.3 Beta 3 release notes: Xcode 8.3 no longer supports Swift 2.3. Please migrate your projects containing Swift 2.3 code to Swift 3 syntax by opening the project and choosing Edit > Convert > To Current Swift Syntax. Commented Mar 2, 2017 at 18:36
  • @breno. I am also working with project 2.3 so many times i tried but getting too many errors . In my project i used carthages & pods. Still in confusion how to update. Have u updated the code. Commented Apr 15, 2017 at 7:54

1 Answer 1

9

Honestly? Any project built with Swift since 2014 should be done with an understanding of code will break with every new version through Swift 3.X. (I'm not at all being critical, just practical.) This year, Swift 4.X is working hard to not break Swift 3.X code.

So with that starting point, here's my thoughts:

  1. Take a backup of a working Swift 2.X app and archive it. Backup that backup.
  2. Accept the price that should have been known when using any version before 3.X - the conversion will be painful and time-consuming.
  3. Wherever possible, do not use third party add ins. They can add to the complexity of migrating to the latest version.
  4. Do consider waiting for Swift 4. I'm not recommending this at all, but saying consider the big picture. But always remember eventually you will have to port things. (The good news is Swift 3 appears stable enough to say future upgrade will not be (at least) as painful.
  5. Consider migrating everything at once. (If you have that golden backup duplicated in several places, that makes it easier.) Yes, there are ways to migrate individual project, files, etc. from 2.X to 3.X - and 4.X (along with what is likely Xcode 9) makes things easier going forward. But only if you are starting from 3.X.
  6. Regards to Swift 2.3... the latest version of Xcode will not compile/build Swift 2.3. Take that as a sign - someday it will no longer be accepted in the App Store. That day may be 2-3 years away (or not), but It's almost 2 years since the promises of ABI and version compatibility were meant for Swift 3.0. BTW, only the latter happened.

EDIT: Regards to point #3 (avoid third party add ins where possible), I found two links expressing the issues that can come up:

Analyzing Third Party Libraries

Avoiding Third Party UI Libraries

Sign up to request clarification or add additional context in comments.

2 Comments

I tend to answer in a "plan for the worst, hope for the best" way. My apps went without hitch - but I had three advantages. (1) I started with the earliest beta of Swift/Xcode possible. While there were issues and changes throughout, I was ready from day 1. (2) My worst area involved CoreImage kernels, and I had a fantastic source who also blogged about what was needed. But most importantly - and I tried to stress this in my answer - I consciously decided to not use any third party code where possible. I do know that's not practical elsewhere, but that's the toughest thing IMHO.
should have just stuck with obj c

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.