On iOS 18, I'm trying to index documents in Spotlight using the new combination of AppIntents+IndexedEntity. However, I don't seem to be able to index the textContent of the document. Only the displayName seems to be indexed. As recommended, I start with the defaultAttributeSet: /// I call this function to index in Spotlight static func indexInSpotlight(document: Document) async { do { if let entity = document.toEntity { try await CSSearchableIndex.default().indexAppEntities([entity]) } } catch { DLog("Spotlight: could not index document: \(document.name ?? "")") } } /// This is the corresponding IndexedEntity with the attributeSet @available(iOS 18, *) extension DocumentEntity { var attributeSet: CSSearchableItemAttributeSet { let attributeSet = defaultAttributeSet attributeSet.title = title attributeSet.displayName = title attributeSet.textContent = docContent attributeSet.thumbnailData = thumbnailData attributeSet.kind = "document" attributeSet.creator = Constants.APP_NAME return attributeSet } } How can I have more that the displayName to be indexed? Thanks :-)

Recently, we have observed that after upgrading to OS 15.4.1, some devices are experiencing network issues. We are using a Network Extension with a transparent app proxy in our product. The user encounters this issue while using our client, but the issue persists even after stopping the client app. This appears to be an OS issue. Below is the sytem logs. In the system logs, it says [C669.1 Hostname#546597df:443 failed transform (unsatisfied (No network route), flow divert agg: 2)] event: transform:children_failed @0.001s In scutil --dns, it says not reachble. DNS configuration resolver #1 flags : reach : 0x00000000 (Not Reachable) resolver #2 domain : local options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 301000 We need to restart the system to recover from the issue.

Recently, I've noticed that background Bluetooth scanning stops when I move an app to the background on an iPhone 17 device with Bluetooth 6. I'm curious about a solution. Background Bluetooth scanning doesn't stop on devices older than iOS 26, or on devices that were updated from an iPhone 17 or earlier to iOS 26.

iOS 18 (22A3354) will not offer a option in settings (> Apps > Phone) after calling openSettings to enable live caller id lookup extension. iPhone and MacBook are in the same network. The PIRService runs on MacBook and is reachable via iPhone Safari (via http://MacBookPro:8080/). Hummingbird print log: hb_method=GET hb_uri=/ [Hummingbird] Request. After deploying the application via Xcode to the iPhone no requests are printed in the terminal. The extension was added like documented and bundle id is also checked multiple times. issuerRequestUri in service-config.json is http://MacBookPro:8080/issue. As far as I can tell, everything has been set up in accordance with the Testing Live Caller ID instructions. Is there something missing?

Hello! Some colleagues and work on Jujutsu, a version control system compatible with git, and I think we've uncovered a potential lock contention bug in either APFS or the Darwin kernel. There are four contributing factors to us thinking this is related to APFS or the Kernel: jj's testsuite uses nextest, a test runner for Rust that spawns each individual test as a separate process. The testsuite slowed down by a factor of ~5x on macOS after jj started using fsync. The slowdown increases as additional cores are allocated. A similar slowdown did not occur on ext4. Similar performance issues were reported in the past by a former Mercurial maintainer: https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/. My friend and colleague André has measured the test suite on an M3 Ultra with both a ramdisk and a traditional SSD and produced this graph: (The most thorough writeup is the discussion on this pull request.) I know I should file a feedback/bug report, but before I do, I'm struggling with profiling and finding kernel/APFS frames in my profiles so that I can properly attribute the cause of this apparent lock contention. Naively, I ran xctrace record --template 'Time Profiler' --output output.trace --launch /Users/dbarsky/.cargo/bin/cargo-nextest nextest run, and while that detected all processes spawned by nextest, it didn't record all processes as part of the same inspectable profile and didn't really show any frames from the kernel/APFS—I had to select individual processes. So I don't waste people's time and so that I can point a frame/smoking gun in the right system, how can I can use instruments to profile where the kernel and/or APFS are spending its time? Do I need to disable SIP?

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.

Issue with Universal Links and App Extension (ShieldAction Handler) I'm currently working on a POC app using the FamilyControls framework and facing an issue when trying to open a Universal Link from an app extension, specifically from a ShieldAction handler. When I try to open a Universal Link, I encounter the following error: Failed to open URL https://sixteen-server-c008110f8759.herokuapp.com/.well-known/apple-app-site-association: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open 'com.apple.mobilesafari' failed." UserInfo={BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x14f2d90b0 {Error Domain=FBSOpenApplicationErrorDomain Code=3 "Application com.sixteen.life is neither visible nor entitled, so may not perform un-trusted user actions." UserInfo={BSErrorCodeDescription=Security, NSLocalizedFailureReason=Application com.sixteen.life is neither visible nor entitled, so may not perform un-trusted user actions.}} Context: I’m using a ShieldAction handler as part of an App Extension to trigger the action (e.g., "Break in Shield") in my app. The app extension (ShieldAction handler) is responsible for trying to open the Universal Link. I’m encountering the error because the app is not visible or entitled to perform this action, which seems to be related to security restrictions when using App Extensions. Questions: App Extension and Universal Link Interaction: Is it possible for an App Extension (like ShieldAction handler) to open a Universal Link or trigger an external app, such as Safari, even though it is not the foreground app? Entitlements for App Extensions: Are there any specific entitlements or permissions required to allow an app extension (ShieldAction handler) to open Universal Links or perform actions like opening Safari from the background? App Visibility and State: How can I ensure that my app is in the right state (visible/active) and has the necessary entitlements to trigger these actions when running in the context of an app extension? Workaround: If this behavior is restricted due to app extension limitations, what would be the recommended workaround to handle launching external apps (like Safari) or Universal Links from within an app extension?

Hello, We use the Network API in our macOS ObjectiveC applications to create a small web server. With macOS Sequoia or Tahoe (not with Sonoma), downloading files from another computer using the built-in ethernet port is way too slow. Steps to reproduce: Computer A (using macOS Tahoe or Sonoma), run an application using the Network APIs to create a webserver Make sure that this computer connects to the network using the Ethernet port, there is no issue when using WiFi On computer B, make an HTTP request to download a 20MB file => it will take about 30 seconds to download => way too slow... We tested with: if on computer A you run a web server using the GCD API instead of Network, it takes 0.2 seconds to download the file => no issue on computer A disable TSO, it improves the results, but that's not a long term solution as it doesn't hold when rebooting I can provide sample code to demonstrate this if needed. This is a new issue as it's been a while we use that code, and only noticed it recently, and macOS Sonoma is not impacted. Thank you for the help you can provide. Pierre

Continuing with my investigations of several issues that we have been noticing in our testing of the JDK with macosx 15.x, I have now narrowed down at least 2 separate problems for which I need help. For a quick background, starting with macosx 15.x several networking related tests within the JDK have started failing in very odd and hard to debug ways in our internal lab. Reading through the macos docs and with help from others in these forums, I have come to understand that a lot of these failures are to do with the new restrictions that have been placed for "Local Network" operations. I have read through https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy and I think I understand the necessary background about these restrictions. There's more than one issue in this area that I will need help with, so I'll split them out into separate topics in this forum. That above doc states: macOS 15.1 fixed a number of local network privacy bugs. If you encounter local network privacy problems on macOS 15.0, retest on macOS 15.1 or later. We did have (and continue to have) 15.0 and 15.1 macos instances within our lab which are impacted by these changes. They too show several networking related failures. However, I have decided not to look into those systems and instead focus only on 15.3.1. People might see unexpected behavior in System Settings > Privacy & Security if they have multiple versions of the same app installed (FB15568200). This feedback assistant issue and several others linked in these documentations are inaccessible (even when I login with my existing account). I think it would be good to have some facility in the feedback assistant tool/site to make such issues visible (even if read-only) to be able to watch for updates to those issues. So now coming to the issue. Several of the networking tests in the JDK do mulicasting testing (through BSD sockets API) in order to test the Java SE multicasting socket API implementations. One repeated failure we have been seeing in our labs is an exception with the message "No route to host". It shows up as: Process id: 58700 ... java.net.NoRouteToHostException: No route to host at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method) at java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:914) at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:871) at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:798) at java.base/sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:857) at java.base/sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:178) at java.base/java.net.DatagramSocket.send(DatagramSocket.java:593) (this is just one example stacktrace from java program) That "send0" is implemented by the JDK by invoking the sendto() system call. In this case, the sendto() is returning a EHOSTUNREACH error which is what is then propagated to the application. The forum text editor doesn't allow me to post long text, so I'm going to post the rest of this investigation and logs as a reply.

