This is quite unfortunate. Today, we pass in the allowProvisioningUpdates flag on test, archive, and exportArchive to ensure that 1) the development profile is up to date and 2) the distribution profile is up to date. This does not error when using an account signed into Xcode. The reason we are attempting to use the API is that this is the suggested workaround from FB14060904. What I’m gathering is that the API is not 1:1 with the operations Xcode can do when an account is signed in. If that is the case, I would expect some more descriptive error messages and clarifications in the man page.

I went ahead and generated a new key, but I am still unable to get this to work. The original error is gone, but now I receive a 401 error from the developer portal using Xcode 16 RC (16A242): env NSUnbufferedIO=YES xcodebuild clean archive -workspace MyApp.xcworkspace -scheme MyApp -configuration Release -archivePath results/artifacts/App.xcarchive -destination generic/platform=iOS -derivedDataPath build -allowProvisioningUpdates -authenticationKeyID **** -authenticationKeyIssuerID **** -authenticationKeyPath /Users/MyUser/MyKey.p8 GatherProvisioningInputs 2024-09-12 07:40:48.226 xcodebuild[41720:6825977] DVTServices: Received response for 0119471B-B1ED-435F-B036-97D661247558 @ <https://appstoreconnect.apple.com/xcbuild/QH65B2/listTeams.action?clientId=XABBG36SBA>. Error = Error Domain=DVTPortalResponseErrorDomain Code=0 "Communication with Apple failed" UserInfo={NSLocalizedDescription=Communication with Apple failed, NSLocalizedRecoverySuggestion=A non-HTTP 200 response was received (401) for URL https://appstoreconnect.apple.com/xcbuild/QH65B2/listTeams.action?clientId=XABBG36SBA} 2024-09-12 07:40:48.393 xcodebuild[41720:6825977] DVTServices: Received response for 7A81B4FA-E41E-47BB-9C7A-D641D09BB9C2 @ <https://appstoreconnect.apple.com/xcbuild/QH65B2/listTeams.action?clientId=XABBG36SBA>. Error = Error Domain=DVTPortalResponseErrorDomain Code=0 "Communication with Apple failed" UserInfo={NSLocalizedDescription=Communication with Apple failed, NSLocalizedRecoverySuggestion=A non-HTTP 200 response was received (401) for URL https://appstoreconnect.apple.com/xcbuild/QH65B2/listTeams.action?clientId=XABBG36SBA}

Logged as FB15055171

Logged the documentation gap as FB12236685

I have a similar request. Given the large impact of this change, I would have expected this to be opt-in for a while before this is enforced to give us time to adapt. As of right now, I have multiple apps that are unable to be built for testing iOS 17 due to this. The reference page "Verifying the origin of your XCFrameworks" only seems to refer to XCFrameworks manually embedded in a project and does not provide guidance for SPM dependencies nor CocoaPods.

With iOS 14 beta 4, the error message has changed from Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service on pid 0 named com.apple.OSLogService was invalidated." UserInfo={NSDebugDescription=The connection to service on pid 0 named com.apple.OSLogService was invalidated.} to Caught error: Error Domain=OSLogErrorDomain Code=9 "Client lacks entitlement to perform operation" UserInfo={NSLocalizedDescription=Client lacks entitlement to perform operation, _OSLogErrorInternalCode=14} It doesn't appear that my Feedback (FB7868256) has been looked at, but, is this being fixed?

So having multiple services for resiliency is not supported? Example: nw_endpoint_t cloudflare = nw_endpoint_create_url("https://cloudflare-dns.com/dns-query"); nw_endpoint_t google = nw_endpoint_create_url("https://dns.google/dns-query"); fallbackResolvers = nw_resolver_config_create_https(cloudflare); nw_resolver_config_add_server_address(fallbackResolvers, google);

Seems to be working much better in iOS 13.4 with the official release of both the OS and Xcode. Still running into a problem where the first character to be input into a web field is not always entered.

Web interactions broke entirely with iOS 13.4 beta 3. It is working (even with autofocus) on beta 4, however, I discovered a new regression. Each interaction with the application/device requires a 60 second wait as the accessibility service believes that com.apple.Spotlight is an interrupting process that needs to idle.

I think I found out why my tests aren't working. The UI elements I'm interacting with during login have the autofocus attribute set. According XCUITest, the text field has keyboard focus when in fact the keyboard is not active at all. I can sometimes work around this by backgrounding and then foregrounding the application to get the keyboard to show up (which then makes input work). I have commented on my Feedbak indicating that this needs to be fixed since it worked in iOS 13.2 and lower.

I think part of the problem is addressed with Xcode 11.4 beta (11N111s) and iOS 13.4 beta 1 (17E5223h). The UI automation tests are able to successfully interact with SFSafariViewController and ASWebAuthenticationSession, however, the tap event causes the text action menu (cut, copy, paste, select all) to come up and the test idles itself while that is visible. Dismissing this causes some text input to be incomplete, leading to test failures. Is anyone else experiencing the same behavior?

This is not resolved with Xcode 11.3.1 (11C505) and iOS 13.3.1 beta 3 (17D5050a)

I received this update this morning: "Potential fix identified - For a future OS update". So, look out for a new beta release I guess?

This is not resolved with Xcode 11.3.1 and iOS 13.3.1 beta 2

Resolved with Xcode 11.3.1