Hello, We are using a Message Filter Extension (ILMessageFilterExtension) to classify SMS/iMessage content (junk vs allow) in our app. After testing on iOS 26.1, we want to confirm whether there are any behavioral, performance, or API-level changes that impact message filtering, such as: Changes in how often the filter extension is invoked Differences in classification accuracy or system overrides New privacy, entitlement, or permission-related restrictions Execution time limits or memory constraints Any changes specific to iMessage vs SMS filtering We did not find any explicit mention of Message Filter Extensions in the iOS 26.1 release notes and would like to confirm whether the existing behavior from previous iOS versions remains unchanged. Has Apple introduced any known or undocumented changes in iOS 26.1 that developers should be aware of when supporting Message Filter Extensions? Sometime I also found unpredictable behaviour on iOS version 18.5 or below, like sometime it works but sometimes starts working. Thanks in advance for any guidance.
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
Hello,
We are using a Message Filter Extension (ILMessageFilterExtension) to classify SMS/iMessage content (junk vs allow) in our app. After testing on iOS 26.1, we want to confirm whether there are any behavioral, performance, or API-level changes that impact message filtering, such as: Changes in how often the filter extension is invoked Differences in classification accuracy or system overrides New privacy, entitlement, or permission-related restrictions Execution time limits or memory constraints Any changes specific to iMessage vs SMS filtering We did not find any explicit mention of Message Filter Extensions in the iOS 26.1 release notes and would like to confirm whether the existing behavior from previous iOS versions remains unchanged. Has Apple introduced any known or undocumented changes in iOS 26.1 that developers should be aware of when supporting Message Filter Extensions? Sometime I also found unpredictable behaviour on iOS version 18.5 or below, like sometime it works but sometimes starts working. Thanks in advance for any guidance.
Hello,
I am developing an internal phone application using CallKit.
I am experiencing an issue with the behavior of remoteHandle settings in iOS 26 and would appreciate any insights you can provide towards a solution.
1. Problem Description
When an iPhone running iOS 26 is in a sleep state and receives a VoIP incoming call where remoteHandle is set to nil or an empty string (@""), we are unable to transition to our application (the UIExtension provided by the provider) from the CallKit UI's "More" (…) button after answering the call.
2. Conditions and Symptoms
OS Version: iOS 26
Initial State: iPhone is in a sleep state
Call Type: An unsolicited(unknown number) VoIP incoming call where the CXCallUpdate's remoteHandle is set to either nil or [[CXHandle alloc] initWithType:CXHandleTypePhoneNumber value:@""]
Symptoms: After answering the VoIP call by sliding the button, selecting the "More" (…) button displayed on the CallKit screen does not launch our application's UIExtension (custom UI), and the iPhone instead stay to the CallKit screen.
3. Previous Behavior (Up to iOS 18)
Up to iOS 18, even when remoteHandle was set to an empty string using the following code, the application would transition normally from "More" after answering an incoming call from a sleep state.
CXCallUpdate *update = [[CXCallUpdate alloc] init];
update.remoteHandle = [[CXHandle alloc] initWithType:CXHandleTypePhoneNumber value:@""];
[provider reportNewIncomingCallWithUUID:uuid update:update completion:completion];
4. Unsuccessful Attempts to Resolve
The issue remained unresolved after changing the handling for unsolicited(unknown number) incoming calls as follows:
CXCallUpdate *update = [[CXCallUpdate alloc] init];
update.remoteHandle = nil; // Set remoteHandle to nil
[provider reportNewIncomingCallWithUUID:uuid update:update completion:completion];
5. Workaround (Temporary)
The problem can be resolved, and the application can transition successfully, by setting a dummy numerical value (e.g., "0") for the value in remoteHandle using the following code:
CXCallUpdate *update = [[CXCallUpdate alloc] init];
update.remoteHandle = [[CXHandle alloc] initWithType:CXHandleTypePhoneNumber value:@"0"]; // Set a dummy numerical value
[provider reportNewIncomingCallWithUUID:uuid update:update completion:completion];
6. Additional Information
If remoteHandle is correctly set with the caller's number (i.e., not an unsolicited(unknown number) call; e.g., value:@"1234567890"), the application transitions normally from the "More" button after answering an incoming call from a sleep state, even in iOS 26.
The above issue does not occur when answering incoming calls while the iPhone is in an active state (not sleeping).
7. Questions
Have there been any other reports of similar behavior?
Should this be considered a bug in CallKit for iOS 26? Should I make file a new Feedback report?
Is there a suitable method to resolve this issue when the caller ID is unsolicited (nil or an empty string)?
This problem significantly impacts user operations as end-users are unable to perform essential in-app actions such as hold or transfer after answering an unsolicited(unknown number) call from a sleep state. We are eager to find an urgent solution and would appreciate any information or advice you can provide.
Thank you for your assistance.
The documentation specifies that when Contacts framework returns unified contacts that each fetched unified contact object (CNContact) has its own unique identifier that’s different from any individual contact’s identifier in the set of linked contacts and that when refetching a unified contact, that this identifier should be used.
There is also an analogous identifier within the list of contactRelations, but each of these don't seem to corespondent to the unified contacts. For example, is a new contact (Sheryl Zakroff) is created in the simulator Contacts and their spouse is set to Hank Zakroff. However, the GUID created for the contactRelations identifier does not correlate to the original Hank Zakroff GUID and cannot be searched.
Is this a bug or what is the indent of the contactRelations identifier?
Here's a debug output of walking the unifiedContacts:
Name: Hank Zakroff
2E73EE73-C03F-4D5F-B1E8-44E85A70F170
- Other : (555) 766-4823
- Other : (707) 555-1854
Name: David Taylor
E94CD15C-7964-4A9B-8AC4-10D7CFB791FD
- Other : 555-610-6679
Name: Sheryl Zakroff
DE783BC8-7917-4138-93F6-3AF0FD4CE083
- Other : (707) 555-1854
- Spouse: <CNContactRelation: 0x60000000dd60: name=Hank M. Zakroff>
- 534B467D-CA00-46D3-897C-16EEA782C9CF
- Looking for ["534B467D-CA00-46D3-897C-16EEA782C9CF"]
[]
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?
Description: I am developing a digital well-being application using the Screen Time API (FamilyControls, ManagedSettings, and DeviceActivity). I am encountering a critical issue where the ApplicationToken provided by the system to my app extensions suddenly changes, causing a mismatch with the tokens originally stored by the main application.
The Problem: When a user selects applications via FamilyActivityPicker, we persist the FamilyActivitySelection (and the underlying ApplicationToken objects) in a shared App Group container. However, we are seeing frequent cases where the token passed into:
ShieldConfigurationDataSource.configuration(shielding:in:)
ShieldActionDelegate.handle(action:for:completionHandler:)
...does not match (using ==) any of the tokens previously selected and stored.
IOS version: 26.2.1
Topic:
App & System Services
SubTopic:
General
Tags:
Family Controls
Device Activity
Managed Settings
Screen Time
I'm experiencing a contradictory validation issue with DeviceActivityReportExtension that creates an impossible situation:
The Problem:
Without NSExtensionPrincipalClass in Info.plist → App Store Connect rejects upload with: "Missing Info.plist values. No values for NSExtensionMainStoryboard or NSExtensionPrincipalClass found"
With NSExtensionPrincipalClass → Local install fails with: "defines either an NSExtensionMainStoryboard or NSExtensionPrincipalClass key, which is not allowed for the extension point com.apple.deviceactivityui.report-extension"
Setup:
Extension point: com.apple.deviceactivityui.report-extension
Using SwiftUI with @main attribute and DeviceActivityReportExtension protocol
Xcode 16.2, iOS 17.6 deployment target
Code structure:
@main
struct SpoolReport: DeviceActivityReportExtension {
var body: some DeviceActivityReportScene {
// Report scenes here
}
}
The extension builds and runs perfectly without NSExtensionPrincipalClass, but cannot be uploaded to App Store Connect. Adding the key allows upload but breaks local installation.
Is this a known issue? Is there a workaround or correct Info.plist configuration for DeviceActivityReportExtension?
Thank you!
Hi there,
Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row.
Feedback: FB21267341
There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC.
DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.
Topic:
App & System Services
SubTopic:
General
Tags:
Family Controls
Device Activity
Managed Settings
Screen Time
Hello, We are using a Message Filter Extension (ILMessageFilterExtension) to classify SMS/iMessage content (junk vs allow) in our app. After testing on iOS 26.1, we want to confirm whether there are any behavioral, performance, or API-level changes that impact message filtering, such as: Changes in how often the filter extension is invoked Differences in classification accuracy or system overrides New privacy, entitlement, or permission-related restrictions Execution time limits or memory constraints Any changes specific to iMessage vs SMS filtering We did not find any explicit mention of Message Filter Extensions in the iOS 26.1 release notes and would like to confirm whether the existing behavior from previous iOS versions remains unchanged. Has Apple introduced any known or undocumented changes in iOS 26.1 that developers should be aware of when supporting Message Filter Extensions? Sometime I also found unpredictable behaviour on iOS version 18.5 or below, like sometime it works but sometimes starts working.
Thanks in advance for any guidance.
Hi DTS / Apple engineers,
We’re attempting to extending our screen time app target to Mac Catalyst. On iOS, FamilyControls works as expected (AuthorizationCenter + FamilyActivityPicker, then ManagedSettings shields + DeviceActivity monitoring/reporting).
On Mac Catalyst:
The project builds with FamilyControls/DeviceActivity/ManagedSettings capabilities enabled.
But attempting to request FamilyControls authorization (or present FamilyActivityPicker) fails at runtime. We see errors similar to:
Failed to get service proxy: The connection to service named com.apple.FamilyControlsAgent was invalidated: failed at lookup with error 159 - Sandbox restriction.
And our app stays authorizationStatus == .notDetermined, with the request failing.
We saw an Apple engineer suggestion to “disable App Sandbox”, but Mac Catalyst apps appear to always be sandboxed, so we can’t disable it.
Questions:
Is FamilyControls authorization supported on Mac Catalyst today? If so, what entitlement/capability is required specifically for Catalyst/macOS?
If FamilyControls auth cannot succeed on Catalyst, does that mean ManagedSettings shields and DeviceActivity monitoring/reporting are effectively unusable on Catalyst (since they depend on that authorization)?
Is there an Apple‑recommended approach for a Catalyst “portal” app that mirrors an iOS child device’s restrictions, or is local enforcement on Catalyst intentionally unsupported?
Any guidance (and any official docs that clarify current platform support) would be hugely appreciated.
Topic:
App & System Services
SubTopic:
General
Tags:
Mac Catalyst
Family Controls
Device Activity
Managed Settings
Reference: FB21797091 / Related to thread 807695
Hello,
I have already submitted a report regarding this issue via Feedback Assistant (FB21797091), but I would like to share the technical details here to seek further insights or potential workarounds.
We are experiencing a technical regression where Universal Links and Shared Web Credentials fail to resolve for Internationalized Domain Names (IDN) specifically on iOS 16 and later. This issue appears to be identical to the one discussed in thread 807695 (https://developer.apple.com/forums/thread/807695).
Technical Contrast: What works vs. What fails On the exact same app build and iOS 16+ devices, we observe a clear distinction:
Standard ASCII Domain (onelink.me): Works perfectly. (Proves App ID and Entitlements are correct)
Internal Development Domain (Standard ASCII): Works perfectly. (Proves our server-side AASA hosting and HTTPS configuration are correct)
Japanese IDN Domain (xn--[punycode].com): Fails completely. (Status: "unspecified")
Note: This IDN setup was last confirmed to work correctly on iOS 15 in April 2025. Currently, we are unable to install the app on iOS 15 devices for live comparison, but the regression starting from iOS 16 is consistent.
This "Triple Proof" clearly isolates the issue: the failure is strictly tied to the swcd daemon's handling of IDN/Punycode domains.
Validation & Diagnostics:
Validation: Our Punycode domain passes all technical checks on the http://Branch.io AASA Validator (Valid HTTPS, valid JSON structure, and Content-Type: application/json).
sysdiagnose: Running swcutil on affected iOS 16+ devices shows the status as "unspecified" for the IDN domain.
Symptoms: Universal Links consistently open in Safari instead of the app, the Smart App Banner is not displayed, and Shared Web Credentials for AutoFill do not function.
Request for Resolution:
We request a fix for this regression in the swcd daemon. If this behavior is a specification for security reasons, please provide developers with a supported method or workaround to ensure IDN domains function correctly.
We have sysdiagnose logs available for further investigation. Thank you.
Does our app need to check the location or can we fully reply on this API to decide whether we wanna comply for the law of places that requires age range information? Looks like it's only covering Texas now..? would it add other places by apple..? And also this API is really hard to test a user in other places, Iike I don't know a user in Brazil gonna return true for false now, but the law in Brazil also requires the age information.
I've tried pass different value like 13,16,18, but I don't see any difference..? could anyone tell what could happen differently if I pass a different value here?
Subject: iOS Fails to Fetch AASA File for Internationalized Domain Names (IDN) in Unicode or Punycode Format
Dear Apple Developer Relations Team And Community Members,
We are reporting a critical bug in the iOS Associated Domains feature that prevents Universal Links from working for apps using Internationalized Domain Names (IDN).
Problem Description:
The iOS operating system does not attempt to download the apple-app-site-association (AASA) file for domains containing non-ASCII characters (e.g., diacritics, Cyrillic).
This failure occurs regardless of whether the domain is specified in the app's entitlements in its human-readable Unicode format (e.g., montréal.ca) or its encoded Punycode format (e.g., xn--montral-fya.ca, xn--e1afka0abm4b.xn--p1ai).
Without fetching and validating this file, Universal Links are not activated, and the system fails to establish a connection between the website and our app.
Steps to Reproduce:
Create an app with the Associated Domains entitlement enabled.
Add an IDN to the entitlement. We tested both formats:
Format A (Unicode): applinks://montréal.ca
Format B (Punycode): applinks://xn--montral-fya.ca
Host a valid AASA file on our server at the correct, accessible well-known URLs for both domain representations:
For montréal.ca: https://montréal.ca/.well-known/apple-app-site-association and https://xn--montral-fya.ca/.well-known/apple-app-site-association
Install the app on a device running the latest iOS version.
Monitor network traffic using a tool like Charles Proxy.
Observed Result:
No HTTP GET request is made to any of the AASA URLs for the domains montréal.ca (in either Unicode or Punycode format) upon app installation. The system does not initiate the domain validation process. In contrast, for a standard ASCII domain (e.g., applinks://example.com), the AASA fetch is triggered immediately and is observed in the network log.
Expected Result:
iOS should correctly resolve the Internationalized Domain Name (whether specified in Unicode or Punycode format in the entitlement) and perform an HTTP GET request to fetch the AASA file from the /.well-known path, identical to its behavior for ASCII domains.
Evidence & Configuration:
Our server is configured correctly: SSL certificates are valid, the AASA file is served with the correct application/json MIME type, and is directly accessible via a browser or curl.
The AASA file's syntax has been validated and is correct.
The issue is reproducible on the latest versions of iOS.
Impact:
This bug blocks a core platform feature for millions of users in regions that use non-Latin scripts (e.g., France, Russia, China, Arab states). It makes it impossible to use Universal Links with our primary domains, severely degrading the user experience and forcing us to seek suboptimal workarounds like registering separate ASCII domains.
Request:
We kindly request that you investigate and log this issue as a bug in iOS and forward it to the appropriate engineering team for a fix in an upcoming update. We are prepared to provide any additional information, demo projects, or server access to assist in diagnostics.
Thank you for your attention to this serious matter.
Hello Apple Developer Community,
I'm working on implementing App Clips for a restaurant platform and need guidance on configuring custom App Clip experiences using URL redirects.
Context:
We have multiple restaurant locations, each needing branded App Clip cards (custom image, title, subtitle). With hundreds of tables across many venues, creating individual App Clip experiences for each table in App Store Connect isn't scalable.
Currently:
Using a single, generic App Clip experience for all locations => https://example.com
Desired Flow:
Customer scans QR code at restaurant table
↓
https://example.com/123
↓
iOS fetches URL
↓
Server responds with 302 redirect
↓
https://example.com/brands/le-pain-quotidien?venue=abc123
↓
iOS displays App Clip card with "Le Pain Quotidien" branding
↓
User taps "Open" → App Clip launches with correct context
What I've Tried:
Configured multiple App Clip experiences in App Store Connect
Implemented 302 redirects from short URLs to branded URLs
Tested various redirect configurations without success
Questions:
Does iOS fetch and follow redirects before displaying the App Clip card, or does it only use the originally scanned URL?
What App Clip experience URLs should be configured in App Store Connect for this redirect scenario?
Are there specific HTTP headers or redirect requirements for iOS to properly recognize the final destination?
Should the App Clip experience be registered for example.com/123 or example.com/brands/le-pain-quotidien?
Reference:
Apple's documentation suggests this is possible:
https://developer.apple.com/documentation/AppClip/configuring-the-launch-experience-of-your-app-clip#Use-short-URLs-or-redirects
Has anyone successfully implemented custom App Clip cards using URL redirects? Any guidance on the correct configuration approach would be greatly appreciated.
Thank you!
Environment:
Xcode 26
iOS 26
Also tested on iOS 18 (working correctly)
Description:
I'm experiencing a behavior change with URL(fileURLWithPath:) when the filename starts with a tilde (~) character.
On iOS 18, passing a filename like ~MyFile.txt to URL(fileURLWithPath:) treats the tilde as a literal character. However, on iOS 26, the same code resolves the tilde as the home directory, resulting in unexpected output.
Minimal Example:
let filename = "~MyFile.txt"
let url = URL(fileURLWithPath: filename)
print(url.lastPathComponent)
Expected Result (iOS 18):
~MyFile.txt
Actual Result (iOS 26):
924AF0C4-C3CD-417A-9D5F-733FBB8FCF29
The tilde is being resolved to the app's container directory, and lastPathComponent returns the container UUID instead of the filename.
Questions:
1. Is this an intentional behavior change in iOS 26? 2. Is there documentation about this change? 3. What is the recommended approach for extracting filename components when the filename may contain special characters like ~?
Workaround:
Using NSString.lastPathComponent works correctly on both iOS versions:
let filename = "~MyFile.txt"
let result = (filename as NSString).lastPathComponent
// Returns: "~MyFile.txt" ✅
Is this the recommended approach going forward?
I found currently there is no way to revoke sharing age to an app after I shared to it, no matter in testing or in app settings
My app is configured with the App Clip experiences, and a Clip App card pops up when an NFC tag is scanned—whether the host app is not launched, running in the background, or active in the foreground. I want to prevent the App Clip card from popping up when the host app is in the foreground; how can this be achieved?
In a class, I call the following (edited to simplify, but it matches the real case).
If I do this:
func getData() -> someClass? {
_ = someURL.startAccessingSecurityScopedResource()
if let data = NSData(contentsOf: someURL as URL) {
do {
let unarchiver = try NSKeyedUnarchiver(forReadingFrom: data as Data)
print((unarchiver.decodeObject(of: [NSArray.self, someClass.self /* and few others*/], forKey: oneKey) as? someClass)?.aProperty)
if let result = unarchiver.decodeObject(of: [NSArray.self, someClass.self /* same other types*/], forKey: oneKey) as? someClass {
unarchiver.finishDecoding()
print("unarchived success")
return result
} else {
unarchiver.finishDecoding()
print("unarchiving failed")
return someClass()
}
}
catch {
return nil
}
}
I get a failure on log : unarchiving failed
But if I comment out the print(unarchiver.decodeObject) - line 8, it works and I get unarchived success
// print((unarchiver.decodeObject(of: [NSArray.self, someClass.self /* and few others*/], forKey: oneKey) as? someClass)?.aProperty)
However, when I do exactly the same for another class (I've compared line by line to be sure), it works even with the print statement.
What could be happening here ?
How should i write and not show this sensitive error?
Topic:
App & System Services
SubTopic:
General