“apple pencil battery life”

Hi, Thank you for the follow-up and for confirming the AASA multi-App ID support, that is a useful detail. Just to make sure we fully understand the recommendation: are you suggesting we add the testing platform's Team ID + Bundle ID to our AASA file so that their re-signed build is also a trusted app for our domain? If so, we want to understand the security implications of listing a third-party signing identity in our AASA file before going down that path. Regarding TestFlight, we are already using it for manual pre-release testing and it works well for that purpose. Our challenge is specifically with automated UI testing in a cloud device farm, where TestFlight distribution is not part of the workflow. We also wanted to ask about a hybrid distribution approach we are considering, and whether it is permitted under Apple's terms: Use the Apple Developer Enterprise Program to distribute the app internally to our cloud-based testing infrastructure, allowing their re-signing process to work und

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

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.

Thanks for the post. I don’t think you have provided much information to be able to help you. Can you provide a focused sample of how you use App Clips? Are you using Xcode, can you create a new sample project that reproduces the issue using the steps below? App Clips are built as a separate target within your existing iOS app project. Open your project in Xcode. Go to File > New > Target. Select App Clip under the iOS tab. Name your App Clip and ensure it is embedded in your main application target. App Clips rely heavily on Universal Links to securely verify the relationship between your website and your app. Add the Associated Domains capability to both your main app target and your App Clip target. Add your domain using the appclips: prefix. Example: appclips:example.com Update the apple-app-site-association (AASA) file on your web server to include an appclips dictionary. { appclips: { apps: [..Clip] } } Please follow this great documentation: https://developer.apple.com/design/human-inter

Thanks so much with the post. Can I ask you what’s your “cloud-based device testing environment”? Because Universal Links rely on cryptographic trust between the app and the web server, the re-signing process inherently could breaks this trust? The platform signs the app with their own provisioning profile, which does not contain your com.apple.developer.associated-domains entitlement? Apple's security model intentionally prevents unauthorized third parties from claiming your domain. Therefore, there is no native Apple provisioning flag that tells iOS to ignore AASA validation for re-signed builds. Can you provide more details? However, please understand that Universal Links will only work on physical devices with the entitlement. Albert Pascual
  Worldwide Developer Relations.