ITMS-90429: Invalid Swift Support - The files libswiftDarwin.dylib, libswiftMetal.dylib, libswiftCoreAudio.dylib, libswiftsimd.dylib, libswiftQuartzCore.dylib, libswift_Concurrency.dylib, libswiftos.dylib, libswiftMapKit.dylib, libswiftObjectiveC.dylib, libswiftDispatch.dylib, libswiftCoreLocation.dylib, libswiftAccelerate.dylib, libswiftCoreGraphics.dylib, libswiftCoreData.dylib, libswiftCoreFoundation.dylib, libswiftUIKit.dylib, libswiftCoreMedia.dylib, libswiftAVFoundation.dylib, libswiftCore.dylib, libswiftFoundation.dylib, libswiftPhotos.dylib, libswiftMediaPlayer.dylib, libswiftCoreImage.dylib aren’t at the expected location
碰到一个上架问题，查找资料后
得知是在app包的最外层存在一个直接暴露dylib，按照官方要求，必须打包成Framework的形式才行。
那么问题转换成把dylib打包成framework，打包现成的dylib成framework需要以下几个步骤
方式一:
直接使用CMake 生成 iOS Framework CMake Framework
该方式需要库的源码
方式二:
- 先用Xcode生成一个framework工程，build出一个release包
- 把dylib变成一个没有.dylib后缀的二进制文件，用这个二进制文件替换第一步framework中生成的二进制产物
- 修改这个二进制文件的rpath.
我们首先来详细讲解
- 生成framework，这一步的目的是为了得到一个framework的目录结构,注意3个点
- 记得把要暴露的头文件拽进来，改成public
- 把库的适配版本改成比你的应用的适配版本要小或者相等的版本
-
不需要签名
我们这一步得到的产物如图
image.png
- 现在我们把我们的libeslog.dylib生成eslog的二进制产物，替换framework的产物，因为真正的代码段数据段符号等数据都在我们的dylib中，framework的eslog里面是空的
❯ lipo -create libeslog.dylib -output eslog
❯ chmod a+rx eslog
然后我们把新生成的eslog替换原来framwork的eslog
注意:
这一步生成的产物的名字一定要和framework的产物名字对得上，framework中有一个info.plist文件，里面有一个字段记录了执行文件名称，这个取名无所谓，但是一定要保证名称都对上
- 现在修改rpath,如果不做这一步，原来的rpath还是指向以前的libeslog.dylib，导入进工程是会dyld not found的
❯ install_name_tool -id @rpath/eslog.framework/eslog eslog
我们重新验证rpath变化
注:
这里有个小坑是修改可执行文件本身的加载路径而非它的依赖库路径是没有办法用
istall_name_tool -change去修改的。
image.png
现在就是一个正常的未签名的framework了，可以给自己用也可以给第三方用了，只需要把它拽进工程,记得embed & singin
重新运行即可正常加载。
