When a user enables an SMS filtering extension via iOS Settings → Messages → Text Message Filtering and selects an app, the following prompt appears: "The developer of [App Name] will receive the text, attachments and sender information in text messages from senders not in your Contacts. Messages may include personal or sensitive information like bank verification codes." This message cannot be modified by developers, and we're receiving complaints and negative reviews from users who are alarmed by it, despite our app not collecting any data. iOS should allow developers to customize this message or reword this message to not make false claims about data collection. We've opened a feedback assistant report here: FB21445903

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()

Environment: Device: iPhone 15 iOS Version: 26.2 Xcode Version: (add your version) Signing: Automatic with Apple Developer account Problem: When calling NFCTagReaderSession.begin(), the session immediately fails with error code 2: "Missing required entitlement". This happens even though: NFCTagReaderSession.readingAvailable returns true NFCNDEFReaderSession.readingAvailable returns true The session object is created successfully Configuration verified: BonoResidente.entitlements: Info.plist (relevant keys): NFCReaderUsageDescription This app needs NFC permission to read transport cards com.apple.developer.nfc.readersession.iso7816.select-identifiers D2760000850101 Apple Developer Portal: App ID com.acalvoelorri.BonoResidente has "NFC Tag Reading" capability enabled Provisioning profiles were regenerated after enabling the capability Xcode: "Near Field Communication Tag Reading" capability added via Signing & Capabilities CODE_SIGN_ENTITLEMENTS correctly points to the entitlements file Automatic signing enabled with valid Development Team Steps taken: Deleted app from device Clean Build Folder (Cmd+Shift+K) Deleted and re-added the NFC capability in Xcode Manually enabled NFC Tag Reading in Apple Developer Portal Rebuilt and reinstalled the app Code: import CoreNFC class NFCReaderService: NSObject, ObservableObject, NFCTagReaderSessionDelegate { @Published var lastReadData: String = "" @Published var isReading: Bool = false private var session: NFCTagReaderSession? func startReading() { guard NFCTagReaderSession.readingAvailable else { lastReadData = "NFC not available on this device" return } session = NFCTagReaderSession( pollingOption: [.iso14443, .iso15693, .iso18092], delegate: self ) session?.alertMessage = "Hold your transport card near the iPhone" session?.begin() isReading = true } func tagReaderSessionDidBecomeActive(_ session: NFCTagReaderSession) { print("NFC session active") } func tagReaderSession(_ session: NFCTagReaderSession, didInvalidateWithError error: Error) { // Error occurs here immediately after begin() print("Error: \(error)") } func tagReaderSession(_ session: NFCTagReaderSession, didDetect tags: [NFCTag]) { // Never reached } } Console logs: ========== NFC DEBUG INFO ========== iOS Version: 26.2 Device Model: iPhone Device Name: iPhone System Name: iOS NFCTagReaderSession.readingAvailable: true NFCNDEFReaderSession.readingAvailable: true Bundle ID: com.acalvoelorri.BonoResidente Creating NFCTagReaderSession with pollingOption: [.iso14443, .iso15693, .iso18092]... Session created: Optional(<NFCTagReaderSession: 0x110fa50e0>) Setting alertMessage... Calling session.begin()... session.begin() completed, isReading = true ========== NFC ERROR DEBUG ========== Full error: Error Domain=NFCError Code=2 "Missing required entitlement" UserInfo={NSLocalizedDescription=Missing required entitlement} Error type: NFCError Localized: Missing required entitlement NSError domain: NFCError NSError code: 2 NSError userInfo: ["NSLocalizedDescription": Missing required entitlement] Questions: Is there a known issue with NFCTagReaderSession entitlements on iOS 26.2? Are there additional entitlements required beyond com.apple.developer.nfc.readersession.formats with value TAG? How can I verify that the installed app's provisioning profile actually contains the NFC entitlement? Any help would be appreciated. Thank you.

Hi everyone, We’re running into a serious issue with App Clip Experience updates not propagating to devices, and I’m hoping someone here has encountered (or solved) this before. Problem Once an App Clip Experience is created and used on devices, subsequent updates made in App Store Connect do not reflect on any devices, even after a long period of time. We’ve tried: • Updating the App Clip Experience URL (adding utm parameters, for example, utm_source and scanning via QR code) • Modifying Experience metadata/content • Waiting several days (over a week) • Testing on multiple devices (including devices that never opened the App Clip before) Despite this, the App Clip continues to show the initially created content, while App Store Connect clearly shows the updated configuration. Important Details • We currently have ~1,300 App Clip Experiences created • All App Clips use the same App Clip Bundle ID • The content behind the URLs updates correctly on the website • Only the App Clip continues to show stale / initial data • Removing and re-invoking the App Clip on devices does not consistently fix the issue At this point, manual updates via App Store Connect appear to be completely ignored once the App Clip is “established.” Questions 1. Is there a known hard cache or CDN behavior on Apple’s side that prevents App Clip Experience updates from propagating? 2. Is there any way to invalidate or refresh an existing App Clip Experience? 3. Does having a large number of App Clip Experiences (~1300) affect update behavior or caching? 4. Is the recommended approach to treat App Clip Experience as immutable and handle all updates via backend / dynamic content only? Right now it feels like: App Clip Experience is effectively a one-time snapshot and not a live-updatable configuration. Any insights, confirmations, or official guidance would be greatly appreciated. Thanks in advance.

Hi all, I'm working on a Call Directory Extension using CXCallDirectoryExtensionContext. I want to add a list of numbers to be blocked. Here's the function I use: override func beginRequest(with context: CXCallDirectoryExtensionContext) { context.delegate = self let blockedNumbers = loadNumberEntries(forKey: blockedKey) let identifiedNumbers = loadNumberEntries(forKey: identifiedKey) addAllBlocking(blockedNumbers, to: context) addAllIdentification(identifiedNumbers, to: context) context.completeRequest() } private func addAllBlocking(_ entries: [NumberEntry], to context: CXCallDirectoryExtensionContext) { let numbers: [Int64] = entries.compactMap { Int64($0.countryCode + $0.phone) }.sorted() for number in numbers { context.addBlockingEntry(withNextSequentialPhoneNumber: number) print("# Added blocking entry: \(number)") } } When I run this, I see in the console: # Added blocking entry: (*my number with country code*) So it seems the number is added correctly. However, in practice, the number is not blocked on the device. I’ve made sure that: The number is stored with the country code prefix. The extension is enabled in Settings → Phone → Call Blocking & Identification. The extension is reloaded after adding numbers. The array of numbers is sorted in ascending order before calling addBlockingEntry. Despite all this, the number still isn’t blocked. Does anyone know why the print shows the number added, but it doesn’t actually block the call? Am I missing something in the way CXCallDirectoryExtensionContext works? Thanks for any advice!

Hello, I have an AppClip technical issue I'd like to ask about: Our Xiaohongshu App (Version 9.14 & Build 9140845 & appid 741292507) was submitted to the App Store for review on December 18th and approved on December 19th, starting a phased rollout. This version was the first to support AppClip functionality, and as of today the app has been fully rolled out, but I still cannot activate the Xiaohongshu App Clip Card using the NFC tag (built-in URL: https://xhslink.com/n/22UG9jlaOfv?sourceid=911). I checked all the configurations of our project's AppClip target (Associated Domains:appclips:xhslink.com), the default experience in the ASC backend (URL: https://appclip.apple.com/id?p=com.xingin.discover.Clip), and the advanced experience (URL: https://xhslink.com/n/Arxpo4IVY9X), and all showed no abnormalities. Furthermore, the default experience URL, after being written with an NFC tag, can be successfully launched by tapping the NFC tag to open the Xiaohongshu App Clip Card, and the Card can also be opened normally in Safari on the phone. However, our advanced experience URL, after being written with an NFC tag, cannot be launched by tapping the Card. Therefore, my question is: Who please can help me check why the Xiaohongshu App Clip Card cannot be launched normally using the advanced experience URL? Thank you very much! My Expectations: My advanced experience URL configured on the ASC platform, such as https://xhslink.com/n/Arxpo4IVY9X, should be recognized and validated by the iOS system when the phone is near the NFC tag and reads https://xhslink.com/n/22UG9jlaOfv?sourceid=911, ultimately triggering the App Clip Card configured in Xiaohongshu's advanced experience settings. Additionally: We have already deployed a large number of NFC tags and other materials in many online stores, and the URL (https://xhslink.com/n/Arxpo4IVY9X) is built-in, and our 9.14 version is fully implemented. However, the newly developed App Clip feature is not working, which is very urgent and I hope Apple can help me find the cause of the problem and how to improve it as soon as possible. Thank you very much!

I've been trying to follow Apple's testing age assurance documentation here. After following each step and setting my user as "Texas, child 16-17, significant change declined", the AgeRangeService consistently throws the notAvailable error: do { let response = try await AgeRangeService .shared.requestAgeRange(ageGates: 18, in: self) // ... } catch AgeRangeService.Error.notAvailable { // Always throws this error }

Install both Motiv Audio and Motiv Video apps from the App Store. Open and use the Motiv Audio app. Remove audio app from background. Open Motiv Video app. Observe that the Motiv Audio app crashes. Both apps are checking Free available space. Both app are using Audio Engine

Hey there, We are being incorrectly blocked by Time Limits since the iOS 26 update released earlier this year. We are receiving complaints from parents that set a screentime limit for "All apps", and then add an exception for us, that they are still getting blocked by the OS after a certain period of time. While we originally thought this was fixed in 26.1, we have recently been made aware it still occurs. Has anyone else experienced this issue? Is there something we can do from our side to protect ourselves from this? Telling customers to remove their "All app" limit isn't really practical given our customer base, so we're looking to see if there's something on Apple's end or our end that can alleviate this.

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.

Problem Description: After upgrading to iOS 26, I discovered that the ExtendedDistanceMeasurement feature in the Nearby Interaction framework is not working as expected. On the same device model, the issue did not occur on iOS 18, but it is present on iOS 26 (including the latest iOS 26.2), and it has started affecting the functionality of my app. I hope this issue can be resolved as soon as possible. Problem Details: On iOS 26 and later versions (including iOS 26.2), when using an iPhone and an Apple Watch both equipped with second-generation UWB chips, enabling isExtendedDistanceMeasurementEnabled initiates the distance measurement process successfully, but the distance information fails to update. The real-time distance between the devices does not display within the app. Affected Devices and Versions: iPhone Model: iPhone 15 Pro Max iOS Version: iOS 26.2 Apple Watch Model: Apple Watch 10 watchOS Version: 26.2 Example Code: The issue can be reproduced by adding the following code from the official sample code: Nearby Interaction Framework Sample Code

Problem Description: After upgrading to iOS 26, I discovered that the ExtendedDistanceMeasurement feature in the Nearby Interaction framework is not working as expected. On the same device model, the issue did not occur on iOS 18, but it is present on iOS 26 (including the latest iOS 26.2), and it has started affecting the functionality of my app. I hope this issue can be resolved as soon as possible. Problem Details: On iOS 26 and later versions (including iOS 26.2), when using an iPhone and an Apple Watch both equipped with second-generation UWB chips, enabling isExtendedDistanceMeasurementEnabled initiates the distance measurement process successfully, but the distance information fails to update. The real-time distance between the devices does not display within the app. Affected Devices and Versions: iPhone Model: iPhone 15 Pro Max iOS Version: iOS 26.2 Apple Watch Model: Apple Watch 10 watchOS Version: 26.2 Example Code: The issue can be reproduced by adding the following code to the official sample code: Nearby Interaction Framework Sample Code private func didReceiveDiscoveryToken(_ token: NIDiscoveryToken) { if session == nil { initializeNISession() } if !didSendDiscoveryToken { sendDiscoveryToken() } os_log("running NISession with peer token: \(token)") let config = NINearbyPeerConfiguration(peerToken: token) // The issue can be reproduced by adding the following code to the official sample code // Enable extended distance measurement if both devices support it if NISession.deviceCapabilities.supportsExtendedDistanceMeasurement && token.deviceCapabilities.supportsExtendedDistanceMeasurement { config.isExtendedDistanceMeasurementEnabled = true } session?.run(config) } Problem Behavior: When either the iPhone or the Apple Watch does not support the second-generation UWB chip (i.e., deviceCapabilities.supportsExtendedDistanceMeasurement = false), the code works as expected. However, when both the iPhone and the Apple Watch support the second-generation UWB chip (i.e., deviceCapabilities.supportsExtendedDistanceMeasurement = true), the code fails to work, and the distance does not update — meaning the real-time distance between the devices is not displayed. Expectation: I hope this issue can be resolved soon, as it is impacting my app. The problem persists in the latest iOS 26.2, and has yet to be fixed.

Hi everyone, I’ve removed my App Clip completely: Deleted all Advanced App Clip Experiences Removed the App Clip target from my build Removed App Clip references from my apple-app-site-association file Deleted the meta tag from my website: But when I scan the QR code, the App Clip card still appears with: "This App Clip is not currently available in your country or region." Does anyone know why this is still showing and how to fully remove it? we need to show our website when this QRCode is scanned. Thanks!

Hi, Is there any way to make AlarmKit alarms snooze when the user presses the hardware volume buttons? Currently, pressing a volume button while an AlarmKit alarm is ringing stops/dismisses the alarm. Why this matters: Many users instinctively press the volume buttons when an alarm starts (either to react quickly while half-asleep or because they’re used to the Clock app behavior). When this stops the alarm entirely, users unintentionally dismiss the alarm, which can lead to missed wake-ups and a poor user experience. In practice, this becomes a frequent source of confusion and frustration because the behavior differs from the system Clock app.

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.

The documentation for isEligibleForAgeFeatures states: Use this property to determine whether a person using your app is in an applicable region that requires additional age-related obligations for when you distribute apps on the App Store. But what does "region" mean? Is this going to return true if the user has downloaded the app from the US App Store? Or will it go further and geolocate the user and identify them as being within a particular relevant state within the US?

I am trying to port my sandboxed macOS app completely over to iOS using a Catalyst target and SwiftUI. There appears to be an issue when trying to drag to the Finder in Catalyst (and in SwiftUI in General). For some reason, the Finder will not accept multiple file drops, only a single file. On my macOS (non-Catalyst AppKit target), I overcame this by dropping multiple files to a UTType of .folder, and the OS accepted the folder. This workaround is not available for iOS because .folder is a macOS-only option. I have a test app to illustrate the issue. Hopefully someone can help. Download Test App

I am trying to port my sandboxed macOS app completely over to iOS using a Catalyst target. In my macOS app, I use 'SwiftySandboxFileAccess' package to add a symlink to '~/Library/PDF Services' so that the 'share to my app' menuItem shows up in the macOS Print Panel (in the PDF menu). It is critical for the function of my app to have this work on macOS. In the Catalyst target, I am having problems gaining access to '~/Library'. I have tried having the user select the folder, but the picker always returns 'canceled'. I have a test app that illustrates this. The test app tries to coax the user into selecting the library folder and then it is supposed to bookmark the location, but I am unable to get this far. As an aside, macOS should probably automatically add an entry to the Print Panel when the app includes PDF as a document type in XCode; it would save a lot of hassle and avoid having to go outside of the sandbox. However, I cannot wait for that. Hopefully someone can help. Download Test App from iCloud (If you have problems downloading the file, it might be because of some iCloud share setting that I am not aware of. Just tell me and I'll figure something out.)

I'm developing a VoIP app. Currently, I'm using CallKit to control call acceptance, and end-of-call processing. When a call comes in while using the phone, CallKit appears as a banner at the top of the screen. When I click "Accept" on the banner, the app opens and the call is received. (For OEMs, clicking the "Accept" button in the banner will accept the call as is.) The reason this feature is needed is, for example, when a call comes in as a banner call while using a navigation app, accepting the call causes the navigation app to go to the back and the VoIP app to come to the foreground, causing inconvenience to customers. This needs to be improved. Please advise.

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.