Hello, I am developing an iPhone application to help users avoid missing important phone calls. The intended behavior is: A user receives a regular cellular call through the built-in iPhone Phone app. The user does not answer the call. Our application automatically detects the missed call. The application schedules repeated local notifications until the user acknowledges the missed call. The critical requirement is that detection must work while our application is in the background, without the user reopening it. Implementation We currently use CXCallObserver to observe cellular call events. When an incoming call ends without being connected, we classify it as a missed call and schedule notifications using UNUserNotificationCenter. Test environment Device: iPhone 17 iOS: 26.7.1 Distribution target: Standard App Store, Japan Testing: Physical device without an attached Xcode debugger Observed behavior Scenario A: Our application is visible immediately before the iPhone is locked. Missed calls have been detected and notifications scheduled after more than 30 to 60 minutes of device lock. Scenario B: Our application is moved to the background before the iPhone is locked, for example by returning to the Home Screen or opening Safari. Missed calls are not detected promptly, even after only a short period in the background. When the user subsequently opens our application, CXCallObserver callbacks may arrive and the earlier missed call is then detected. This defeats the purpose of the application because the user must reopen it to receive alerts. Questions Is CXCallObserver expected to deliver callbacks while its application is suspended, or only when the process is executing? Is there any supported public iOS API, extension, or background execution mechanism that allows a third-party application to detect missed calls from the built-in Phone app while the application is suspended or terminated? Can a regular cellular missed-call event wake or relaunch a third-party application? If CXCallObserver cannot support this use case, is there another Apple-supported solution available to ordinary App Store applications distributed in Japan? We are looking for an approach that does not require external hardware, carrier integration, private APIs, or unsupported background execution techniques. If this use case is not supported by the public iOS SDK, confirmation of that limitation would be very helpful. Thank you for your guidance.

When i use the MFMailComposeViewController in visionOS, there is no cancel button for the controller. The button at the bottom closes the app. Is anyone else experiencing this? if([MFMailComposeViewController canSendMail]) { MFMailComposeViewController* controller = [[MFMailComposeViewController alloc] init]; controller.mailComposeDelegate = (id <MFMailComposeViewControllerDelegate>)view; [controller setToRecipients:toAddresses]; [controller setSubject:subject]; [controller setMessageBody:body isHTML:isHtml]; [view presentViewController:controller animated:YES completion:nil]; }

I wrote a python script MXSymbolicate to symbolicate crash reports produced by MetricKit. To symbolicate a given frame, it needs the symbol file for that frame's library. For system libraries, my system only has the requisite files on disk if I've plugged an iOS device of that type at that iOS version into my computer at some point (I assume these symbol files from the device are generated by Xcode when it's preparing to debug on a new device). All these different versions of the symbol files take up a fair bit of space on my machine over time, and it means the symbolication process isn't very portable. Is there a better way to get ahold of symbol files for system libraries? Or is the expectation that we (as third party developers) only symbolicate the frames from our own apps?

I am developing a watch-only bedside clock for an Apple Watch running watchOS 27.0.1. The user needs to remove the watch in hot weather and still see the time without having a charger available. The requirements are: wrist detection remains enabled; the watch is off wrist and unplugged; the app is opened manually on the watch; the clock remains visible without periodic touches or any Mac/developer connection. Covering the screen should turn it off. The UI contains only the time, date, and battery level. It does not need protected data, HealthKit access, or programmatic unlocking. Independent physical testing still ends in the app transitioning to the background and the display turning off. Always On configuration and background runtime are not sufficient in the tested off-wrist state. Experimental idle-display requests either have no visible effect or extend the visible period to approximately 60 seconds. Updating the native scene's requested idle duration every 20 seconds does not renew the observed display deadline, despite the local readback showing the requested values. Is there a supported public API or system-owned presentation surface that can keep a nonsensitive clock visible in this situation while preserving wrist detection and authentication? If this requires an approved entitlement or a platform capability, is one available to third-party developers for this use case? Please distinguish keeping the process alive, retaining the frontmost app, and keeping the physical display visible after removal from the wrist. I have not claimed additional entitlements or changed the watch's authentication settings. I would appreciate clarification of the supported platform boundary before undertaking further device experiments.

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)

