I've been stuck on Guideline 2.3 for two weeks now and I'm running out of ideas. My app is iPhone-only (UIDeviceFamily = [1]) and has been on the App Store since January. Version 2.1.9 passed review fine. The only change in 2.1.10 is adding two DeviceActivity extensions — a DeviceActivityMonitor and a DeviceActivityReport — for screen time-based stress detection. Every build since then gets rejected with the same message: "The UIRequiredDeviceCapabilities key in the Info.plist is set up in such a way that the app will not install on the device used in review." Review devices: iPhone 14 Pro, iPhone 17 Pro Max, iPad Air M3. Here's what I've tried across 13+ submissions: UIRequiredDeviceCapabilities as ["arm64"] (array) — rejected Empty array [] — rejected Removed the key entirely — upload validation fails, Xcode re-injects arm64 anyway Post-build script to force ["arm64"] — rejected Dictionary format {"arm64": true} — rejected Added com.apple.developer.family-controls to extension entitlements — rejected Enabled Family Controls (Distribution) on extension bundle IDs — rejected Fixed CFBundleVersion mismatch between host app and extensions — rejected Set TARGETED_DEVICE_FAMILY=1 on all targets including extensions — rejected Tried GENERATE_INFOPLIST_FILE=YES with minimal plists — rejected Tried ExtensionKit type for the report extension — rejected In the exported IPA, every target has UIRequiredDeviceCapabilities = ["arm64"] and UIDeviceFamily = [1]. The entitlements, provisioning profiles, and code signing all look correct. arm64 is supported on every review device they listed. The previous version (2.1.9) without DeviceActivity extensions passes review with the exact same UIRequiredDeviceCapabilities and signing configuration. Has anyone shipped an app with DeviceActivityMonitor + DeviceActivityReport extensions successfully? Is there something specific about these extension types that affects device capability validation? Or is there a known issue with the review system and FamilyControls extensions? I've replied to the review team multiple times asking which specific capability is causing the failure, but the response is always the same generic template. Any guidance would be really appreciated — I'm completely blocked on shipping this update.

I started a fresh “Sticker Pack App” project, add one image to it and it wouldn’t show up on emulator or device. From what I remember, there shouldn't be any coding involved, just drag and drop images of the correct format and dimensions and it should work. I tried changing the file format, dimensions etc while consulting with web and AI assistant searches and but still didn’t work. Apple support also didn't reply with anything useful but to post in the forum. I'm guessing I'm missing something trivial where a lot of us here have encountered before. Appreciate your help here, thank you in advance!