I've been trying to add a CoreSpotlight indexer to my macOS application. The new template for the indexer uses the new appex CSImportExtension style importer. I've been following this -> https://developer.apple.com/documentation/corespotlight/csimportextension I changed the CSSupportedContentTypes in the Info.plist file to the correct file type uti. I added a dummy value into the attributes (see code below) - just setting contentDescription to 'noodle' (easy to search for) class ImportExtension: CSImportExtension {   override func update(_ attributes: CSSearchableItemAttributeSet, forFileAt: URL) throws {     // Add a dummy value, and see whether spotlight finds it     attributes.contentDescription = "noodle" } } I have a number of files on disk that match the uti (and can be found when I search by the file name) Yet, when I build and run my app, the a spotlight search for 'noodle' finds no results. Can anyone give me any advice? I cannot find any indication that the ImportExtension is called (although when I put a log message at the start of the update() call there's no message in the console which seems to suggest it's not being called). Is there any way of debugging this? Cheers and thanks -- Darren.

I'm seeing a lot of these in my logs: PersistentIdentifier PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-swiftdata://Course/BC9CF99A-DE6A-46F1-A18D-8034255A56D8), implementation: SwiftData.PersistentIdentifierImplementation) was remapped to a temporary identifier during save: PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-coredata:///Course/t58C849CD-D895-4773-BF53-3F63CF48935B210), implementation: SwiftData.PersistentIdentifierImplementation). This is a fatal logic error in DefaultStore ... though everything seems to work. Does anyone know what this means in this context? Anything I can do to not have this appear?

