Rewriting the entire class in Swift is not the (immediate) goal.You’d prefer to write the new/changed code in Swift. You want to add a new feature to the existing class, or you want to make substantial changes to part of the class.You have a fairly large and complex Objective-C class.
Piecemeal conversion of an Objective-C class to Swift Even though this is a general limitation that doesn’t have anything to do with interoperability, it affects me most when I work on mixed Swift/Objective-C code. I’d like to talk about one such cause of friction in particular that isn’t even directly related to interoperability, and that’s the fact that extensions can’t contain stored properties in both Swift and Objective-C, all stored properties/ ivars must be part of the main type definition. That said, mixing two languages always causes some amount of friction. The interoperability between Objective-C and Swift is generally quite good 1 - in fact, I’m amazed how well Apple was able to make the two languages work together given how different they are. The exception to the rule: when a particular subsystem reaches a tipping point - say, 60 % of it is written in Swift - it can make sense to transition the rest as well in order to minimize pains caused by mixing the two languages. We don’t rewrite existing code in Swift just for the sake of it, but only if a subsystem is due for a major overhaul anyway. We try to write new code in Swift, but about 75–80 % of the code base is still Objective-C. I’m currently working on a fairly large iOS app with a long history.
0 kommentar(er)
