hello last year at the WWDC Apple announced a app extension for audio playback in CarPlay for iOS apps is there a guide to add this feature because whenever I open my custom music I can hear the music playing trough the car's speakers and I see the album art, but I have no controls on the display of the car the person I white this app for is a indie producer who wants his huge collection to be available for people to enjoy there is no subscription of login

Hi all, I've been observing what appears to be a timing mismatch in how Apple handles Korea trial-to-paid consent, and I wanted to see if other developers are seeing the same thing. Per Korean regulations effective Feb 14, 2025, Apple must obtain explicit user consent before converting a free trial to a paid subscription. Apple handles this via email, push notifications, and an in-app consent option accessible from Settings > Subscriptions. For a 7-day trial in the Republic of Korea storefront, I'm observing: Consent push notifications (Agree to continue your subscription without interruption) start arriving ~1 day after trial redemption, at roughly hourly frequency. However, when the user taps the push and navigates to Settings > Subscriptions, there is no consent option available. The only visible action is "Cancel Free Trial". The consent option only becomes available around day 4 of the trial (i.e., 3 days before renewal, matching Apple's documented messaging cadence [1]). For the first ~3 days, users receive hourly push notifications they cannot act on. The only way to stop them is to cancel the subscription entirely. This is happening across multiple apps in the Korean App Store, so it appears to be a platform-level behavior rather than an app-specific issue. Is anyone else observing this behavior? Any insight from Apple engineers or other developers would be greatly appreciated. [1] https://developer.apple.com/help/app-store-connect/reference/in-app-purchases-and-subscriptions/consent-for-subscription-offer-conversions

Hi everyone, I have developed an app that requires push notifications to notify users to respond to a questionnaire. After login, I inform the user that the app needs push notifications in order to function properly, and I request their consent to receive notifications. However, during the review process, Apple keeps rejecting the app with the following message: Issue Description The app requires push notifications in order to function. Next Steps Push notifications must be optional and must obtain the user's consent to be used within the app. Anyone knows how to fix this problem? Thank You

Just curious if there is anyway to expedite the FamilyControl entitlement. I have seen few people stuck in this step for few days. I submit mine on the 4/18, and my Case ID: 102874096254 Just want to see if I can see any estimate time for my request. Thanks, Jing

Hey my app subscriptions are currently in review whilst my app has been approved 2 times, i need this to be approved to start marketing it.

Hi, I have a problem with watchOS widget configuration intents. It turns out that watchOS is unable to load text for localization keys. This is how I set configuration parameter in WidgetConfigurationIntent: @Parameter( title: LocalizedStringResource( "watchWidgetConfig.showSymbols", defaultValue: "Symbole", table: "WidgetLocalizable", bundle: widgetBundle ), default: true ) var showSymbols: Bool Unfortunately, on a device always the defaultValue is used. I tried everything and nothing works. What's weird, it correctly works on watchOS simulator and if you configure widgets in iOS "Watch" app. On real Apple Watch, the "defaultValue" is displayed. I'm not sure if it's important but both: the Swift file with WidgetConfigurationIntent and WidgetLocalizable.xcstring are included in two targets: Watch Widget Extension and Watch App. I tried so far: All variants of LocalizableStringResource init. With/without "table", with/without "bundle". Previously I had texts in Localizable.strings, I migrated it to WidgetLocalizable.xcstrings and it didn't work either. Setting only one target for WidgetLocalizable.xcstring and WidgetConfigurationIntent. I checked inside xcarchive to see if WidgetLocalizable.xcstring is copied correctly. Seems like watchOS bug, but I would be happy to know if someone figured out any workaround. Xcode: Version 26.4 (17E192) iOS 26.4.1 watchOS 26.4 I already created a ticket: FB22509406

Hi, I’m having an issue where my auto-renewable subscriptions keep detaching from my app version after I submit the build in App Store Connect. Details: App ID: com.growthsync.app Platform: iOS (Capacitor build) Using auto-renewable subscriptions What’s happening: I attach all subscriptions to the app version under “In-App Purchases” Everything looks correct before submission After submitting, the subscriptions become detached or require localisation to be re-entered again This happens every time I resubmit Additional issue: Subscriptions are not working in TestFlight either It feels like they are not properly linked to the binary What I’ve already checked: Product IDs match exactly in code and App Store Connect Subscriptions are in the correct group All localisation fields are filled within character limits Products show as “Ready to Submit” before attaching I reattach them before every submission Questions: Why would subscriptions repeatedly detach after submission? Is this a known App Store Connect issue? Is there a specific order required when creating, localising, and attaching subscriptions? Could this be related to the binary not recognising the products? This is currently blocking release so any help would be appreciated. Thanks.

Hello, For the past few days I have been working on integrating a Crash Reporter called "BugSplat" to our macOS desktop app and it got me thinking, how do crash reporters work on macOS ? After days of trial and error (and claude's help) I managed to integrate it but with a different behavior than windows. On Windows: When the app crashes, the BugSplat crash report window opens and allows you to write your details and message to be sent with the crash report (along with a log file) On macOS: It displays the normal macOS' "App exit unexpectedly", to which I click dismiss. But then when I re-open the app the BugSplat crash report window appears. I asked claude if I can avoid the normal macOS dialog entirely, to which it replied: "This is by design — BugSplat macOS is a next-launch crash reporter, not an in-process one. Here's why that's intentional and unavoidable: When a process crashes (SIGSEGV, SIGBUS, etc.), macOS's ReportCrash daemon independently monitors all processes and shows the "quit unexpectedly" dialog — there's no API to suppress it. Meanwhile, BugSplat's Mach exception handler captures the crash data to disk. On the next launch, BugSplat finds that crash data and shows its dialog. This is the same model used by every macOS crash reporter (PLCrashReporter, Firebase Crashlytics on macOS, etc.). The process heap is in a corrupted state at crash time, so showing UI from inside the crashed process is unreliable." LLMs sometimes speak confidently even when they're wrong so that's why I'm asking: Is it really true that that's the normal behavior for every crash reporter? And is it really that huge of a change to overwrite the macOS dialog entirely ? Thank you in advance and sorry for the long paragraph

Hello! My subscriptions have been stuck in review for a while. I have been chasing my tail trying to get the sandbox purchases to work but the subscriptions are not returning after "sale". Is this because the subscriptions are still in review? Will the purchase ever return a product in the sandbox environment if the products are still in review? How do we get the subscriptions approved? I have submitted them with the app multiple times. The app is rejected because I can't complete it without the subscriptions but the subscriptions are never reviewed. Help!

My enterprise app requires a launch daemon that provides services to support my Security agent plugin. I bundle everything in an App and install using AirWatch. This all used to work until something changed, either AirWatch or the MacOS version. Now the install fails because my SMAppService instance returns an error when .register is called: Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} If I install by opening my installer package as a user, the install always succeeds. The app is an enterprise app and is not distributed through the App Store. The app also installs a security extension. The security extension is installed and activated before any calls to SMAppService. I can't figure out what has changed in the last few months that would cause the error, or how to fix this. Any help or pointers would be appreciated.

I would like to enable the app to persist a stable SIM identifier and compare it across app sessions so it can reliably detect when the user has changed SIM cards. When a SIM change is detected—especially while the device is on Wi-Fi—the app should trigger SIM-change handling (for example: refresh auth/session, reload account-specific data, and update feature availability). The implementation must be robust for: Dual-SIM and eSIM devices Temporary network unavailability or delayed carrier info Current challenge: On Wi-Fi, the existing hash can distinguish a different operator but cannot reliably detect a SIM-card-level change. We need a way to uniquely identify the SIM card itself, not just the operator.

I’m looking for some advice regarding the usage of temporary exception entitlements in Mac App Store apps. Specifically the Apple Event Temporary Exception to communicate with other third party applications (not first-party macOS system apps): The Best Practices for Submitting Scriptable and AppleScript Apps to the Mac App Store section is a bit vague (how to 'request' a temporary entitlement?) and I couldn't find it mentioned in the Review Guidelines. Before designing, implementing and testing functionality based on the Apple Event Temporary Exception I’d like to know if these entitlements would: A. Always be rejected on the Mac App Store B. Only accepted in highly specific use cases C. Accepted if there is a clear use case and sufficient argumentation For this particular use case I’d like to send Apple Events to Adobe Illustrator and QuarkXPress. The application helps the user with some design tasks in their documents. The app requests the currently open documents and accesses document content to process used design elements. This is optional functionality that the user must explicitly enable in the app. I’m aware that the com.apple.security.scripting-targets entitlement is preferred. (Side question: are these always allowed or can they also be rejected for third party app scripting?) However, many third party applications don’t offer any scripting access groups in their definition, including Adobe Illustrator and QuarkXPress in this case. So before spending a lot of time implementing this feature I’d like to have some indication whether it is unlikely that sending Apple Events to third party apps will be allowed on the Mac App Store. Thanks for any insights!

We have recently enrolled to the platform integrator program in order to be able to use this API https://developer.apple.com/documentation/applepaywebmerchantregistrationapi to verify our customers' domains for apple pay. We have distributed certifications and the domain association file and have successfully conducted the domain verification call. Consequently, the domain is registered for a given merchant. However, when conducting a payment session request, we receive an error response saying that the domain is not registered. Specific example: We POST to https://apple-pay-gateway.apple.com/paymentservices/registerMerchant with body: { "domainNames": [ "example.com" ], "encryptTo": "platformintegrator.com.example", "partnerInternalMerchantIdentifier": "example", "partnerMerchantName": "example" } and get a 200 response. The apple server successfully conducts the call to the example.com/.well-known/apple-developer-merchantid-domain-association resource. Then the GET request to https://apple-pay-gateway.apple.com/paymentservices/merchant/example lists the domain for this merchant: Response { "domainNames": [ "example.com" ], "partnerMerchantName": "example", "partnerInternalMerchantIdentifier": "example", "partnerMerchantValidationURI": "/.well-known/apple-developer-merchantid-domain-association", "encryptTo": "<hashed merchant id>", "delegatedCommerce": { "enabled": true } } However, when trying to initiate an apple pay payment session here: POST https://apple-pay-gateway.apple.com/paymentservices/paymentSession Body: { "merchantIdentifier": "platformintegrator.com.example", "displayName": "example", "initiative": "web", "initiativeContext": "example.com" } we receive this error response: { "statusMessage": "Payment Services Exception merchantId=<hashed merchant id> not registered for domain=example.com", "statusCode": "400" } Our assumption is that after registering a domain for a merchant the apple pay process should work. We already have a working apple pay implementation with the traditional domain verification process with merchant IDs. We would like to know if we are missing any detail or what is causing this error in our payment process.

FB: https://feedbackassistant.apple.com/feedback/22556883 We're seeing a small number of production users where both Transaction.currentEntitlements and Transaction.all return zero transactions for a valid, active, non-refunded non-consumable IAP. This makes it impossible to restore the purchase via any StoreKit 2 API. Environment: Xcode 26.4 (Build 17E192) iOS 26.4.1 Direct call to SK2 Transactions.all & Flutter in_app_purchase package v3.2.3 (uses SK2 on iOS 15+) Non-consumable IAP (one-time purchase) What we observe: AppStore.sync() triggers but the purchase stream returns 0 transactions Transaction.all returns empty Transaction.currentEntitlements also returns empty User is confirmed on the correct Apple ID Issue reproduces on both iPhone and Mac for the same Apple ID Issue appears to have started recently for users who previously had no problems Debug log from affected production user: [2026-04-20T08:50:10.744115Z] init: iapAvailable=true [2026-04-20T08:50:10.744566Z] init: isPremium=false [2026-04-20T08:50:10.744567Z] init: triggering silent restorePurchases [2026-04-20T08:50:45.974566Z] restore: started [2026-04-20T08:50:45.986848Z] restore: sk2Transactions count=0 [2026-04-20T08:50:45.993004Z] restore: sk2Direct isVerified=false active=null [2026-04-20T08:50:45.993011Z] restore: sk2Direct inconclusive — falling back to standard restore [2026-04-20T08:51:16.000851Z] restore: timed out after 30s — fallback isPremium=false [2026-04-20T08:51:16.000910Z] restore: completed — succeeded=false foundPurchase=false Unable to reproduce in sandbox — Transaction.all works correctly there. Appears specific to production for a small subset of users. Has anyone else seen this?

I'm building an app with a leaderboard based on users' step counts, so I need the data to sync in real time at minimum. The problem is that when the app is terminated, steps don't seem to be counted at all, so if a user hasn't opened the app in 5 days, the leaderboard ends up completely out of sync. Is it even possible to retrieve this data when the app has been terminated and hasn't been opened? I'm currently using Background Fetch, which works when the app is suspended, slowly, but it does work. However, it does not sync when the app is fully terminated.

Dear Screen Time Team! The Screen Time passcode can be brute-forced without rate limiting by repeatedly attempting guesses through the "Erase All Content and Settings" flow. This allows unlimited passcode attempts with no delay, lockout, or escalation, effectively defeating the purpose of the Screen Time passcode as a parental control mechanism. Impact: Children can bypass Screen Time protections by guessing the passcode No rate limiting enables trivial brute-force attacks (especially for 4-digit codes) Undermines trust in Screen Time as a parental control system Creates real-world safety risks for families relying on Screen Time restrictions Publicly shared methods (e.g. on TikTok) increase likelihood of widespread abuse Steps to Reproduce: Enable Screen Time and set a passcode Open Settings → General → Transfer or Reset iPhone → Erase All Content and Settings When prompted for the Screen Time passcode, enter an incorrect code Repeat the process with different guesses Expected Result: After a small number of incorrect attempts, the system should: enforce exponential backoff delays, or temporarily lock further attempts, or require Apple ID authentication Attempts should be rate-limited across system flows Actual Result: Unlimited passcode attempts are allowed No delay, lockout, or penalty is applied Enables rapid brute-force guessing of the Screen Time passcode Notes: This appears to bypass standard passcode protections that exist in other parts of iOS The issue is especially severe for 4-digit Screen Time passcodes (10,000 combinations) The attack surface is exposed through a system-level reset flow Suggested Fix: Introduce global rate limiting for Screen Time passcode attempts across all entry points Apply exponential backoff after failed attempts Require Apple ID authentication after multiple failures Consider enforcing 6-digit minimum passcodes for Screen Time Log and unify attempt counters across system components Severity: Critical (Security vulnerability enabling brute-force of parental control passcode) See TikTok: https://www.tiktok.com/@aldanaisthebest12170/video/7615053429500644621 Feedback request: FB22263276 – Frederik (one sec app)

Dear Screen Time Team! The current 6 MB memory limit for the DeviceActivityMonitor extension no longer reflects the reality of modern iOS devices or the complexity of apps built on top of the Screen Time framework. When Screen Time APIs were introduced with iOS 15, hardware constraints were very different. Since then, iPhone performance and available RAM have increased significantly…but the extension memory limit has remained unchanged. My name is Frederik Riedel, and I’m the developer of the screen time app “one sec.” Our app relies heavily on FamilyControls, ManagedSettings, and DeviceActivity to provide real-time interventions that help users reduce social media usage. In practice, the 6 MB limit has become a critical bottleneck: The DeviceActivityMonitor extension frequently crashes due to memory pressure, often unpredictably. Even highly optimized implementations struggle to stay within this constraint when using Swift and multiple ManagedSettings stores. The limit makes it disproportionately difficult to build stable, maintainable, and scalable architectures on top of these frameworks. This is not just an edge case…it directly impacts reliability in production apps that depend on Screen Time APIs for core functionality. Modern system integrations like Screen Time are incredibly powerful, but they also require a reasonable amount of memory headroom to function reliably. The current limit forces developers into fragile workarounds and undermines the robustness of apps that aim to improve users’ digital wellbeing. We would greatly appreciate if you could revisit and update this restriction to better align with today’s device capabilities and developer needs. Thank you for your continued work on Screen Time and for supporting developers building meaningful experiences on top of it. Feedback: FB22279215 Best regards, Frederik Riedel (one sec app)

Starting somewhere around macOS 26.3, my sandboxed file manager spontaneously loses access to ~/Library/Mobile Documents mid-session. Setup: at launch, the user grants access to '/', '/Users', or '~' via NSOpenPanel; I store a security-scoped bookmark and call startAccessingSecurityScopedResource(). This works fine - including iCloud Drive - until some point mid-session. When it breaks, two things happen simultaneously: Enumeration fails: NSCocoaErrorDomain Code=257 (NSFileReadNoPermissionError)< NSPOSIXErrorDomain Code=1 (EPERM) Console shows the kernel refusing extension issuance: couldn't issue sandbox extension com.apple.app-sandbox.read for '/Users//Library/Mobile Documents': Operation not permitted And probing NSFileProviderManager confirms the process has been rejected system-wide: NSFileProviderManager.getDomainsWithCompletionHandler > NSFileProviderErrorDomain Code=-2001 "The application cannot be used right now." (underlying Code=-2014) What makes this specific to FP-backed paths: regular paths under the same '/' bookmark (~/Library/Application Support, etc.) stay accessible and recover normally with a fresh startAccessingSecurityScopedResource() call. Only ~/Library/Mobile Documents and its subtree fail - the entire tree, including the parent directory itself. Relaunch always restores access. What I've tried and ruled out: Re-resolving the bookmark + startAccessingSecurityScopedResource() - returns stale=false, granted=true but access is not restored; the kernel still refuses extension issuance for FP-traversing paths. NSFileCoordinator coordinated read - doesn't help; the coordinator depends on the same sandbox extension the kernel is refusing. Instantiating NSFileProviderManager(for: domain) per domain - fails with -2001 for every domain, confirming the rejection is process-wide, not path- or domain-specific. My working theory: when a FileProvider daemon (bird/cloudd/fileproviderd) restarts mid-session, the process's FP-client XPC registration is invalidated, and the kernel subsequently refuses to issue sandbox extensions for any path served by FP - even with a valid bookmark. The process seems to have no API path to re-register its FP-client identity without relaunching. Current workaround: I detect the -2001 response and prompt the user to relaunch, then do a programmatic self-relaunch if they confirm (which is obviously horribly intrusive). Questions: Is there an API that lets a sandboxed consumer app reconnect its FP-client identity mid-session, short of relaunching? Is there an entitlement or capability that would make the kernel's extension issuance resilient to FP daemon restarts? Has anyone else hit this on 26.x and found a workaround? Filed as FB22547671.

We are seeing a CloudKit private database failure for this specific container: iCloud.com.matrixqlc.photodiet.sync Failure pattern: accountStatus succeeds in some cases ensure/create custom zone succeeds but record/database-level operations consistently fail with: CKErrorDomain code = 15 CKInternalErrorDomain code = 2000 HTTP 500 Failing operations include: allRecordZones() databaseChanges(since:nil) allSubscriptions() fetch record zone metadata save record fetch record query records What makes this unusual is that the issue follows the container, not the app. On the same physical device, same Apple ID, same developer team: PhotoDiet + iCloud.com.matrixqlc.photodiet.sync => fails RepaymentCalculator + iCloud.com.matrixqlc.photodiet.sync => fails PhotoDiet + iCloud.com.matrixqlc.repaymentcalculator.sync2 => succeeds RepaymentCalculator + iCloud.com.matrixqlc.repaymentcalculator.sync2 => succeeds So this does not currently look like: app-specific entitlement/provisioning issues device/account issues CloudKit API misuse in one app record schema or app business logic issues It currently looks like the container iCloud.com.matrixqlc.photodiet.sync itself may be in a bad backend state. Sample request identifiers: RequestUUID: C8403047-0037-4D36-A7A7-CF3C83584A42 RequestUUID: 04437D9D-115E-45F5-87B5-A8CD146AE705 RequestUUID: C924B620-BAEE-403D-B944-151ADCF3419F RequestUUID: A54E79E1-6037-4533-BA09-18FBC436851C RequestUUID: 3EFD8913-3781-47CF-A48C-B651BF38EA50 RequestUUID: 2677A991-40B3-42AB-9CE5-3C4F1288EE08 Feedback Assistant ID: FB22539748 Has anyone seen a container-specific CloudKit private database failure like this, where multiple apps under the same team can access one container normally but consistently fail on another container with CKError 15 / HTTP 500?

Hi, I'm having the same issue described in https://developer.apple.com/forums/thread/690974?page=2. When connected to Xcode or when the app is in the foreground, HKObserverQuery fires correctly and my app processes step updates. But once disconnected from Xcode, background delivery stops completely and the observer callback is never called. My setup: com.apple.developer.healthkit.background-delivery entitlement is present and in the provisioning profile enableBackgroundDelivery(for: .stepCount, frequency: .immediate) returns success = true HKObserverQuery is registered on every launch including background launches I also have CMPedometer.startEventUpdates running as a supplemental trigger Background Modes includes "Background fetch" and "Background processing" Device: iPhone, iOS 17.4+ App type: App uses Screen Time / Family Controls (ManagedSettings) to block apps until a step goal is met Has anyone found a reliable fix? Any feedback from Apple engineers would be appreciated.