You can create OBJC design with Swift interoperability in mind (and there are tools that make it easier like NS_SWIFT_NAME ) but I'm not going to cover that use case. I'm only looking at the use case of writing all new code in Swift within a hybrid codebase. Turns out a hybrid codebase is totally possible, and in this blog post I’ll share the tricks I used to design it. And sometimes it just isn't worth the effort.Ĭan we maintain a hybrid codebase? If we start adding new code written in Swift and keep the existing code in OBJC, would it be possible to integrate them together and call OBJC-based components from Swift and vice-versa? Will we have to restrain from using certain Swift or OBJC features in order to be able to use a hybrid codebase? It's tempting to write new code in Swift, but we can't migrate all the existing OBJC codebase quickly. It's more fun to work with, and all the new Cocoa projects are being written in Swift.Īt Shopify, we want to adopt Swift where it makes sense, while understanding that many existing projects have an extensive codebase (some of them written years ago) in Objective-C (OBJC) that are still actively supported. It's a modern language offering syntax constructs encouraging developers to write better architecture using fewer lines of code, making it expressive. It's strictly typed, which means you can prove the correctness of your program at compile time, given that your typesystem describes the domain well. Swift is gaining popularity among iOS developers, which is of no surprise.
0 Comments
Leave a Reply. |