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?

In TextKit 1 we have the method NSTextStorage.addLayoutManager(_:) that allows to show the same text in multiple text views. This method exists with NSLayoutManager but not with NsTextLayoutManager. Is there a way to achieve the same thing with TextKit 2?

I have a file named ä.txt (with German umlaut) on my FTP server. I select it like this: let openPanel = NSOpenPanel() openPanel.runModal() let source = openPanel.urls[0] Running this code unexpectedly throws an error: do { print(try source.checkResourceIsReachable()) } catch { print(error) // Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory” } Manipulating the URL also seems to change the underlying characters: print(source) // file:///Volumes/abc.com/httpdocs/%C3%A4.txt print(URL(fileURLWithPath: source.path)) // file:///Volumes/abc.com/httpdocs/a%CC%88.txt Note that both variants of the URL above also throw the same error when running URL.checkResourceIsReachable(). If I download the file to my Mac, then both variants print file:///Users/me/Downloads/a%CC%88.txt and neither of them throws an error when running URL.checkResourceIsReachable(). What is the problem? How can I correctly access this file on the FTP server?

All the threads only contain system calls. The crashed thread only contains a single call to my app's code which is main.swift:12. What could cause such a crash? Crash report

Even when the action is run on the main thread, the following code causes a crash on iOS, but not on macOS. The game launches with a simple yellow rectangle, and when it finishes fading out and should be removed from the overlay scene, the app crashes. The code can be pasted into the file GameController.swift of Xcode's default project for Multiplatform macOS and iOS game. import SceneKit import SpriteKit @MainActor class GameController: NSObject { let scene: SCNScene let sceneRenderer: SCNSceneRenderer init(sceneRenderer renderer: SCNSceneRenderer) { sceneRenderer = renderer scene = SCNScene(named: "Art.scnassets/ship.scn")! super.init() sceneRenderer.scene = scene renderer.overlaySKScene = SKScene(size: CGSize(width: 500, height: 500)) DispatchQueue.main.async { let node = SKShapeNode(rect: CGRect(x: 100, y: 100, width: 100, height: 100)) node.fillColor = .yellow node.run(.sequence([ .fadeOut(withDuration: 1), .removeFromParent() ])) renderer.overlaySKScene!.addChild(node) } } } The Xcode console shows this stacktrace: *** Assertion failure in -[UIApplication _performAfterCATransactionCommitsWithLegacyRunloopObserverBasedTiming:block:], UIApplication.m:3246 *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Call must be made on main thread' *** First throw call stack: ( 0 CoreFoundation 0x00000001804ae0f8 __exceptionPreprocess + 172 1 libobjc.A.dylib 0x0000000180087db4 objc_exception_throw + 56 2 Foundation 0x0000000180d17058 _userInfoForFileAndLine + 0 3 UIKitCore 0x00000001853cf678 -[UIApplication _performAfterCATransactionCommitsWithLegacyRunloopObserverBasedTiming:block:] + 376 4 UIKitCore 0x000000018553f7a0 -[_UIFocusUpdateThrottle scheduleProgrammaticFocusUpdate] + 300 5 UIKitCore 0x0000000184e2e22c -[UIFocusSystem _requestFocusUpdate:] + 548 6 UIKitCore 0x0000000184e2dfa4 -[UIFocusSystem requestFocusUpdateToEnvironment:] + 76 7 UIKitCore 0x0000000184e2e864 -[UIFocusSystem _focusEnvironmentWillDisappear:] + 408 8 SpriteKit 0x00000001a3d472f4 _ZL12_removeChildP6SKNodeS0_P7SKScene + 240 9 SpriteKit 0x00000001a3d473b0 -[SKNode removeChild:] + 80 10 SpriteKit 0x00000001a3d466b8 -[SKNode removeFromParent] + 128 11 SpriteKit 0x00000001a3d1678c -[SKRemove updateWithTarget:forTime:] + 64 12 SpriteKit 0x00000001a3d1b740 _ZN11SKCSequence27cpp_updateWithTargetForTimeEP7SKCNoded + 84 13 SpriteKit 0x00000001a3d20e3c _ZN7SKCNode6updateEdf + 156 14 SpriteKit 0x00000001a3d20f20 _ZN7SKCNode6updateEdf + 384 15 SpriteKit 0x00000001a3d26fb8 -[SKScene _update:] + 464 16 SpriteKit 0x00000001a3cf3168 -[SKSCNRenderer _update:] + 80 17 SceneKit 0x000000019c932bf0 -[SCNMTLRenderContext renderSKSceneWithRenderer:overlay:atTime:] + 60 18 SceneKit 0x000000019c9ebd98 -[SCNRenderer _drawOverlaySceneAtTime:] + 204 19 SceneKit 0x000000019cb1a1c0 _ZN3C3D11OverlayPass7executeERKNS_10RenderArgsE + 60 20 SceneKit 0x000000019c8e05ec _ZN3C3D13__renderSliceEPNS_11RenderGraphEPNS_10RenderPassERtRKNS0_9GraphNodeERPNS0_5StageENS_10RenderArgsEbRPU27objcproto16MTLCommandBuffer11objc_object + 2660 21 SceneKit 0x000000019c8e18ac _ZN3C3D11RenderGraph7executeEv + 3808 22 SceneKit 0x000000019c9ed26c -[SCNRenderer _renderSceneWithEngineContext:sceneTime:] + 756 23 SceneKit 0x000000019c9ed544 -[SCNRenderer _drawSceneWithNewRenderer:] + 208 24 SceneKit 0x000000019c9ed9fc -[SCNRenderer _drawScene:] + 40 25 SceneKit 0x000000019c9edce4 -[SCNRenderer _drawAtTime:] + 500 26 SceneKit 0x000000019ca87950 -[SCNView _drawAtTime:] + 368 27 SceneKit 0x000000019c943b74 __83-[NSObject(SCN_DisplayLinkExtensions) SCN_setupDisplayLinkWithQueue:screen:policy:]_block_invoke + 44 28 SceneKit 0x000000019ca50600 -[SCNDisplayLink _displayLinkCallbackReturningImmediately] + 132 29 libdispatch.dylib 0x000000010239173c _dispatch_client_callout + 16 30 libdispatch.dylib 0x0000000102394c14 _dispatch_continuation_pop + 756 31 libdispatch.dylib 0x00000001023aa4e0 _dispatch_source_invoke + 1736 32 libdispatch.dylib 0x00000001023997f0 _dispatch_lane_serial_drain + 340 33 libdispatch.dylib 0x000000010239a774 _dispatch_lane_invoke + 420 34 libdispatch.dylib 0x00000001023a71a8 _dispatch_root_queue_drain_deferred_wlh + 324 35 libdispatch.dylib 0x00000001023a6604 _dispatch_workloop_worker_thread + 488 36 libsystem_pthread.dylib 0x000000010242bb74 _pthread_wqthread + 284 37 libsystem_pthread.dylib 0x000000010242a934 start_wqthread + 8 ) libc++abi: terminating due to uncaught exception of type NSException Am I doing something wrong?

I've been running my SceneKit game for many weeks in Xcode without performance issues. The game itself is finished, so I thought I could go on with publishing it on the App Store, but when archiving it in Xcode and running the archived app, I noticed that it seriously hangs. The hangs only seem to happen when I run the game in fullscreen mode. I tried disabling game mode, but the hangs still happen. Only when I run in windowed mode the game runs smoothly. Instruments confirms that there are many serious hangs, but it also reports that CPU usage is quite low during those hangs, on average about 15%. From what I know, hangs happen when the main thread is busy, but how can that be when CPU usage is so low, and why does it only happen in fullscreen mode for release builds?

In my SceneKit game I'm able to connect two players with GKMatchmakerViewController. Now I want to support the scenario where one of them disconnects and wants to reconnect. I tried to do this with this code: nonisolated public func match(_ match: GKMatch, player: GKPlayer, didChange state: GKPlayerConnectionState) { Task { @MainActor in switch state { case .connected: break case .disconnected, .unknown: let matchRequest = GKMatchRequest() matchRequest.recipients = [player] do { try await GKMatchmaker.shared().addPlayers(to: match, matchRequest: matchRequest) } catch { } @unknown default: break } } } nonisolated public func player(_ player: GKPlayer, didAccept invite: GKInvite) { guard let viewController = GKMatchmakerViewController(invite: invite) else { return } viewController.matchmakerDelegate = self present(viewController) } But after presenting the view controller with GKMatchmakerViewController(invite:), nothing else happens. I would expect matchmakerViewController(_:didFind:) to be called, or how would I get an instance of GKMatch? Here is the code I use to reproduce the issue, and below the reproduction steps. Code Run the attached project on an iPad and a Mac simultaneously. On both devices, tap the ship to connect to GameCenter. Create an automatched match by tapping the rightmost icon on both devices. When the two devices are matched, on iPad close the dialog and tap on the ship to disconnect from GameCenter. Wait some time until the Mac detects the disconnect and automatically sends an invitation to join again. When the notification arrives on the iPad, tap it, then tap the ship to connect to GameCenter again. The iPad receives the call player(_:didAccept:), but nothing else, so there’s no way to get a GKMatch instance again.

I was just having a look at some crash reports downloaded by Xcode, and I noticed the same wrong pattern I already mentioned here: the crash reports indicate that method A calls method B, which is impossible. In the first crash report below, method MainViewController.showSettings seems to be called by ConfirmMoveViewController.openSourceInFinder, which is impossible. ConfirmMoveViewController.openSourceInFinder is a context menu action in a modal window, and MainViewController.showSettings is in a completely different window and the two methods have no relation whatsoever. In the second crash report below, MainViewController.setSortMode is triggered by the press of a button (and nothing else) but seems to be called by OtherViewController.copy that can be triggered by a context menu (or keyboard shortcut). The two methods have no relation whatsoever. The rest of the stack trace confirm that it's indeed the button that was pressed. This seems to me like a quite serious bug in how macOS creates crash reports. 1.crash 2.crash

My app supports different plain text file formats, including the standard .txt and Markdown. When creating a new document, my app already asks which format it should have, so when saving it, I would expect that the save panel already selects that format in the popup button, but currently it always selects "Plain Text". For example, I would expect for a Markdown document that it selects "Markdown" instead of "Plain Text". Is there a way to force it to select the most specific format matching the document format?

A user of one of my apps reported that since the update to macOS 26.1 they are no longer able to scan Macintosh HD: the app used to work, but now always reports that Macintosh HD contains a single empty file named .nofollow, or rather the path is resolved to /.nofollow. Initially I thought this could be related to resolving the file from the saved bookmark data, but even restarting the app and selecting Macintosh HD in an open panel (without resolving the bookmark data) produces the same result. The user tried another app of mine with the same issue, but said that they were able to scan Macintosh HD in other App Store apps. I never heard of this issue before and my apps have been on the App Store for many years, but it looks like I might be doing something wrong, or the APIs that I use are somehow broken. In all my apps I currently use getattrlistbulk because I need attributes that are not available as URLResourceKey in all supported operating system versions. What could be the issue? I'm on macOS 26.1 myself and never experienced it.

Since NSPathControl.setPathComponentCells(_:) and .clickedPathComponentCell() are deprecated, I'm trying to use pathItems and clickedPathItem instead. Since I'm representing a virtual path, I cannot use the NSPathControl.url setter, but instead set pathItems directly. The problem is that in the action method it doesn't seem possible to get the index of the clicked path item, nor does it seem possible to associate any kind of data with each path item, since when the action method is called, the actual object instances stored in pathItems and also the one returned by clickedPathItem change every time. Here is the sample code that reproduces the issue: class ViewController: NSViewController {     @IBOutlet weak var pathControl: NSPathControl!          override func viewDidLoad() {         super.viewDidLoad()         pathControl.pathItems = ["a", "b", "c"].map({ title in             let item = NSPathControlItem()             item.title = title             return item         })     }     @IBAction func selectPath(_ sender: NSPathControl) {         print(sender.clickedPathItem!.description, sender.clickedPathItem!.title, sender.pathItems.description)     }      } Here is a sample output (notice how the printed addresses change every time): <NSPathControlItem: 0x6000012780a0> a [<NSPathControlItem: 0x6000012780a0>, <NSPathControlItem: 0x600001278020>, <NSPathControlItem: 0x600001278090>] <NSPathControlItem: 0x600001278070> a [<NSPathControlItem: 0x600001278070>, <NSPathControlItem: 0x600001278140>, <NSPathControlItem: 0x6000012780d0>] <NSPathControlItem: 0x60000124c030> a [<NSPathControlItem: 0x60000124c030>, <NSPathControlItem: 0x60000124c080>, <NSPathControlItem: 0x60000124c070>]

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.

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.

In macOS 26 I noticed there is a section Menu Bar in System Settings which allows to toggle visibility of status items created with NSStatusItem. I'm assuming this is new, since I never noticed it before. Currently my app has a menu item that allows toggling its status item, but now I wonder whether it should always create the status item and let the user control its visibility from System Settings. Theoretically, keeping this option inside the app could lead to confusion if the user has previously disabled the status item in System Settings, then perhaps forgot about it, and then tries to enable it inside the app, but apparently nothing happens because System Settings overrides the app setting. Should I remove the option inside the app? This also makes me think of login items, which can be managed both in System Settings and inside the app via SMAppService. Some users ask why my app doesn't have a launch at login option, and I tell them that System Settings already offers that functionality. Since there is SMAppService I could offer an option inside the app that is kept in sync with System Settings, but I prefer to avoid duplicating functionality, particularly if it's something that is changed once by the user and then rarely (if ever) changed afterwards. But I wonder: why can login items be controlled by an app, and the status item cannot (at least I'm not aware of an API that allows to change the option in System Settings)? If the status item can be overridden in System Settings, why do login items behave differently?

Xcode downloaded a crash report for my app that crashed when trying to insert a String into a Set<String>. Apparently there was an assertion failure ELEMENT_TYPE_OF_SET_VIOLATES_HASHABLE_REQUIREMENTS. I assume that this assertion failure happened because the hash of the new element didn't match the hash of an equal already inserted element, but regardless, I don't understand how inserting a simple string could trigger this assertion. Here is essentially the code that leads to the crash. path is any file system directory, and basePath is a directory higher in the hierarchy, or path itself. var scanErrorPaths = Set<String>() func main() { let path = "/path/to/directory" let basePath = "/path" let fileDescriptor = open(path, O_RDONLY) if fileDescriptor < 0 { if (try? URL(fileURLWithPath: path, isDirectory: false).checkResourceIsReachable()) == true { scanErrorPaths.insert(path.relativePath(from: basePath)!) return } } extension String { func relativePath(from basePath: String) -> String? { if basePath == "" { return self } guard let index = range(of: basePath, options: .anchored)?.upperBound else { return nil } return if index == endIndex || basePath == "/" { String(self[index...]) } else if let index = self[index...].range(of: "/", options: .anchored)?.upperBound { String(self[index...]) } else { nil } } } crash.crash