Hi Apple engineering team, I’m trying to integrate the new Live Caller ID Lookup (PIR) on iOS using your pir-service-example code as well as a custom mock server in Vapor, but the extension never advances past the /issue/token-key-for-user-token step. I’ve tried both: 1. Official Example Cloned https://github.com/apple/pir-service-example Ran PIRService locally Confirmed that GET /.well-known/private-token-issuer-directory → 200 GET /issue/token-key-for-user-token → 200 (DER bytes, correct SPKI) No POST /issue ever fires 2. Mock Server (Vapor) Implemented all five endpoints (/config, /.well-known/private-token-issuer-directory, /issue/token-key-for-user-token, /issue, /queries) Verified with curl and openssl asn1parse that: GET /.well-known/private-token-issuer-directory Content-Type: application/private-token-issuer-directory { "issuer-request-uri":"https://…/issue", "token-keys":[…] } GET /issue/token-key-for-user-token Content-Type: application/octet-stream <DER bytes> Added Cache-Control: public, max-age=3600 on directory and SPKI Stubbed POST /issue to always return { "token": "" } Still no POST /issue request from the extension Reproduction Steps Install and enable a Live Lookup extension pointing to my server. Trigger an incoming call on device. Watch server logs—only see the two GETs, never /issue or /queries. Expected Behavior After fetching the SPKI DER, the framework should issue a POST /issue call (Privacy Pass flow) and then POST /queries. Observed Behavior Stuck in an infinite loop of: GET /.well-known/private-token-issuer-directory GET /issue/token-key-for-user-token (repeat…) No progression to the /issue or /queries endpoints. What I’ve Tried Verified JSON kebab-case and headers exactly match examples Confirmed SPKI DER is valid via openssl asn1parse Added Cache-Control headers Tested on real device, localhost url, and ngrok public URL Mocked a valid-looking token response Could you advise what additional requirement or format detail I’m missing that prevents from advancing past /issue/token-key-for-user-token? These are the main files: LiveLookupExtension.swift routes.swift service-config.json Thanks in advance!

Hi Apple Developer Community, I'm implementing MetricKit launch performance tracking in our iOS app and need clarification on two properties: histogrammedTimeToFirstDraw histogrammedOptimizedTimeToFirstDraw The Documentation Problem: The official MetricKit documentation provides minimal explanation of these properties beyond their names. Based on naming conventions, I initially assumed: histogrammedTimeToFirstDraw = cold launches histogrammedOptimizedTimeToFirstDraw = warm/optimized launches Based on our measurements: The “optimized” metric appears only in a small fraction of launches The "optimized" metric is actually slower The naming suggests the opposite behavior Questions: What specific launch conditions does each metric measure? Why would "optimized" launches be slower and less frequent? Is histogrammedOptimizedTimeToFirstDraw related to iOS app pre-warming or prediction features? If these metrics don’t correspond to cold vs. warm launch times, is there an alternative way to measure them accurately? Any clarification from Apple or insights from developers who've tracked these metrics would be greatly appreciated.

We encountered an issue with iOS 26 and release version. We developed a voipout application and we created an entry in native call log on dev/prod version with our app that run under iOS 18.6 and earlier. On iOS 26 TestFlight version didn't create entry in call log but debug version did it. I don't find any clue in CallKit documentation for iOS 26 and we use action.fulfill(withDateStarted: .now) for call and end transaction and we develop under Xcode 26 Do you have any suggestion to solve our problems ?

Since the iOS 26.2 update, we have been experiencing anomalous behavior with the DeviceActivityMonitor extension when utilizing the ScreenTime API. Specifically, we are receiving the eventDidReachThreshold event within a few minutes of initiating monitoring, despite configuring a high usage limit. The process of turning off Screen Time -> restarting the device -> turning on Screen Time does not work. Any ideas? Thanks Filed Feedback Assistant: FB21560904

Hi, I'm using ScreenCaptureKit on macOS 14+ to record a single window. I've noticed that the Presenter Overlay only appears when capturing the entire screen, but it does not appear when recording a specific window or a region. Is there a way to enable the Presenter Overlay while recording a single window or a defined region, similar to how it works with full-screen capture? Any guidance or clarification would be greatly appreciated. Thanks in advance!

