Can I use old frameworks when migrating to Swift 3? - 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

Related

Module compiled with Swift 5.1 cannot be imported by the Swift 5.1.3 compiler

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

Updating Xcode cause fail in loading frameworks

I have updated my Xcode Client to 10.0 and installed all components. Now i have 9 errors in my project (a Swift project, that needs to be converted to Swift 4.2).
I use Facebook and Vuforia framework, and it seems like the problem lies there. I have tried to update the Pods, but this make no difference.
It is like the frameworks cant be read properly, because they are not converted yet. But i cant convert to Swift 4.2 as long as the build faild. Do i need to update the frameworks somehow?

Convert to Current Swift Syntax Failed - "No such module" (Swift 4, Xcode 9)

In Xcode 9, I am trying to do the automatic conversion to Swift 4.
It fails with the following message:
Convert to Current Swift Syntax Failed
Please ensure that all selected targets build successfully with the currently configured Swift version before attempting a migration.
It's complaining of a missing module. But when I do a regular build there are no issues. Not sure if this is relevant, but the module (which Xcode is complaining is missing) was already converted to Swift 4 earlier (in it's own project).
Note: No Cocoapods / Carthage used here.
Note: Two solutions tried (and worked) but do not address the underlying issue.
One solution is to do the conversion manually (change Swift version to 4 in build setting and apply Fix-Its one by one until no more build errors).
Another solution is to disable the third party framework (comment out all code where it's used), do the auto-migration, and then re-enable the framework. This could get pretty difficult with bigger projects.
I can't find any solution yet.
For now I fix manually setting Swift Language Version
After changing from 3.2 to 4.0 I compile and fix errors and warnings manually.
I'm waiting for a better solution!
I also got this problem while converting my project to Swift 4.0. Looks like problem appears when you try to convert target which imports a framework which is already in Swift 4.0. At your screenshot you try to convert 'RecipeTextParser' which imports 'SovaTools' which is already Swift 4.0.
I found dirty, but working solution. You can use older(Swift 3.2) version of 'SovaTools' when converting. You should NOT check it's mark in target selection window of conversion tool. Then, when 'RecipeTextParser' will be successfully converted you can use Swift 4.0 'SovaTools' version again.
I got this error and in my case one of my Pods(the one Xcode was complaining about) was a Swift 4 target and the rest were Swift 3.2. Looking at the build logs it looks like Xcode built that framework in one location and was searching for it in another. When I reverted that Pod to an older version(that used Swift3.2) the problem went away. Obviously a Xcode bug. HTH
Just update your pod and it will resolve the issue.
To update pod:
open terminal and go to your project directory
type pod update
This resolved my issue.
Xcode (Xcode 9) language migration feature is not as much accurate that it can migrate your complete code/project from one swift version to another with zero tolerance. It skips few code migration for us (developers). It may be bug or inaccuracy of tool. But you need to put some manual effort also, to completely migrate swift language version for your project/code.
Now, according to your snapshot, Xcode is showing and error for 'RecipeTextParser' framework. I think this is an external/third party framework. Another point to note, you've integrated this framework using CocoaPods:
Any one of following can be reason for failure of code migration:
CocoaPods locks framework (files) for editing. So language migration process may not be able to migrate (or identify) code for external/thirdparty framework.
In general terms, Framework is package of code files, so framework itself may not allow file/source code editing.
Suggestion as solution:
Update your cocoa pods as well as all frameworks integrated using cocoa pods compatible to latest swift language version.
If you've manually integrated/added external/third party frameworks, then you need to update/replace those also.
Some manual effort is required to completely migrate code between swift languages. I tried swift migration with above options and my all projects are now compatible with swift 4.

swift 2.3 to swift 3.0

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

Swift 3.0 will not be 2.2 source compatible... will I have to rebuild my apps?

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.

Resources