CODEWITHSUNDEEP
iosswiftstaticframeworks
Cindy
Cindy

Reputation: 57

Swift framework or Objective-c library

Our team will need to update a library that was written in obj-c and has been distributed to other iOS developers in the past. We are evaluating if we should go with Swift framework in this update. We all look forward to using swift but hope to get insights on how easy it can be adopted given our potential developers may use swift, obj-c, or a mixture in their projects. By the time we complete the update we plan to support iOS8 and above only. Any insight/suggestions are very much appreciated.

Upvotes: 0

Views: 141

Answers (2)

Rob
Rob

Reputation: 437542

At the very least, I'd recommend auditing the existing library for nullability, as that will yield a more logical Swift interface to the Objective-C framework.

I wouldn't advise porting to Swift just for the sake of porting to Swift, but rather only if there's a compelling advantage. But a well-written Objective-C framework can generally be used perfectly well in Swift apps.

Upvotes: 1

Laurent Michel
Laurent Michel

Reputation: 405

I have a library that's 90K loc written in Objective-C and still based on MRC (But compatible with ARC). It took me a week to do minor adjustments in the header files with method names and annotations (such as __nullable) to bring the codebase to a state where I could write demo client program in Swift. The demo program look completely natural. The integration was fairly seamless, only a few subtle points with ARC to address. Bottom line, I wouldn't necessarily convert an existing framework and rewrite from Objective-C to Swift. The two languages integrate beautifully and we are doing fairly sophisticated design that use the full array of OO design patterns and make extensive use of closures (blocks). And everything works flawlessly with Swift closures seen as Objective-C blocks. That's a few hundred classes and a few thousands methods.

The addition of __nullable __nonnull annotation proved important to avoid optional types and their explicit dereference throughout (lots of types with ! at the end!). That was the biggest change.

Don't change what is working. Your framework will look native to Swift users.

Upvotes: 1

Related Questions