Still once you convert the whole project the target logic may be way different then it was in Objective-C.
There is no benefit of porting a well written code, port only the code you wish to continue developing and wish to do it in Swift. If this is a project that is still in development then you should probably exclude modules that will most likely never be modified. So first for each screen and then for each group you will be able to commit and push your changes so other developers may continue working on the project. At this point you will need to migrate the whole group altogether for the procedure to work. It seems for iOS applications that would be starting with view controllers.Īfter you are done with those most straight forward classes you might want to start breaking your project down to groups where each group is as closed as possible and used as least by other groups as possible. You should start with classes, files and modules which are least used by other parts of your project. Some code might change substantially when porting to Swift such as enumerations and class nesting though this is not mandatory at least in first phase.
You don't want to specify it because you will not need it at the end when the whole code is migrated so you should avoid working on the same file twice.Įvery Objective-C file can be used by Swift by simply adding its header into bridging header. When a file is converted into Swift it will no longer be usable by Objective-C unless you specify it to be.
You will need to be converting code basically file by file. If you really must do this then let's look at some facts:
0 kommentar(er)
