iOS平台实践细节
推荐实践路线
- application: 推荐手动建立工程,方便团队里iOS工程师使用
- sdk: 使用cmake生成,并设置成同手动工程配置,方便application工程师开箱即用
- c++: 使用cmake管理,并通过sdk层引用
iOS的Info.plist如何处理
iOS平台上的Product常见一个Info.plist文件用于描述基本信息
CMake提供了两个基本模版
- MacOSXFrameworkInfo.plist.in
- MacOSXBundleInfo.plist.in
并且可以通过设置一些环境变量填入这个模版, 参考官方文档
1 | set(MACOSX_FRAMEWORK_IDENTIFIER "demo.alanli") |
也可以用户模仿官方模版自己指定模版,并且指定路径
1 | set_target_properties( |
Xcode Generate 生成的工程和手工不一致
在使用Xcode Genreate的时候生成的工程有些选项和手工是不一致的,导致不能当成一个正常的Project来用
两个主要的问题
- Framework不能进行Archive操作
- Dependency和LinkLibrary的关系
解决方案分别是
- 手工生成的Project的Build Setting - SKIP_INSTALL 是YES, 而CMake生成的是 NO
- Xcode的Run指令会自动link已经dependency的target,不需要CMake的指令再link一遍,如果不是Xcode Generate则需要CMake进行Link
列出一份基本的配置表,帮助我们可以还原Xcode11 手动创建的工程配置, 更多细节可以参考源代码
1 | set_target_properties( |
默认是MAC 要设置成iOS
已知的错误实践
由于CMake可以使用Xcode作为Generator,所以大部分开发者会有生成一个TestApp的想法,及通过
1 | add_executable(test_app ${Headers} ${Sources}) |
虽然CMake支持这个功能,但是对于一些细节问题处理的不够好,有三个问题会依次出现
- 通过 cmake –build . 指令编译失败
- 签名问题比较复杂,如果多团队使用不同的证书,通用性比较差
- 无法生成Asset.xcassets 文件,可以通过Resource管理图片,不方便不懂CMake的开发队友
解决这三个问题引入的方法复杂度远高于三个问题本身,所以不推荐使用CMake生成测试用App,尽量采用示例代码的结构
签名问题
根据CMake文档FRAMEWORK的示例代码
1 | set_target_properties(dynamicFramework PROPERTIES |
使用”iPhone Developer”的原因是因为Xcode会自动寻找合适的证书,如果不使用这种通用字符串,可以指定具体的签名文件
根据经验推荐以下两点
- 如果你有App需要源码依赖Framework,不推荐对Framework进行签名,而统一交给App进行签名
- 如果发布的Release产品就是一个Framework必须签名,推荐使用 “iPhone Distribution”,并设置CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM
Swift启用
1 | # 注意要在写add_library add_execute 之前 |
并且Swift因为更新的原因常常会找不到Compiler,需要更新至最新CMake,例如No CMAKE_Swift_COMPILER could be found