In a Simulator instance running iOS 15, I am able to tap and hold an app in the Dock and drag it to the left or right screen border to create a new window of that app. But when doing that in a Simulator instance running iOS 16 or 17, after tap and holding an app in the Dock, I cannot drag it anywhere, it just stays in the Dock. Is this a bug or is there another solution?

I keep getting crash reports in Xcode for one of my macOS apps published on the App Store. Actually it's not the main app that crashes, but the embedded Finder Sync extension. The crash reports indicate that this source code line static var appGroupSaveDirectoryUrl = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: identifier)!.appendingPathComponent("Library/Application Support/somedata") crashes with error Swift runtime failure: Unexpectedly found nil while unwrapping an Optional value + 0 (<compiler-generated>:0) That line is a static variable defined in a class that is included in the main app as well as the Finder extension. The documentation reads In iOS, the value is nil when the group identifier is invalid. In macOS, a URL of the expected form is always returned, even if the app group is invalid If the documentation says that the method call can never be nil, why am I getting this crash? Is it a bug or is the documentation wrong, or am I doing something wrong? And why does the Finder Sync extension crash and not the main app? I cannot reproduce this crash with the App Store app or within Xcode and Console shows no crash reports for the app on my Mac.

I cannot find in the documentation if using NEFilterDataProvider.apply(_:) has any advantage over manually inspecting incoming flows in handleNewFlow(_:) other than being a shortcut. Or are those rules guaranteed to be applied even if the network extension crashes or similar? If it has no practical advantages, then manually inspecting each flow allows to set up more flexible dynamic rules.

In my macOS app I'm encoding and restoring the state of a view between app launches. It used to work fine until I updated to macOS 14 and Xcode 15. Now Xcode logs this error when calling coder.decodeObject(forKey: "string"): *** -[NSPersistentUIKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSString' (0x1dfa40918) [/System/Library/Frameworks/Foundation.framework]' for key 'string', even though it was not explicitly included in the client allowed classes set: '{( )}'. This will be disallowed in the future. The following sample code reproduces the issue: class ViewController: NSViewController { override func viewDidAppear() { invalidateRestorableState() } override class func allowedClasses(forRestorableStateKeyPath keyPath: String) -> [AnyClass] { return [NSString.self] } override func encodeRestorableState(with coder: NSCoder) { coder.encode("asdf", forKey: "string") } override func restoreState(with coder: NSCoder) { print(coder.decodeObject(forKey: "string") as! String) } } What am I doing wrong?

I'm testing my NEFilterDataProvider system extension by building it in Xcode and then copying the built app into the Applications folder. When I do changes to the extension's code, obviously the system extension process currently running needs to be shut down or restarted when I launch the new app version. Increasing the app version and build numbers each time always seem to trigger the system extension update in macOS, but that's not so convenient and at the latest when publishing the update those numbers cannot just make arbitrary jumps. I've read that moving an app to the trash should uninstall any attached system extensions, and this seems to be confirmed by the alert that macOS shows when doing so, but even after clicking Continue and authenticating with Touch ID to confirm the uninstall and emptying the trash, it sometimes happens that when launching the next version of my app from the Applications folder the old system extension is still running, which I notice e.g. because the app crashes since it's using different IPC method signatures than the system extension. When checking in Activity Monitor the system extension is also still listed. Even restarting the Mac doesn't always solve the issue, so when this happens my only solution is to increase the build and version numbers to make it work, and then reset them later when moving the app to the trash correctly uninstalls the system extension again. Is this a bug or am I missing something? Or is there a workaround that doesn't involve booting into safe mode and manually uninstalling the system extension? P.S.: I just tried booting into safe mode and moving the files from /Library/SystemExtensions to the trash as suggested on discussions.apple.com, but I got an alert saying that I didn't have the privileges to do so.