We are developing an MDM agent app that uses FamilyControls with .individual authorization to enforce Screen Time restrictions (app blocking, domain blocking via ManagedSettingsStore and DeviceActivityCenter). The Problem We are actively subscribing to AuthorizationCenter.shared.$authorizationStatus to detect authorization changes. However, when the user revokes the app's FamilyControls authorization through Settings (either via Settings > Screen Time > Apps With Screen Time Access, or Settings > Apps > [Our App]), the publisher does not emit any value. All ManagedSettingsStore restrictions are lifted immediately by the system, but our app receives no notification of this change. The only scenario where the publisher reliably emits is when a debugger is attached (i.e., running directly from Xcode). Without the debugger, the publisher is completely silent — even when the app returns to foreground. Code Example We tried subscribing directly to AuthorizationCenter.shared.$authorizationStatus with no intermediary, exactly as shown in the documentation: AuthorizationCenter.shared.$authorizationStatus .sink { status in print("[DIRECT] authorizationStatus emitted: \(status)") } .store(in: &cancellables) This subscription is set up at app launch and stored in cancellables. The result is the same — the publisher does not emit when the user revokes authorization in Settings without a debugger attached. Documentation Reference The documentation for authorizationStatus states: "The status may change due to external events, such as a child graduating to an adult account, or a parent or guardian changing the status in Settings." And: "The system sets this property only after a call to requestAuthorization(for:) succeeds. It then updates the property until a call to revokeAuthorization(completionHandler:) succeeds or your app exits." This suggests the publisher should emit when the status is changed via Settings, but in our testing it does not — unless a debugger is attached. What We Verified We tested with a development-signed build (which includes the com.apple.developer.family-controls entitlement), launched from Xcode, then disconnected the debugger, killed the app, and relaunched from the home screen. Scenario Publisher emits on revocation? Running from Xcode (debugger attached) Yes, immediately Development-signed build (no debugger) No — silent even on foreground return We also confirmed: MDM configuration profiles can disable Screen Time entirely, but cannot restrict the per-app authorization toggle — the user can always freely revoke the app's Screen Time access The Security Gap This creates a significant gap for parental controls use cases: User leaves the app (app goes to background) User goes to Settings and disables Screen Time access for the app All restrictions are immediately lifted User uses the device freely User re-enables Screen Time access and opens the app Everything syncs back to normal — administrator never knows Questions Is there any supported mechanism to receive a notification (background or foreground) when FamilyControls individual authorization is revoked? We are subscribing to AuthorizationCenter.shared.$authorizationStatus but it does not emit. Is the $authorizationStatus publisher expected to work only when a debugger is attached? Is this a known limitation or a bug? Can DeviceActivityMonitor extension detect authorization revocation? Based on documentation it appears limited to schedule/threshold events, but we haven't confirmed this. Is there a planned API improvement to address this gap? Environment iOS 26.2 Xcode 26.3 Swift 6.2.4 FamilyControls .individual authorization Related Threads Screen time API can be disabled easily Changing Screen Time Passcode does not protect apps

From the Developer Guide page 12 for the entitlements. The footnote mentions that CarPlay EV charging app and CarPlay fueling app entitlements may be combined in a single app Does this mean that i can implement both fuelling and EV charging feature in the same app ? How will the entitlement process to get this be done ? should i make 2 request for each of the entitlement ?

Device: iPhone 15 Pro Max, iOS 26.4 Xcode: Latest version, development signing with "Automatically manage signing" Team: Registered Apple Developer Program (Organization) Problem DeviceActivityReport SwiftUI view renders completely blank. The Report Extension's makeConfiguration(representing:) is never called (confirmed via App Group counter that stays at 0). The DeviceActivityMonitorExtension callbacks (intervalDidStart, eventDidReachThreshold) also never fire. What works AuthorizationCenter.shared.requestAuthorization(for: .individual) → .approved DeviceActivityCenter().startMonitoring() → registers schedules successfully, center.activities returns them ManagedSettingsStore.shield.applications → blocks apps correctly from the main app process Screen Time is enabled and actively collecting data (Settings > Screen Time shows per-app usage: Clash Royale 2h 35m, etc.) App Group UserDefaults(suiteName:) read/write works from the main app What doesn't work DeviceActivityReportExtension.makeConfiguration() is never called (callCount stays 0 in App Group) DeviceActivityMonitorExtension.intervalDidStart() is never called No extension callbacks fire at all — the extension process is never launched by iOS Confirmed it's NOT our app's issue We created a brand new Xcode project from Apple's template: File > New > Project > App File > New > Target > Device Activity Report Extension Added Family Controls capability to both targets Embedded DeviceActivityReport view in ContentView with daily filter Built and ran on the same device Result: Same blank screen. The template project's Report Extension also never renders any data. Console errors Failed to locate container app bundle record. The process may not be entitled to access the LaunchServices database or the app may have moved. (501) personaAttributesForPersonaType for type:0 failed with error Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction." LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" What we've tried Deleting app, rebooting device, reinstalling Re-requesting FamilyControls authorization on every launch Embedding extensions with "Embed & Sign" (not just "Embed Without Signing") Verified all 3 .appex files are in PlugIns/ directory at runtime Verified App Group (group.com.parentguard.app) is accessible Verified all App IDs and capabilities registered in Apple Developer portal Tried different DeviceActivityFilter configurations (daily, hourly) Placed DeviceActivityReport view at root of view hierarchy Clean build, new provisioning profiles Extensions embedded [Diagnose] Found extension: DeviceActivityReportExtension.appex [Diagnose] Found extension: DeviceActivityMonitorExtension.appex [Diagnose] Found extension: ShieldConfigurationExtension.appex Question Has anyone gotten DeviceActivityReport or DeviceActivityMonitorExtension to work on iOS 26.4 with a development-signed build from Xcode? Is there a specific configuration or workaround that makes the extension process launch? The Sandbox restriction error (159) on usermanagerd.xpc seems to be the root cause — is there an entitlement or device setting we're missing?