Our app is developed for iOS, but some users also run it on macOS (as an iOS app via Apple Silicon). The app requires local network permission, which works perfectly on iOS. Previously, the connection also worked fine on macOS, but since the recent macOS update, the app can no longer connect to our device. Additionally, our app on macOS doesn't prompt for local network permission at all, whereas it does on iOS. Is this a known issue with iOS apps running on macOS? Has anyone else experienced this problem, or is there a workaround? Any help would be appreciated!

I don't see upload option for the App Store connect, can only export .ipa. Also having issues with Transporter, pasting error message here. Could not create a temporary .itmsp package for the app "Redacted.ipa". Unable to determine app platform for 'Undefined' software type. Is anyone else facing the same issue? I am using Xcode 15.

Recently I've been working on a demo project called iLibrary. The main goal was to learn more about CloudKit and SwiftData. After a while I noticed that there were some hangs/freezes when running the app in debug mode. I first tried this with Xcode 15.4 and iOS 17.5. Here the hang only appears at the beginning, but only for a few seconds. But when I exit debug mode, there are no more hangs. With Xcode 16 beta 4 and iOS 18 it looks completely different. In this case, the hangs and freezes are always present, whether in debug mode or not. And it's not just at the beginning, it's throughout the app. I'm aware that this is still a beta, but I still find this weird. And when I profile this I see that the main thread gets quite overloaded. Interestingly, my app doesn't have that many operations going on. So I guess something with the sync of SwiftData or my CloudKitManger where I fetch some records from the public database is not running fine. Lastly, I wanted to delete the iCloud app data. So I went to Settings and tried to delete it, but it didn't work. Is this normal? Does anyone have any idea what this could be? Or has anyone encountered this problem as well? I'd appreciate any support. My project: https://github.com/romanindermuehle/iLibrary

We are testing our existing live build, which was prepared with Xcode 16.2, on iOS 26 beta for experience assurance and found that the [[UIDevice currentDevice] systemVersion] API is returning iOS 19 instead of the expected version iOS 26. Has anyone else observed this issue?

