简体   繁体   中英

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:

  1. 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?

  2. 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:

  1. Save a backup copy of the project before attempting to convert/migrate anything.
  2. Follow the Xcode recommendations for updating the code.
  3. Update the dependencies such as Cocoa Pods.
  4. 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/

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM