Hi there, I’m curious to understand how the system determines which language to use for an app. The system is currently set to en-IN (English - India). My app supports the following languages: en (the default development language) en-GB (United Kingdom) en-IE (Ireland) en-US (United States) When I run the app, the Bundle.main.preferredLanguages returns [„en-GB“, „en“], which causes the app to be set to en-GB. However, when the app doesn’t support the preferred system language, I would expect it to default to the en language. Surprisingly, this is not the case. This behavior is precisely described in Technical Note TN2418. Unfortunately, there’s no explanation provided. Is this behavior related to the CLDR Linguistic Distance? I also attempted to replace the default development language en with en-001 (English - world), but it had no effect.

I'm having problem with my VoIP application. My app uses Callkit and VoIP push notification to make SIP calls between same app. Sometimes after taking the phone the call doesn't start. I found out iOS is not sending back audioSession didActive response to my app. Is this known issue or bug?

We are currently verifying the functionality of CXSetTranslatingCallAction. We tested its implementation in a VoIP app—using Apple's Translate app by default—and confirmed that it works correctly in some instances. However, we have encountered an issue where, under certain conditions, the real-time translation feature becomes unavailable until the device is rebooted. The issue manifests as follows: When the real-time translation feature is enabled in CallKit, a beep sounds accompanied by the announcement "Starting translation," but the translation fails to proceed and terminates immediately. This behavior persists upon repeated attempts. Restarting the app does not resolve the issue; once this occurs, the feature remains unusable until the device itself is rebooted. Since the feature works normally after a device reboot, it does not appear to be a fundamental implementation error; I would like to investigate the root cause of this behavior. What information or steps are required to investigate this? I conducted the test using an iPhone 16 Pro running OS version 26.5. It is the same for both CallKit and LCK.

I'm testing code that uses NSMetadataQuery and I noticed some odd behavior. I run a query where the search scope is set to my Desktop directory. The predicate is set to search for a file name that contains 'we' (display name to be precise: kMDItemDisplayName). And I get no results. So I stop the app from Xcode then I create a new folder on the Desktop and name it we exactly. Then I rerun my app and start the query again - still no results. Unfortunately none of the Spotlight based APIs I'm using report errors. There is no delegate method -queryDidFailWithError: or anything like that. So in another place my app uses the lower level MD prefixed APIs in Core Services to read file metadata and I notice that those APIs are failing as well. Specifically I try to load metadata for a PNG image. I create an MDItemRef via MDItemCreateWithURL (and I do get an MDItemRef). Then I call MDItemCopyAttributes with the MDItemRef and an array of metadata attribute names: CFDictionaryRef fetchedData = MDItemCopyAttributes(mdItem, attributeNames); I step through it in the debugger and fetchedData is NULL. Since there is no error handling APIs available for any of this my app just silently fails. I have Console.app open when I step through MDItemCopyAttributes call in the debugger and this logs out every time: com.apple.spotlightserver Bad checksum on fetch attributes reply from store, 0x123ea456.... FWIW I do not have Spotlight indexing turned off on my system. Also jumping to Finder I'm experiencing the same failures (metadata isn't populating and the Desktop search for we produces no results). Actually on further inspection it looks like all searches are producing no results. Spotlight appears to be in a broken state system wide. I'm pretty sure a system restart will 'fix' it - until it starts occurring again. But for obvious reasons I'd like to avoid releasing a feature in my app that results in this kind of experience. Is there anything I can do on my end to workaround or avoid this issue? And tips or advice would be greatly appreciated.

