x/mobile: gomobile bind produces xcframework incompatible with new Xcode 15.3 requirements for iOS builds
#66500
Comments
dmitshur
added
the
NeedsInvestigation
|
Change https://go.dev/cl/574055 mentions this issue: |
dmitshur
added
NeedsFix
|
@scosman For symlinks, There seems to be a mistake using |
|
@Simon-Zeng added a comment explaining that above. dst is relative to src. If both are absolute, when the framework is copied, it keeps original path. This keeps it all relative. Result is correct: |
…orm, fixing Xcode 15.3 compatibility issues This patch updates the framework generation code to follow the Apple spec for placing content: https://developer.apple.com/documentation/bundleresources/placing_content_in_a_bundle Previously, we setup the framework in MacOS format, and used symlinks to make it compatible with iOS format. This approach no longer works (it works locally in simulator, but causes signing issues when attempting to upload apps for distribution, or running on real hardware). We now setup the expected bundle format for each platform. Other benefits: - Thirds the size of the xcframework and resulting app binary when distributing the xcframework by zip (common for SPM and other formats). The symlinks resulted in duplicate files after zipping, which made it into the final app. - Set MinimumOSVersion, fixing SPM compatibility issue - Eliminates the blank Info.plist - Initial testing shows this also fixes golang/go#66406 (code signing issues) as a side effect of using the proper format Testing: - Tested all 4 platforms (iOS, simulator, macOS, Catalyst) on Xcode 15.3 Fixes golang/go#66406 Fixes golang/go#66500 Change-Id: I8538989efe67cb0d2d0496087dcbeca923c3dffe GitHub-Last-Rev: 28dca85 GitHub-Pull-Request: golang#98 Reviewed-on: https://go-review.googlesource.com/c/mobile/+/574055 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
@scosman Bundle version and short bundle version in
|
|
@hajimehoshi easy fix if we're okay with hard coded version. Otherwise we need to add a top level command line parameter for version. I'm guessing most folks will ignore the optional param and end up with defaults anyways. Thoughts? Confirmed this works: Alternative:
I'm in favour of keeping it simple though. |
|
I didn't know that .framework also required version strings. 🤔 Shouldn't CFBundleVersion be in the semantic version like 0.0.0? Also, would AppStore accept an updated .framework with the same fixed version? |
|
What about using Adding a global flag to specify the version would be nice but this would be another task. |
|
I confirmed it fixes validation. CFBundleVersion is most commonly a single digit build number. It can be How about:
|
My concern is that if a user wants to give a spcific version later, an epoch number seems too big. So, as a tentative version, |
|
The convention I've seen is resetting CFBundleVersion to 0 every time you bump CFBundleShortVersionString, so this wouldn't impact them. But your way will address those concerns so let's do it. I'll patch tomorrow. |
I thought a new CFBundleVersion must always be bigger than old ones, so resetting 0 didn't work. I might be wrong. EDIT: Yeah, there could an issue with TestFlight. fastlane/fastlane#20743 I don't know the same thing applies to .framework though.
Thanks! |
An app containing a framework can't be validated and distributed without these. Using `0.0.epoch` format per discussion here: golang/go#66500 (comment)
An app containing a framework can't be validated and distributed without these. Using `0.0.epoch` format per discussion here: golang/go#66500 (comment)
|
Change https://go.dev/cl/575115 mentions this issue: |
…ing Apple validation/distribution An app containing a framework can't be validated and distributed without these two entries in the framework bundle's `Info.plist`. Using `0.0.epoch` format per discussion here: https://go.dev/issue/66500#issuecomment-2025767017 Tested Xcode 15.3 with: - without keys, fails to validate - with keys: passing validation, distribution upload, and Apple's server validation ("Ready to test" server check). Fixes golang/go#66500 Change-Id: I2e0718247301ec7db36f8d85aea81b203ca7848b GitHub-Last-Rev: 1455c5e GitHub-Pull-Request: #100 Reviewed-on: https://go-review.googlesource.com/c/mobile/+/575115 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com>
…ing Apple validation/distribution An app containing a framework can't be validated and distributed without these two entries in the framework bundle's `Info.plist`. Using `0.0.epoch` format per discussion here: https://go.dev/issue/66500#issuecomment-2025767017 Tested Xcode 15.3 with: - without keys, fails to validate - with keys: passing validation, distribution upload, and Apple's server validation ("Ready to test" server check). Fixes golang/go#66500 Change-Id: I2e0718247301ec7db36f8d85aea81b203ca7848b GitHub-Last-Rev: 1455c5e GitHub-Pull-Request: golang#100 Reviewed-on: https://go-review.googlesource.com/c/mobile/+/575115 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com> Reviewed-by: Than McIntosh <thanm@google.com>
Go version
go1.22.0 darwin/arm64
What did you do?
gomobile bindto produce a xcframeworkWhat did you see happen?
The output xcframework isn't compatible with Xcode 15.3 (new Xcode release), when used with iOS devices.
It works on simulator now because of a fix I made for: #66018
However the following tasks fail:
I've determined the fix, described here: #66018 (comment)
I believe the fix is to follow the Apple "placing content in a bundle" docs fully. Previously we follow the MacOS docs, then create symlinks from where content is expected on iOS to the MacOS locations. To fix we should follow the right format per platform, without symlinks. We also need to add the new keys.
Open to other suggestions on how to fix. Will try to make a patch next week using approach above if no other suggestions are made.
cc @hajimehoshi @Simon-Zeng
What did you expect to see?
It should work on Xcode 15.3 😀
The text was updated successfully, but these errors were encountered: