OC、Swift混编并使用pod模块化的那些坑与解决方案

  • 如果编译时自动生成的Swift.h报找不到<Product/Product.h>,把<Product/Product.h>改成<Product/Product-umbrella.h>就好了，Xcode的bug。详见这个issue
  • 可以在pod 的demo项目里配依赖pod的:path，避免从网络拉取，加快迭代速度
  • pod spec里resource和resource-bundle是有区别的。resource-bundle会在当前改pod的bundle里再加一个bundle，个人认为不是特别有必要。
  • 如果只需要一个模块里一个子模块，就用在所需模块里定义subspec（比如App Extension里不能有对UIApplication.sharedApplication的依赖，另起一个pod有感觉没必要）
  • 用Swift时NCClassFromString的参数要用 bundle.className， bundle就是pod名或者主项目名，因为这个原因感觉router的action最好使用OC实现
  • 有时候自动生成的<Product>-Swift.h会 #import <Product/Product.h>，然而编译这个文件的时候Product模块还没编译完，直接报错，报错了后把这一行删了就好，目前没找到更好的解决方案。。。。
  • 有些pod有对静态库的依赖，注意 在source_files和vendored_libraries里 都 包括静态库，并且多加一句s.pod_target_xcconfig = { 'OTHER_LDFLAGS' => '"-ObjC"' }
  • performSelector所对应的函数一定要有返回值……不然会崩……
  • 同一个pod里Swift可以直接调用OC，但是OC调用Swift时需要把权限设为public
  • 如果所依赖的pod里有vendored_framework且该framework没有modulemap且又要在swift里调用。。。乖乖写bridge header里吧。。。
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

推荐阅读更多精彩内容