Hi! We’ve had Live Caller ID Lookup in production for a while. We’re seeing backend RPS on our /queries endpoint much higher than our expected incoming call volume. While testing with Console.app during an incoming call, it looks like iOS may still hit our service even when the caller number is already in the user’s Contacts - but I’m not 100% sure from logs alone. Can you confirm: Does iOS invoke Live Caller ID Lookup (i.e. call /queries) for every incoming call, including calls from saved Contacts? If yes, is this simply expected framework behavior? Thanks!

Call Screening has serious issues right now leading to missing calls from genuine callers because the system does not acknowledge them with missed call notifications or badges in a lot of cases. I'm posting this in the hope of catching an engineer who can bring this to the attention of the teams working on this. Filed as FB20678829 — I ran the following tests with iOS 26.1 beta 3, but the issues have been occurring on iOS 26.0 as well. I used an iPhone, Apple Watch, iPad, and Mac for this. The iPhone has Call Screening enabled with the option „Ask Reason for Calling“ The iPhone has call forwarding enabled to all devices. Test 1: Active Focus Turn on a focus like Do not Disturb on all devices. Lock all devices. Make a phone call to the iPhone with an unknown number. Behavior: iPhone: displays Call Screening UI on the Lock Screen, but it will not light up the screen. You don’t know Call Screening is happening unless you activate the display just in that moment on devices without Always On Display. Watch: does nothing. Mac: does nothing. iPad: displays Call Screening UI on the Lock Screen, but it will not light up the screen. You don’t know Call Screening is happening unless you activate the display just in that moment. In this test the caller does not answer any of the Call Screening questions and just hangs up. The result is that only the Mac displays a missed call notification. iPhone, iPad, and Watch do not acknowledge the missed call (no phone app icon badge, no notification, no badge inside the Phone app itself), you can only see the call inside the Calls list when manually looking for it. Test 2: No Focus Turn off any focus like Do not Disturb on all devices. Lock all devices. Make a phone call to the iPhone with an unknown number. Behavior: iPhone: displays Call Screening UI on the Lock Screen, but it will not light up the screen. You don’t know Call Screening is happening unless you activate the display just in that moment on devices without Always On Display. Watch: does nothing. Mac: displays Call Screening UI when unlocked. iPad: displays Call Screening UI on the Lock Screen, but it will not light up the screen. You don’t know Call Screening is happening unless you activate the display just in that moment. In this test the caller does not answer any of the Call Screening questions and just hangs up. The result is that only the Mac displays a missed call notification. iPhone, iPad, and Watch do not acknowledge the missed call (no phone app icon badge, no notification, no badge inside the Phone app itself), you can only see the call inside the Calls list when manually looking for it. The only improvement here is that the Mac now shows the Call Screening UI. Test 3: Caller answers Call Screening questions An active focus does not matter. Lock all devices. Make a phone call to the iPhone with an unknown number. Once the caller answered the Call Screening questions, the following happens: All devices ring like expected When the caller hangs up or I don’t answer: Mac: Shows Missed Call notification without details iPhone: Shows Missed Call notification with transcript of Call Screening (also badges phone app icon) iPad: does nothing. Watch: Shows the mirrored iPhone notification. Things to note: When turning off call forwarding on iPhone to other Apple devices like iPad and Mac, the phone app icon is always badged for missed calls when Call Screening was active, but no notification is displayed regardless.

In iOS 18, when a contact with multiple phone numbers called, the system clearly indicated which specific number was used—often by highlighting it in red for missed calls or tagging it as 'recent.' However, in iOS 26, this distinction is missing, and there is no way to determine which of the contact's numbers the call originated from.

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.

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!

I am implementing a custom SMS filter using the IdentityLookup framework. My goal is to authenticate the network requests made via context.deferQueryRequestToNetwork using a user-specific JWT token generated in the containing (main) app after a successful login.

Hi, We are working to integrate the Live Caller ID Lookup feature into our app. After submitting the request form via the link: https://developer.apple.com/contact/request/live-caller-id-lookup/, we received this reply from Apple: Apple’s OHTTP relay has been configured to talk to your OHTTP gateway. Now Live Caller ID Lookup should work for your application extension when distributed through App Store. However, before officially releasing our app on the App Store, we’d like to make sure the Live Caller ID Lookup feature is working as expected. To test this, we uploaded the app to TestFlight, and it successfully passed App Review. However, the test failed — we observed that the system tries to fetch the config from http://www.example.com/config instead of our actual configuration URL. Questions: Is this expected behavior when using TestFlight? Does the Live Caller ID Lookup feature only become active after full public release on the App Store? Is there any recommended way to test this feature before public release? Thank you!

I use WeatherKit with Swift to get multiple cities weather by longitude and latitude. But I use this API in WeatherService for daily forecast: final public func weather<T>(for location: CLLocation, including dataSet: WeatherQuery<T>) async throws -> T And I found there is something wired: The date of WeatherKit::DayWeather is based on my device's timezone settings. Tokyo's Day Weather is start at UTC+8, New York' Day Weather is start UTC+8. Is there any way to set timezone correctly?

