“A Summary of the WWDC25 Group Lab”

Hi @Dick_Long, Thanks for your questions. You wrote: A. From the document above, can I performed the Steps 1&2 before the app transfer? if so, is there a maximum lead time for these transfer_subs? To migrate their users, the transferring team (Team A) must obtain their user access token(s) and generate a transfer identifier(s) prior to initiating the app transfer. If the app belongs to an app group, Team A must also ungroup them before initiating the transfer. If the app is configured with a Services ID, it will also transfer. If Team A wants to keep the Services ID, they must remove the association with the app before initiating the transfer. Important: If a user doesn’t use any other applications from Team A, Team A will no longer be able to communicate with the migrated user using their private email address after the transfer. Next, you wrote: B. Regarding Step 5(Team B exchanging transfer identifiers via https://appleid.apple.com/auth/usermigrationinfo) are there specific rate limits (reques

[Details] Looking at Bonjour_Conformance_Guideline.pdf ... there were some differences: So, for future reference, the Bonjour Conformance Guideline document is primarily focused on details of how the test needs to be run, NOT what the test actual does or how to interpret it's results. The details of the test process itself are found in: Documentation/Conformance Test Outline.txt ...inside the disk image of the conformance test itself. For the share reply timing test, that document says: II.8 Shared Reply Timing The test tool issues a query for a shared (service PTR) record, and records how quickly the device answers. This test is repeated 10 times. The response times must form a uniform random distribution in the range 20ms - 125ms. Any results in the range 10ms - 20ms, or 125ms - 750ms are warnings. Any results less than 10ms or more than 750ms are failures. For purposes of determining a uniform random distribution, only the answers that fall into the correct time range (20ms - 125ms) are considered. It is a

Right. I've done a clean build (with only the one, new app group), the entitlements file is correct, and it runs with the correct entitlements on both my dev machine and a Ventura one. Curiously, though, the entitlements validated flag is still not showing as set. I'm waiting to hear back on the results from the Sequoia machine, but I expect that means it's still going to fail. So in the meantime -- could this be an issue with notarization rather than signing? I've just discovered that because we're distributing the app in-house rather than through the App Store, the installer package for these internal releases hasn't been going through notarytool. Is that a deal-breaker under the newer OS versions?

[quote='879587022, jblum2000, /thread/817268?answerId=879587022#879587022, /profile/jblum2000'] The first problem is that the entitlements validated flag is not set. [/quote] OK. That explains the runtime behaviour you’re seeing, because: The system won’t grant you access to the container because it can’t trust your entitlements. And it won’t display the standard UI because it knows that file providers run in the background. [quote='879587022, jblum2000, /thread/817268?answerId=879587022#879587022, /profile/jblum2000'] And the codesign result shows that the new app group is not present [/quote] And that’d do it. As to how it got built this, it’s hard to say without digging deeper into your build process. [quote='879587022, jblum2000, /thread/817268?answerId=879587022#879587022, /profile/jblum2000'] I'll try a complete rebuild and get back to you ASAP. [/quote] That’s always a good start. And if that doesn’t help, you can look at the build transcript to see how entitlement values are flowing from your

Thanks, Quinn! The first problem is that the entitlements validated flag is not set -- here's the relevant text: code signing info = valid refuse invalid pages kill on invalid pages require enforcement allowed mach-o platform dyld And the codesign result shows that the new app group is not present, just the old one: Executable=/Applications/MyApp.app/Contents/PlugIns/EMPFileProvider.appex/Contents/MacOS/EMPFileProvider [Dict] [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.network.client [Value] [Bool] true [Key] keychain-access-groups [Value] [Array] [String] XXXXXXXXXX.com.mydomain.MyApp.Shared [Key] com.apple.security.application-groups [Value] [Array] [String] group.com.mydomain.MyApp [Key] com.apple.application-identifier [Value] [String] $(AppIdentifierPrefix)$(PRODUCT_BUNDLE_IDENTIFIER) ...which is odd because the embedded.provisionprofile inside the .appex lists all three: com.apple.security.application-groups group.XXXXXXXXXX.com.

Hello, You can find most of the answers and details to your points by going through the Supporting offer codes in your app article, but let me give you a summary to your specific questions: You can test offer codes in the sandbox environment for all In-App Purchase product types: consumable, non-consumable, non-renewing subscription, and auto-renewable subscription. To redeem an offer code in the sandbox environment, follow these steps: On your device, sign in using a Sandbox Apple Account. On the Sandbox Account Settings page, tap Initiate Transaction. Select Offer Codes and redeem a sandbox offer code you created in App Store Connect. You can use the information contained in the transaction to identify products purchased with offer codes, you need to check the offer property of Transaction on StoreKit, or the offerIdentifier if you're using the App Store Server API or notifications. If you're not using it yet, we highly recommend using the App Store Server libraries to adopt the App Store Server AP

Still banging my head on this 😬 Thanks to the author of the gateway software I’m using we figured out those errors, and everything seems good on that front. Still getting a lot of Bad Request, Evaluation key not found errors during queries. The sample project documentation says these should happen when the server is restarted bc old keys are cached, but they happen all the time. Still, this is only on the /queries endpoint, which is not involved in setup (afaik). The client is still at times throwing this on TestFlight builds: : -[NEPIRChecker start:responseQueue:completionHandler:] - failed to register with PIR for Group site.kaylees.Wipr2 usecase site.kaylees.Wipr2.url.filtering The thing is, all other endpoints always work with no issues: /.well-known/private-token-issuer-directory, /token-key-for-user-token, /issue, /config, and /key are always successful. As far as I can tell, this should be enough for registration. What exactly does the failed to register with PIR error mean?

Thanks for the post. Please refer to the documentation for further details. However, I would like to provide a concise summary of my interpretation: it is not possible to programmatically initiate a Live Activity from a background execution context, such as a CLLocationManager wakeup, using local APIs. https://developer.apple.com/design/human-interface-guidelines/live-activities/ The ActivityAuthorizationError.visibility error occurs because Live Activity strictly requires the app to be in the foreground and visible to the user to start a Live Activity locally with user’s permission. If a user taps an Interactive Widget, uses a Shortcut, or asks Siri, the System executes the LiveActivityIntent. Because the user initiated the action via the OS, Apple grants the Intent the privilege to start a Live Activity, even if your app's main process is in the background. I would recommend you to read the workflows very carefully as Live Activity entirely as may show that you can start via Push Notification servi

I’m not sure what’s going wrong here but I have a couple of diagnostics tests for you to run. Both require you to get your file provider started. Once you have that: Use launchctl procinfo to check whether the process has the entitlements validated flag set. App Groups: macOS vs iOS: Working Towards Harmony has an explanation of how to do this. Use codesign to check the entitlements of the running process: % codesign -d --entitlements - PID where PID is the process ID. What do you see? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com