I'm using this code to get the path of an executable from the audit token provided in NEFilterDataProvider.handleNewFlow(_:), forwarded from the Network Extension to the main app via IPC: private func securePathFromAuditToken(_ auditToken: Data) throws -> String { let secFlags = SecCSFlags() var secCode: SecCode? var status = SecCodeCopyGuestWithAttributes(nil, [kSecGuestAttributeAudit: auditToken] as CFDictionary, secFlags, &secCode) guard let secCode = secCode else { throw NSError(domain: NSOSStatusErrorDomain, code: Int(status)) } var secStaticCode: SecStaticCode? status = SecCodeCopyStaticCode(secCode, secFlags, &secStaticCode) guard let secStaticCode = secStaticCode else { throw NSError(domain: NSOSStatusErrorDomain, code: Int(status)) } var url: CFURL? status = SecCodeCopyPath(secStaticCode, secFlags, &url) guard let url = url as URL? else { throw NSError(domain: NSOSStatusErrorDomain, code: Int(status)) } return url.path } This code sometimes returns paths like /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/Resources/helpd or /Library/Developer/CoreSimulator/Volumes/iOS_21A328/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.0.simruntime/Contents/Resources/RuntimeRoot/usr/libexec/mobileassetd. But sometimes the SecCodeCopyGuestWithAttributes fails with status 100001 which is defined in MacErrors.h as kPOSIXErrorEPERM = 100001, /* Operation not permitted */. In these cases I resort to this code, which I have read is not as secure: private func insecurePathFromAuditToken(_ auditToken: Data) throws -> String? { if auditToken.count == MemoryLayout<audit_token_t>.size { let pid = auditToken.withUnsafeBytes { buffer in audit_token_to_pid(buffer.baseAddress!.assumingMemoryBound(to: audit_token_t.self).pointee) } let pathbuf = UnsafeMutablePointer<Int8>.allocate(capacity: Int(PROC_PIDPATHINFO_SIZE)) defer { pathbuf.deallocate() } let ret = proc_pidpath(pid, pathbuf, UInt32(PROC_PIDPATHINFO_SIZE)) if ret <= 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } return String(cString: pathbuf) } return nil } This insecure code then returns paths like /usr/libexec/trustd, /usr/libexec/rapportd, /usr/libexec/nsurlsessiond and /usr/libexec/timed. From what I can see, SecCodeCopyGuestWithAttributes fails for all processes in /usr/libexec. Some of these processes have executables with the same name placed in another directory, like /Library/Developer/CoreSimulator/Volumes/iOS_21A328/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.0.simruntime/Contents/Resources/RuntimeRoot/usr/libexec/mobileassetd for which it succeeds, while for /usr/libexec/mobileassetd it fails. Occasionally, both the secure and the insecure methods fail and in these cases the secure one returns status code 100003, which is defined as kPOSIXErrorESRCH = 100003, /* No such process */. When can this happen? This seems to happen with both NEFilterFlow.sourceAppAuditToken and sourceProcessAuditToken. What is the problem?

I noticed an issue in macOS 14 which I didn't have on macOS 13. I used to be able to set a custom mouse cursor when it moves over a certain view area in my app, but now it's regularly reset to the standard arrow cursor. This is easily reproduced with the following code. When I move the mouse in and out of the red rectangle. When moving in, the cursor should become a hand, and when moving out an arrow again. It seems that particularly when moving the mouse to the right of the red rectangle it quickly gets reset to the arrow cursor, while moving the mouse on the left side it often stays a hand. Even uncommenting the line with cursor?.set() makes the mouse cursor flicker between arrow and hand. Is this a known bug or am I doing something wrong? class ViewController: NSViewController { var cursor: NSCursor? let subframe = CGRect(x: 100, y: 100, width: 300, height: 100) override func loadView() { let subview = NSView(frame: subframe) subview.wantsLayer = true subview.layer!.backgroundColor = NSColor.red.cgColor view = NSView(frame: CGRect(x: 0, y: 0, width: 500, height: 300)) view.addSubview(subview) view.addTrackingArea(NSTrackingArea(rect: .zero, options: [.activeInKeyWindow, .inVisibleRect, .cursorUpdate, .mouseMoved], owner: self)) } override func mouseMoved(with event: NSEvent) { if subframe.contains(view.convert(event.locationInWindow, from: nil)) { if cursor == nil { cursor = .openHand cursor!.push() print("set cursor") } } else if let cursor = cursor { cursor.pop() self.cursor = nil print("unset cursor") } // cursor?.set() } }

When promoting my app or a significant update at https://developer.apple.com/contact/app-store/promote I have to fill out a Target Submission Date and a Target Release Date. The release date is when I want the app or update to be released to the public on the App Store, but what is the submission date? Can the submission date in relation to the release date influence the likelihood of my app or update being considered for a promotion? Should the interval between the submission and release date be as large as possible?

Since NEFilterFlow.identifier is documented as The unique identifier of the flow., I thought I could use it to store the flow by its identifier in a dictionary in order to retrieve it later. I do this when the system extension pauses a flow because it needs to ask the user whether the flow should eventually be allowed or dropped. But then I noticed that sometimes when allowing a previously paused flow, identified by its identifier, my system extension doesn't find that flow anymore. After some debugging it turned out that this happens because I stored at least one other flow with the same id which, when confirmed, is removed again from the dictionary, so there is no more flow with that identifier waiting in the dictionary. Is it expected that the identifiers are recycled for different flows, or does it mean that the same flow is effectively being passed to .handleNewFlow(_:) multiple times, such as if the extension waited "too long" between pausing a flow and allowing or dropping it? What does this mean?

Xcode contains several crash reports downloaded from users of my app. Thread 0 apparently crashes after calling NSApp.runModalForWindow(_:) (within the redacted stacktrace rows 17-19 that are locations in my own code). All the other threads only contain calls to system code. What could cause such a crash? ... Code Type: ARM-64 Parent Process: launchd [1] User ID: 501 ... OS Version: macOS 13.5.2 (22G91) ... Crashed Thread: 0 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x000000018800c728 Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [61015] Thread 0 Crashed: 0 AppKit 0x000000018800c728 -[NSApplication _crashOnException:] + 240 (NSApplication.m:6808) 1 AppKit 0x0000000187e54a10 __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 644 (NSCATransaction.m:98) 2 AppKit 0x0000000188530cfc ___NSRunLoopObserverCreateWithHandler_block_invoke + 64 (AppKit_Internal.h:745) 3 CoreFoundation 0x0000000184b059f0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36 (CFRunLoop.c:1789) 4 CoreFoundation 0x0000000184b058dc __CFRunLoopDoObservers + 532 (CFRunLoop.c:1902) 5 CoreFoundation 0x0000000184b04f14 __CFRunLoopRun + 776 (CFRunLoop.c:2944) 6 CoreFoundation 0x0000000184b044b8 CFRunLoopRunSpecific + 612 (CFRunLoop.c:3418) 7 HIToolbox 0x000000018e356df0 RunCurrentEventLoopInMode + 292 (EventLoop.c:455) 8 HIToolbox 0x000000018e356a80 ReceiveNextEventCommon + 220 (EventBlocking.c:311) 9 HIToolbox 0x000000018e356984 _BlockUntilNextEventMatchingListInModeWithFilter + 76 (EventBlocking.c:171) 10 AppKit 0x0000000187d2b97c _DPSNextEvent + 636 (CGDPSReplacement.m:818) 11 AppKit 0x0000000187d2ab18 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716 (appEventRouting.m:407) 12 AppKit 0x0000000187f63bd0 -[NSApplication _doModalLoop:peek:] + 216 (NSApplication.m:3469) 13 AppKit 0x0000000187f62ad4 __35-[NSApplication runModalForWindow:]_block_invoke_2 + 56 (NSApplication.m:3516) 14 AppKit 0x0000000187f62a80 __35-[NSApplication runModalForWindow:]_block_invoke + 108 (NSApplication.m:3516) 15 AppKit 0x0000000187f62364 _NSTryRunModal + 100 (NSModal.m:25) 16 AppKit 0x0000000187f62224 -[NSApplication runModalForWindow:] + 292 (NSApplication.m:3516) ... 20 AppKit 0x0000000187ed34cc -[NSApplication(NSResponder) sendAction:to:from:] + 440 (appEventRouting.m:1888) 21 AppKit 0x0000000187ed32e4 -[NSControl sendAction:to:] + 72 (NSControl.m:1459) 22 AppKit 0x0000000187fda170 -[NSTableView _sendAction:to:row:column:] + 116 (NSTableView.m:9022) 23 AppKit 0x0000000187fd8d70 -[NSTableView mouseDown:] + 4224 (NSTableView.m:11191) 24 AppKit 0x0000000187ecdef0 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3476 (winEventRouting.m:1003) 25 AppKit 0x0000000187e58b2c -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 364 (winEventRouting.m:402) 26 AppKit 0x0000000187e587ec -[NSWindow(NSEventRouting) sendEvent:] + 284 (winEventRouting.m:257) 27 AppKit 0x0000000187e57b30 -[NSApplication(NSEvent) sendEvent:] + 1556 (appEventRouting.m:0) 28 AppKit 0x00000001880a7c48 -[NSApplication _handleEvent:] + 60 (NSApplication.m:3342) 29 AppKit 0x0000000187d1efa0 -[NSApplication run] + 500 (NSApplication.m:3430) 30 AppKit 0x0000000187cf63cc NSApplicationMain + 880 (NSApplication.m:9413) 31 MyApp 0x0000000102980cd0 main + 128 (main.swift:12) 32 dyld 0x00000001846cff28 start + 2236 (dyldMain.cpp:1165) ...

Xcode contains several crash reports downloaded from users of my app. Thread 0 apparently crashes at [CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink], but there's not a single stacktrace line that contains code within my app, so I have no idea what this means or how to reproduce it. What could cause such a crash? Code Type: X86-64 (Native) Parent Process: launchd [1] User ID: 501 ... OS Version: macOS 14.0 (23A344) ... Crashed Thread: 0 Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [1920] Thread 0 Crashed: 0 AppKit 0x00007ff81c3730c1 -[NSApplication _crashOnException:] + 289 (NSApplication.m:7290) 1 AppKit 0x00007ff81c175ea5 __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 853 (NSCATransaction.m:98) 2 AppKit 0x00007ff81cc43339 ___NSRunLoopObserverCreateWithHandler_block_invoke + 41 (AppKit_Internal.h:760) 3 CoreFoundation 0x00007ff818a13836 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 (CFRunLoop.c:1789) 4 CoreFoundation 0x00007ff818a1375a __CFRunLoopDoObservers + 493 (CFRunLoop.c:1902) 5 CoreFoundation 0x00007ff818a12cdc __CFRunLoopRun + 850 (CFRunLoop.c:2946) 6 CoreFoundation 0x00007ff818a12372 CFRunLoopRunSpecific + 557 (CFRunLoop.c:3420) 7 HIToolbox 0x00007ff82327e9d9 RunCurrentEventLoopInMode + 292 (EventLoop.c:455) 8 HIToolbox 0x00007ff82327e616 ReceiveNextEventCommon + 201 (EventBlocking.c:311) 9 HIToolbox 0x00007ff82327e531 _BlockUntilNextEventMatchingListInModeWithFilter + 66 (EventBlocking.c:171) 10 AppKit 0x00007ff81c01a0c5 _DPSNextEvent + 880 (CGDPSReplacement.m:806) 11 AppKit 0x00007ff81c90b150 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1304 (appEventRouting.m:410) 12 AppKit 0x00007ff81c00b63a -[NSApplication run] + 603 (NSApplication.m:3488) 13 AppKit 0x00007ff81bfdf670 NSApplicationMain + 816 (NSApplication.m:10105) 14 MyApp 0x0000000100627071 main + 129 (main.swift:12) 15 dyld 0x00007ff8185b03a6 start + 1942 (dyldMain.cpp:1269) Thread 1: 0 libsystem_kernel.dylib 0x00007ff8188f9a2e mach_msg2_trap + 10 1 libsystem_kernel.dylib 0x00007ff818907e4a mach_msg2_internal + 84 (mach_msg.c:201) 2 libsystem_kernel.dylib 0x00007ff818900b6e mach_msg_overwrite + 653 (mach_msg.c:0) 3 libsystem_kernel.dylib 0x00007ff8188f9d1f mach_msg + 19 (mach_msg.c:323) 4 CoreFoundation 0x00007ff818a14475 __CFRunLoopServiceMachPort + 143 (CFRunLoop.c:2624) 5 CoreFoundation 0x00007ff818a12ee5 __CFRunLoopRun + 1371 (CFRunLoop.c:3007) 6 CoreFoundation 0x00007ff818a12372 CFRunLoopRunSpecific + 557 (CFRunLoop.c:3420) 7 AppKit 0x00007ff81c1773e0 _NSEventThread + 122 (NSEvent.m:5493) 8 libsystem_pthread.dylib 0x00007ff818939202 _pthread_start + 99 (pthread.c:904) 9 libsystem_pthread.dylib 0x00007ff818934bab thread_start + 15

Xcode contains several crash reports downloaded from users of my app. Thread 1 apparently crashes while performing a string interpolation. All the other threads only contain calls to system code. The String.appendingPathComponent(_:) that appears in the stacktrace is defined as follows: extension String { func appendingPathComponent(_ pathComponent: String) -&gt; String { return pathComponent == "" ? self : self == "" || self == "/" ? "\(self)\(pathComponent)" : "\(self)/\(pathComponent)" } } What could cause such a crash? Thread 1 Crashed: 0 CoreFoundation 0x00007ff81566f9df __CFStringEncodeByteStream + 120 (CFStringEncodings.c:692) 1 Foundation 0x00007ff8164c95aa -[NSString(NSStringOtherEncodings) getBytes:maxLength:usedLength:encoding:options:range:remainingRange:] + 204 (NSStringEncodings.m:341) 2 libswiftCore.dylib 0x00007ff822c6c1e0 String.UTF8View._foreignDistance(from:to:) + 208 (StringUTF8View.swift:507) 3 libswiftCore.dylib 0x00007ff822c56715 _StringGuts.append(_:) + 1445 (StringGutsRangeReplaceable.swift:191) 4 MyApp 0x00000001010c3c0f String.appendingPathComponent(_:) + 15 (&lt;compiler-generated&gt;:0)

When calling DispatchQueue.main.async or DispatchQueue.main.sync with a call to self without capturing self, I get a compiler error: Call to method 'asd' in closure requires explicit use of 'self' to make capture semantics explicit Since I usually use DispatchQueue.main.async, I'm now used to solving this error by capturing self like this: DispatchQueue.main.async { [self] in asd() } But this unfortunately doesn't seem to work with DispatchQueue.main.sync: DispatchQueue.main.async { [self] in asd() } This gives the compiler warning: Call to method 'asd' in closure requires explicit use of 'self' to make capture semantics explicit; this is an error in Swift 6 This warning only appears for DispatchQueue.main.sync and not for DispatchQueue.main.async. Why? How can I avoid having to prefix every method call with self. in this case?

Since NEFilterFlow.identifier is documented as The unique identifier of the flow., I thought I could use it to store the flow by its identifier in a dictionary in order to retrieve it later. I do this when the system extension pauses a flow because it needs to ask the user whether the flow should eventually be allowed or dropped. But then I noticed that sometimes when allowing a previously paused flow, identified by its identifier, my system extension doesn't find that flow anymore. After some debugging it turned out that this happens because I stored at least one other flow with the same id which, when confirmed, is removed again from the dictionary, so there is no more flow with that identifier waiting in the dictionary. Is it expected that the identifiers are recycled for different flows, or does it mean that the same flow is effectively being passed to handleNewFlow(_:) multiple times, such as if the extension waited "too long" between pausing a flow and allowing or dropping it? handle(_:) can be called multiple times for the same flow, but why .handleNewFlow(_:)? All flows with duplicate ids seem to be UDP, and the local host and port and remote host and port are the same for all flows with the same id. Most of the duplicate flows have a process path of /usr/sbin/mDNSResponder (resolved with the sourceAppAuditToken).

I've noticed that depending when I call NSApp.runModal(for:), the table view contained in the presented window is unresponsive: it either doesn't scroll at all, or the content only updates after one or two seconds, presumably after the inertial scrolling has ended. In the sample code below I call NSApp.runModal(for:) in 3 different ways: with a direct call inside the callback to perform(_:with:afterDelay:) inside the callback to DispatchQueue.main.async. Only method 2 works. Why? @main class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { // Insert code here to initialize your application let window = NSWindow(contentViewController: ViewController(nibName: nil, bundle: nil)) // 1. doesn't work runModal(for: window) // 2. works // perform(#selector(runModal), with: window, afterDelay: 0) // 3. doesn't work // DispatchQueue.main.async { // self.runModal(for: window) // } } @objc func runModal(for window: NSWindow) { NSApp.runModal(for: window) } } class ViewController: NSViewController, NSTableViewDataSource, NSTableViewDelegate { override func loadView() { let tableView = NSTableView() tableView.addTableColumn(NSTableColumn()) tableView.dataSource = self tableView.delegate = self let scrollView = NSScrollView(frame: CGRect(x: 0, y: 0, width: 500, height: 500)) scrollView.documentView = tableView view = scrollView } func numberOfRows(in tableView: NSTableView) -> Int { return 100 } func tableView(_ tableView: NSTableView, objectValueFor tableColumn: NSTableColumn?, row: Int) -> Any? { return "\(row)" } func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { let cell = NSTableCellView() cell.addSubview(NSTextField(labelWithString: "\(row)")) return cell } }