Hi there, I'm planning to develop a simple underwater compass app for Apple Watch Ultra 2, intended for recreational scuba diving down to 40 meters. The app itself does not need depth or pressure measurements beyond 6 meters. Its primary function is compass navigation using heading data. During a dive, however, I would like the app to: remain frontmost and visible throughout the dive; use Water Lock; use an underwater-depth WKExtendedRuntimeSession; continue receiving compass heading updates; allow interaction through physical controls such as the Digital Crown and Action Button; remain operational below 6 meters, potentially down to 40 meters. I understand that the Shallow Depth and Pressure capability limits CMWaterSubmersionManager depth/pressure data to approximately 6 meters, while access to depth/pressure data down to 40 meters requires the full Submerged Depth and Pressure entitlement. My question is: If my app does not require depth/pressure measurements beyond 6 meters, is the full Submerged Depth and Pressure entitlement still required simply to keep the underwater extended runtime session, UI, compass heading updates, and physical-control interaction working below 6 meters? In other words, does the 6-meter entitlement limit apply only to depth/pressure data, or does it also limit the ability of an underwater compass app to remain operational during a scuba dive below 6 meters? Target hardware: Apple Watch Ultra 2. Thanks in advance!

Hello, We are developing a macOS app using Apple-Hosted Managed Background Assets (MBA). Our resources are strictly coupled to specific app binary versions (e.g., App v1.0 is incompatible with Asset Pack v2.0 due to data schema and data format changes). We plan to use Essential asset packs, but also plan to provide an in-app fallback using ensureLocalAvailability during initial launch to handle cases where background downloads fail or are delayed. We have questions regarding the version-resolution behavior and Apple's recommended architecture for version-coupled assets. Scenario A user installs App v1.0 (which targets Asset v1.0). The initial Essential download fails (e.g., network disconnect). The user opens the app without local assets. Later, Asset v2.0 is released to the App Store alongside App v2.0. The user on App v1.0 launches the app and calls ensureLocalAvailability. Questions [1] Version Resolution & Fallback Behavior When an app has no local asset pack installed and calls: try await AssetPackManager.shared.ensureLocalAvailability( of: appResources01, requireLatestVersion: false // or the legacy ensureLocalAvailability(of:) ) Does the system always fetch the latest live version in the App Store (v2.0), or is there any mechanism to retrieve the historical version compatible with App v1.0? Is it possible for an app to explicitly request a specific Asset Pack version rather than the currently active App Store version? [2] Scope of shouldDownload(_:) Does ManagedDownloaderExtension.shouldDownload(_:) get invoked during an explicit in-app call to ensureLocalAvailability? Or is shouldDownload(_:) exclusively called for system-initiated background download cycles? [3] Recommended Architecture for Version-Coupled Resources If an application cannot maintain backward compatibility within a single continuously versioned Asset Pack (v1 → v2 → v3), what is Apple's recommended design pattern? Option A (Separate Identifiers): Define distinct Asset Pack identifiers for each incompatible app generation (e.g., AppResources-v1, AppResources-v2)? Option B (Forced App Update): Use a single Asset Pack identifier and require older app versions to prompt a forced app update via the Mac App Store if assets are missing and incompatible? Option C: Is there another recommended mechanism within Background Assets for managing strict asset-binary version coupling? Thank you for your guidance!

iOS 27, See image below. From top to bottom I'm using: displayName containerDisplayName contentDescription I haven't found a way to remove the transaction amount from my containerDisplayName and display it in the top right with some other CSSearchableItemAttributeSet value. Is it even possible?

I'm developing a digital wellbeing app using FamilyControls and DeviceActivity. The core functionality of the app is to show the user their per-application Screen Time usage, including the application identity and duration (for example, Instagram — 1h 30m, YouTube — 45m). I understand that on iOS 26.4+, AuthorizationStatus.approvedWithDataAccess and DeviceActivityData.activityData(filteredBy:using:) provide access to non-tokenized application usage data. I also understand the current Apple documentation states that customer installations can only obtain approvedWithDataAccess on devices located in the EU with an Apple Account configured to an EU country or region, and that outside the EU the authorization status never becomes approvedWithDataAccess. My app and test device are based in Kazakhstan. My question is not about bypassing Apple's privacy model or implementing an undocumented workaround. I would like to know whether there is any official path for a legitimate third-party Screen Time / digital wellbeing app to obtain this data outside the EU, for example: an additional entitlement; a developer approval or application process; a regional exception; an alternative Apple-supported API; or any other official mechanism. We already have the Family Controls distribution entitlement approved and have enabled the Family Controls App and Website Usage capability. If no such mechanism exists, I would appreciate confirmation that the EU restriction is currently absolute for customer installations and that there is no additional entitlement or approval process available for developers outside the EU. The reason I am asking is that per-application usage is a core part of the application's functionality, so I want to make sure I am not missing an official Apple-supported option before designing around this limitation.

We are implementing regional age-assurance checks for an iPhone app that supports iOS 17 and later. It is a paid toddler app with no backend, app accounts, ads, in-app purchases, messaging or shared user content. All content is suitable for young children. Optional family voice recordings remain on the device. We plan to request Declared Age Range when Apple's regulatory signals require it, process the response locally, and avoid logging, storing or transmitting age data. We are seeking supported technical behavior, rather than legal advice or preapproval: What supported API or platform guarantee establishes that initial download/purchase parental consent was obtained? The age-range response does not appear to expose a separate initial-consent status. Apple's age-assurance Q&A says the platform prevents launching an app after a parent revokes consent. The implementation guidance also describes RESCIND_CONSENT through App Store Server Notifications. For an app with no backend or remotely accessible service, can local access rely on the platform's launch blocking, or is a notification server still required? If a server is required, what local enforcement behavior should it drive? What is the supported behavior for offline reopening and unavailable or network-error results, particularly on older supported iOS versions where the regulatory APIs are unavailable? Does platform enforcement also cover an app already running when consent is revoked, and how should an offline app handle that transition? Documentation or a sample showing this entirely local case would be helpful.

After transferring the App ownership to a different account, if you update the app on iOS, two identical apps will show up in Settings > Screen Time. Users can't control the blocking settings from before the update - the only fix is to restart the phone. After the next execution of manageStore.shield.applications, users still can't manually disable the restrictions - their only option is to uninstall and reinstall the app. I believe this is related to how Screen Time API's authentication works - it's not just tied to the app's bundle ID, but also linked to the developer account's organization ID. Any suggestions for a clean solution that would allow smooth app updates after the transfer without running into these issues?

I’m looking for clarification on how Apple retrieves the apple-app-site-association (AASA) file for Universal Links / Associated Domains. Assume a domain exposes the AASA file at: https://example.com/.well-known/apple-app-site-association The domain is protected by Geo-Blocking, where access from certain countries/regions is restricted. I would like to understand the expected network behavior for AASA retrieval: Can requests to retrieve the AASA file originate from Apple infrastructure in different countries or regions globally? Does Apple publish a list of source countries, IP addresses, IP ranges, or network ranges specifically used for AASA retrieval? Can the source country or IP address change over time due to Apple's infrastructure, CDN, or routing? Is there any supported way to force AASA retrieval through a particular region, such as the US? If certain countries are blocked, is there any way to determine whether Apple may use infrastructure from those countries for AASA retrieval? Is the recommended approach to allow the following endpoint to be publicly reachable regardless of source geography? The objective is to restrict access as much as possible while ensuring that Universal Links continue to work reliably. If there is any official Apple documentation covering the source network, IP ranges, geographic locations, or accessibility requirements for AASA retrieval, a reference would be greatly appreciated.

I’m evaluating an iOS app that uses Family Controls / DeviceActivity for an adult user’s voluntary personal device-management and digital-wellbeing goals. The app would also have an optional social competition feature where friends participate in fantasy-style leagues based on completion of their individual digital-wellbeing goals. I’m trying to understand the restrictions in Apple Developer Program License Agreement Section 3.3.3(P), specifically whether a privacy-preserving result derived locally from Family Controls / DeviceActivity can leave the device when the underlying usage data never does. I’m considering three architectures: A — Locally derived fantasy score DeviceActivity information is evaluated entirely on-device and converted locally into an abstract score. The server receives only: fantasy_points = 82 No Screen Time duration, app identity, website activity, bundle identifier, or underlying usage information leaves the device. B — Binary goal completion A user creates a private usage goal, such as remaining below their chosen daily device-usage threshold. The goal is evaluated entirely on-device. The server receives only: goal_completed = true The server then awards predetermined fantasy points. It never receives the underlying Screen Time value. C — Opaque challenge completion A user privately selects an app/activity goal. DeviceActivity evaluates the threshold locally. The server receives only: challenge_id = C928 completed = true The server knows C928 is worth a predetermined number of points, but does not receive the selected app identity, usage duration, Screen Time quantity, or other underlying DeviceActivity information. In all three approaches, raw Screen Time duration, per-app usage duration, application/bundle identity, website activity, DeviceActivity reports, and underlying historical usage records would remain on-device. Friends would only see fantasy points, matchup results, standings, and/or achievements. My question: Under Section 3.3.3(P) and the Family Controls requirements, are any of A, B, or C permitted? More specifically, does Apple consider an abstract score, boolean goal-completion result, or opaque challenge-completion result to itself be “device or usage data” when it was derived from Family Controls / DeviceActivity? If none of these architectures are permitted, is there a supported privacy-preserving architecture that allows an on-device DeviceActivity evaluation to affect a server-side social or multiplayer feature without transmitting the underlying device/usage information? I’m trying to establish the compliant architecture before development rather than build around an incorrect interpretation of the Family Controls requirements.

I'm developing an iOS parent-child app that uses FamilyControls and DeviceActivity. Before distribution, I need to test AuthorizationCenter.shared.requestAuthorization(for: .child), including the guardian approval flow. So far I have tested .individual, which authenticates the device owner and does not exercise the child flow. Apple Developer Program Support directed me to this forum. What is the Apple-supported way to test this flow in this situation? Is there an Apple-supported test-only account or setup for this flow without using a child's personal Apple Account? If so, where are its requirements documented? If not, what is the recommended alternative? Can Sandbox Apple Accounts used for StoreKit Family Sharing tests be used to sign in to iCloud and test FamilyControls .child, or are they limited to purchase testing? Is there a supported simulator or other test method for guardian approval, or must this be verified using a child Apple Account in a real Family Sharing group on physical devices? I want to follow Apple's account rules and test the actual parental authorization path before distribution. References to official guidance would be appreciated.

(lldb) p [@"ΗΙzzz" caseInsensitiveCompare:@"ᾚabc"] (long long) -1 (lldb) p [@"ᾚabc" caseInsensitiveCompare:@"ΗΙzzz"] (long long) -1 Note the unicode char in the second string. The results can't be both -1, afaik, if one is -1 the other one should be +1. This causes inconsistent indexing in a sorted array resulting in obscure crashes of my app. Am I doing something wrong? Tested on iOS 27 and macOS 26.6.

We ship a Live Caller ID Lookup extension (PIR-based) for spam call blocking. It works, and our PIR server is fast. But in practice, whether a call gets blocked depends on the quality of the user's internet connection at the moment the call arrives. The system waits only about 1 second for the blocking response. On a fast, stable connection it arrives in time. On an average or unstable connection it often doesn't, and the spam call rings through. So under the current platform limits we cannot guarantee blocking for every call. How we measured For each call we read the device syslog (CommCenter, CallDirectory, ciphermld, callservicesd) and our server logs. The extension cache was reset before each call, so every call triggered a real network lookup. All times are in ms and measured from addNewIncomingCall. Server-side processing of the PIR query was consistently 51–61 ms. The variance is almost entirely network transfer between the device and the server (or relay): In call D, HTTP/2 metrics show the ~28 KB request was handed to the network stack immediately (outbound_duration_ms=0), but response headers arrived only after 2216 ms. In call E, the device waited ~660 ms between finishing the upload to the relay and receiving the first byte of the response. Connection setup on a new connection cost 176–271 ms (DNS + TCP + TLS, or a QUIC handshake to the relay). Before the first byte was sent, the system spent another 54–225 ms after the call arrived. In the failing cases the syslog shows: CallDirectory: not all blocking fetches returned within 1 second(s) callservicesd: shouldBlock: NO shouldSilence NO The block response (shouldBlock=1) then arrives 100–1500 ms too late, and the call keeps ringing. What works: repeat calls After the first lookup the result is cached on the device. A repeat call from the same number is silenced without contacting the server, whatever the connection speed. In our logs, follow-up calls from the same number were silenced within ~65 ms of addNewIncomingCall, with no network request. So a user may get the first spam call from a number but not the next ones. The first call, though, is exactly the one users complain about. The problem with the 1-second budget Each blocking lookup has to: Send a PIR query Receive a response of ~22–25 KB. Often open a new TLS/QUIC connection through the OHTTP relay. All of this has to fit into about 1 second, together with the system's own overhead before the request is sent. On a good connection that takes about 250–650 ms. On an average mobile or congested Wi-Fi connection it easily goes past 1 second, and nothing the developer can optimize on the server helps. Our server already responds in about 50 ms.