I'm using FamilyActivityPicker to get consent for app/category management, which returns a FamilyActivitySelection object. I serialize this FamilyActivitySelection object (just applicationTokens and categoryTokens) and pass it to my DeviceActivityMonitor extension via App Group UserDefaults. I am using the JSON encoder/decoder over PropertyList (though both seem to exhibit the same behavior). After inspecting the FamilyActivitySelection object immediately after it's returned by FamilyActivityPicker in the main app, the application.bundleIdentifier property is consistently nil for every Application object within selection.applications. Similarly, category.localizedDisplayName is nil for ActivityCategory objects. This happens whether "Select All Apps" is used or if apps/categories are selected individually. I understand that this is the intended behavior due to Apple's user privacy policies. I read on another post that my app can be provided with bundle identifiers and app names within Shield Configuration extensions and Device Activity Report extensions - I'm not sure which ones or how exactly to do this. I am aware that I can use Label(applicationToken) SwiftUI view to display the app name/icon, but this doesn't give programmatic access to the bundleIdentifier string. My app will not log or export these bundleIdentifiers outside of its sandbox. My goal is to create mappings to the FamilyActivitySelection with the publicly accessible bundleIdentifiers. Any guidance, examples, or clarification on the intended workflow for this scenario would be greatly appreciated!

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?

When updating an existing advanced app clip experience, the change doesn't actually apply. It shows the correct image in the UI, but when you use the app clip it shows the old image. Looking into it more, the status has "UPDATE_SUBMITTED". Seems related to this issue (https://developer.apple.com/forums/thread/810544) and this issue (https://developer.apple.com/forums/thread/810351).

Steps To reproduce: Login to application and App has joined the PTC channel. Push the application to background and Lock the device. From the System UI press the talk button which will start transmit. Audio Session has been activated and Audio unit has been initialised properly. On terminator side no media is being played out. Issue observed consistently on specific models which has configured audio codec with Stereo type. More details are added : FB20281626

We tried to fetch the recorded PPG data using SensorKit with the following code, however the didFetchResult callback method is never called. let ppgReader = SRSensorReader(sensor: .photoplethysmogram) let request = SRFetchRequest() let nowDate = Date() let toDate = nowDate.addingTimeInterval(-25 * 60 * 60) let fromDate = toDate.addingTimeInterval(-24 * 60 * 60) request.from = SRAbsoluteTime.fromCFAbsoluteTime(_cf: fromDate.timeIntervalSinceReferenceDate) request.to = SRAbsoluteTime.fromCFAbsoluteTime(_cf: toDate.timeIntervalSinceReferenceDate) ppgReader.delegate = self; ppgReader.fetch(request) The delegate called the didComplete successfully: func sensorReader(_ reader: SRSensorReader, didCompleteFetch fetchRequest: SRFetchRequest) But never called the didFetchResult func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject>) -> Bool Any ideas why ? (I am wearing the watch for couple days and ensure it has the data for the time period I am querying) One thing I notice is when Apple granted us the entitlement, it uses Uppercase for ECG and PPG, however the document use Lowercases in the plist https://developer.apple.com/documentation/sensorkit/srsensor/photoplethysmogram Dose it matter ?

Hi everyone, I’m honestly trying to understand what’s going on with the Family Controls API review process. I submitted my entitlement request on March 5, and as of today (March 19), there has been zero response. I also opened a support ticket on March 16, and that hasn’t received any response either. What’s confusing is that updates to another app on the same developer account were approved within days — so clearly the account is in good standing and active. At this point, it feels like there’s no visibility into what’s happening: Is the request under review? Is it waiting for additional information? Or is it just sitting in a queue indefinitely? I understand that Family Controls is a sensitive API, but a two-week silence with no status or communication makes it very difficult to plan or ship features. For those who’ve gone through this: How long did your approval actually take? Did you receive any communication during the process? Is there any reliable way to get visibility or speed this up? Right now, this is blocking a feature we’ve invested significant time building, and the lack of feedback is the most frustrating part. This is really giving me pain. Would really appreciate any insights.

Similar Issue to FB13556935: On iOS 26.3.1, deviceactivityd produces zero log output and never wakes a DeviceActivityMonitor extension at the scheduled time, even when the schedule is successfully registered. The extension's intervalDidStart(for:) method is never called. Steps to Reproduce: Create an app with a DeviceActivityMonitor extension subclass Add the com.apple.developer.family-controls entitlement to both the main app and extension targets Add a shared App Group entitlement to both targets In the main app, call: let center = DeviceActivityCenter() center.stopMonitoring([.myActivity]) let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour: 17, minute: 30), intervalEnd: DateComponents(hour: 17, minute: 45), repeats: true ) try center.startMonitoring(.myActivity, during: schedule) Verify registration succeeds: DeviceActivityCenter().activities.contains(.myActivity) returns true Background the app completely and wait for the intervalStart time (5:30 PM in this example) Expected Result: intervalDidStart(for:) is called in the extension process at 5:30 PM. ManagedSettings shields are applied without any user interaction. Actual Result: intervalDidStart(for:) is never called. No extension process is launched. Filtering Console.app for deviceactivityd on the device returns 0 messages — the daemon produces no logs whatsoever despite an active registered schedule. Shields are never applied. Additional Evidence: Third-party apps using DeviceActivity (e.g. Prayer Lock) successfully apply shields at scheduled times on the same device and OS version, confirming the framework is not universally broken Filtering Console.app for the app's bundle ID at the trigger time shows the main app process applying shields via a UNCalendarNotificationTrigger fallback — but no extension process activity DeviceActivityCenter().activities correctly lists the registered activity before and after the trigger time, confirming the schedule registration API is functional Environment: iOS 26.3.1 Physical device (required for FamilyControls) Development-signed build with com.apple.developer.family-controls entitlement provisioned App Group shared between main app and extension targets