Hi Apple Dev community, I want to ask if CallKit and CXCallDirectoryProvider (with addBlockingEntryWithNextSequentialPhoneNumber) doesn't work for 3rd party Phone apps. Is this a known issue that CallKit doesn't work on 3rd party iOS Phone apps (like WhatsApp, etc)? Thank you.

Hello I'm working on Live Caller ID Lookup implementation on my own pet-project, as I understood I need to create app and extension for this app. I also created test PIR-service. I did configure serviceURL, tokenIssuerURL and userTierToken. In My app I implemented following code Task { if LiveCallerIDLookupManager.shared.status(forExtensionWithIdentifier: "some-extension") == .disabled { `//` Show an alert. print("LiveCallerIDLookupManager is disabled") } do { // Open Settings. try await LiveCallerIDLookupManager.shared.openSettings() } catch { } It does open Call settings, but I don't understand what should I do next.

I am still struggling to nail down the screen time between monitoring and showing it in a DeviceActivityReport. It's always off by a couple of percentage points, which results in a difference of a couple of minutes between the time shown for my total screen time in DeviceActivityReport and DeviceActivityMonitor with a threshold set for all apps/websites/categories. In the report, I am looping through all segment (there is only 1 segement using .daily segment interval for a given day) then loop through all categories and all apps within each category and sum up all totalActivityDuration for each app. Based on avaiable documentation, that should corrolate to DeviceActivityMonitor threshold but it doesn't. Are there any differences in how these 2 places count screen time? Are there any apps/core ios services which are excluded from DeviceActivityMonitor. Would appreciate any help at all, I'm losing my mind here. My current suspicion is that Apple Developer documentation is counted twice. i.e. this website https://developer.apple.com/documentation/deviceactivity/deviceactivitymonitor shows up in usage as an App with bundleId of apple.developer.wwdc-release and time spent there is counted twice, against this bundleId AND Safari. I don't know why it's not counted as a webdomain.

AgeRangeService is the burning topic right now. Needless to say, Everything is so unclear. We got our app finally into the TestFlight for QA and the product to test. only to find out that AgeAssurance for sandbox testing does not work. There is no document confirming or denying whether and when age assurance for the App with the release configuration in test flight would work. There isn't any guidance from Apple on whether an app that sells physical goods, such as an e-commerce app, can continue doing business as usual. Also, there is no clarity that the Age assurance options are off, 13, unverified, 13 verified, and so on. How those should be used.

Hi I'm trying to build a screen time app and the Apple docs and APIs really leave something to be desired. I want to block apps on a schedule. That's it. To do this I need my DeviceActivityMonitorExt to know which apps to block. I need to somehow pass a DeviceActivitySelection from the main app into this DeviceActivityMonitorExt. How can I do this?