Hi everyone, I’ve filed a Feedback report (FB20986470) for a serious issue affecting the Call Directory database when add phone numbers for call blocking. When adding blocking numbers to a Call Directory extension, the system’s CallKit database (/private/var/mobile/Library/CallDirectory/CallDirectory.db) becomes corrupted. The reload call (reloadExtensionWithIdentifier) fails with error code 11 when the system tries to insert blocking entries, and the Console app on macOS shows the following errors: database corruption page 2265525 of /private/var/mobile/Library/CallDirectory/CallDirectory.db at line 81343 of [f0ca7bba1c] database corruption at line 79387 of [f0ca7bba1c] Error Domain=com.apple.callkit.database.sqlite Code=11 "sqlite3_step for query 'INSERT INTO PhoneNumberBlockingEntry (extension_id, phone_number_id) VALUES (?, (SELECT id FROM PhoneNumber WHERE (number = ?))), (?, (SELECT id FROM PhoneNumber WHERE (number = ?))),...)'" After this happens, CallKit becomes fully corrupted on the device and no further numbers can be added, even after: Disabling and re-enabling the extension Restarting the device (either force or soft restart) Reinstalling the app Waiting for a couple of minutes after this issue happens (that CallKit could possibly self-recovered) I also tested other call-blocking apps, and they all fail with the same error. The only thing that recovers the system is a full “Reset All Settings.” This issue has been reported by many users of my app, across multiple iOS versions and devices. Similar related issue reported by another developer: https://developer.apple.com/forums/thread/806129 Steps to Reproduce: Enable the Call Directory extension from a call-blocking app. Add and reload blocking numbers (a few thousand entries). Perform multiple reloads between additions. Check the Console, the corruption errors appear. From this point, all insert attempts fail system-wide. Expected Result: Entries should be inserted successfully, or the system should self-recover without persistent corruption. Actual Result: sqlite3_step fails with Code=11, and the Call Directory database remains corrupted until the user resets all settings. Additional Notes: All numbers are sorted and deduplicated before insertion. Happens intermittently after multiple reloads. The system log always shows internal database failure. Environment: Device: iPhone 16 Plus iOS 18.2 Beta (23C5027f) Xcode 16.1 (17B55) Attachments (included in Feedback FB20986470): sysdiagnose captured immediately after the failure (with Phone app General Profile) It seems like a system-level corruption affecting all Call Directory extensions once it occurs.