Goal: Manually install an explicit version of Rosetta2 Background: Me and some customers have an old app (intel) which perfectly worked with Rosetta2. In the last week of April most macheines were updated to Mac Os 15.4.1. and the app still starts but certain functionality is bronken. Some fields ind the forms don't write back to the database, some data can't be read from the database. (Most installations will fade out over the next month but it would be great to have the app fully working for data migration.) First try was to step back to 15.4. (Clean Install - Install App - Rosetta installs as expected): no change, app still broken Second try back to 15: (Clean Install - Install App - Rosetta installs as expected): App still broken (!) This is interesting as the app worked for month using Mac Os 15! Third try: Back to MacOS 14 (Clean Install - Install App - Rosetta installs as expected): App is working like nothing happend. (All attempts on same hardware of course.) Reasoning: Rosetta2 was the only software (besides the app itself) installed after clean MacOS installs. Now, my guess is that there were might be a change in Rosetta2 as the app worked on MacOs 15 up the update 15.4.1. was installed. Checking versions (pkgutil --pkg-info com.apple.pkg.RosettaUpdateAuto): Rosetta version MacOS 14: 1.0.0.0.1.1722778371 Rosetta version on MacOS 15.4.1: 1.0.0.0.1.1744447383 To fully verify the cause it would be great to uninstall Rosetta on MacOS15.4.1 machine and explicit install lower version (1.0.0.0.1.1722778371) which must be available somewhere as MacOS14 still gets this version. I know how to uninstall - is there a possibility to manually install an explicit version of Rosetta2?

We are building an AI-powered smart glasses companion app, similar to Meta Ray-Ban. We want to provide true hands-free calling support. Right now, whenever the app tries to dial a native cellular call, iOS shows a confirmation screen that requires the user to tap to start the call. If the user always has to confirm/tap on the phone screen, there is no real point in using smart glasses for making calls. How can we initiate a native outgoing call without any confirmation dialog or extra tap, exactly like Siri does it, or like the Meta Ray-Ban glasses do when the user says “Hey Meta, call [name]” Please guide us on the correct APIs, entitlements, or integration path to achieve this behavior. Thank you.

Hey there! So, I'm trying to see what I'm able to do with the Device Activity Report Extension, and I have a few questions about the following quote: To protect the user’s privacy, your extension runs in a sandbox. This sandbox prevents your extension from making network requests or moving sensitive content outside the extension’s address space. In particular, what constitutes the address space for this extension? Can I save data to a UserDefaults object that only the extension can access? (Apps like Opal allow the user to label apps as "distracting" and "non-distracting", and I'm wondering how they do that!) From what I've read, I believe it cannot write to a shared app group or model (and I just want to confirm this) It also seems that there's nothing preventing it from reading data from the main app, so I'm just wondering if it's able to read data from an app group or model with no problem. Thanks in advance!

We’ve been implementing LiveCallerId using OHTTP and have hit a wall with the production environment. The setup works perfectly in TestFlight, but the release version of the app is consistently being rejected by the Apple OHTTP Relay when trying to tunnel traffic to our gateway. Timeline & Status: Applied via the form in September 2025. Received confirmation in November 2025 that our /.well-known/ohttp-keys endpoint was correctly configured. Since then, we've struggled to get a dialogue with Apple to confirm the final production whitelisting. Technical Observations: Our ohttp-keys endpoint is being polled frequently (every few minutes). Based on the traffic, this is clearly the Apple Relay infrastructure fetching/refreshing the keys, not the devices themselves. This suggests the Relay "sees" our configuration, yet it still refuses to tunnel traffic to our gateway in the production environment. Since everything is functional in TestFlight, our implementation seems correct. It feels like there is a configuration mismatch or a missing "production flip" on the Relay side for our Bundle ID. If anyone from the Apple engineering team could verify the status for this Bundle ID, it would be a huge help. We've been stuck in this "TestFlight-only" state for quite a while now.

Hi everyone, We're using the react-native-device-activity package to implement app blocking via Apple's Screen Time API. The blocking functionality works well: when the user selects apps and taps "Done," those apps get blocked as expected. However, we're facing an issue with unblocking apps that the user later unselects. Even after the user unchecks some apps and taps "Done" again, those previously selected (now unselected) apps remain blocked and still show the shield.