Add workaround to distribute prototype build in synchronized folder Xcode setup

[mokagio]

Somehow, switching to Xcode synchronized folders broke Fastlane's ability to generate the export_options automatically.

As a workaround, we can specify them manually for the time being.

See:

• Demo Project: Convert Groups to Buildable Folder references #676
• https://buildkite.com/automattic/gravatar-sdk-ios/builds/2135/steps?sid=0195d364-32bb-47c4-a10c-0da0a39806ce

---

For the record, I also tried removing the PROVISIONING_PROFILE_SPECIFIER definition in Enterprise.xcconfig. The release xcconfig overrides it, but I thought that maybe the new Xcode setup interfered with Fastlane.

Gravatar-SDK-iOS/Demo/Demo/Enterprise.xcconfig

Lines 7 to 15 in 6c22d6c

	// Fastlane match uses a common pattern to name provisioning profiles, which allows us use this top-level, centralized definition.
	// Each target + build configuration combination will interpolate its bundle id value in here.
	//
	// Note: This setting works in Xcode and it seems like xcodebuild can also resolve it.
	// But once we add Fastlane's build_app (gym) into the pipeline, the resulting provisioning profile value is not interpolated.
	// As such, we have to re-define the value explicitly in each target.
	//
	// Leaving it here for reference in case the Fastlane will be resolved...
	PROVISIONING_PROFILE_SPECIFIER = match InHouse $PRODUCT_BUNDLE_IDENTIFIER

Unfortunately, it did not change the build outcome.

[mokagio]

Unrelated, but I noticed the scheme name here was outdated.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Gravatar Prototype Build by scanning the QR code below to install the corresponding build.

	App Name	Gravatar Prototype Build
	Build Number	2146
	Version	1.0
	Bundle ID	com.automattic.gravatar-sdk-demo-uikit.prototype-build
	Commit	c796623
	App Center Build	Gravatar SDK Demo - UIKit #614

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[AliSoftware]

Added some more links to fastlane issue and Xcodeproj PR to document this even more. Otherwise LGTM.

I'm hoping I'll be able to find some time next week to work on the fastlane codebase and fix that (either land PRs that might fix it already, or fix it myself otherwise + look at other Xcode 16-related PRs…) before doing a new version of fastlane.

No promises about the timeline though, so in the meantime I'm all good with going with this workaround.

[andrewdmontgomery]

Thank you for sorting this!

I am more than happy to merge this and then follow up later with an update to fastlane + removing this workaround.

[andrewdmontgomery]

For posterity, we can revert these commits when fastlane is updated to handle this properly.

We can leave commit 68cb0bfc50590ad0311cc7609920545aa2d3fa0a, as it fixes a scheme name.