Closed 0x5e closed 3 years ago
Chiming in with some unsolicited advice here based on experience with CLOpenSSL...
It is possible to host binaries in GitHub releases and download them during CocoaPods builds using a custom script then mark them as vendored. Unfortunately, CocoaPods does not expose much details about a build so you can't download a version for only particular platform or architecture. However, given the rise of XCFrameworks that point is moot.
Switching to Xcode 12 for Apple Silicon support, building the ARM64 slice for macOS, and switching to the XCFrameworks is quite a lot of fundamental changes. Any of then alone can cause incompatibilities.
For example, Themis which uses CLOpenSSL has not made an XCFramework switch, and that has broken iOS Simulator builds with Xcode 11. Therefore we made a conscious decision to make the new version a flag day. That is, users requiring Xcode 11 support were asked to use an older version until they are ready to upgrade.
It's not an amazing stance for a security library, but maintainers' time is limited. Given that Apple does not really support older Xcode versions, upgrades sometimes require upgrading your entire OS, and users are often upgrading to the latest version right away... In this kind of ecosystem it is at least not deplorable, in my opinion, to support only the latest toolchain version.
The git repo size growth is concerning, also I have a feeling the tools are not fully ready for a different distribution, eg.: Swift Package Manager in Xcode has issues when artifacts are downloaded (from my experience with another project). Cocoapods (as @ilammy) mention doesn't support fetched binaries out of the box. Probably (of irony) Carthage is the best suited for the task.
Therefore we made a conscious decision to make the new version a flag day. That is, users requiring Xcode 11 support were asked to use an older version until they are ready to upgrade.
I agree with that. It's too much hassle to try to support Xcode 11 with such fundamental changes.
I'm a closed source SDK developer, distribute binary framework using CocoaPods http url, this really solved my problem.
And my SDK users, they may develop a App, or develop a SDK based on mine SDK, for their users. Any compatible problem will cause a big problem, I can't force my users or user's users to do things although that is reasonable.
I agree with not support Xcode 11 with big changes. In the future, if Xcode not making big changes, Xcode version for building the OpenSSL should match AppStoreConnect minimal requirements, is that okay?
distribute binary framework using CocoaPods http url, this really solved my problem.
what do you mean, is there a way to provide binaries with URL in podspec? am I missing something here?
@krzyzanowskim yes, here's the doc and example:
https://guides.cocoapods.org/syntax/podspec.html#source
https://github.com/tuya/tuya-home-ios-sdk/blob/main/TuyaSmartUtil.podspec
thanks! I guess this can be done using Github release archives.
@0x5e https://github.com/krzyzanowskim/OpenSSL/commit/bb6620fd32186c34b29ba6822d7490db58b908ed this should do the job for CocoaPods
@krzyzanowskim Yes, this will reduce the download size during pod update, but repo size is still growing...
yea, I'm going to leave it like that for now though. I want to have full control over binaries
Alright :-)
Hi krzyzanowskim,
Currently, I have two problems:
Maybe we can put binary in Github Releases, using Github Actions to select Xcode version & complete the build process. This is my early try using github actions. If you agree with me, I will make a pr later.
https://github.com/0x5e/OpenSSL