Post not yet marked as solved
When attempting to add a recent build to an External test group, I am receiving the error:
This build is using a beta version of Xcode and can’t be submitted. Make sure you’re using the latest version of Xcode or the latest seed release found on the releases tab in News and Updates
This build is a macOS app built with Unity, which is then codesigned, packaged with productbuild, and then uploaded with xcrun altool --upload-package.
The version of Xcode being used was released about a week ago.
Xcode Version 15.4 (15F31d), built of an Intel Mac Mini running macOS 14.4.1 (23E224).
I have seen threads in the past about this, but nothing recent. (1,2)
Post not yet marked as solved
After updating our build server to Sonoma 14.1.1 / Xcode 15.0.1, we have been unable to push builds to the App Store / TestFlight via our Jenkins processes that worked fine prior to the update.
Here are the command and logs for the most recent failure:
xcodebuild -allowProvisioningUpdates -authenticationKeyPath **** -authenticationKeyID **** -authenticationKeyIssuerID **** -exportArchive -archivePath /Users/michael/.jenkins/workspace/fang-develop/NativeBuild/app.xcarchive -exportOptionsPlist appInfoExportOptions.plist -exportPath /Users/michael/.jenkins/workspace/fang-develop/NativeBuild
2023-11-30 17:46:36.511 xcodebuild[22730:1230158] [MT] IDEDistribution: -[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path "/var/folders/8n/fl18cv195kq4g8mm5qmv2qvc0000gp/T/Unity-iPhone_2023-11-30_17-46-36.510.xcdistributionlogs".
error: exportArchive: The operation couldn’t be completed. (IDEFoundation.DistributionCredentialedProviderLocatorError error 1.)
IDEFoundation.DistributionCredentialedProviderLocatorError.providerRequestFailed(Unexpected nil property at path: 'Actor/relationships/providerId')
** EXPORT FAILED **
The appInfoExportOptions.plist is quite bare:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>destination</key>
<string>upload</string>
<key>method</key>
<string>app-store</string>
</dict>
</plist>
A few notes about this:
The issue has been reproduced on a Intel Mac Mini running macOS 14.1.1 / Xcode 15.0.1
A manual archive and distribute action in Xcode on the build system have been successful (but untenable as a solution) to successfully push up the builds.
This failure occurs with using the -authentication___ flags as well as attempting to have Xcode auto-select the proper account. (We have several accounts signed into Xcode on the build server, a few of which have access to several Apple Development Teams.)
I haven't been unable to find anything remotely related to this issue online; except this post from a year ago.
I preemptively filed a feedback about this one: FB13425804
Any help/ideas would be greatly appreciated!
We're in the process of updating an app that we released approximately a year ago -- which had no issues with codesigning and notarization in our last release.
The current version fails at the initial submission process; stating that the file "must be a zip archive (.zip), flat installer package (.pkg), or UDIF disk image (.dmg)"
The process itself we're taking is rather straightforward, and follows much of what I've seen repeated on the forums here.
A few additional details:
The app itself (a Unity project with a lot of content that needs to be shipped with the app) is quite large, weighing in at around 20GB.
Despite this large size, we were able to go through this process in the past with no issues.
I was originally running Xcode 13 on Big Sur, but upgraded to Xcode 14 on Ventura to no avail.
Our notarization script runs the following:
ditto -c -k --keepParent OurAppName.app NotarizationFileName.zip
xcrun notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait
When we add --verbose to the xcrun command; this is our output:
$ Build > xcrun notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait --verbose
[23:01:54.643Z] Debug [MAIN] Running notarytool version: 1.0.0 (27), date: 2023-03-25T23:01:54Z, command: /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool submit NotarizationFileName.zip --keychain-profile OUR_CREDENTIAL_PROFILE --wait --verbose
Conducting pre-submission checks for NotarizationFileName.zip and initiating connection to the Apple notary service...
[23:01:54.717Z] Info [PREFLIGHT] NotarizationFileName.zip is not a zip archive. warning [/Users/michael/.jenkins/workspace/bastion-add-build-tools/Build/NotarizationFileName.zip]: 17179869184 extra bytes at beginning or within zipfile
(attempting to process anyway)
. Err: 1
[23:01:54.729Z] Debug [PREFLIGHT] NotarizationFileName.zip did not pass the disk image potentiality test. Moving on to other tests.
[23:01:54.730Z] Debug [PREFLIGHT] NotarizationFileName.zip is not a flat installer package.
[23:01:54.731Z] Debug [PREFLIGHT] Finished completing determination of file type for NotarizationFileName.zip. Operation took 80ms.
Error: NotarizationFileName.zip must be a zip archive (.zip), flat installer package (.pkg), or UDIF disk image (.dmg)
Usage: notarytool <subcommand>
See 'notarytool --help' for more information.
Post not yet marked as solved
Do any Apple tools exist that currently enable Bulk IAP management?
I have been trying to use the iTMSTransporter, and the following command does respond appropriately, but the metadata.xml that is returned is incredibly bare, and does not include any of the 50+ IAPs we have in our app.
./Transporter.app/Contents/itms/bin/iTMSTransporter -m lookupMetadata -u *** -p *** -destination ~/Desktop/IAP -apple_id *** -app_platform ios -subitemtype InAppPurchase
Post not yet marked as solved
We've created and distributed a Universal app for Intel/Apple Silicon devices, which then gets launched by an Intel-only launcher.
I'm finding that if I launch the app from the launcher, Activity Manager is reporting that it is an Intel application, whereas if I launch it directly, it reports as an Apple (Silicon) application. (Worth noting: this app is completely codesigned/notarized.)
This is definitely odd, because we have other Universal projects that get distributed on different Intel-only launchers (e.g. Steam) and they are properly launched as a native Apple Silicon app.
I apologize that I'm low on information here; happy to do more work to provide additional info.
mcarriere.