We’re building an iOS app that uses an ILMessageFilterExtension to classify unwanted property-related SMS messages. Our goal is for filtered/junk messages to trigger an automatic scan/classification flow so the main app can show the user useful stats like “X messages blocked since your last check-in,” and ideally categorize them by type such as likely wholesaler, investor, realtor, scam, or unclear. The bottleneck we’re running into is understanding the correct architecture and limits of the Message Filter Extension. We know the extension can inspect sender/message content and return allow/junk, and we understand that network requests are limited to Apple’s deferred query flow. What we’re trying to clarify is whether there is an Apple-compliant way for the extension to persist lightweight scan results or aggregate counts that the containing app can later read, without violating privacy or extension restrictions. We do not need to export a full copy of message bodies into the app; what we want is a compliant way to keep counters/summary metadata such as blocked count, blocked since last app open, and maybe category counts. Questions we’re trying to answer: Is it acceptable for an ILMessageFilterExtension to persist aggregate scan stats for later display in the main app? If so, what is the recommended storage pattern for lightweight counters/metadata? Can extension-side classification results be surfaced to the app only as summary data, not raw message content? If using deferred network classification, what is the best way to reflect those results back into user-facing counts like “messages blocked since last check-in”? Our desired user experience is: unwanted message hits the filter filter classifies it locally or via deferred server lookup message is junked if appropriate aggregate counters are updated when the user opens the app, they see something like: 12 messages blocked since your last check-in 8 likely wholesalers 3 scams 1 unclear We’re mainly looking for guidance on the correct Apple-supported architecture here, especially around what data can be retained/shared between the extension and the containing app.

Hello, I have submitted the Family Controls Distribution entitlement request twice, but I have not received any confirmation email or follow-up number for either submission. App: parental control app Bundle ID: com.learnunlock.app Use case: We use FamilyControls (authorization), ManagedSettings (shield apps), and DeviceActivity (schedule restrictions) to help families manage screen time. Could anyone from Apple please check the status of my submissions, or advise on next steps? Thank you.

