We settled on a combination of ‘per-layer’ and ‘per-functionality’ conversion, since the thought of doing it all in one shot and dealing with days of compiler issues seemed potentially detrimental to our health and sanity. But where do you start? Is it best to convert everything at once and then solve the integration issues, or is it better to convert one piece at a time while ensuring the project compiles and runs between stretches? So the decision was made: we wanted to bring the project up-to-date by converting all the Objective-C code, and replacing old frameworks along the way if possible. For a project that was going to be in active development for the next years, we really wanted to rid ourselves of annotations and `NSObject` subclasses if not for purity, then just for peace of mind. Not only that, but the compiler insisted on overriding the `initWithCoder` initializers, causing a boilerplate mess. For example, we were using Overcoat for network and parsing (a wrapper that uses AFNetworking and Mantle), meaning that new API models still had to subclass `MTLModel` and use `NSObject`-backed field properties structs and native Swift types were not an option. The crux comes down to when you want to use Swift’s modern features for functionalities that depend on existing ObjC systems. The urgency to convert the project would not have been as aggravating had Xcode done this job correctly.
#Objc to swift converter code
The autocomplete is useless at best, and the compiler red-marks all bridged code as ‘unknown receiver / no visible until you compile and run, making it a challenge to narrow down syntax errors or get the function signatures correct. While bridging is a quick way to interoperate between the two languages, it is unfortunately let down by numerous bugs in Xcode. Seems simple enough, but you can already see the inconveniences. Since most Swift developers came off Objective-C, working with both in the same project is often common practice: use the provided bridging headers, annotate Swift methods and properties with and ensure that you use ObjC-compatible types. Although this is initially satisfactory, it became apparent that this project would not remain sustainable throughout the next few years.
Integration with older functionalities was done via the various bridging technologies provided by Xcode. Once Swift 2.0 was out, new functionalities were implemented in the new language. Although excited to explore and develop in this new language, we felt that it would be best to wait for the next iteration - such that our developers could get accustomed to it, and for Apple to iron out any early adopter issues. A long-standing client of ours, a commercial market leader, has had their business-critical application in active development since 2014, which you’ll remember is when Swift first made its appearance.
0 kommentar(er)