Environment: macOS 15.2 (24C101) with Xcode 16.2 (16C5032a) Goal: I am trying to build a simple IMKInputController-based input method. Problem: My .app bundle registers successfully and I can select it as an input source. When selected, it blocks keyboard input, but my handle method does not seem to execute or produce output. I have placed NSLog statements in my controller's init and handle methods. Code for the controller: import InputMethodKit // The IMKTextInput protocol is provided by the framework. // We don't need to define our own bridging protocol for this test. public class HelloWorldController: IMKInputController { public override init!(server: IMKServer!, delegate: Any!, client inputClient: Any!) { super.init(server: server, delegate: delegate, client: inputClient) NSLog("HelloWorldIME: Controller has been initialized.") } public override func handle(_ event: NSEvent!, client sender: Any!) -> Bool { NSLog("HelloWorldIME: handle() method was called.") // ================== FINAL FIX APPLIED HERE ================== // 1. First, we ensure the client is a fundamental Objective-C object. guard let clientObject = sender as? NSObject else { NSLog("HelloWorldIME: Error - client object is not an NSObject.") return false } NSLog("HelloWorldIME: Successfully cast client to NSObject.") // 2. Now that we have an NSObject, we can safely check if it responds to the selector. let selector = #selector(IMKTextInput.insertText(_:replacementRange:)) if !clientObject.responds(to: selector) { NSLog("HelloWorldIME: Error - client object does not respond to the insertText selector.") return false } NSLog("HelloWorldIME: Client responds to insertText. Preparing to insert text.") // 3. Since we've confirmed it responds, we can now safely treat it as an IMKTextInput // and call the method. let client = clientObject as! IMKTextInput let stringToInsert = "A" let replacementRange = NSRange(location: NSNotFound, length: 0) client.insertText(stringToInsert, replacementRange: replacementRange) NSLog("HelloWorldIME: Called insertText with string '\(stringToInsert)'. Action complete.") // ======================================================== return true } }

Hello everyone, I would like to know if there is any way for an iOS app to automatically access a user’s total Screen Time (for example, daily or weekly usage) and then share this with friends so they can compare results, like in a “Screen Time battle”? Thanks you very much for you help!

We developed a "Default Translation App" following the guide: https://developer.apple.com/documentation/translationuiprovider/preparing-your-app-to-be-the-default-translation-app. I have already configured everything that needs to be configured according to the document, but there is still this problem

Dear Apple, while implementing Declared Age Range API in my app, I've noticed a mistake in documentation: the isEligibleForAgeFeatures property is marked 26.0+ in documentation, but 26.2+ in Xcode, which ultimately leads to inability to use it with OS below 26.2. Moreover, I'm thoroughly confused by this quote from documentation: This flag returns true on iOS and iPadOS based on a person’s eligibility and always returns false on macOS. It leads me to two questions: Is it possible to use Declared Age Range API for macOS apps? Will it be possible to use it in future? Will there be any changes regarding this matter in a meantime (especially after Jan 1st)? If yes - when should we expect these changes? If no - why this API declares macOS 26+ support alongside iOS/iPadOS, if it simply doesn't work for macOS now? As of now, my iOS app works flawlessly with given API (on iOS 26.2) while macOS app returns isEligibleForAgeFeatures = false and requestAgeRange request always throws AgeRangeService.Error.notAvailable. Also, does it mean that one should not use isEligibleForAgeFeatures boolean while implementing Declared Age Range API for apps below iOS 26.2 (I mean 26.0+)? Or implementing given API for iOS 26.2+ is a sufficient way to go? So shouldn't the whole API be marked as 26.2+? The minimum iOS version in my app is 16.0 and minimum macOS version is 13.0 anyway, so the significant part of users is left out of these updates, but the main goal here is legal compliance.

We've been using the WeatherKit API for a few years now. Everything has been pretty stable. We'll periodically get 404 errors, but they usually disappear within a couple days. Starting March 5th we've again been getting 404 errors that slowly ramped up to March 20th and continued. We have had no code changes on our end, so something seems to have changed / broken on the server side of things. Here are some example API calls that are giving us a 404 error now https://weatherkit.apple.com/api/v1/weather/en/35.9981205/-78.8920444?dataSets=forecastDaily&dailyStart=2025-03-21T05:00:00Z&timezone=America/New_York&countryCode=US https://weatherkit.apple.com/api/v1/weather/en/41.4789363/-81.7404134?dataSets=forecastDaily&dailyStart=2025-03-21T04:56:00Z&timezone=America/New_York&countryCode=US Does anyone have any insights or information on this? Also if Apple is listening, an error more meaningful than 404 would be much much appreciated.

Share Age Range Permission is set to 'Ask First'. Application requested for AgeRange via requestAgeRange API. System presented a consent window where user has to make a choice. User did not acted. Application was pushed to background. Our Application supports PushToTalk Framework and we have successfully joined the channel already. User tapped on the blue-pill , SystemUI will get presented. User tapped on the SystemUI, A New Full Screen SystemUI will get presented. User chosen 'Leave' option and our application left the active channel. 10 User brought the application to foreground and the previous "Share Age Range" system window disappeared. 11. After Step 10, We need to terminate and launch our application in order to get the "Share Age Range" system window. Is "Share Age Range" system window getting disappear is expected here or a BUG

Hi, We’re building an iOS app that uses the Screen Time APIs (FamilyControls and DeviceActivity) to display a user’s own usage metrics inside the app. With the appropriate permissions granted, we are successfully reading and presenting metrics such as: Total screen time Device pickups These metrics are already visible to the user inside our app. We would now like to introduce a user-initiated “Share” feature. The idea is to: Render selected Screen Time metrics into a shareable image card generated locally on device. Present the standard iOS share sheet (UIActivityViewController). Allow the user to share that image to Messages, social apps, etc., if they choose. Important clarifications: This is fully user-initiated. The app does not automatically transmit Screen Time data. The metrics are already displayed in-app with user permission. The share asset would be generated locally. No background export or server-side posting would occur unless explicitly triggered by the user via the share sheet. We are seeking clarification on whether there are any policy or API restrictions around: Rendering Screen Time-derived metrics into a user-facing share card Allowing user-initiated export of those metrics via the standard iOS share flow Are there any additional privacy requirements, entitlement constraints, or App Review considerations we should be aware of when implementing this? Thanks in advance for any guidance.

I’m configuring App Clip launch behavior and would appreciate some clarification. In my setup, the App Clip launch URL is the same as the deep link used to open the full app. Both are configured in the Apple App Site Association (AASA) file. Observed behavior: Scanning a QR code with this URL correctly launches the App Clip. Tapping the same URL when it’s shared (for example, via Messages) launches the full app via the deep link instead of the App Clip experience. I’m reviewing the documentation here: https://developer.apple.com/documentation/appclip/configuring-the-launch-experience-of-your-app-clip#Choose-App-Clip-experiences-you-want-to-support The table mentions that an App Clip can be invoked via “A shared link to an App Clip in the Messages app.” However, when I tap the shared link in Messages, the deep link experience is triggered instead of the App Clip. My questions are: Is this behavior expected when the App Clip URL and the app’s deep link URL are the same? Does launching an App Clip from a shared Messages link require a distinct URL or additional configuration beyond what’s in the AASA file? Are there specific constraints or priorities between universal links for the full app and App Clip invocation in this scenario? Any clarification or guidance would be greatly appreciated. Thank you.

Hello, I’m developing a third-party VoIP app called Heyno and trying to support Siri-initiated calls so they behave like WhatsApp / FaceTime, especially from the lock screen. Target behavior From the locked device, the user says: “Hey Siri, call <contact> using Heyno” Expected result: • System CallKit audio-call UI appears. • No “continue in ” sheet, no forced unlock or foregrounding. • Our app handles the VoIP leg in the background via CXProviderDelegate. WhatsApp already does this with: “Hey Siri, call <contact> on WhatsApp” I’m trying to reproduce that behavior for Heyno using public APIs. I have followed the SiriKit + CallKit VoIP docs but cannot get a clean Siri → CallKit → app flow from the lock screen without either: Being forced into .continueInApp (unlock + foreground), or Hitting CallKit transaction errors when starting the call from the app in response to the intent. Current implementation Intents extension (INStartCallIntentHandling) • resolveContacts(for:with:) normalizes to E.164 and returns INPersonResolutionResult.success. • resolveDestinationType → .success(.normal). • resolveCallCapability → .success(.audioCall). Confirm / handle currently: func confirm(intent: INStartCallIntent, completion: @escaping (INStartCallIntentResponse) -> Void) { completion(INStartCallIntentResponse(code: .ready, userActivity: nil)) } func handle(intent: INStartCallIntent, completion: @escaping (INStartCallIntentResponse) -> Void) { completion(INStartCallIntentResponse(code: .ready, userActivity: nil)) } Earlier, I used .continueInApp with an NSUserActivity carrying the normalized number and metadata, but that always produced a “Continue in Heyno” sheet that requires unlock and foreground, which breaks the lock-screen Siri flow. App target – CallKit provider In the app I have CXProvider + CXProviderDelegate, which work correctly when calls are initiated from inside the app: func provider(_ provider: CXProvider, perform action: CXStartCallAction) { let handle = action.handle.value // Start VoIP / WebRTC / LiveKit / Asterisk call here provider.reportOutgoingCall(with: action.callUUID, startedConnectingAt: Date()) provider.reportOutgoingCall(with: action.callUUID, connectedAt: Date()) action.fulfill() } If I construct a CXStartCallAction and submit it via CXCallController.request(...) from the app, CallKit UI appears and our pipeline runs correctly. What I tried and what fails Starting CallKit from the Intents extension Calling CXCallController.request(...) directly from handle(intent:completion:) in the extension always yields: com.apple.CallKit.error.requesttransaction error 1 (unentitled) The extension does not have the CallKit entitlement, and the docs say not to initiate calls from the extension, so this path seems unsupported. Using .continueInApp + NSUserActivity Pattern: • handle(intent:) builds NSUserActivity (activityType = NSStringFromClass(INStartCallIntent.self), title = "Heyno Start Call", userInfo with E.164 handle, etc.). • Returns INStartCallIntentResponse(code: .continueInApp, userActivity: activity). • App receives the activity, then starts CallKit + VoIP. Functionally this works, but iOS always requires unlock + foreground (“Continue in Heyno”), which is not acceptable for a Siri lock-screen call. App group + Darwin notification (extension → app → CallKit) Experiment: • Extension writes the normalized number into an app-group UserDefaults. • Extension posts a Darwin notification. • App (if running) listens, reads the number, and initiates CXStartCallAction + VoIP. Observed: • Works only when the app is already running in the background; a killed app is not woken. • In some states I see CXErrorCodeRequestTransactionError.invalidAction (error 6) if I try to issue a CXStartCallAction while CallKit is already doing something as part of the Siri flow. • Siri sometimes replies “There was a problem with the app,” likely because CallKit rejects the transaction or sees duplicate/conflicting actions. My understanding so far • The Intents extension should resolve/confirm the intent but not start the call. • The source of truth for starting a call should be: Siri → CallKit → app’s CXProviderDelegate.provider(_:perform: CXStartCallAction) • The app then starts the VoIP leg, reports started/connected, and fulfills. Where I am stuck What is not clear is how Siri is supposed to route an INStartCallIntent into CallKit for a third-party VoIP app on a locked device without using .continueInApp. If my extension simply: • resolves the contact, • confirm → .ready, • handle → .ready (no NSUserActivity, no CallKit), I do not see a documented mechanism that causes: “Hey Siri, call <contact> using Heyno” on the lock screen to: • Present a CallKit audio call bound to Heyno, and • Deliver CXStartCallAction to my CXProviderDelegate while the app stays in the background. Questions For third-party VoIP apps today, is it recommended to implement INStartCallIntentHandling at all, or should we rely only on CallKit registration and Siri’s built-in support for “Call with ” (no SiriKit extension)? If an INStartCallIntentHandling extension is still the intended pattern: • Should confirm/handle simply return .ready and never start CallKit or set NSUserActivity? • In that case, is Siri expected to invoke CallKit on our behalf and create a CXStartCallAction targeting our provider, even when the device is locked and the app is not foreground? Is there any supported way for a Siri-triggered third-party VoIP call to start from the lock screen via CallKit without: • using .continueInApp (unlock + foreground), and • starting CallKit directly from the Intents extension (unentitled)? Is there any additional configuration, entitlement, provisioning profile flag, or Info.plist key required so that Siri can map “Call using Heyno” directly to our CallKit provider and background VoIP implementation? Current options: • .continueInApp + NSUserActivity → works, but always requires unlock + app UI. • Start CallKit from the extension → fails with “unentitled” and appears unsupported. • Extension → app-group + notification → app → CallKit → VoIP → fragile, with intermittent CXErrorCodeRequestTransactionError.invalidAction. • Remove the extension and hope Siri/CallKit auto-routes to our provider → unclear if this is supported for third-party VoIP apps or reserved for privileged apps. I would appreciate guidance on the intended architecture for this scenario, and whether the “Siri from lock screen → CallKit UI → background VoIP call” flow is achievable for an App Store VoIP app like Heyno using public APIs only.

We’re seeing unexpected NFC behavior once our app has 50+ Advanced App Clips created. Expected: Scanning an NFC tag with a URL that is NOT an App Clip invocation should show the standard “Open in Safari” notification. Actual: After we create ~50+ Advanced App Clips, scanning NFC tags for URLs on the same domain that are not associated with App Clips consistently shows “CPSErrorDomain error 2” instead of the Safari prompt.
 QR codes for the same non–App Clip URLs work as expected (shows Safari prompt). Clearing the App Clips “Experience Cache” sometimes helps briefly, but the error returns on consequent scans. Notes: Domain has valid AASA. App Clip invocation URLs work as expected.
 The issue appears tied to the number of Advanced App Clips configured. Below ~50, non–App Clip NFC scans behave correctly; above that, they fail.
 Affected across multiple devices and iOS versions tested. Repro steps: Configure 50+ Advanced App Clips for paths on a single domain.
 Encode a different URL on the same domain that is NOT listed as an App Clip invocation into an NFC tag.
 Scan the NFC tag on iPhone.
 Observe “CPSErrorDomain error 2” instead of the “Open in Safari” notification. Impact: blocks our NFC use case for regular web links once we scale App Clip experiences. Sysdiagnose #: FB20563121