I want to use a ci_script to change the CI_BUILD_NUMBER to a new value. But in XCODE CLOUD there seems to be no programmatic way to change it?

I'm building a Unity application for ios that also communicates with Firebase (and GDrive, if it makes a difference, as well as some other servers). When running it through Unity Build Automation with fastlane, this is what it's failing on. Help? inline-code[2024-04-10T09:53:11.680Z] - 7.4.1.2.7.4 - [0;36mINFO [0m: SwiftCompile normal arm64 Compiling\ AsyncAwait.swift,\ Result.swift,\ Storage.swift,\ StorageComponent.swift,\ StorageConstants.swift,\ StorageDeleteTask.swift,\ StorageDownloadTask.swift,\ StorageError.swift,\ StorageGetDownloadURLTask.swift,\ StorageGetMetadataTask.swift,\ StorageListResult.swift,\ StorageListTask.swift,\ StorageMetadata.swift,\ StorageObservableTask.swift,\ StoragePath.swift,\ StorageReference.swift,\ StorageTask.swift,\ StorageTaskSnapshot.swift,\ StorageTaskState.swift,\ StorageTokenAuthorizer.swift,\ StorageUpdateMetadataTask.swift,\ StorageUploadTask.swift,\ StorageUtils.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/AsyncAwait.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Result.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Storage.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/StorageComponent.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/StorageConstants.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Internal/StorageDeleteTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/StorageDownloadTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/StorageError.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Internal/StorageGetDownloadURLTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Internal/StorageGetMetadataTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/F... [2024-04-10T09:53:11.680Z] - 7.4.1.2.7.4 - [0;36mINFO [0m: torageTokenAuthorizer.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Internal/StorageUpdateMetadataTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/StorageUploadTask.swift /opt/workspace/workspace/arpalusdev.productrecognition.ios-provisioned-app/temp20240410-3408-1mgvzme/Pods/FirebaseStorage/FirebaseStorage/Sources/Internal/StorageUtils.swift (in target 'FirebaseStorage' from project 'Pods') [2024-04-10T09:53:11.680Z] - 7.4.1.2.7.4 - [0;36mINFO [0m: (2 failures)

Hello, we recently added a build plugin to our swift package and we have a Xcode project that uses the swift package as a dependency and we build that Xcode project from the command line using xcodebuild build-for-testing. After we added that build plugin to the swift package, xcodebuild now fails and says this: If I remove that build plugin from the swift package then xcodebuild build-for-testing will build successfullly. It is also worth noting then when we run the xcodebuild build-for-testing command we pass in multiple -destination flags. If we pass one -destination flag then xcodebuild succeeds even with the build plugin. So it seems like the issue is around having multiple destination flags and a build plugin added. This sounds like a bug within xcodebuild. Any thoughts or ideas on why this isn't working would be helpful! Here is an example of what our full xcodebuild command looks like: xcodebuild build-for-testing -project “SomeProject” -scheme “SomeScheme” -configuration Debug -destination ‘SomeDestination1’ -destination ‘SomeDestination2’ -destination ‘SomeDestination3’ -disableAutomaticPackageResolution -onlyUsePackageVersionsFromResolvedFile -skipPackageUpdates -skipPackagePluginValidation -allowProvisioningUpdates DEVELOPMENT_TEAM=SomeTeam Thank you!

I want to integrate an apple pay account on the website, but on the point where I am validating merchant that return "false" responses . I already followed the documentation and tried many times but still did not resolve it. Please help me to resolve this issue. so that i can integrate apple pay for heartland. here i mentioned my block of code where i am verifying merchant, please help to fix this. server side code: (PHP): $merchantSession = fetchAppleMerchantSession($validationURL); echo json_encode($merchantSession); function fetchAppleMerchantSession($validationUrl){ $cert_url = base_path('cert/merchant.pem'); $cert_key = base_path('cert/merchant.key'); $data = [ 'merchantIdentifier' => 'domain.com', 'domainName' => 'domain.com', 'displayName' => 'Disp Name', 'initiative' => 'web', 'initiativeContext' => 'domain.com' ]; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $validationUrl); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data)); curl_setopt($ch, CURLOPT_CERTINFO, true); curl_setopt($ch, CURLOPT_VERBOSE, true); curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2); curl_setopt($ch, CURLOPT_SSLCERT, $cert_url); curl_setopt($ch, CURLOPT_SSLKEY, $cert_key); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); curl_setopt($ch, CURLOPT_HTTPHEADER, array("Content-Type: application/json")); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $res = curl_exec($ch); curl_close($ch); $result = json_encode($res); return ['data' => $result, 'status' => false]; } client side code (JS): // Create Apple Pay session within the user gesture handler const session = new ApplePaySession(6, paymentRequest); // Handle merchant validation session.onvalidatemerchant = (event) => { console.log("event", {event, session}); const validationURL = event.validationURL; fetch('gp_applepay_validate.php', { // Replace with your server-side validation endpoint method: 'POST', headers: { 'Content-Type': 'application/json', 'Access-Control-Allow-Headers': "*" }, body: JSON.stringify({ validationURL }), }) .then((response) => { console.log("response.json()", response); return response.json(); }) .then((data) => { console.log("datappp", data); if (data.status) { event.completeMerchantValidation(data.data); } else { console.error('Merchant validation failed:', data.data); session.abort(); alert('Payment failed: ' + data.data); // Improve error message } }) .catch((error) => { console.error('Error during merchant validation:', error); session.abort(); alert('An error occurred during payment. Please try again later.'); // Generic error message for user }); };

On our CI (GitHub Actions) we are signing our .ipa with codesign and after that uploads the resulting .ipa with altool to TestFligt. The problem is that the entitlements added by codesign no longer appear when we view the build on TestFlight. The app requires entitlements for push notification and for associated domains. codesign -s Distribution prod.entitlements prod.ipa Immediately after we do a codesign --verbose --display --entitlements - and the entitlements show fine. Next command is xcrun altool --upload-app --type ios -f prod.ipa --apiKey $api_key_id --apiIssuer $appstore_api_key_issuer To us it seems like altool strips the entitlements from the .ipa. What are we doing wrong?

I'm working on some apps at the minute, with the intention of running a lot of automated UI tests. Xcode cloud looks great and has a lot of integrated features, but having to make sure I don't run too many hours so my subscription doesn't stop mid dev cycle, or getting a surprise large bill etc, are things I want to avoid. Even the cheapest paid plan for a year works out about the same cost as an M2 mac mini, which would probably be significantly faster than the cloud nodes. Github actions allow you to provide your own machines. But actions requires a lot more scripting, and so far they've been very slow to update Macos/Xcode versions (not sure how this will effect supplying own machine). My preference would be to deploy my own machine for Xcode cloud, similar to what we used to be able to do with Xcode server. I think this is currently impossible right? Is there any word that this might be an added feature in the near future?

Hello, I have a swift package that supports visionOS and one of its targets is a xcframework that also support visionOS and when I try to archive that swift package (using xcodebuild archive) I get this error: note: '<xcframework path>' is missing architecture(s) required by this target (x86_64), but may still be link-compatible. (in target '[library name]' from project '<swift package name>') But starting in Xcode 15.2 (I have Xcode 15.4 installed), you cannot develop for visionOS on Intel machines. So why does it require that the xcframework needs x86_64 support for the visionOS simulator? Any help would be great. Thanks!

We have an iOS project that is configured with automatically managed signing. We cannot get automatic signing to work on our CI (GitHub Actions). To even get xcodebuild to archive we have to force it to not sign at all: xcrun xcodebuild \ -workspace app.xcworkspace \ -scheme prod \ -configuration 'Release' \ -destination generic/platform=iOS \ -archivePath ./build/prod.xcarchive \ CODE_SIGN_IDENTITY="" \ CODE_SIGNING_REQUIRED=NO \ CODE_SIGNING_ALLOWED=NO \ clean archive All our attempts to make xcodebuild archive do manual signing have failed. In order to have the app properly signed with the right entitlements we then call codesign: codesign -f \ -s Distribution \ --entitlements prod.entitlements \ ./build/prod.xcarchive/Products/Applications/prod.app Then we export the ipa: xcrun xcodebuild \ -exportArchive \ -archivePath ./build \ -exportOptionsPlist exportOptions.plist \ -exportPath ./build This seems to work so my question is: Is it supported to do manual signing this way? Is there a better way? If we omit the codesign step, the app will still be signed - by exportArchive we assume, but then the entitlements are missing.

This issue started to appear in the last couple of weeks. And it's annoying because Xcode Cloud actually is based on build duration. Here is a sample: The whole build took like 10 minutes. We can easily consume the 25 hours free tier because of these. The crash logs are completely useless. And the failing tests change from one run to the other and on different simulators. I really hope Xcode Cloud team look into this as it's frustrating and kills the whole point of Xcode Cloud (BTW, these issues won't happen on Bitrise).

I'm trying to upload an ipa during CI/CD using the following command: API_PRIVATE_KEYS_DIR=<path_to_AuthKey_<key_id>.p8_dir> xcrun altool --upload-app --apiKey <my_key_id> --apiIssuer <issuer_id> -t ios -f my.ipa But it fails with the following error: Error Domain=ITunesConnectionAuthenticationErrorDomain Code=-26000 \"Failure to authenticate.\" UserInfo={NSLocalizedRecoverySuggestion=Failure to authenticate., NSLocalizedDescription=Failure to authenticate., NSLocalizedFailureReason=App Store operation failed.} I fear the reason is that the altool doesn't support individual API keys, is that correct or am I doing something wrong?