I have an app that I am implementing background assets, using self hosted unmanaged. Everything compiles fine, and I get no errors. But I can't figure out how to trigger the 'install' phase into the extension. I have tried copying the app into /Applications without luck. I have deleted the entire DerivedData and all copies of the application. Nothing seems to work. I tried using the Apple provided sample app from here and got the same results. I don't understand why the CLI tool backgroundassets-debug only works with iOS based connected devices? Please let me know how can I test my BADownloaderExtension on Mac via XCode. Thank you.

My share extension accepts a shared location and I want to bring the user into the containing app at the corresponding map screen. I understandNSExtensionContext.open(_:completionHandler:) is restricted to Today widgets per the App Extension Programming Guide, and I observe it reporting success == false. The technique I am asking about is different: walking the extension's responder chain to obtain the UIApplication instance, then calling open(_:options:completionHandler:) on it. In a minimal sample this launches the containing app and the completion handler reports success == true, on both iOS 26 and iOS 27. What makes this worth asking rather than assuming: It never references UIApplication.shared, which is annotated NS_EXTENSION_UNAVAILABLE_IOS. open(_:options:completionHandler:) itself carries no extension-unavailable annotation in the SDK, so the call compiles cleanly even with APPLICATION_EXTENSION_API_ONLY = YES. I am aware of https://developer.apple.com/forums/thread/773342, where an Apple Frameworks Engineer wrote that "There's no supported way for you to launch your app directly from App Extensions, except Today and Widgets." That thread does not cover the responder chain specifically, which is why I am asking. My questions: a) Is this permitted? Is obtaining UIApplication via the responder chain from a Share Extension and calling open(_:options:completionHandler:) considered a violation of App Store Review Guideline 2.5.1 (public APIs used as intended), independent of whether it currently functions? b) If it is not permitted, what is the recommended way for a Share Extension to hand a location to its containing app such that the user arrives at the relevant screen? The code in question, in its entirety: @objc private func openUsingResponderChain() { var responder: UIResponder? = self while let currentResponder = responder { if let application = currentResponder as? UIApplication { application.open(targetURL, options: [:]) { [weak self] success in self?.report("UIApplication via responder chain -> success = \(success)") } return } responder = currentResponder.next } report("No UIApplication found in the responder chain") } Full sample project: https://github.com/valtermak-voya/share-extension-open-url-repro A containing app registering opensample:// plus a share extension target built with APPLICATION_EXTENSION_API_ONLY = YES. The method above is the whole of the extension's logic. Filed with DTS as Case-ID 22452440.

We ship a ~6.2 GB Apple-hosted managed asset pack and request it with AssetPackManager.ensureLocalAvailability(of:). If the app goes to the background even once while the download runs, the transfer continues to the end and then fails with ManagedBackgroundAssetsProcessingPipeline.Dispatcher.PipelineNotFound. The system discards the resume data, and the next attempt starts again from byte 0. What the sysdiagnose shows: On backgrounding, backgroundassets.user logs allows BG activity, pausing any foreground downloads for background demotion and hands the download to nsurlsessiond. On return it logs re-promoted 1 previously-demoted foreground downloads. Each handoff moves the stream to another STExtractionService.privileged instance, which logs No processing pipeline with the ID "…" was found; defaulting to an extraction memory footprint of 50 MB. When the HTTP response ends: [Relay] No endpoint was found for the key "…" (fault) → The stream couldn't be finished: No processing pipeline with the ID "…" was found → Removing the resumption info → the download fails. This happened on every app-requested download that was backgrounded at least once. One run reached 100 % in the foreground and still failed. The only download that ever completed was the system's own prefetch download, which ran entirely in the background with the app never launched. Over one afternoon about 46 GB were downloaded for a single 6.2 GB pack. Questions: Is this a known issue with the demotion/promotion of foreground asset-pack downloads? Is AssetPack.download(for: nil) plus BADownloadManager.scheduleDownload(_:) a supported way to request a managed pack from the app, so the download never gets foreground priority? We're testing it now. Is there any other way to keep a download requested from a foreground app from being demoted? Filed as FB24888599.

Hello all, Looking for guidance for my app. I run a workout studio and the time frames for classes are all in military time. I have tried extensively to have this turned off and I am just unsure what is left to do. Has anyone dealt with something like this?