I've already submitted this as a bug report to Apple, but I am posting here so others can save themselves some troubleshooting. This is submitted as FB14337982 with an attached complete Xcode project to replicate. In iOS 17 we use a ModelActor to download data which is saved as an Event, and then save it to SwiftData with a relationship to a Location. In iOS 18 22A5307d we are seeing that this code no longer persists the relationship to the Location, but still saves the Event. If we put a breakpoint in that ModelActor we see that the object graph is correct within the ModelActor stack trace at the time we call modelContext.save(). However, after saving, the relationship is missing from the default.store SQLite file, and of course from the app UI. Here is a toy example showing how inserting an Employee into a Company using a ModelActor gives unexpected results in iOS 18 22A5307d but works as expected in iOS 17. It appears that no relationships data survives being saved in a ModelActor.ModelContext. Also note there seems to be a return of the old bug that saving this data in the ModelActor does not update the @Query in the UI in iOS 18 but does so in iOS 17. Models @Model final class Employee { var uuid: UUID = UUID() @Relationship(deleteRule: .nullify) public var company: Company? /// For a concise display @Transient var name: String { self.uuid.uuidString.components(separatedBy: "-").first ?? "NIL" } init(company: Company?) { self.company = company } } @Model final class Company { var uuid: UUID = UUID() @Relationship(deleteRule: .cascade, inverse: \Employee.company) public var employees: [Employee]? = [] /// For a concise display @Transient var name: String { self.uuid.uuidString.components(separatedBy: "-").first ?? "NIL" } init() { } } ModelActor import OSLog private let logger = Logger(subsystem: Bundle.main.bundleIdentifier!, category: "SimpleModelActor") @ModelActor final actor SimpleModelActor { func addEmployeeTo(CompanyWithID companyID: PersistentIdentifier?) { guard let companyID, let company: Company = self[companyID, as: Company.self] else { logger.error("Could not get a company") return } let newEmployee = Employee(company: company) modelContext.insert(newEmployee) logger.notice("Created employee \(newEmployee.name) in Company \(newEmployee.company?.name ?? "NIL")") try! modelContext.save() } } ContentView import OSLog private let logger = Logger(subsystem: Bundle.main.bundleIdentifier!, category: "View") struct ContentView: View { @Environment(\.modelContext) private var modelContext @Query private var companies: [Company] @Query private var employees: [Employee] @State private var simpleModelActor: SimpleModelActor! var body: some View { ScrollView { LazyVStack { DisclosureGroup("Instructions") { Text(""" Instructions: 1. In iOS 17, tap Add in View. Observe that an employee is added with Company matching the shown company name. 2. In iOS 18 beta (22A5307d), tap Add in ModelActor. Note that the View does not update (bug 1). Note in the XCode console that an Employee was created with a relationship to a Company. 3. Open the default.store SQLite file and observe that the created Employee does not have a Company relationship (bug 2). The relationship was not saved. 4. Tap Add in View. The same code is now executed in a Button closure. Note in the XCode console again that an Employee was created with a relationship to a Company. The View now updates showing both the previously created Employee with NIL company, and the View-created employee with the expected company. """) .font(.footnote) } .padding() Section("**Companies**") { ForEach(companies) { company in Text(company.name) } } .padding(.bottom) Section("**Employees**") { ForEach(employees) { employee in Text("Employee \(employee.name) in company \(employee.company?.name ?? "NIL")") } } Button("Add in View") { let newEmployee = Employee(company: companies.first) modelContext.insert(newEmployee) logger.notice("Created employee \(newEmployee.name) in Company \(newEmployee.company?.name ?? "NIL")") try! modelContext.save() } .buttonStyle(.bordered) Button("Add in ModelActor") { Task { await simpleModelActor.addEmployeeTo(CompanyWithID: companies.first?.persistentModelID) } } .buttonStyle(.bordered) } } .onAppear { simpleModelActor = SimpleModelActor(modelContainer: modelContext.container) if companies.isEmpty { let newCompany = Company() modelContext.insert(newCompany) try! modelContext.save() } } } }

We are experiencing a large number of crashes in our production environment, mainly occurring on iOS 16 systems and iPhone 8 and iPhone X devices. The crash log and stack trace are as follows: Error: Assertion failed: (false) function _onqueue_rdar53306264_addWaiter file TubeManager.cpp line 1042 Crashed: com.apple.CFNetwork.LoaderQ 0 libsystem_kernel.dylib 0x7198 __pthread_kill + 8 1 libsystem_pthread.dylib 0xd5f8 pthread_kill + 208 2 libsystem_c.dylib 0x1c4b8 abort + 124 3 libsystem_c.dylib 0x70d8c err + 266 4 CFNetwork 0x1eb80 CFURLRequestSetMainDocumentURL + 6288 5 CFNetwork 0x44fd8 CFURLCacheRemoveAllCachedResponses + 22624 6 CFNetwork 0x39460 _CFHostIsDomainTopLevel + 968 7 CFNetwork 0x1f754 CFURLRequestSetMainDocumentURL + 9316 8 CFNetwork 0x233e0 CFURLRequestSetRequestPriority + 8792 9 CFNetwork 0x20d38 CFURLRequestCopyHTTPRequestBodyStream + 1612 10 CFNetwork 0x4f950 CFHTTPCookieStorageCopyCookies + 16276 11 CFNetwork 0x15878 CFURLRequestSetURL + 7600 12 libdispatch.dylib 0x637a8 _dispatch_call_block_and_release + 24 13 libdispatch.dylib 0x64780 _dispatch_client_callout + 16 14 libdispatch.dylib 0x3f6fc _dispatch_lane_serial_drain$VARIANT$armv81 + 600 15 libdispatch.dylib 0x401e4 _dispatch_lane_invoke$VARIANT$armv81 + 432 16 libdispatch.dylib 0x41304 _dispatch_workloop_invoke$VARIANT$armv81 + 1620 17 libdispatch.dylib 0x49f14 _dispatch_workloop_worker_thread + 608 18 libsystem_pthread.dylib 0x1bd0 _pthread_wqthread + 284 19 libsystem_pthread.dylib 0x1720 start_wqthread + 8 Have you encountered a similar issue before?

