“Apple Maps Guides”

Thanks so much for the reply and the detailed information. Yes, looks like the resigning will cause the issue you have described. I still recommend you to test against your devices to make sure the AASA file get downloaded and works well before sending the build to the App Store. You are correct that we do not offer a native provisioning flag to bypass AASA validation. Apple’s AASA file specification fully supports listing multiple App IDs (Team ID + Bundle ID) for a single domain. You can also use TestFlight to distribute your app to test devices. Wish you luck. Looking forward to your app. Albert Pascual
  Worldwide Developer Relations.

Thank you for the quick response and for the clarification on how iOS enforces AASA validation, that context is very helpful. To answer your question: our cloud-based device testing environment is a third-party device farm that runs automated UI tests against real iOS devices hosted in their infrastructure, BrowserStack. In order to install our app on their devices, their platform re-signs the app using their own provisioning profile, which is where the Associated Domains entitlement is lost. We fully understand that this is a security boundary by design, we are not looking to bypass AASA validation in production. Our concern is specifically scoped to pre-production testing: we need a way to validate our authentication flow end-to-end (including the Universal Link redirect back into the app) in an automated, cloud-hosted environment before shipping to production. Given your confirmation that there is no native provisioning flag to accommodate this, we have a follow-up question: Short of the Enterprise Develop

Thanks for the detailed response! To answer your questions: OAuth - I don't see a pattern other than time. It seems to lose the OAuth token 2 or 3 times per day. It also doesn't seem to depend on idle time. I can be in the middle of working and it will lose the token. Yes, especially since thinking can go off the rails or go into a nearly-endless loop, this serves as a way to monitor and guide agent progress. I did file a feedback on all the issues, btw! (FB22310171 on the whole set of issues, and I also just filed FB22316631 per your request on this specific one.) Next time this occurs, I will attach it to the Feedback report. No, I have never downloaded or setup Codex. I especially want to highlight the additional bug I reported in my Feedback report but did not post here -- the agent will take action even if I specifically tell it to ask for approval before proceding. This is concerning because there is now some internal state where the agent believes it has gotten permission even though it hasn't

Hello there, Can i rely on the following mapping: generateKey — local only, two possible errors: featureUnsupported (simulator, iOS < 14) unknownSystemFailure (Secure Enclave fault). attestKey — contacts Apple servers, possible errors: featureUnsupported (simulator, iOS < 14) unknownSystemFailure (Secure Enclave fault) invalidInput (one time challenge is not hashed properly) invalidKey (key already attested) serverUnavailable (no network, Apple service down, rate limiting in action). generateAssertion — local only, possible errors: unknownSystemFailure((Secure Enclave fault)) invalidInput (one time challenge is not hashed properly) invalidKey (key deleted from Secure Enclave).

Apple folks can't comment future plans based on the company's policy. I'd say that your ask is best handled as a feedback report for HealthKit. Do you have a feedback report yet? If not, I’d suggest that you file one and share your report ID here. Thanks. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I found a solution my putting the intent into a shared framework and linking it with public struct SharedIntentsPackage: AppIntentsPackage to the app and the widget so iOS will propagate it into the metadata. It works but looks to unintuitive to me compared to the usual apple system integration apis.