Hello,
In production, a large number of users experience outgoing call reporting fails with the following error:
com.apple.CallKit.error.requesttransaction Code=2
The iOS version doesn't matter, errors are present in v15-26
Details
My CXProvider held as a global singleton, so it’s unlikely to be deinited.
There is no explicit call to CXProvider.invalidate() in the app.
If I manually invalidate the CXProvider, I observe the expected failure when trying to create an outgoing call (com.apple.CallKit.error.requesttransaction error 2).
However, If I recreate the CXProvider after the error, outgoing calls are reported correctly.
Many users trigger the providerDidReset delegate method (CXProviderDelegate) before this error.
According to the documentation, providerDidReset can be called by the system, and we are supposed to end all active calls, but the documentation doesn't suggest recreating the CXProvider.
Question
Should I recreate CXProvider after providerDidReset and forget about that, or could this error be caused by something else?
General
RSS for tagDelve into the world of built-in app and system services available to developers. Discuss leveraging these services to enhance your app's functionality and user experience.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hi, we are developing a screen time management app. The app locks the device after it was used for specified amount of time.
After updating to iOS 26.2, we noticed a huge issue: the events started to fire (reach the threshold) in the DeviceActivityMonitorExtension prematurely, almost immediately after scheduling. The only solution we've found is to delete the app and reboot the device, but the effect is not lasting long and this does not always help.
Before updating to iOS 26, events also used to sometimes fire prematurely, but rescheduling the event often helped. Now the rescheduling happens almost every second and the events keep reaching the threshold prematurely.
Can you suggest any workarounds for this issue?
When I launch the Quick Look Preview Extension target in Xcode, an app called Quick Look Simulator opens with an almost empty window:
Online I read that the Terminal command qlmanage allows to test Quick Look plugins (which I think were an older format for creating Quick Look extensions), but running
qlmanage -p /path/to/previewed/file -c public.text -g /path/to/QuickLookPreviewExtension.appex
(where QuickLookPreviewExtension.appex is generated by the Xcode build and is located in the DerivedData folder) gives an error
Can't get generator at QuickLookPreviewExtension.appex
How can I debug a Quick Look Preview Extension?
I would like to share an issue observed during app development.
When changing Bluetooth settings from the system Settings app without using multitasking, the app does not terminate but instead logs the user out.
However, when changing Bluetooth settings while using multitasking, the app terminates completely.
In this context, I would like to understand:
Whether there is any system behavior that causes the app to refresh or restart when Bluetooth settings are changed
And why the app behavior differs in a multitasking environment, particularly in terms of app lifecycle handling
Any insights into these behaviors would be greatly appreciated.
I decode an object with NSKeyedArchiver (SecureCoding):
typealias BoolArray = Array<Array<Bool>>
let val = decoder.decodeObject(of: NSArray.self, forKey: someKey) as? BoolArray
I get the following log:
*** -[NSKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSNumber' (0x204cdbeb8) [/System/Library/Frameworks/Foundation.framework]' for key 'NS.objects', even though it was not explicitly included in the client allowed classes set: '{(
"'NSArray' (0x204cd5598) [/System/Library/Frameworks/CoreFoundation.framework]"
)}'. This will be disallowed in the future.
I changed by adding NSNumber.self in the list :
let val = decoder.decodeObject(of: [NSArray.self, NSNumber.self], forKey: someKey) as? BoolArray
No more warning in log.
Is there a reason for this ?
Is there a way to enumerate all files within a folder of an asset pack or just all files in general?
My application is using the Apple demo code to load a file from an Apple hosted asset pack:
let descriptor = try AssetPackManager.shared.descriptor(for: "NAV/NavData.db3")
defer {
try descriptor.close()
}
if let path = path(for: descriptor) {
self.database = try Database(path: path)
}
As my "Navigation Data" is updated each month with an updated asset pack I would like to have the name of the .db3 file reflect the current data cycle (e.g. NAV2601.db3, NAV2602.db3, ...)
Ideally I would like to iterate over all files within the NAV folder of the current asset pack and pick the most recent one.
Unfortunately, neither the AssetPackManager nor the AssetPack object seem to include an API for this.
It would be cool to have something like:
let files = try AssetPackManager.shared.files(for: "NAV/")
for file in files {
//Check and load
}
In iOS 18 (beta 1-4) when you set openAppWhenRun = false in your AppIntent of your live activity the perform function never gets called.
In iOS 16 and 17 my live activities work. I have downloaded other apps and in their live activities any button tab which doesn´t open the app is also doing nothing in iOS 18.
Has anyone got this working? Any comments from an Apple engineer on this?
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?
A screen time app I'm making has started telling users that their limit was reached even when they're far below their limit for the day (sometimes even at 0 minutes for the day).
This issue only started happening after upgrading my software to iOS 26.2.
Is this happening to anyone else? If so how have you found any solutions or does anyone know of any changes that could be causing this? Any help would be appreciated.
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
I have applied for CarPlay support here Apply here to get your app approved for CarPlay use: https://developer.apple.com/contact/carplay/ but have not received any acceptance or answers. Does anyone know what to do?
We're building a parental control app using FamilyControls (.child authorization). Our architecture:
Parent sends pause command → Firestore + FCM
Child receives push → NotificationService Extension triggers main app
Main app sets ManagedSettings Shields
Problem: If child disables Notifications in Settings and force-quits the app, we cannot enforce Shields.
What we've tried:
Firestore Realtime Listener (works only when app is running)
DeviceActivityMonitor (intervalDidStart/End only triggers at schedule boundaries, eventDidReachThreshold requires explicit app selection via FamilyActivityPicker)
Question: Is there a recommended approach for parental control apps to reliably enforce Shields when the child has disabled notifications? Or is this a known limitation?
Topic:
App & System Services
SubTopic:
General
Tags:
Family Controls
Device Activity
Managed Settings
Screen Time
When we request auth from the AuthorizationCenter, it seems that we're only really able to allow users to control the apps on the parent's phone. Is there a way to allow us to let parents manage apps on the kid's device directly through our parent app?
For context, we have 2 different apps, one for the parent and one for the child. The child is able to purchase screen time and the parent can redeem them (activate those minutes) from their end.
I'm currently working with the FamilyControls API and testing my app on two different devices. Both apps are in the same family-sharing network with one phone being the owner of the network (I'll call this A) and the other one being an adult in the network(I'll call this B).
When device A picks apps using the FamilyActivityPicker, it shares that selection with device B (via encoding, sending over network, and decoding on device B). However, interacting with the token (displaying it, using it in shield) throws an error saying the token is null.
From the documentation, I thought every token would be the same across all devices in the family sharing network. So my question:
How do I send the FamilyActivitySelection from A to B and have the tokens still be functional?
Does this functionality only work if A is a "parent" and B is a "child" in the family sharing network?
Also, side note:
If I reverse the process and send the tokens from B to A. Interacting with the token works exactly as expected. For some reason, it's only going from A to B where it doesn't work.
Topic:
App & System Services
SubTopic:
General
Tags:
Application Services
Family Controls
Screen Time
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.
Hey!
I'm trying to create an XPC messaging feature between my daemon and main application.
I'm trying to use the new Swift low-level API available from macOS 14.0. The documentation is extremely confusing when looking at it from Swift:
The xpc_listener_t type
Seems to be something I shouldn't use in the Swift API, and would rather have to use XPCListener.
Also, it appears to have no public API other than the xpc_listener_set_peer_code_signing_requirement function. Which would make it impossible to create this type.
However, when going into xpc.h, one can see that there is an API in fact:
API_AVAILABLE(macos(14.0), macCatalyst(17.0))
API_UNAVAILABLE(ios, tvos, watchos)
XPC_EXPORT XPC_SWIFT_NOEXPORT XPC_RETURNS_RETAINED XPC_WARN_RESULT
xpc_listener_t _Nullable
xpc_listener_create(const char * service,
dispatch_queue_t _Nullable target_queue,
xpc_listener_create_flags_t flags,
xpc_listener_incoming_session_handler_t incoming_session_handler,
xpc_rich_error_t _Nullable * _Nullable error_out);
which is a very unusual declaration - the first parameter for example shows up as Int8 type in Swift. Not to mention I haven't been able to create the next parameter, xpc_listener_create_flags_t at all, even though it seems to be a UInt64-based flag based on the C declaration, but passing UInt64(0) throws a compiler error. It really seems like something I shouldn't use from Swift.
But then again, the extremely important security-related API mentioned above, xpc_listener_set_peer_code_signing_requirement can only take an xpc_listener_t object as a parameter, not an XPCListener type.
There seems to be no conversion available between the two. However the documentation in the XPC framework seems to be telling the story of these two types being very equal, because of the following:
The xpc_session_t type
seemingly again has only deprecated methods mostly, the important one staying behind is xpc_session_set_peer_code_signing_requirement.
However, this would again require the creation of an xpc_session_t object, for which in the XPC framework one will find declarations like:
@available(macOS, introduced: 13.0, deprecated: 14.0, renamed: "XPCSession")
@available(macCatalyst, introduced: 16.0, deprecated: 17.0, renamed: "XPCSession")
@available(iOS, unavailable)
@available(tvOS, unavailable)
@available(watchOS, unavailable)
public typealias xpc_session_t = OS_xpc_object
plus basically all API of XPCSession being originally declared as xpc_session_* APIs and all of them having deprecated: 14.0, renamed: * marks. This is telling me xpc_session_t and XPCSession are in fact the same/same-ish.
But again, there is seemingly no conversion between these two types. Which brings me to again being unable to create a code signing requirement for the XPCSession object.
I've read some older forum posts, and I saw Apple Engineers admitting the code signing requirement APIs are missing from the new Swift APIs, however they seem to have been added in macOS 14.4 - although it appears to have been mistakenly added to the C-family functions, which have not been exposed to Swift correctly, because they still use the deprecated xpc_listener_t and xpc_session_t types.
So my question is: what is going on here? :) Making XPC connections without a code signing requirement in 2025 seems like a no-go, so do I have to still stick with C - even though this new API seems to be focused on Swift?
My CoreSpotlight extension seems to exceed the 6 MB memory limit. What’s the best way to debug this?
I've tried to attach the debugger on the Simulator but the extension seems to be never launched when I trigger the reindex from Developer settings. Is this supposed to work?
On device, I am able to attach the debugger. However, I can neither transfer the debug session to Instruments, nor display the memory graph. So I've no idea how the memory is used.
Any recommendations how to move forward? Is there a way to temporarily disable the memory limit since even with LLDB attached, the extension is killed.
Project Background:
I am developing a third-party custom keyboard for iOS whose primary feature is real-time voice input.
In my current design, responsibilities are split as follows:
1. The container (main) app is responsible for:
Audio recording
Speech recognition (ASR)
2. The keyboard extension is responsible for:
Providing the keyboard UI
Initiating the voice input workflow
Receiving transcription results via an App Group
Inserting recognized text into the active text field using textDocumentProxy.insertText(_:)
Intended User Flow
The intended workflow is:
The user is typing in a third-party app (for example, WeChat) using my custom keyboard.
The user taps a “Voice Input” button in the keyboard extension.
The keyboard extension activates the container app so that audio recording and ASR can begin.
After recording has started, control returns to the original app where the user was typing.
The container app continues running in the background, maintaining active audio recording and ASR.
Recognized text is continuously streamed back to the keyboard extension and inserted into the current cursor position in real time.
Observed Industry Behavior
Some popular third-party keyboards on iOS, such as WeChat Keyboard and Doubao Keyboard, appear to provide a similar user experience in which:
Voice input can be initiated directly from the keyboard while typing in another app.
The user remains (or returns) in the original typing context after voice input starts.
Speech recognition continues and text is streamed into the active text field without interrupting the typing experience.
I would like to better understand how this type of workflow aligns with iOS platform capabilities and supported APIs.
My Questions
Is it supported by iOS public APIs for a custom keyboard extension to activate its container app to start audio recording and ASR, then return to the original host app while the container app continues recording and performing ASR in the background?
If this workflow is not supported, are there any Apple-recommended or supported alternative architectures for achieving a similar user experience, especially when audio recording and ASR logic are currently implemented in the container app rather than in the keyboard extension?
Goal
My goal is to design a solution that is fully compliant with iOS public APIs and platform constraints, while providing a real-time voice input experience comparable to existing third-party keyboards on the platform.
Any guidance on supported APIs, recommended architectures, or relevant documentation would be greatly appreciated.
Based on the documentation, I understand that the UnwantedCommunicationReporting extension works with SMS and MMS messages. However, I'd like official confirmation about support for different message types:
SMS: Appears to be supported ✅
MMS: Appears to be supported ✅
RCS (Rich Communication Services): Support unclear ❓
iMessage: Support unclear ❓
Hello everyone,
I’m experiencing a WeatherKit issue that occurs consistently on both the iOS 26.2 Simulator and a real device running iOS 26.2.
Environment:
Xcode: latest
iOS: 26.2
Occurs on: Simulator AND physical device
WeatherKit usage: via WeatherService API (not manual REST)
Location Services: authorized (When In Use / Always)
Issue:
WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2
"The operation couldn’t be completed."
Already verified:
WeatherKit capability is enabled for the App ID
com.apple.developer.weatherkit entitlement is present
Bundle ID matches the App ID
App is signed with the correct Team ID
Behavior is identical on Simulator and physical device
Error occurs before any WeatherKit response is returned
Questions:
Is this a known issue with WeatherKit on iOS 26.2?
Are there any known limitations or requirements for WeatherService
related to WeatherDaemon validation?
Is there a recommended way to diagnose why WeatherDaemon
rejects the request with Code=2?
Code:
private let weatherService = WeatherService()
Topic:
App & System Services
SubTopic:
General