“Apple Maps Guides”

Thank you for your post. We recommend that you sign up for a session with App Review during the weekly Meet with Apple event. Sign in with your Developer ID and select Request a one-on-one App Review consultation. A member of the App Review team will help you with your questions regarding the review process and the App Review Guidelines.

After additional testing, this appears to be an orphaned MobileAsset cleanup issue rather than a normal simulator uninstall problem. The runtime payload remains on disk under /System/Library/AssetsV2, but in some cases Xcode no longer exposes it in Components/Platforms and simctl does not have a usable reference to remove it cleanly. In other words, the asset still occupies space, but the supported management tools have effectively lost authoritative control over it. At that point the problem becomes structural: the remaining files are in a SIP-protected system location. So even if the exact asset folder can be identified, it cannot be manually removed through normal user-space means while SIP is enabled. That leaves no supported path to reclaim the space once the asset has fallen out of Xcode/simctl management. Technically, the remaining workaround is to disable SIP and remove the orphaned asset manually, but that is not a reasonable solution for routine simulator runtime cleanup. SIP exists specifically to

We advise against rapidly mutating content that is eligible for download retry, as it can lead to a fragile solution. For further information, please refer to our recommendations on the HTTP Live Streaming (HLS) authoring specification for Apple devices. If this solution is still desired, we suggest exploring the STABLE-RENDITION-ID and STABLE-VARIANT-ID attributes. This approach decouples the variant identity from its CDN location. To facilitate the refresh of the Multi-Variant-Playlist (MVP), you can rely on the HTTP cache-control headers. AVFoundation will attempt to retry expired MVP, but it will default to the cached playlist if a new MVP cannot be retrieved. To achieve the re-download behavior of the MVP, use the HTTP headers Cache-Control: must-revalidate, along with max-age.

When did you install the TestNet Profile and are you sure it's still valid? The previous profile expired in early February, so you'll need to have updated it recently. Note that you need to install the profile on all the devices involved and that a mixed configuration where the iOS device has the current profile but the HomeHub does not will very likely generate behavior similar to what you're seeing. Here is exactly what is happening: Our device successfully sends a QueryImage command to the HomePod. The HomePod receives it, but immediately fires back a QueryImageResponse that essentially means UpdateNotAvailable, forcing the device into an 86400-second sleep timeout. Chapter 4 of the Apple Matter OTA - User Guide (r6) outlines a number of specific recommendations and guidelines. Are you following all those guidelines, particularly around MinApplicableSoftwareVersion and MaxApplicableSoftwareVersion? Many of our recommendations in these specifications are best understood as requirements, no

The Apple Developer Forums are for questions about APIs and features intended specifically for developers. Since it sounds like you went to the Apple Support Community already and were sent here because you are running a beta, then you should file a bug report in Feedback Assistant.

@michelbechelani-aya Yes, if you distribute the app using the Apple Developer Enterprise Program or TestFlight there is no need to resign the app, therefore everything will work on the app. Now the most robust way to handle OAuth/Sign-in flows in automated cloud testing does not need Universal Links entirely for your test builds. Create a specific build configuration for your cloud tests. In this build, configure your app to use a Custom URL scheme for its callback. Configure your staging/testing Auth Server to accept and redirect to this Custom URL scheme instead of the Universal Link (https://...). When the test runner triggers the login, the browser will redirect to myapp-test://, which the OS will route back to your app, regardless of who signed it. Not trying to side track you. Follow your architecture, but I want to make sure to show there are other options. Albert Pascual
  Worldwide Developer Relations.

Thank you for your post. We recommend that you sign up for a session with App Review during the weekly Meet with Apple event. Sign in with your Developer ID and select Request a one-on-one App Review consultation. A member of the App Review team will help you with your questions regarding the review process and the App Review Guidelines.

If your app has been rejected and you need help resolving the issue, consider taking advantage of one of the following support options available from App Review: Reply to the message from App Review in App Store Connect and request clarification. Request a call with an Apple representative to discuss the outcome of the review. Submit an appeal to the App Review Board if you believe your app follows the App Review Guidelines. Visit the Contact Us page on Apple Developer and select the App Review tile to learn more.

Thank you for the feedback. Let me clarify: My app is a SwiftUI iOS fitness app called GymFusion. It uses Anthropic's Claude AI API to power features like meal photo scanning, body composition analysis, and workout coaching. The rejection is solely about Guidelines 5.1.1(i) and 5.1.2(i) — the app shares user data with a third-party AI service (Anthropic) and Apple says the app doesn't clearly disclose this or ask for permission. There are no in-app purchase issues — apologies for any confusion. Here's what I've implemented: The app's entry point (RootView) shows the AI consent screen as the first view on every launch. It's not a sheet or popup — it's embedded in the view hierarchy: if auth.isLoading { // Loading screen } else if !consentManager.hasConsented && !consentManager.hasSeenConsent { AIConsentView() // Consent blocks the entire app } else if auth.isAuthenticated { MainTabView() } else { AuthView() } The consent screen: Lists all data shared (photos, workout history, body measurements

Hi, Thank you again for your continued guidance on this. Since Universal Links are part of our sign-in/login/authorization workflow, they are required for all of our testing workflows. Our cloud testing platform has indicated that if we distribute the app to them via the Apple Developer Enterprise Program, they would not need to re-sign it, which would preserve the Associated Domains entitlement and allow the sign-in flow to work correctly on their device farm. Since our app also needs to be published to the App Store, we would continue using our standard Apple Developer Program for that purpose. Is this a valid scenario? We want to stay within Apple's supported provisioning model. If maintaining both an Enterprise Program and a Developer Program membership is the right path forward, we are prepared to do that.