When I tap on one of the buttons in the ShieldAction extension I want to close the shield and open the parent app instead of the shielded app. Is there any way of doing this using the Screen Time API? class ShieldActionExtension: ShieldActionDelegate {      override func handle(action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void) {     // Handle the action as needed.           let store = ManagedSettingsStore()               switch action {     case .primaryButtonPressed:       //TODO - open parent app       completionHandler(.defer)     case .secondaryButtonPressed:       //remove shield       store.shield.applications?.remove(application)       completionHandler(.defer)         @unknown default:       fatalError()     }   }   }

Hi We are trying to set the child's age but kind of stuck in loop in Age Range SetUp. Attached a video for reference. Could you please suggest what steps we are missing or is this a Bug from Age Range Services Framework.

Hi all, I'm the developer of OV Message, an end-to-end encrypted SMS messaging app already shipped on Google Play (Android, where it natively encrypts SMS content). The iOS port aims to be the default carrier-messaging app, handling SMS, MMS, and RCS through TelephonyMessagingKit with the com.apple.developer.carrier-messaging-app entitlement under the EU programme. While testing the cold-launch flow on iOS 26.x, I've hit a reproducible bug that silently drops the first SMS/MMS/RCS that wakes the app, and I'd like to confirm whether other devs working with this API see the same. The bug When a default carrier-messaging app is force-killed and a message arrives, iOS correctly: Routes the message via CommCenter (IMS in my case — SFR France) Wakes the app in background (state = .background at didFinishLaunchingWithOptions) Acquires a TelephonyMessaging runningboard assertion on the app But CommCenter then pushes the pending message via XPC before the client TMK library has finished registering its messageHandlersByID dictionary. Result: client responds Received unhandled request, server logs TMKXPCError Code=2, message is dropped, never delivered to for await in incomingMessageNotifications. Subsequent messages (with the app warm) work fine. Native log sequence (from idevicesyslog with the Telephony logging profile) T+0.000 CommCenter: SMS arrives via IMS (k3GPP) T+0.003 CommCenter: Default app is set to com.example.app T+0.004 CommCenter: Attempting to launch and acquire process assertion T+0.083 CommCenter: Notifying SMS message received, target: bundleID=... T+0.085 CommCenter(TMK): There are no client connections matching, pending message [~125 ms — app boots] T+0.128 App(TMK): Configuring connection T+0.128 App(TMK): Pinging remote end T+0.130 CommCenter(TMK): Received new connection from PID T+0.130 CommCenter(TMK): New incoming connection, flushing pending messages (1) ← server flushes T+0.130 App(TMK): Received unhandled request ← client not ready T+0.131 CommCenter(TMK): Failed to send pending message: TMKXPCError Code=2 T+0.132 App(TMK): Registered for IncomingMessageNotification (smsReceived) ← ~2 ms too late The race window between Pinging remote end (client) and Registered for IncomingMessageNotification (client) is 2–7 ms across my measurements. CommCenter considers the connection ready as soon as the ping completes, but the client library populates messageHandlersByID slightly after, so the dispatch fails. Minimal reproduction I built a ~50-line Swift app to confirm this isn't specific to OV Message. UIKit AppDelegate, single for await in TelephonyMessagingSession.shared.smsService.incomingMessageNotifications started in didFinishLaunchingWithOptions. No SwiftUI, no other modules, no Darwin notifications. Just TMK. Steps: Build & install on iPhone iOS 26.x with carrier-messaging-app entitlement (auto-provisioned in iOS 26) Settings → Apps → Default Messaging → select the test app Force-kill, then send 2 SMS in rapid succession from another phone Wait 30 s, open the app — log shows only the 2nd SMS Same result: the 1st SMS is gone. I've reproduced this consistently dozens of times. Source code (Swift + xcodegen project.yml): https://gist.github.com/ovmessage/fbc529292a65222191bec6ce5e5a4275 What I've tried Task.detached(priority: .userInitiated) to decouple the for await from main thread scheduling — no effect (race is internal to TMK lib, before our scheduling) Pre-fetching cellularServices synchronously — no effect Subscribing MMS + RCS in parallel — no effect Direct XPCSession/xpc_connection_create_mach_service to com.apple.commcenter.tmk.xpc — Apple has marked these unavailable on iOS for 3rd-party apps (no public way to bypass the lib) I've also done runtime introspection of the TMK framework via Mirror, which confirms the architecture: a single XPCConnection.messageHandlersByID dict shared by smsReceived, mmsReceived, rcsReceivedNotification — all four entries (incl. serviceStatusNotification) are populated after the XPC ping. So the same race affects SMS, MMS, and RCS equally. Suggested fixes (Apple-side) Either: Server (CommCenter): defer flushing pending messages until the client confirms its handlers are registered (extra XPC handshake message) Client (TelephonyMessagingKit): register messageHandlersByID entries before sending Pinging remote end, so they exist when the server starts flushing Buffer client-side: cache messages received before handler registration completes, dispatch on attach Filed in Feedback Assistant FB[YOUR_FB_NUMBER_HERE] Question for fellow devs If you're also building with carrier-messaging-app entitlement (Beeper, Google Messages on iOS, anyone in the EU programme), can you confirm whether you see the same race? Especially interested in whether: It happens with non-IMS carriers (mine is SFR France, IMS-routed via SIP) iOS 26.1 / 26.2 changed the timing Anyone has found a workaround I haven't tried Thanks.

Hi everyone, We are investigating a possible iOS permission state issue after a device previously installed our app through TestFlight and later installed the production version from the App Store using the same Bundle ID. Environment: Device: iPhone 15 iOS version: 26.2.1 App distribution history: The app was previously installed through TestFlight and later installed from the App Store Permissions involved: Camera / Photos Issue: When the user opens the App Store version of the app and tries to access a feature that requires Camera or Photos permission, the iOS permission prompt does not appear as expected. Also, the app does not appear under: Settings > Privacy & Security > Camera or: Settings > Privacy & Security > Photos Because of this, the user cannot manually enable the permission. Another user on iOS was able to grant the permissions normally, so the issue appears to be isolated to the device that previously used the TestFlight build. Expected behavior: When the App Store version requests Camera or Photos permission, iOS should display the permission prompt, or the app should appear under Settings > Privacy & Security > Camera/Photos so the user can manage the permission manually. Actual behavior: The permission prompt does not appear, and the app does not appear in the corresponding privacy permission list. Possible cause: It seems like the device may be preserving or reusing a stale privacy permission state from the previous TestFlight installation, since both the TestFlight build and the App Store build use the same Bundle ID. Steps to reproduce: Install the app through TestFlight. Open the app and trigger a Camera/Photos permission request. Grant or deny the permission. Stop testing or remove the TestFlight version. Install the production version from the App Store using the same Bundle ID. Open the App Store version. Trigger the same Camera/Photos permission request flow. Go to Settings > Privacy & Security > Camera/Photos. The app does not appear, or the permission prompt does not behave as expected. Workarounds attempted or suggested: Close and reopen the app. Restart the iPhone. Delete and reinstall the app from the App Store. Stop testing the app from TestFlight. Reset Location & Privacy settings. Question: Has anyone experienced a similar issue where iOS does not show the permission prompt or does not list the app under Privacy & Security after switching from a TestFlight build to the App Store version with the same Bundle ID? Is there a recommended way to fully clear the previous TestFlight permission state, or should this be reported as a possible iOS/TestFlight permission state bug?

I'm developing an iOS application that relies on peer-to-peer discovery and connection using Bluetooth. The expected behavior is: Two iOS devices with the application installed. Both users marked as "visible". When within Bluetooth range, the devices should discover each other and establish a connection. However, the problem occurs when: The application is in the background (minimized) OR The device is locked (screen off). In these states: The devices can no longer be detected. The search returns no nearby devices. Connection could not be established. ChatGPT: What you want to do probably runs into a structural limitation of iOS — it's not a bug. And iOS: severely limits background BLE scanning. reduces advertising frequency. may even stop completely depending on the state (lock screen). In other words: 👉 iPhone was not designed to function as a "continuous radar" between background apps. Apps that do something similar (like AirDrop or Find My): use Apple's private or privileged APIs or combine BLE + Wi-Fi + Ultra Broadband. i need help : /

Hi all, Our team (D36U48VRGM) holds approved Family Controls (Distribution) entitlement on three bundles, all live on the App Store as part of the same app: com.strategieayoub.quranfocus (main app) com.strategieayoub.quranfocus.ShieldAction com.strategieayoub.quranfocus.ShieldConfiguration We've added a fourth target — a DeviceActivityMonitor extension at com.strategieayoub.quranfocus.DeviceActivityMonitor — to replace our current BGProcessingTaskRequest re-shield path. The BGTaskScheduler approach is unreliable for our use case: iOS routinely runs the task hours late or skips it entirely, leaving users' apps unblocked far past the unlock window we promised. DeviceActivityMonitor's intervalDidEnd callback is the only mechanism Apple provides that fires reliably regardless of app state. The new bundle ID is registered, has Family Controls (Development) provisioned, and intervalDidEnd works correctly during local on-device testing. The blocker is Distribution — Xcode's Signing pane shows: "Bundle identifier is using development only version of Family Controls (Development) capability. Please request access to Family Controls (Distribution) to avoid issues when distributing." Two questions: The previous per-asset Family Controls request form has been replaced with a single account-level form that contains no free-text field where I can specify a bundle ID. How does Apple now expect developers with already-approved teams to attach an additional child bundle to that approval? Phone Developer Support said they cannot make entitlement attachments and pointed me back to the form. Is there a documented escalation path? Thanks for any pointers.

I'm working on a MailKit extension and I'm getting a full Mail crash every time I click the Primary Action button in my message banner. I have filed a feedback: FB22513160 Apple's own unsubscribe banner successfully presents a confirmation modal when its primary action is clicked, demonstrating that this flow is intended to work. That behavior does not appear to be accessible to third-party extensions via the documented EMessageSecurityHandler API. Or if it is and I'm missing something, I'd love to know. Thanks!

Hello, I want to echo the DeviceActivityReport "concurrency" problems flagged in https://developer.apple.com/forums/thread/720549, and ask a related question. (Thanks to Kmart and other Apple dev support folks who have been monitoring these forums and responding diligently.) I would like to display daily and weekly stats in the same view, broken down by specific apps (as in the native Screen Time). However, instantiating multiple DeviceActivityReport objects with different filters and/or different contexts leads to confusion, where the two views will incorrectly and intermittently swap data or duplicate data where it shouldn't (seemingly upon some interval when the extension provides fresh data). There isn't documentation on how to display multiple reports at once. Is the idea that logic for multiple reports should be embedded within the extension itself in the makeConfiguration() function and there should only be a single DeviceActivityReport in the main App, or is this a bug? Even with a single DeviceActivityReport, I run into inconsistencies where the View provided by the extension takes multiple seconds to load or fails to load altogether. The behavior seems random...I will build the application with the same code multiple times and see different behavior each time. Finally, a plug for better support in the Simulator for the entire set of Screen Time APIs. Thanks!

Hello, I submitted a request for Family Controls (Distribution) approval, and it has now been over 4 days without any update on the status. I understand that review times can vary, but I wanted to check if this delay is expected or if there’s anything I might need to do on my end to help move the process forward. Could anyone from the Apple team or the community provide insight into: Typical processing times for Family Controls distribution requests Whether delays beyond a few days are common Any steps I should take to follow up or expedite the review For reference: Status: Submitted Submission time: April 21, 2026 Any guidance would be greatly appreciated. Thank you!

I've already submitted multiple cases about this issue. My Family Controls Distribution request was apparently approved (or I was told via Developer Support) for my Shield Action & Shield Configuration extensions, but the Distribution option still does not appear in the identifiers. This is blocking my ability to distribute via TestFlight. I need someone who can update the identifier capabilities or explain why the approved capability is not showing.

I submitted a Family Controls Framework Entitlement request on April 16, 2026 for my iOS app (Team ID: U3BVGVPCEH). After 11 days, the request still shows "Submitted" with no status update or email communication. I submitted two additional requests on April 20 and April 23 thinking the first had failed (no confirmation email was ever received). All three show "Submitted": J5DLD62PNZ — April 16 VV8B272DHZ — April 20 D362NT677B — April 23 I also opened a Developer Support ticket on April 23 with no response yet. Can anyone help me a bit? I cannot distribute my app by Testflight and I need it for my PhD.

Looks like the Weather Kit API is not responding. I experience the same with Weather App - API is returning 504 HTTP errors I was wondering if I was alone on this situation In this example: in my app the weather complication is consuming my weather provider which is based on Weather Kit Thank you for your answers. Ilyes

Weatherkit rest api and framework both dont response any request? Is it temporary issue?