The documentation for CGColorRef (https://developer.apple.com/documentation/coregraphics/cgcolorref?language=objc) clearly shows that it is a struct. However, when I try to store a cell's border color using CGColorRef originalColor = self.bg.layer.borderColor and inspect what happens in the debugger, both that property and its copy have the same address. And later when I try to restore the border color the copy still has the same address but is no longer valid and causes a crash on assignment (originalColor is actually an instance variable...) This is all object behavior, not struct behavior. If CGColorRef really was a struct, the contents would have been copied, the instance variable would have had its own address that would never have changed, and the value would have remained valid indefinitely and let me copy it back without a problem. Why is this documented wrong? Was this a recent change? I actually had this code working at some point, and now it's broken.

I need my application to copy some files, but using Finder. Now, I know all different methods and options to programmatically copy files using various APIs, but that's not the point here. I specifically need to use Finder for the purpose, so please, let's avoid eventual suggestions mentioning other ways to copy files. My first thought was to use the most simple approach, execute an AppleScript script using NSUserAppleScriptTask, but that turned out not to be ideal. It works fine, unless there already are files with same names at the copying destination. In such case, either the script execution ends with an error, reporting already existing files at the destination, or the existing files can be simply overridden by adding with overwrite option to duplicate command in the script. What I need is behaviour just like when Finder is used from the UI (drag'n'drop, copy/paste…); if there are existing files with same names at the destination, Finder should offer a "resolution panel", asking the user to "stop", "replace", "don't replace", "keep both" or "merge" (the latter in case of conflicting folders). So, I came to suspect that I could achieve such bahaviour by using Apple Events directly and passing kAEAlwaysInteract | kAECanSwitchLayer options to AESendMessage(). However, I can't figure out how to construct appropriate NSAppleEventDescriptor (nor old-style Carbon AppleEvent) objects and instruct Finder to copy files. This is where I came so far, providing srcFiles are source files (to be copied) URLs and dstFolder destination folder (to be copied into) URL: NSRunningApplication *finder = [[NSRunningApplication runningApplicationsWithBundleIdentifier:@"com.apple.finder"] firstObject]; if (!finder) { NSLog(@"Finder is not running."); return; } NSAppleEventDescriptor *finderDescriptor = [NSAppleEventDescriptor descriptorWithBundleIdentifier:[finder bundleIdentifier]]; NSAppleEventDescriptor *dstDescriptor = [NSAppleEventDescriptor descriptorWithString:[dstFolder path]]; NSAppleEventDescriptor *srcDescriptor = [NSAppleEventDescriptor listDescriptor]; for (NSURL *url in srcFiles) { NSAppleEventDescriptor *fileDescriptor = [NSAppleEventDescriptor descriptorWithString:[url path]]; [srcDescriptor insertDescriptor:fileDescriptor atIndex:([srcDescriptor numberOfItems] + 1)]; } NSAppleEventDescriptor *event = [NSAppleEventDescriptor appleEventWithEventClass:kAECoreSuite eventID:kAEClone targetDescriptor:finderDescriptor returnID:kAutoGenerateReturnID transactionID:kAnyTransactionID]; [event setParamDescriptor:srcDescriptor forKeyword:keyDirectObject]; [event setParamDescriptor:dstDescriptor forKeyword:keyAETarget]; NSError *error; NSAppleEventDescriptor *result = [event sendEventWithOptions:(NSAppleEventSendAlwaysInteract | NSAppleEventSendCanSwitchLayer) timeout:10.0 error:&error]; The code above executes without any error. The final result descriptor is a NULL descriptor ([NSAppleEventDescriptor nullDescriptor]) and there's no error returned (by reference). However, nothing happens, Finder remains silent and the application doesn't make macOS/TCC prompt for a permission to "automate Finder". I wonder if the approach above is correct and if I use correct parameters as arguments for all calling method/messages. I'm specially interested if passing keyAETarget is the right value in [event setParamDescriptor:dstDescriptor forKeyword:keyAETarget], since that one looks most suspicious to me. I'd really appreciate if anyone can help me with this. I'd also like to point out that I tried the same approach outlined above with old-style Carbon AppleEvent API, using AECreateDesc(), AECreateAppleEvent(), AEPutParamDesc() and AESendMessage()… All API calls succeeded, returning noErr, but again, nothing happened, Finder remained silent and no macOS/TCC prompt for a permission to "automate Finder". Any help is highly appreciated, thanks! -- Dragan