In IOS17 and IOS18, core spotlight can only match app contents by searching for the displayName, but cannot hit the contents by using keywords. Moreover, when matching the app content by searching for the "displayName", it requires inputting four consecutive characters to achieve a match.These issues did not occur in iOS 16. What is the reason for this? Here is my code. func addItemToIndex(_ item: QSpotlightItem) { let attributeSet = CSSearchableItemAttributeSet(contentType: .item) attributeSet.title = item.title attributeSet.displayName = item.title attributeSet.contentDescription = item.contentDescription attributeSet.keywords = item.keywords attributeSet.thumbnailData = item.thumbnailImage attributeSet.contactKeywords = item.keywords attributeSet.supportsNavigation = true let searchableItem = CSSearchableItem(uniqueIdentifier: item.id, domainIdentifier: "xxx", attributeSet: attributeSet) searchableItem.expirationDate = .distantFuture CSSearchableIndex.default().indexSearchableItems([searchableItem]) { error in if let error = error { } else { } } }

Hi everyone, I'm experiencing crashes that consistently occur on iOS 18 devices, which seem to share a common root cause. I'm hoping for some guidance. Here are the details of the crashes as received from Xcode Organizer: Crash Trace 1: 0 CoreFoundation 0x0000000192c50e54 CF_IS_OBJC + 76 (CFRuntime.c:461) 1 CoreFoundation 0x0000000192c4dd3c CFRelease + 60 (CFRuntime.c:1202) 2 CoreFoundation 0x0000000192d015e0 _signalEventSync + 252 (CFStream.c:636) 3 CoreFoundation 0x0000000192d53050 ___signalEventQueue_block_invoke + 28 (CFStream.c:646) 4 libdispatch.dylib 0x000000019a93c370 _dispatch_call_block_and_release + 32 (init.c:1549) 5 libdispatch.dylib 0x000000019a93e0d0 _dispatch_client_callout + 20 (object.m:576) 6 libdispatch.dylib 0x000000019a9456d8 _dispatch_lane_serial_drain + 744 (queue.c:3934) 7 libdispatch.dylib 0x000000019a9461e0 _dispatch_lane_invoke + 380 (queue.c:4025) 8 libdispatch.dylib 0x000000019a951258 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 9 libdispatch.dylib 0x000000019a950aa4 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 10 libsystem_pthread.dylib 0x000000021a00fc7c _pthread_wqthread + 288 (pthread.c:2696) 11 libsystem_pthread.dylib 0x000000021a00c488 start_wqthread + 8 (:-1) Crash Trace 2: 0 libobjc.A.dylib 0x0000000186f33c20 objc_msgSend + 32 1 CoreFoundation 0x0000000189cb14b8 _inputStreamCallbackFunc + 36 (CFObject.m:1952) 2 CoreFoundation 0x0000000189cb0aa8 _signalEventSync + 216 (CFStream.c:626) 3 CoreFoundation 0x0000000189d01e30 ___signalEventQueue_block_invoke + 28 (CFStream.c:646) 4 libdispatch.dylib 0x0000000191948370 _dispatch_call_block_and_release + 32 (init.c:1549) 5 libdispatch.dylib 0x000000019194a0d0 _dispatch_client_callout + 20 (object.m:576) 6 libdispatch.dylib 0x00000001919516d8 _dispatch_lane_serial_drain + 744 (queue.c:3934) 7 libdispatch.dylib 0x00000001919521e0 _dispatch_lane_invoke + 380 (queue.c:4025) 8 libdispatch.dylib 0x000000019195d258 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 9 libdispatch.dylib 0x000000019195caa4 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 10 libsystem_pthread.dylib 0x000000021214bc7c _pthread_wqthread + 288 (pthread.c:2696) 11 libsystem_pthread.dylib 0x0000000212148488 start_wqthread + 8 Crash Trace 3: 0 libobjc.A.dylib 0x00000001941d9ce8 objc_loadWeakRetained + 156 (NSObject.mm:525) 1 CoreFoundation 0x0000000196d0a0f4 _outputStreamCallbackFunc + 36 (CFObject.m:1960) 2 CoreFoundation 0x0000000196d09724 _signalEventSync + 216 (CFStream.c:626) 3 CoreFoundation 0x0000000196d07948 ___signalEventQueue_block_invoke + 28 (CFStream.c:646) 4 libdispatch.dylib 0x000000019e9de248 _dispatch_call_block_and_release + 32 (init.c:1549) 5 libdispatch.dylib 0x000000019e9dffa8 _dispatch_client_callout + 20 (object.m:576) 6 libdispatch.dylib 0x000000019e9e75cc _dispatch_lane_serial_drain + 768 (queue.c:3934) 7 libdispatch.dylib 0x000000019e9e8124 _dispatch_lane_invoke + 380 (queue.c:4025) 8 libdispatch.dylib 0x000000019e9f338c _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 9 libdispatch.dylib 0x000000019e9f2bd8 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 10 libsystem_pthread.dylib 0x00000002220f3680 _pthread_wqthread + 288 (pthread.c:2696) 11 libsystem_pthread.dylib 0x00000002220f1474 start_wqthread + 8 Notable Points: All crashes occur only on iOS 18 and newer versions. The crashes are independent of the Xcode version used to build the app (tested with both Xcode 15.4 and 16). All crash traces occur in CoreFoundation and seem to have nothing related to our app codebase. I've attempted to profile the app using Instruments to identify any zombie objects, but the crashes do not manifest on my own devices. I've referred to discussions, including this forum thread, but have not yet found a solution. Questions: Has anyone else encountered similar issues on iOS 18? Are there specific aspects of iOS 18 that might contribute to these CoreFoundation and libobjc-related crashes? Would appreciate any suggestions for further diagnostics or potential workarounds. Thank you for your help!

