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?
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:
Take a backup of a working Swift 2.X app and archive it. Backup that backup.
Accept the price that should have been known when using any version before 3.X - the conversion will be painful and time-consuming.
Wherever possible, do not use third party add ins. They can add to the complexity of migrating to the latest version.
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.
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.
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
Related
Check several publications with the same compilation error, and it really seems annoying that some libraries do not have support for current versions, well Apple also updates the Xcode many times along with the Swift version. Then after reviewing many publications and research, I discovered this post where they indicate:
Swift 5 provides binary compatibility for applications: a guarantee
that, in the future, an application created with one version of the
Swift compiler will be able to communicate with a library built with
another version. This applies even when using the version
compatibility mode from previous languages (-swift-version 4.2).
In other cases, they indicate using carthage update --platform iOS --no-use-binaries but I am using cocoapod so I cannot use that solution and finally indicate enabling Build Libraries For Distribution, but nothing really worked for me until now and I can't help thinking that maybe tomorrow they will launch swift 5.1.4 and the support they make for swift 5.1.3 is unusable.
I really hope you can help me with the solution to the problem I present with the compilation error and if anyone knows about the post ABI STABILITY
I keep downloading sample codes and many times it says "Unsupported Swift Version 3.x...Use Xcode 10.1 to migrate the code to Swift 4".
Why is it not possible to migrate to Swift 4 using Xcode 10.3 or Xcode 11 beta?
More importantly, I am using Swift 4.2 in my own Project that has several dependancies as well through Pods. If I don't upgrade to Swift 5.1 or later, it seems my own project would start getting such errors in Xcode 12 or so, correct? While I can convert my own code to Swift 5.1, I have no idea if dependencies such as SwiftyDropbox would migrate to Swift 5.1 so easily. What implications it would have for my project in future and what could I do to future proof my project in that case?
Ask Apple. The company has decided – certainly for good reasons – to migrate files only to the Current Swift Syntax. Feel free to create legacy system partitions with older versions of Xcode to migrate code step by step.
The grace period to update the Swift version is long enough to ensure a smooth transition. At least Xcode allows to use the 3 most recent Swift versions in the same project. However you are responsible to maintain the version control. Check the dependencies periodically for updates. If a dependency is not able to release an update within the grace period it's not much good.
I know Swift is not yet ABI stable, but does that only count for major versions of Swift?
Is there any guarantee that minor or patch versions (under semantic versioning) of Swift are ABI stable?
I'm guessing there is no guarantee here, but just wanted to double check if anyone has come across anything detailing ABI stability for different minor/patch versions of Swift.
Also, if I use a Swift binary framework compiled with a different version of Swift I get a compiler error usually. If I don't get a compiler error in my project does that mean it is safe, or could there still potentially be runtime issues with a slightly different (patch version) of Swift?
Update 3
We also have module stability, starting with Xcode 11, with the help of the newly introduced .swiftinterface files. One caveat, though, is that the code will have to be build with the -enable-library-evolution flag. More details here.
Update 2 Module stability is scheduled for Swift 6: https://swift.org/blog/abi-stability-and-more/#module-stability
This is an excerpt from the Swift evolution repo.
Update Swift 5 comes with some ABI stability:
The Swift 5 release will provide ABI stability for the Swift Standard Library.
Unfortunately, not yet. For Swift 4, they state this here: https://swift.org/blog/swift-4-1-release-process/.
Swift 4.1 is not binary compatible with 4.0. It contains a variety of under-the-hood changes that are part of the effort to stabilize the Swift ABI in Swift 5.
Hopefully we'll get ABI stability in Swift 5
I think we should know what is ABI stability firstly, After that your confusion has already been removed.
Today, the latest version of Swift is 3.1, so chances are if you ship an app tomorrow, your app bundle will contain the Swift dynamic libraries for 3.1, however, there are plenty of apps in the store right now which link 3.0, 2.3, and probably even some older apps that link 2.1 and earlier. Nothing is stopping me from downloading your app (on 3.1) and my app (on 2.3) and running them side-by-side on my iPhone with iOS 10.3, since both apps link against their own bundled version of Swift. It's exactly the same as you bundling Alamofire 4.4 and while I bundle 3.0.
When a language is ABI-stable (Application Binary Interface), that means it is packaged and linked with the operating system itself, in this case: iOS. The Swift code you compile on your computer has a binary interface into the operating system itself rather than any dynamic library you bundle with your application. Because of this, Apple has to be able to guarantee that my Swift code, when compiled to machine code (bitcode, LLVM-IR, yada-yada), will be able to interface properly with the rest of the operating system, and (probably more importantly) will not break between versions of iOS / Swift.
As it stands today, the Swift language specification and compiler are not in a state where the Swift team would feel comfortable making this promise of ABI-stability; changes to Swift are still too frequent and the roadmap is still too long. As soon as the Swift library is merged into iOS, it becomes much much harder to make big changes.
Why does it matter?
Yes, the bundle size of your application will decrease because you will no longer have to include the Swift standard library in your Frameworks folder, which is nice.
Language changes will be smaller / less frequent, so you won't have to worry about events like migration from Swift 2 -> 3 (I'm still scarred from that)
Developers will be able to create 3rd-party libraries written in Swift and distribute pre-compiled frameworks (binaries), because they no longer need to bundle the Swift standard library into their framework, and will instead be linking against the same version of Swift as your app (the one packaged with iOS).
I'm currently migrating my project to Swift3 as I know that there is one bug I have under iOS 10 that needs to be fixed.
So I installed iOS 10 on one of my devices.
Now I can't run my app on the device, getting the 'Could not find developer disk image' error.
So I downloaded the latest Xcode8-beta.
Now my code can't be compiled - I first have to convert it to the newest syntax.
So while fixing all the non auto-converted syntax issues, I'm getting errors for frameworks I'm importing, too:
"Module file was created by an older version of the compiler"
Which - to my understanding - means that this framework needs to be recompiled with the current version of XCode.
This would mean that I would have to cross my fingers that all the frameworks I use are up-to-date, or otherwise, fix those, too?
Is it not possible at all to use 'deprecated' frameworks?
Is this Apple being super strict to get rid of any Swift1/2 code as possible?
This would mean that I would have to cross my fingers that all the frameworks I use are up-to-date, or otherwise, fix those, too?
Is it not possible at all to use 'deprecated' frameworks?
Is this Apple being super strict to get rid of any Swift1/2 code as possible?
Yup. Swift 3 is it.
I feel bad for those that had to convert their C code to swift 2, and now swift 3 is coming xD
Hopefully they will make the transition easier with the final release version, and that shortly after that all of the major frameworks will have been updated (for you to recompile).
You need to recompile the frameworks. Even frameworks managed with dependency managers like Carthage (which recompile on each update command) are still having problems with XCode 8 Betas / Swift 3: https://github.com/Carthage/Carthage/issues/1440
http://thenextweb.com/apple/2016/05/09/swift-3-0-developer-previews-wwdc/#gref
Does this mean anything? Will I have to completely rebuild my apps or merely convert 2.2 syntax to 3.0?
Swift 3.0 will not be compatible with 2.2. Here is the list of the current proposals, it also details what has been implemented already, and what will be :
https://github.com/apple/swift-evolution
You will not have to entirely rebuild your App, but you will have to adapt your code.
I'd say no. Every Swift app comes with its own runtime and standard libraries of whatever Xcode version you used to build it. Some of my Swift 1.0 app still runs on the latest version of El Capitan.
Source incompatibility means you can't take valid code written in Swift 2, feed it to the Swift 3 compiler and expect everything to go smoothly. There will be errors and deprecation warnings, much of which you already see today with Swift 2.3.
You also can't take a compiled application written in Swift 2 and make it run without modification on a Swift 3 runtime either. Swift is lacking a stable Application Binary Interface (ABI) at the moment. That's why every Swift app must carry its own runtime. OS X and iOS don't provide those at the system level. Hence Swift app tends be larger in size, more of a problem on iOS than OS X.
With Swift 3, Apple is trying to establish a stable ABI so your compiled Swift 3 can run without modification on the Swift 4 runtime, whenever that comes.
What about source code compatibility? No one knows what Chris Lattner has in mind or what he considers archaic. Removing the ++ and -- operator in Swift 3 seem superfluous to me. And why kill C-style for loop too?
I'm currently adapting all my code to the present state of Swift 3. The existing code is certainly not compatible; most methods have been renamed, case names have been lowercased, and so on. To what extent Apple will assist by providing a migration tool is unknown, as that's in the future.
#CodeDifferent provided a great answer, but I'd like to extend on it.
AFAIK, if your Swift 2 app is compiled with its own runtime linked in (i.e., not relying on the system runtime), then your app will run fine & there's no need to rebuild on a Swift 3 machine to run on a Swift 3 machine. But if there's no runtime compiled into the app, then your app won't run on a machine with a Swift 3 ABI.
Of course, if you are going to compile with application with Swift 3, then you will have to re-build.