x/mobile: `gomobile bind` produces xcframework incompatible with new Xcode 15.3 requirements for iOS builds

[scosman]

Go version

go1.22.0 darwin/arm64

What did you do?

gomobile bind to produce a xcframework

What 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: https://github.com/golang/go/issues/66018

However the following tasks fail:

• Debugging on a real device
• Validating an app archive containing the xcframework
• Releasing an app using the xcframework

I've determined the fix, described here: https://github.com/golang/go/issues/66018#issuecomment-2016541996

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 😀

[hajimehoshi]

CC @hyangah @dmitshur

[scosman]

WIP fix: https://github.com/scosman/gomobile/commits/master/

[gopherbot]

Change https://go.dev/cl/574055 mentions this issue: cmd/gomobile: produce frameworks which follow Apple's specs per platform, fixing Xcode 15.3 compatibility issues

[Simon-Zeng]

@scosman This fix should take Mac OS compatibility into consideration too, as reported in #66406 .

[Simon-Zeng]

@scosman For symlinks, There seems to be a mistake using "A": "Versions/Current". Shouldn't it be "Versions/A": "Versions/Current"?

[scosman]

@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: Current -> A

[Simon-Zeng]

@scosman Bundle version and short bundle version in Info.plist is necessary for the iOS archive to pass validation.

[scosman]

@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:

  <key>CFBundleShortVersionString</key>
  <string>1.0.0</string>
  <key>CFBundleVersion</key>
  <string>0</string>

Alternative:

• CFBundleShortVersionString: hardcode 1.0.0
• CFBundleVersion: generated unique random each run. epoch + rand will give generally increasing order, but unique IDs per build.

I'm in favour of keeping it simple though.

[hajimehoshi]

I didn't know that .framework also required version strings. 🤔

Shouldn't CFBundleVersion be in the semantic version like 0.0.0? https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion?language=objc

Also, would AppStore accept an updated .framework with the same fixed version?

[hajimehoshi]

What about using 0.0.[epoch] for both?

Adding a global flag to specify the version would be nice but this would be another task.

[scosman]

I confirmed it fixes validation.

CFBundleVersion is most commonly a single digit build number. It can be x.x.x, but single int is allowed and most common. Spec is "one to three period-separated integers".

How about:

• CFBundleShortVersionString : 0.0.[epoch]
• CFBundleVersion: epoch

[hajimehoshi]

CFBundleVersion: epoch

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, 0.0.[epoch] sounds better. Thoughts?

[scosman]

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.

[hajimehoshi]

The convention I've seen is resetting CFBundleVersion to 0 every time you bump CFBundleShortVersionString, so this wouldn't impact them.

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. https://github.com/fastlane/fastlane/discussions/20743 I don't know the same thing applies to .framework though.

I'll patch tomorrow.

Thanks!

[gopherbot]

Change https://go.dev/cl/575115 mentions this issue: cmd/gomobile: Add CFBundleShortVersionString and CFBundleVersion, fixing Apple validation/distribution