Hey, I'm trying to update my old app that used DarkSky to WeatherKit, and struggling. I always get: ailed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" This is regardless if I do it on my iPad, or in the simulator. I have done the following: Selected WeatherKit on the Capabilities and App Services tabs of the Identifier section on developer. Put it under signing and capabilities in XCode I've tried making a new provisioning profile, cleaning build folder, etc. Not sure what to do here. I suspect part of this problem is that I developed this app in 2018 and now I'm trying to update it. I am able to run the app on TestFlight, but not as an internal tester. Apple won't let me, so I have to add myself as an external tester. Thanks for any help you can provide!

I'm reaching out to see if anyone else is experiencing issues with the Live Caller ID feature on iOS. We recently encountered a problem where the feature stopped working entirely. Here's a brief overview of the situation: We were monitoring test traffic on our backend and noticed everything came to a halt around 1:00 AM UTC on November 15th. After this time, any attempts to reach our backend through calls failed completely. I tested this across multiple devices running iOS 18.2 and iOS 18.0. I used both TestFlight builds and development builds via Xcode, which should communicate directly with our backend. I experienced the problem on our main application as well as a dedicated test app. To troubleshoot further, I even set up a local server on localhost and tried directing requests there, but the requests did not reach the local server when a call was received. Further debugging in Console.app revealed the following error: identity request returned error: Error Domain=com.apple.CipherML Code=400 "Error Domain=com.apple.CipherML Code=401 "Unable to request data by keywords batch: failed to fetch token issuer directory" However, when I manually tried to hit our server endpoint using curl, the request successfully reached the server: curl https://our_server/something hb_method=GET hb_uri=/something [Hummingbird] Request -- log on backend This suggests that while our backend is responsive, the requests from the iOS client side are simply not being initiated.

ios ipad 18.3 on iPad 7. generation sound is missing - in YouTube the advertising videos never starts

Hello Apple Developer Community, I’m working on integrating Siri into my React Native app using native iOS code and bridging to React Native. I’ve followed the necessary steps to set up Siri support, including: Adding the Siri capability. Adding Siri usage descriptions in Info.plist. Using AppIntent and AppShortcutsProvider to define shortcuts. However, I’m facing the following issues: Siri Prompts for Confirmation When a user says a phrase, Siri asks, "Turn on 'MyApp' shortcuts with Siri?" instead of directly recognizing the phrase. Is this expected behavior? If so, how can I reduce friction for users and make the experience more seamless? Inconsistent Behavior for Existing Users For users updating to a version with Siri support: When the app is closed, Siri says, "MyApp hasn't added support for that with Siri." When the app is open, Siri prompts, "Turn on shortcut for MyApp?" and rest all working fine Why does Siri not recognize the shortcut when the app is closed, even though the shortcut is defined in AppShortcutsProvider? How can I ensure that Siri recognizes the shortcut regardless of whether the app is open or closed? Other than using AppIntent and AppShortcutsProvider should i try Donating shortcuts(will that helps for updated user case). Please help me on this

I have a very basic App Intent extension in my macOS app that does nothing than accepting two parameters, but running it in Shortcuts always produces the error "The action “Compare” could not run because an internal error occurred.". What am I doing wrong? struct CompareIntent: AppIntent { static let title = LocalizedStringResource("intent.compare.title") static let description = IntentDescription("intent.compare.description") static let openAppWhenRun = true @Parameter(title: "intent.compare.parameter.original") var original: String @Parameter(title: "intent.compare.parameter.modified") var modified: String func perform() async throws -> some IntentResult { return .result() } }

