“A Summary of the WWDC25 Group Lab”

Hi @tfnyldrm, You wrote: One of our app is alreadey released, can we still do it to share the same Apple login? Any existing app the uses Sign in with Apple can be added to an app group to share the same user session of the primary app across all child apps. To learn more, see Configuring your environment for Sign in with Apple https://developer.apple.com/documentation/signinwithapple/configuring-your-environment-for-sign-in-with-apple Cheers, Paris X Pinkney |  WWDR | DTS Engineer

So, let me start here: Should I avoid 'cloning' directories in general with the copyfile function? No, quite the opposite. If you read the copyfile man page closely, you'll find that it's very careful to NEVER say that it clones directories. It either refers to cloning individual files or recursive cloning. Recursive cloning means using COPYFILE_CLONE on directories and is actually the standard behavior across all of our copy APIs (and the Finder). More specifically, COPYFILE_CLONE means that copy file calls clonefile for every possible individual file object and creates new objects for directories or anywhere it can't use clonefile. Note that this process is more sophisticated than it might seem, as it doesn't just use cloning within the same file system, but actually preserves clones across volumes (which is much trickier). copyfile() can also do standard copy all data copies on APFS but, to be honest, I've never come up with any good reason why you would do so, as it's basically the same as saying please m

Thank you for your replies. Unfortunately, this didn't help either. I developed an app with SwiftDate in a GroupContainer. The data model is stable, and all relationships are optional. The next step should be to switch to an iCloudContainer. Both computers are on the same network and have internet access and access to the developer account. I disabled and re-enabled automatic signing. No change. A comparison of the project.pbxproj files showed two new lines in the non-functional project: 913a913 CODE_SIGN_IDENTITY = Apple Development; 948a949 PROVISIONING_PROFILE_SPECIFIER = ; I manually deleted these two lines and restarted Xcode. There was no change in behavior; the same error occurred. I also manually downloaded the profile from the developer website and tried to sign it manually. But this deployment profile has the same error again: Entitlements: 8 included, 1 Missing What surprises me is that the working version on the MacBook lists 12 entitlements. The entitlements are identical on both systems. aps-env

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