According to the documentation, using Scope(restriction: .none) can expose the extension point to third-party app extensions. Below is my implementation, which ultimately results in an error.
Code for declaring the extension point:
@available(iOS 26.0, *)
extension AppExtensionPoint {
@Definition
static var priceExtension: AppExtensionPoint {
Name("priceExtension")
UserInterface(false)
Scope(restriction: .none)
}
}
Code for locating the extension point:
monitor = try await AppExtensionPoint.Monitor(appExtensionPoint: .priceExtension)
When executing the code to locate the extension point, the following error occurs:
However, in practice, I found that declaring the extension point in this way results in an error when trying to locate it:
Error Domain=com.apple.extensionKit.errorDomain Code=19 "Failed to add observer" UserInfo={NSLocalizedDescription=Failed to add observer}
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
We use call directory extension in one of our applications, we notice that call id is truncated on IOS 18.
Example: "Grady GmbH" instead of "GRADY ARCHIE,
PRICEWATERHOUSECOOPER GMBH"
We notice also if we have calls in the history then the caller id is shown correctly.
Issue only on IOS 18.
Topic:
App & System Services
SubTopic:
General
On iOS 26, calling CXCallDirectoryManager.sharedInstance.openSettings() does not navigate to the “Call Blocking & Identification” settings page as documented. Instead, it either opens the main Phone settings page or fails to navigate entirely. This breaks the expected behavior for enabling Call Directory extensions and impacts onboarding flows for apps using CallKit.
Expected:
Settings should open directly to Phone → Call Blocking & Identification.
Actual:
Navigates to the main Phone settings page
This appears to be a regression from previous iOS versions. Documentation still states this API should open the correct page.
~5% of our users when downloading the iOS application from the Apple Store for the first time are unable to enrol a Passkey and experience an error saying the application is not associated with [DOMAIN].
The error message thrown by the iOS credentials API is
"The operation couldn't be completed. Application with identifier [APPID] is not associated with domain [DOMAIN]"
We have raised this via the developer support portal with case id: 102315543678
Question:
Why does the AASA file fail to fetch on app install and is there anything that can be done to force the app to fetch the file?
Can this bug be looked at urgently as it is impacting security critical functionality?
Other Debugging Observations
We have confirmed that our AASA file is correctly formatted and hosted on the Apple CDN. Under normal circumstances the association is created on install and Passkey enrolment works as intended.
We have observed that when customers uninstall/reinstall the app this often, but not always, resolves the issue. We also know this issue can resolve itself overtime without any intervention.
We have ruled out network (e.g VPN) issues and have reproduced the issue across a number of different network configurations.
We have ruled out the Keychain provider and have reproduced it across a variety of different providers and combinations of.
We observed this across multiple versions of the iOS operating system and iPhone hardware including the latest hardware and iOS version.
Hi There, hopefully someone can help me here, we weren’t aware but our universal links stopped working sometime last year, as they are not used often on the apps, it wasn’t noticed. We checked all the elements and this is the situation:
Our apple-app-site-association file is located at
https://ourdomain.com.au/.well-known/apple-app-site-association
And it is accessible and can be downloaded.
We have Associated Domain services enabled for our app Bundle Id: au.com.identifier.app
The Entitlements.plist in our app contains the list of associated domains - the second is the full url, the portal won't let me write it as such as it's not the real address.
But links for the first two, …ourdomain.com.au domains don’t work
Request https://ourdomain.com.au/.well-known/apple-app-site-association downloads the file and returns status code:403
While checking the availability with
https://app-site-association.cdn-apple.com/a/v1/ourdomain.com.au
we get the error:
ourdomain.com.au: Failed to load resource: the server responded with a status of 404 (Not Found)
Going directly to the hosted website:
https://app-site-association.cdn-apple.com/a/v1/ourdomain-prod-ourdomainwebsite.azurewebsites.net
Returns the json:
{
"activitycontinuation": {
"apps": [
"99ABCD88XXX.au.com.identifier.app",
"99ABCD88XXX.au.com.identifier.server.adhoc",
"99ABCD88XXX.au.com.identifier.server.dev"
]
},
"applinks": {
"apps": [],
"details": [
{
"appID": "99ABCD88XXX.au.com.identifier.app",
"paths": [ "/m/" ]
},
{
"appID": "99ABCD88XXX.au.com.identifier.server.adhoc",
"paths": [ "/mt/" ]
},
{
"appID": "99ABCD88XXX.au.com.identifier.server.dev",
"paths": [ "/md/*" ]
}
]
}
}
It appears to be something in the redirect from the url but debugging shows nothing obvious. Has anyone experienced this before?
Thanks
Topic:
App & System Services
SubTopic:
General
Explanation of the issue
When tethering is enabled and a wireless connection is established,
there are instances where an IP address is not assigned.
Steps to Reproduce the Issue (if possible)
Enable iPhone tethering and connect wirelessly using 11ax.
Expected Result
The iPhone assigns an IP address, enabling network connectivity.
Actual Result Observed
DHCP negotiation failed.
After attempting communication with the DHCP server via DHCP Discover, a DHCP Offer was returned from the iPhone.
If this was missed, it would retry by performing another DHCP Discover.
However, the iPhone does not issue a DHCP Offer no matter how many times it retries.
The IP address is not assigned unless the wireless connection is disconnected and reconnected.
If the initial Discover is missed, does this invalidate subsequent Offer retries?
The above issue has been confirmed on iPhone 17 Pro and iPhone 16. It does not appear to occur on iPhone 15.
Hello,
I have a question about data deserialization using NSKeyedUnarchiver in iOS SDK development.
Current Situation:
Previously, we were using the NSKeyedUnarchiver.unarchiveObject(with: Data) function
We have changed to using the NSKeyedUnarchiver.unarchivedObject(ofClasses:from:) method to deserialize complex objects stored in UserDefaults
We need to include all types in the ofClasses parameter, including Swift primitive types as well as various custom classes and structs within the project
Questions:
Implementation Approach: Is it correct pattern to include all classes defined in the project in the ofClasses array? Is this approach recommended?
Runtime Stability: When using this approach, is there a possibility of runtime crashes? Are there any performance issues?
Alternative Methods: If the current approach is not the correct pattern, what alternatives should we consider?
Current Code Structure:
All model classes conform to the NSSecureCoding protocol
We use the requiringSecureCoding: true parameter
We use a whitelist approach, explicitly listing only allowed classes
I would like to know if this structure is appropriate, or if we should consider a different approach.
Thank you.
Hi,
We've noticed that this issue occurs more frequently after upgrading to iOS 18.4.1 and can result in one-way audio.
Our app uses CallKit with WebRTC to establish VoIP connections.
However, on iOS 18.4.1, CallKit no longer triggers:
func provider(_ provider: CXProvider, didActivate audioSession: AVAudioSession)
We're currently comparing the occurrence rate across different iOS versions to better understand the impact.
Could you please help analyze the root cause of this issue?
We are not receving incoming call from blocked numbers below iOS 26 versions but same in iOS 26 onwards we are receiving the incoming call..
Can you please provide any solutions to fix the issue
Its possible to add the Declared Age Range entitlement to extensions, in particular I'm looking at a Notification Service Extension.
However the DAR requestAgeRange() API takes a view controller as a parameter. Presumably therefore its not possible for a notification service extension to obtain the age range itself directly?
Yes the extension can read it from shared groups if the app reads it and set it into the group. However the scenario I'm thinking of is this:
App runs and gets the age range. Sets its functionality accordingly.
The server sends pushes which are intercepted by the notification service extension, the extension adjusts its functionality based upon what the app wrote to shared groups
The user changes the age range setting, but the app doesn't run.
The extension keeps receiving pushes but its functionality is now out of sync with the age range as its not able to obtain it directly
Topic:
App & System Services
SubTopic:
General
We tested call blocking on iOS 26 and noticed something strange: the call will not be blocked if an outgoing call was made to its number before. Nevertheless, it will be blocked if we delete the outgoing call record from the Phone.app Recents.
This behavior looks like a bug and is unexpected when using our application. Was this a planned callkit change in iOS 26? Is it possible to get the correct call blocking behavior back?
We set blocking rules with addBlockingEntry(withNextSequentialPhoneNumber:) and this problem is not present in iOS 18 and earlier.
Thank you in advance
On iOS 18 and lower version, my application supports automatically switching to [System settings - Personal Hotspot] directly. But on iOS 26, my application will be redirected to [System settings- Apps].
Does iOS 26 disable the behavior of directly jumping to the system hotspot page? If support, could you share the API for iOS 26?
Some Apple URL schemes are documented for third-party use. It’s fine to use those URL schemes for their intended purpose.
Other Apple URL schemes are not officially documented. Their use is unsupported. If you rely on such implementation details, things might work, or they might not, and that state might change over time.
IMPORTANT If you ship via the App Store, pay attention to clause 2.5.1 of the App Review Guidelines.
The Apple URL scheme documentation is not always easy to find. I’m aware of the following:
Apple URL Scheme Reference
QA1924 Opening Keyboard Settings from a Keyboard Extension [This Q&A was retired years ago.]
Preparing your app to be the default messaging app
The doc comments for es_new_client in <EndpointSecurity/ESClient.h>
Developer > Bug Reporting describes the applefeedback scheme
Additionally, as questions about this most commonly crop up in the context of opening Settings (System Settings on macOS), I wanted to highlight the following:
UIApplication.openSettingsURLString property (in Objective-C this is UIApplicationOpenSettingsURLString)
UIApplication.openNotificationSettingsURLString property (in Objective-C this is UIApplicationOpenNotificationSettingsURLString)
UIApplication.openDefaultApplicationsSettingsURLString property (in Objective-C this is UIApplicationOpenDefaultApplicationsSettingsURLString)
AccessibilitySettings.openSettings(for:) method
FIFinderSyncController.showExtensionManagementInterface() class method
SMAppService.openSystemSettingsLoginItems() class method
VSOpenTVProviderSettingsURLString global
CXCallDirectoryManager.openSettings(completionHandler:) method
If your app needs to perform some action that’s not covered by the above, file an enhancement request for a supported way to do that. Make sure to describes your use case in detail.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Revision History
2025-10-28 Added a reference to UIApplication.openDefaultApplicationsSettingsURLString. Made other minor editorial changes.
2025-04-21 Added a reference to CXCallDirectoryManager.openSettings(completionHandler:).
2024-10-25 Added a reference to UIApplication.openNotificationSettingsURLString and VSOpenTVProviderSettingsURLString. Added a link to Preparing your app to be the default messaging app.
2024-10-01 Added info about the applefeedback URL scheme.
2024-09-29 Added a reference to SMAppService.openSystemSettingsLoginItems().
2024-09-27 Added a titbit for Finder Sync extension developers. Added an invitation to file feedback.
2024-08-05 First posted.
My app is a VoIP softphone for Mac that allows people to make phone calls to a regular phone numbers. The app exists since before Mac App Store. The app declares itself to the system as capable of handling tel: URLs. Until now, people could change the default handler for tel URLs in FaceTime settings (Default for calls).
In macOS Tahoe 26, this doesn't seem to be possible any more. That option is gone from the FaceTime settings.
Is it completely gone or has it been moved somewhere else? If there is no UI control for this any more, is it possible to change it programmatically?
I'm implementing the PushToTalk framework and have encountered an issue where channelManager(_:didActivate:) is not called under specific circumstances.
What works:
App is in foreground, receives PTT push → didActivate is called ✅
App receives audio in foreground, then is backgrounded → subsequent pushes trigger didActivate ✅
What doesn't work:
App is launched, user joins channel, then immediately backgrounds
PTT push arrives while app is backgrounded
incomingPushResult is called, I return .activeRemoteParticipant(participant)
The system UI shows the speaker name correctly
However, didActivate is never called
Audio data arrives via WebSocket but cannot be played (no audio session)
Setup:
Channel joined successfully before backgrounding
UIBackgroundModes includes push-to-talk
No manual audio session activation (setActive) anywhere in my code
AVAudioEngine setup only happens inside didActivate delegate method
Issue persists even after channel restoration via channelDescriptor(restoredChannelUUID:)
Question:
Is this expected behavior or a bug? If expected, what's the correct approach to handle
incoming PTT audio when the app is backgrounded and hasn't received audio while in the
foreground yet?
Subject: Call Directory Extension Enable Failure for Individual User
Dear Apple Developer Support,
We are experiencing an issue with our Call Directory Extension where one specific user cannot enable it, while thousands of other users on the same iOS version can enable it successfully.
Issue Details:
App: 美信 (Midea Connect)
Problem: Extension fails to enable with error: "请求'美信'的数据时失败" (Failed to request data from app)
Affected: 1 user out of thousands
iOS Version: 26.0.1
What Works:
All other users can enable the extension normally
Same iOS version, no issues
App Group and Extension identifier are correctly configured
User Has Tried:
Reinstall app - No effect
Toggle extension off/on - Still fails
Restart device - No improvement
When an alarm is scheduled for 00:00, the system displays the fullscreen alarm interface twice.
After the second fullscreen view appears, both the “Stop” and “Snooze” buttons become unresponsive, but using the physical button (volume or power button) can dismiss the alarm and correctly trigger the StopIntent.
This behavior occurs consistently (100%), whether the system time is set normally or manually adjusted before the alarm triggers.
Environment:
Device: iPhone 14 Pro Max
iOS Version: 26.0
Reproducibility: 100%
Topic:
App & System Services
SubTopic:
General
Hi Guys,
I've been wanting to make a bettermouse-like tool for some time now, but I can't figure out how to modify mouse events to do it. I've managed to get mouse events, like the cursor moving, but I can't seem to modify them. What I try either creates a feedback loop, does absolutely nothing, or makes the cursor have a seizure. Any help is appreciated!
Topic:
App & System Services
SubTopic:
General
Hi,
As a company, we have several apps in the AppStore that contain AppClips.
With the latest iOS18 it works without any problems.
With all iOS26 betas so far, however, there is always the problem “ASDErrorDomain- Error 507” and the AppClip cannot be opened.
You can easily test this by scanning the following QR code with the system camera:
You only ever get this error instead of the option to open the AppClip.
As the iOS26 beta phase is already at an advanced stage, we are naturally concerned as to whether the problem will be solved.
Hello,
Back in January 2024, I filed a bug report regarding a cache being kept by the macOS Wallpaper Agent. This cache contains every image ever set as a users wallpaper, and at the time the issue was reported, it never cleared, leaving hundreds of gigabytes wasted on users disks in some cases.
FB13536275
This issue was ultimately fixed in macOS 15.1 beta 6, and remained fixed for the duration of macOS 15. The fix was excellent - the cache was reduced to storing just 2-3 days worth of images.
Sadly, we've discovered that this issue is back in macOS Tahoe. The cache has moved locations, and once again is not clearing. We have filed this bug again, less than a year after it was first fixed:
FB20636593
We develop an app called 24 Hour Wallpaper that keeps the wallpaper in sync with the time of day. This necessitates that the app regularly changes the wallpaper, which sadly now results in an infinitely growing and useless cache of BMP files generated by the system.
As we waited 10 months for this to get fixed the first time, we expect to wait at least that long to get it fixed again, and have no confidence that it will stay fixed because the last fix lasted less than a year. This leaves us in a bad position, as people can't use our app without the cache growing arbitrarily and ultimately completely filling their disk.
We've already had customers call Apple to complain about this, and the good news is that the support agents understand that this is a problem with macOS, not with our app.
What we've decided to do is add a feature to the app that monitors the size of this cache and periodically deletes it. We're required to get the users permission the first time to do this, but after that the permission is cached, so the app can keep the cache folder clean regardless of if macOS is doing it's job or not.
We haven't seen any side effects or problems as a result of doing this. We've seen other apps like CleanMyMac do this without any problems. We're wondering if there is anything we should be aware of regarding this caches behavior before releasing this flushing feature.
Thanks for your time,
-josh