if #available(iOS 16.0, *) {       print("donated")       let intent = BasicIntent()       IntentDonationManager.shared.donate(intent: intent)    } Trying to test if donations work with the new App Intents framework. Donating the shortcut once a user taps a button. The shortcut is not appearing on the lock screen. Everything else is working as expected. The Shortcut is appearing in the Shortcuts App and is working via Siri. In developer settings I have Display Recent Shortcuts -> On Display Donations on Lock Screen -> On Allow Any domain -> On Allow Unverified sources -> On Running iOS 16.2, iPhone 11.

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.

All of my apps stopped working with WeatherKit this morning. They all return an "Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2" error. I am certain that the WeatherKit capability added (in project) and enabled as a Capability & App Service (on developer portal for the identifier). All other iCloud features of my apps are working as expected. I have also done all the normal troubleshooting using codesign / security cms, etc. to verify entitlements. I created the following simple project to verify the integration. import WeatherKit import CoreLocation struct ContentView: View { @State private var temp: Measurement<UnitTemperature>? = nil var body: some View { VStack { if let t = temp { Text("\(t.value.rounded())°\(t.unit.symbol)") } else { Text("Fetching…") .task { let service = WeatherService() do { let location = CLLocation(latitude: 50.318668, longitude: -114.917710) let weather = try await service.weather(for: location, including: .current) temp = weather.temperature } catch { print("Error:", error) } } } } } } Any ideas what may be happening?

I've developed a new Quicklook data-based preview extension for a custom file type that generates an image preview of the file. I previously used a Quick Look generator plug-in but support for it was deprecated and now removed in macOS Sequoia. My app opens files using a open(url.path, O_RDWR | O_NONBLOCK | O_EXLOCK) call. The locking flags are used to prevent other clients from writing the file if it's already open. I discovered that when Finder is showing the “large” file previews (such as when in column or gallery modes) from a SMB share, the open call fails with EWOULDBLOCK as if the file is locked. It does work just fine on local files. Opening with O_SHLOCK also has the issue. Surprisingly it does work just fine for previews that return Plain Text data instead of Image data. Using the lsof command, it seems like the Quicklook process has some kind of lock on the file. This is the output of the lsof command: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE QuickLook 48487 XXXX txt REG 1,15 125000611 3161369 Attached is a test project that tries a few different opening and locking functions. It also includes a test file and a sample image preview extension that displays a red square. When everything is working, regular console messages show the progress of the tests. When the file is on a SMB share and selected in Finder Gallery mode, the open test will fail with a fault message in the console. Notably, locking with flock works, which is weird because it should have similar semantics according to the man page for open(2). Filed this as FB15051186

Not sure if my question is weird or not, but I didnt find any documentation about an sdks access to an apps documents directory. Im assuming that because sdk is part of the sandbox that it can access and read from the documents directory? i.e. if i used NSFileManager.defaultManager.URLForDirectory( directory = NSCachesDirectory, inDomain = NSUserDomainMask, appropriateForURL = null, create = false, error = null, ) to write a file called "file.txt", then any sdk my app used has the ability to access the contents of said directory? If yes, why isnt this considered something more worth mentioning? usually in filemanager tutorials they never warn about this. FYI: Im asking more for iOS and iPadOs then MacOs.

I'm the developer of Camera RawX (avail on the Mac App Store). I'm working on Camera RawX for iOS to provide Quick Look support for camera RAW files not supported by iOS. I use the Files app to open a RAW file to invoke Quick Look on my iPad (it is running iOS 17.6.1). The RAW file in question is a Fuji compressed RAF file. When I tap on the RAF file, iOS opens the Quick Look window, but my app's Quick Look extension is not called. If the RAW file in question is a Sigma Foveon X3F file, a file that has no native Apple RAW support, then my Quick Look extension is called and I'm able to display the image in the Quick Look window without issue. It seems that a system recognized RAW file extension (RAF in this case), is not triggering my Quick Look extension. On the macOS, this works fine without any issue. The strange thing is that my Thumbnail extension is being called when the RAW files show up in Files. Even if it is a RAF file. So it seems like a bug to me or am I missing something crucial in my Info.plist file? Albert

