如何为Objective-C和Swift创建通用iOS库? [英] How to make an universal iOS library for both Objective-C and Swift?

查看:142
本文介绍了如何为Objective-C和Swift创建通用iOS库?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我需要为iOS(框架或静态库 - 我还没有决定)创建一个可以在Objective-C和Swift项目中使用的库。这样做的最佳方式是什么?我看到它的方式我有三个选择:


  1. 在Objective-C中编写库并添加对Swift(桥接标题等)的支持。

  2. 在Swift中编写库并添加对Objective-C的支持。

  3. 在Objective-C和Swift中编写两个库。我真的想避免这个选项。

这里的主要要求是开发人员应该尽可能地使用它。理想情况下,他们应该能够选择他们的语言而不关心,或者甚至不知道图书馆本身的语言是什么。这可以做到吗?



此外,我希望能够使用CocoaPods分发库,如果这有任何意义的话。

解决方案

选项2. 是不可能的(稍后会详细介绍)

选项3。正如你所说,你应该真的避免它。



选项1 是最好的。只需使用Obj-C和Swift设计您的API。这是什么意思?



•不要使用选择器 - 它们不是Swift标准。


虽然确保了应用程序的运行时兼容性,但Swift语言
本身将继续发展,二进制接口也将改变
。为了安全起见,应用程序的所有组件都应使用
构建相同版本的Xcode和Swift编译器,以确保它们
一起工作。



这意味着需要仔细管理框架。例如,
如果您的项目使用框架与嵌入的
扩展共享代码,您将需要一起构建框架,应用程序和扩展
。依赖于
使用Swift的二进制框架是危险的 - 特别是来自第三方。随着Swift的改变,那些
框架将与你的应用程序的其余部分不兼容。当
二进制接口稳定一年或两年时,Swift运行时将
成为主机操作系统的一部分,并且此限制将不再存在。


Peter Steinberger, PSPDFKit 的创始人,也是一个分发为一个已编译的库遇到了同样的问题:他们现在被Obj-C困住了,不能使用Swift


I need to make an library for iOS (either Framework or static library - I haven't decided yet) that can be used in both Objective-C and Swift projects. What is the best way of doing this? The way I see it I have three options:

  1. Write the library in Objective-C and add support for Swift (bridging headers etc).
  2. Write the library in Swift and add support for Objective-C.
  3. Write two libraries, both in Objective-C and Swift. I really want to avoid this option.

The main requirement here is that it should be as easy for developers to use as possible. Ideally, they should be able to choose their language and not care, or indeed even know, what language the library itself was written in. Can this be done?

Also, I want to be able to distribute the library with CocoaPods, if this has any significance.

解决方案

Option 2. Is out of question (described in detail later)
Option 3. As you said, you should really avoid it.

Option 1 is the best. Just design your API with Obj-C and Swift in mind. What does it mean ?

• Don't use selectors - they're not a Swift standard.
Use nullability to convert to optionals
• Closures and blocks may have the same syntax, but there's a slight difference, watch out for that:

Swift closures and Objective-C blocks are compatible, so you can pass Swift closures to Objective-C methods that expect blocks. Swift closures and functions have the same type, so you can even pass the name of a Swift function.

Closures have similar capture semantics as blocks but differ in one key way: Variables are mutable rather than copied. In other words, the behavior of __block in Objective-C is the default behavior for variables in Swift.

Source: Apple's Using Swift with Cocoa and Objective-C - It explains everything in detail.

You can read more here.

When designing such API you have to know how everything is converted, but if you do it right the users won't notice a difference :)

Module File

Make sure your x.framework is shipped with the modules folder and file inside.

New Xcode generates it for you. This way users can use your Obj-C project in Swift without adding it to a bridging file. So they can just import myLib out of the box.

Why not Swift?


Unfortunately, the most sensible way to distribute a compiled library right now is to write it in Objective-C.

And that's because of one big reason: Swift Binary Compatiblity Problem

While your app’s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together.

This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift — especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.

Peter Steinberger, the founder of PSPDFKit, which is also a library distributed as a compiled library has ran into the same problem: they're stuck with Obj-C for now and can't use Swift.

这篇关于如何为Objective-C和Swift创建通用iOS库?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