Hi there, I am working on a little application which processes cursor and graphics tablet data and adds some extra control to the output. So far it makes use of... if let eventTap = CGEvent.tapCreate(tap: .cgSessionEventTap, //.cghidEventTap place: .headInsertEventTap, options: .defaultTap, eventsOfInterest: eventMask, callback: handleTapEvent, userInfo: userInfo) ... to modify existing events. The issue that in some cases arises (it's a globally working app) - that some other applications pull and process pointer-data aside the event stream and therefor create conflicting values. Would creating and posting events to a 'virtual pointing device' on a lower system level (kext) help? Let's discuss. BR, E

Hello, I am investigating call behaviour on a dual SIM iPhone. Observed behavior: A specific line is selected in Settings > Cellular > Default Voice Line. Our app initiates the native call flow by opening a phone-number URL scheme with the destination number. The native Phone app does not always place the call using the selected default line. Expected behaviour: The native Phone app should place the call using the line selected in Settings > Cellular > Default Voice Line Questions: In this flow, is line selection fully controlled by iOS? Is there any supported way for an app to ensure the native Phone app respects the selected default line? Is this a known limitation or known issue on dual SIM devices? Any clarification on expected iOS behaviour would be appreciated.

CTFontManagerCreateFontRequestRunLoopSource does not receive any font requests on macOS 27, since beta 5. This API worked fine until macOS 27 beta 4, including previous macOS releases. It looks like this is caused by the App Sandbox. When the com.apple.security.app-sandbox entitlement is disabled the font request source does receive events. Report including sample project: FB24764122 let source = CTFontManagerCreateFontRequestRunLoopSource(0, { (dict, pid) in /* does not receive events when sandboxed */ } CFRunLoopAddSource(CFRunLoopGetCurrent(), source, .defaultMode) Is this a deliberate change or is this a bug in macOS 27? Is there an entitlement that can be set to enable the API in sandboxed apps? My application is distributed on the Mac App Store and as standalone app. Both are properly sandboxed for added security. Disabling the App Sandbox for this specific API would be very undesirable as users will lose all Sandbox benefits.

Hi, I am developing a Screen Time App and I am having issues with the ShieldConfigurationExtension (ShieldConfigurationDataSource). I know this extensions is sandboxed but I should be able to read data from the main app. I am using SwiftData as my database, but I am unable to initialize it in the extensions with an error indicating insufficient file permissions. I have App Group set up and I am able to share data using UserDefaults but that is just inconvenient. Is there any way I could just open the SwiftData in read only mode so that I could display the user some info on the shield? SwiftData Init: private func setupContainer() throws { let schema = Schema([ DogEntity.self, HouseEntity.self ]) // Use app group container if available let config: ModelConfiguration if let containerURL = FileManager.default.containerURL( forSecurityApplicationGroupIdentifier: "group.\(Bundle.app.bundleIdentifier ?? "")" ) { config = ModelConfiguration(schema: schema, url: containerURL.appendingPathComponent("default.sqlite")) } else { config = ModelConfiguration(schema: schema) } self.container = try ModelContainer(for: schema, configurations: [config]) } Error in extension: fault: Attempt to add read-only file at path file:///private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite read/write. Adding it read-only instead. This will be a hard error in the future; you must specify the NSReadOnlyPersistentStoreOption. error: (3) access permission denied error: Encountered exception error during prepareSQL for SQL string 'SELECT TBL_NAME FROM SQLITE_MASTER WHERE TBL_NAME = 'Z_METADATA'' : access permission denied with userInfo { NSFilePath = "/private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite"; NSSQLiteErrorDomain = 3; } while checking table name from store: <NSSQLiteConnection: 0x154100300> error: Store failed to load. <NSPersistentStoreDescription: 0x15402d590> (type: SQLite, url: file:///private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite) with error = Error Domain=NSCocoaErrorDomain Code=256 "The file “default.sqlite” couldn’t be opened." UserInfo={NSFilePath=/private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite, NSSQLiteErrorDomain=3} with userInfo { NSFilePath = "/private/var/mobile/Containers/Shared/AppGroup/51431199-5919-4AE6-940C-6FE3C53EEB46/default.sqlite"; NSSQLiteErrorDomain = 3; } Any help appreciated 🙂

I'm developing an iPad app where I want to annotate things on a pdf. I subclassed PDFAnnotation to drag text on a pdf. When I use Xcode 26 everything is working fine and everything is rendered perfect. But when I run the same code with Xcode 27 on iOS27 I get a pixelated annotation. iOS26 iOS27 The code: import UIKit final class ManualPlacementPreviewAnnotation: PDFAnnotation, DraggablePreviewAnnotation { private let text: String private let textFont: UIFont private let textColor: UIColor var isGrabbed = false init(bounds: CGRect, text: String, font: UIFont, color: UIColor) { self.text = text self.textFont = font self.textColor = color super.init( bounds: bounds.insetBy(dx: -PreviewAnnotationChrome.padding, dy: -PreviewAnnotationChrome.padding), forType: .freeText, withProperties: nil ) } required init?(coder: NSCoder) { text = "" textFont = .systemFont(ofSize: 12) textColor = .black super.init(coder: coder) } override func draw(with box: PDFDisplayBox, in context: CGContext) { context.saveGState() context.translateBy(x: 0, y: bounds.minY + bounds.maxY) context.scaleBy(x: 1, y: -1) let content = contentBounds UIGraphicsPushContext(context) NSAttributedString(string: text, attributes: [ .font: textFont, .foregroundColor: textColor, ]).draw(in: content) UIGraphicsPopContext() PreviewAnnotationChrome.draw(context, around: content, grabbed: isGrabbed) context.restoreGState() } } Is this a bug in iOS27 or am I doing something wrong?

I'm a font developer. In the development process, I will revise a font and overwrite the OTF file that is currently enabled (registered) with macOS. If I then launch an app, it will immediately use the revised version of the font; while apps that are already loaded will continue to use the old version. This suggests that each app is loading new and separate font data, rather than getting it from some existing cache in memory. Yet macOS does have a "font cache" of some sort. Some apps, like TextEdit, seem to only load the fonts that they need to use. However, other apps, like Pages, load every enabled (registered) font on the OS!! (According to the Open Files list in Activity Monitor.) Given that /System/Library/Fonts/ is 625 Mb, and we can't disable any of it, isn't that a lot of data to be repeating? How many fonts is too many fonts? I can't find much documentation about the process.

Hi, Shortly: On iPadOS27, when changing the color of a PKInk programmatically, it doesn't reflect in PKDrawing on screen. In all previous versions of iPadOS I was able to change the color of a PencilKit stroke via: canvasView.drawing.strokes[0].ink.color = .red And it changed on screen. As of iPadOS 27 - it doesn't. However, the underlying data is changing correctly: print(canvasView.drawing.strokes[0].ink.color) //prints: "UIExtendedSRGBColorSpace 0 0.533333 1 1" - blue color. canvasView.drawing.strokes[0].ink.color = .red print(canvasView.drawing.strokes[0].ink.color) //prints: "UIExtendedSRGBColorSpace 1 0 0 1" - red color, good. But the stroke stays blue on screen. I've filed a Feeback at FB24771438. And am using a temp workaround to "refresh" the drawing with: let current = canvasView.drawing canvasView.drawing = PKDrawing() //blank one canvasView.drawing = current IMHO, it should be possible to change the color like that and re-render it in the View right away, since the PKInk's .color property is a { get set } property. Is this the intended behavior? A bug or a feature? Thanks!

I’m developing a macOS menu-bar app intended for distribution on the Mac App Store. Is there a supported public API or an available entitlement that allows a sandboxed macOS app to read the built-in ambient light sensor in real time? The feature would be optional, process readings locally, and adjust display dimming and warmth. It would not use the camera or transmit sensor data. SensorKit’s ambient light API is unavailable on macOS in our SDK, and its research-only access and delayed data do not meet this use case. We want to avoid private APIs. Could you confirm whether a supported approach exists, or advise how to submit an enhancement request?

We have a published, approved App Clip that works correctly via QR code and the Safari Smart App Banner, but URL-based invocation does not trigger the App Clip card in any context. Most notably, Apple's own default App Clip URL does not work either: https://appclip.apple.com/id?p=hazel-torus.Clip **Tapping this link in Messages or Notes does nothing. ** Long-pressing it shows a generic website link preview rather than the App Clip card, even though appclip.apple.com is Apple's domain and requires no configuration on our end. Setup details: App Clip bundle ID: hazel-torus.Clip Team ID: 2UNR2APH47 App Clip experience URL: https://passportreader.app/open AASA includes a correctly formatted appclips key with 2UNR2APH47.hazel-torus.Clip (confirmed via https://app-site-association.cdn-apple.com/a/v1/passportreader.app that AASA is correctly cached) Associated Domains entitlements (appclips:passportreader.app) are present on the App Clip target App and App Clip experience are both Approved / Ready for Sale Tested on two physical devices, neither with the full app installed Since QR and Safari banner invocation work, the App Clip itself and its entitlements appear correctly configured. The fact that even Apple's own appclip.apple.com URL fails, and is treated as an arbitrary website link, suggests this may be a backend indexing issue specific to this App Clip rather than a client-side configuration problem. Has anyone else encountered this, or know what could cause appclip.apple.com to not be recognized as an App Clip URL?

Can all the AI stuff be turned off on the new iPhone 18 pro running iOS 27?

Hi there! My claim is that ManagedSettingsStore.TokenExpiryMessage API family doesn't work properly. I'm curious if that's only me, or others have also found it confusing, or non-working? I haven't found much public discussion about it, so this is the start of it. There are multiple confusing scenarios from my playing with it, but the simplest example is that ~30% of my apps NEW users get the ".tokensDidExpire" as soon as they approve Screen Time Permissions. Note that they haven't even seen the FamilyActivityPicker! FB23391495 is the feedback. Apple dev responded, but it didn't give confidence that my bug report was deemed correct (which can be fair!). However, it's current status is "Potential fix identified - For a future OS update," so maybe there is something to it. The API is likely quite difficult to get right, so I am happy to provide feedback on potential implementation so it's 100% solid.

If the user prohibits Spotlight in System Settings for a given directory and I set that URL as one of the search scopes on an NSMetadataQuery- I believe the query will return no results. Is there an API for detecting Spotlight unavailability? Ideally I would like to display something in the UI for this kind of situation to explain why a feature built on top of this API is not working.

Hello, We are developing applications using Apple's Nearby Interaction framework for continuous UWB ranging between an iPhone and a UWB-enabled accessory. We have identified a reproducible issue on iPhone 17 where, after running several prolonged UWB ranging sessions (sometimes more than 2 hours), the UWB ranging functionality eventually enters a state where it no longer operates correctly. Once the issue occurs, restarting the application does not recover the UWB functionality. The iPhone must be fully restarted before UWB ranging starts working normally again. We strongly believe the issue is not related to application-specific logic but is a OS issue Device: iPhone 17 UWB: U2 iOS: iOS 26 & iOS 27 beta 4 Framework: Nearby Interaction Steps to reproduce Establish a Nearby Interaction UWB ranging session between the iPhone 17 and a compatible UWB device. Keep the ranging session running continuously for a prolonged period. Repeat this process several times if needed, using long-running sessions. Eventually, the OS will stop delivering didUpdate OS callbacks with ranging distance. After the issue occurs, start a new Nearby Interaction session. Actual result Once the issue occurs, a newly started UWB ranging session only delivers one valid didUpdate ranging callback to the application. After this first callback, no further valid ranging updates are delivered. The issue persists when: the current ranging session is stopped; the application is completely terminated; the application is launched again; a new Nearby Interaction session is created. The only way we have found to recover the device is to fully restart the iPhone. After restarting the phone, Nearby Interaction UWB ranging works normally again. The issue is not in the UWB accessory, the accessory will keep doing valid ranging with other phones, this is only affecting the iPhone that entered the invalid UWB state. Expected result After stopping a Nearby Interaction session and creating a new session, UWB ranging should start normally again, regardless of how many previous ranging sessions have been executed. Terminating and relaunching the application should also release any application-owned resources associated with the previous session. Request Could you please investigate whether this behavior is related to the Nearby Interaction framework, the iPhone 17 UWB subsystem, or an internal UWB state that is not correctly reset between ranging sessions? If any other iOS developer has experienced similar behaviour it would be great if you can share your findings. Material delivered I am attaching a console log that I captured on my iPhone 17. Here the prolonged session was already executed and UWB already entered the invalid state. The iPhone and the UWB accessory are close to each other. We can observe that valid ranging notification (didUpdate) is only delivered for the first ranging round, following ranging rounds will lead to error (the OS does not deliver ranging distance notfs anymore. After this the only way to recover UWB technology is to restart the iPhone. Let us know if you need any additional information for debugging this issue. Feedback assistant issue identifier: FB24484779 logs-iphone17-uwb-issue.rtf

On iOS 27 beta / Xcode 27.0, PDFDocument.write(to:) no longer serializes destinations for link annotations that are created at runtime. The annotation and its PDFActionGoTo action are both written, but the destination's page reference is not, so every internal link is dead. This worked correctly on iOS 26. PDFs generated on iOS 26 still navigate correctly; the same code on iOS 27 beta produces PDFs whose links are all dead.

I would like to clarify the expected behavior of a default App Clip link regarding tap responsiveness. Issue: When I tap the default App Clip invocation URL in Safari or the Notes app, the first tap does not respond (no App Clip card appears). Only the second tap successfully presents the App Clip card. Steps to Reproduce: Place the default App Clip URL in Safari (or Notes app) Tap the link once → no App Clip card appears Tap the same link again → App Clip card appears as expected Environment: Invocation source: Safari / Notes app App Clip type: Default App Clip experience (appclip.apple.com URL) Observation: This issue reliably occurs when there is no cached App Clip metadata on the device. When the metadata is already cached, the App Clip card appears on the first tap as expected. What I've already checked: Not in Private Browsing mode Question: Is this the expected behavior? Is there a recommended way to make the first tap reliably present the App Clip card even without a pre-existing cache? Thank you for your assistance.