Hi all, I'm working on a really basic counter app as a way to explore SwiftData and have come across some behavior that I don't understand. I have a very simple App Intent that increments a user-specified counter in my app. The intent doesn't throw any errors and correctly updates the CoreData store but, when I switch back to my app from the Shortcuts app (where I'm testing the app intent), the view hasn't updated. Closing and re-opening the app shows the incremented counter value but I'd like to know if it's possible to have my app's UI update when the CoreData store is updated from outside the app without relaunching the whole app. For some brief context, here's my view and the App Intent: struct ContentView: View { @Environment(\.modelContext) private var modelContext @Query private var counters: [Counter] // ... var body: some View { NavigationStack { List { ForEach(counters) { counter in CounterRowItem(counter: counter) } .onDelete(perform: deleteItems) } // ... } } struct IncrementCounterIntent: AppIntent { static var title: LocalizedStringResource = "Increment Counter" @Parameter(title: "Name", optionsProvider: CounterOptionsProvider()) var name: String func perform() async throws -> some IntentResult & ReturnsValue<Int> { let provider = try CounterProvider() guard let counter = try provider.fetchCounters().first(where: { $0.name == name }) else { print("Couldn't find counter with name '\(name)'") return .result(value: 0) } counter.count += 1 try provider.context.save() return .result(value: counter.count) } private final class CounterOptionsProvider: DynamicOptionsProvider { func results() async throws -> [String] { try CounterProvider().fetchCounters().map { $0.name } } } }

For login purposes, we may want to try automatically checking to see if an email address is set up in certain databases. It looks like the preferred way to do this is via ABAddressBook.shared().me(), then get the right key via in the properties? This, however, is treated as accessing the whole address book and brings up a confirmation dialogue. However, as I thought about it, that might not be the real way we'd want -- we'd want to go through Active Directory, perhaps? Am I making any sense, or just being incoherent? 😄

I’m encountering an issue while reading/writing shared preferences using UserDefaults with an App Group in my iOS Message Extension. The following error appears in the console: `Couldn't read values in CFPrefsPlistSource&lt;0x3034e7f80&gt; (Domain: [MyAppGroup], User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd. I have correctly enabled the App Group in both my containing app and the Message Extension, and I am using UserDefaults(suiteName:) to access shared preferences. However, I keep getting this error when trying to read/write values. Has anyone encountered this before? How can I properly configure my app group preferences to avoid this issue? Any help would be greatly appreciated!

The app gets stuck after login on an iOS 18 device. It works in Xcode, but the simulator shows the following console error: IntegrationApp(769,0x1f0094c00) malloc: xzm: failed to initialize deferred reclamation buffer (46).

Observed few times that providerDidBegin(_:) delegate never called for the complete app session after app init(as part of this CXProvider registered) which was built with SDK 26 and running on iOS 26. This issue observed multiple times with our testing. Since there is no providerDidBegin:, client is marking CallKit as not ready and never report any calls for VoIP APNS and ended up in app crash due to "[PKPushRegistry _terminateAppIfThereAreUnhandledVoIPPushes]" Please refer for sysdiagnose logs : FB19778306

I have a SwiftUI document-based app that for the sake of this discussion stores accounting information: chart of accounts, transactions, etc. Each document is backed by a SwiftData DB. I'd like to incorporate search into the app so that users can find transactions matching certain criteria, so I went to Core Spotlight. Indexing & search within the app seem to work well. The issue is that Spotlight APIs appear to be App based & not Document based. I can't find a way to separate Spotlight data by document. I've tried having each document maintain a UUID as a document-specific identifier and include the identifier in every CSSearchableItem. When performing a query I filter the results with CSUserQueryContext.filterQueries that filter by the document identifier. That works to limit results to the specific file for search operations. Index updates via CSSearchableIndexDelegate.reindex* methods seem to be App-centric. A user may have file #1 open, but the delegate is being asked to update CSSearchableItems for IDs in other files. Is there a proper way to use Spotlight for in-app search with a document-based app? Is there a way to keep Spotlight-indexed data local within the app & not make it available across the system? I.e. I'd like to search within the app only. System-level searches should not surface this data.

Hello, I think it is quite a common use-case to open the parent app that owns the ShieldActionDelegate when the user selects an action in the Shield. There are only three options available that we can do in response to an action: ShieldActionResponse.none ShieldActionResponse.close ShieldActionResponse.defer It would be great if this new one would be added as well: ShieldActionResponse.openParentApp While finding a workaround for now, the problem is that the ShieldActionDelegate is not a normal app extension. That means, normal tricks do not work to open the parent app from here. For example, UIApplication.shared.open(url) does not work because we can’t access UIApplication from the ShieldActionDelegate unfortunately. NSExtensionContext is also not available in the ShieldActionDelegate unfortunately, so that’s also not possible. There are apps however, that managed to find a workaround, in my research I stumbled across these two: https://apps.apple.com/de/app/applocker-passcode-lock-apps/id1132845904?l=en-GB https://apps.apple.com/us/app/app-lock/id6448239603 Please find a screen recording (gif) attached. Their workaround is 100% what I’m looking for, so there MUST be a way to do so that is compliant with the App Store guidelines (after all, the apps are available on the App Store!). I had documented my feature request more than 2 years ago in this radar as well: FB10393561