Convert Old Xcode Project to New - ios

Let's say I found some source code from 3 years ago but now it doesn't run right due to xcode changes. Is there an easy and quick way to convert an old xcode project to work with the newest xcode?

There is no definite simple way to always correctly uplift an old codebase.
It depends if it's ObjC or Swift.
It depends which version of Xcode you're moving to.
It depends on the libraries the project links against.
etc etc etc.
If you edit your question to be more specific you will get more help.

Related

Xcode editor taking too much time in compiling

I'm a newbie in Swift. I just created a new single view project in xcode9.3 and tried building it and its taking forever to compile.
Why is this so?
I have had something similar to this, and I found that restarting Xcode a few times should solve the problem.
If this doesn't work, you might want to download the latest version of Xcode. As of now, I think the latest non-beta version is 9.4.1.
Had the same issue in the past.
The swift compiler have some issues with specific code styles which makes it sometimes compile files even slower.
In the end we quit Swift as a development language and moved to React Native and back to Objective-C on iOS projects as swift became too cumbersome.
Moving forward, you might want to look at some of guides out there.
This two looks promising.
https://medium.com/rocket-fuel/optimizing-build-times-in-swift-4-dc493b1cc5f5
https://github.com/fastred/Optimizing-Swift-Build-Times
Back when I was working on swift, this was guide we were using as a guideline:
Part 1
Part 2

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

Recommended way to migrate project source code from swift 2.2 XCode 7.3.1 to swift 3 XCode 8?

I have a project which is almost completed in swift 2.2, Now I want to update the code to swift 2.2 to swift 3.0.I am using the Cocoapods for thrid party library integration and need following suggestions:
Should I go ahead update the libraries used first by running pod update? If any lib has not updated to support swift 3 what should i do?
Should I go ahead to update code to swift 3 manually or follow the XCode8 suggestions?
If I directly go for XCode8 suggestions then XCode8 starts giving suggestions to update library source code also.I am searching for the good way to handle all this. Thanks.
There is not a "best" way — as every project is potentially different in how easily it can be converted to an updated version of the language it's written in.
It would be recommended to:
Save a backup copy of the project before attempting to convert/migrate anything.
Follow the Xcode recommendations for updating the code.
Update the dependencies such as Cocoa Pods.
Fix any unresolved issues that might not have worked during the conversion.
Have patience, as often the conversion is not a one-click process.
If some of your libraries haven't been updated to Swift 3.0 then that's no problem, as you can tell the compiler to compiler only that library with the old compiler.
My suggestion, (and indeed how I updated my own projects), is to run the automatic migration wizard. (Editor>Code Syntax>Upgrade to latest Swift syntax). Then you should run pod update making sure to remove any version specifiers in your podfile.
Once you have done both of these things you can open your project and be greeted with a lot of compiler errors, the bigger your project the more you will have; unfortunately this is somewhat unavoidable because the built in migration tool sucks.
Now it is going to be a case of trudging through and fixing these errors, most of them will probably be something really simple like dropping AnyObject for Any, but a few may trip you up.
Now as I mentioned, if a library hasn't yet been updated for Swift 3.0 you can open your Pods project settings and select the library in question. Under build settings you'll find a key called Use legacy Swift syntax. Set this to true and rebuild. This forces the compiler to use the old compiler for this pod only.
I hope this in depth explanation is of help.
I Found some strategy migrating to Swift 3
I migrated directly to Swift 3.0. I use CocoaPods, so I migrated my dependencies first. This means following the steps above for each open source library (or private pod).
So far, the only dependencies I have for this project are my own libraries, which made this quite easy since I control all of the code. However, if you have third-party dependencies, then I would recommend opening an issue on the project to discuss migration plans with the current maintainers. I expect most popular projects are doing something similar to what I described above. For example, AlamoFire has a swift2.3 and swift3.0 branch. If needed, you can fork and migrate third-party libraries yourself — then submit a pull request or use your fork until the maintainers offer a solution. However, you should definitely reach out to project maintainers before submitting a pull request for migration.
Until Xcode 8 is final, you’ll need to point your pods to these new branches:
pod 'MyLibrary', :git => 'https://github.com/username/MyLibrary.git', :branch => 'swift3.0'
This tells CocoaPods to fetch the latest on the swift3.0 branch, instead of the latest published version.
Once your dependencies and Podfile are updated, you can run pod update to bring in the Swift 3.0 versions of each library. Then you can migrate your main app. I suggest commiting all of this migration in a single commit — update all dependencies, migrate your app, then commit — to keep your history clean.
Bugs
Xcode’s migration tool is not perfect.It would sometimes fail to migrate test targets, or only partially migrate app and framework targets. When this happens, you can attempt to run the tool again, but it’s probably best to make changes manually. Here are some of the specific issues that I saw:
Some expressions inside of XCTAssert*() did not migrate.
Some expressions inside closures did not migrate.
Sometimes waitForExpectations(timeout:) did not migrate.
Migrating NSIndexPath to IndexPath when used in certain contexts often resulted in derpy things like (indexPath as! NSIndexPath).section.
Enums with associated NSDate values migrated to case myCase(Foundation.Date) instead of case myCase(Date).
Sometimes optional protocol methods did not migrate, which can produce hard-to-find bugs.
Ref Links :
http://www.jessesquires.com/migrating-to-swift-3/
https://swift.org/migration-guide/

Can I use old frameworks when migrating to Swift 3?

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

Resources