I reported Korean IME bug to QT Bug report. Please refer to below link. https://bugreports.qt.io/browse/QTBUG-136128?jql=text%20~%20korean%20ORDER%20BY%20created%20DESC But, QT reponsed me like follwing. Thank you for reporting. However, this issue seems like a known issue with apple's Korean IME. There are many threads in Korean community about the same problem with Non-Qt apps. If this issue is a really Qt issue, feel free to open it again. Is there any workaround to fix this IME bug ? Thanks, Ted

My application provides a unique feature for MacOS 26+ users, while keeping legacy for other versions (12.4+). So I aim to provide two help books localized package, depending on MacOS' version of the running computer. I designed two help bundles, with their own Info.plist files (identifiers, default filename…) and I've made multiple checks to verify that all their settings are correct and different when needed. As an app's info.plist can deal only with one Help Book, my application delegate registers both in applicationDidFinishLaunching: using: [[NSHelpManager sharedHelpManager] registerBooksInBundle:[NSBundle mainBundle]]; In Interface Builder, the help menu item is connected to the application delegate's "showHelp:" method to set the correct help package. The code in this method is: if (@available(macOS 26.0,*)){ helpbook = @"fr.myapp.updated.help"; } else { helpbook = @"fr.myapp.legacy.help"; } [[NSHelpManager sharedHelpManager] openHelpAnchor:@"index" inBook:helpbook]; The problem is that despite the MacOS version of the user's Mac, (either 15.1 or 26.2) , the «legacy» helpbook is always used. All default index.html (for each lproj) have a tag immediately after the I spent dozen of hours to understand the problem, forum parsing, including hours long dialogs with ChatGPT and Claude AIs (not mentioning MacOS' help system cache problems I could solve) I noticed also, to be complete, that when parsing the application package, opening the legacy .help with "Tips.app" always works, but with the "updated" one the help system opens with an "unavailable content" message. Both help bundles are fully included in the built application. Tested whether the app is installed in the debug directory, moved to in the Applications one, reboot, emptying/deleting cache files. So Houston, I have a problem… Any idea?

I'm building a macOS app that uses WKWebView for text editing (not NSTextView). I need to provide grammar checking by calling NSSpellChecker programmatically and sending results back to the web editor. The problem: TextEdit (which uses NSTextView) catches grammar errors like "Can I has pie?" and "These are have" — but when I call NSSpellChecker's APIs directly, those same errors are never flagged. I've tried both APIs: 1. The unified check() API: let results = checker.check( text, range: range, types: NSTextCheckingAllTypes, options: [:], inSpellDocumentWithTag: tag, orthography: &orthography, wordCount: &wordCount) This returns only .orthography results (language detection). No .spelling, no .grammar — just orthography. 2. The dedicated checkGrammar(of:startingAt:...) API: let sentenceRange = checker.checkGrammar( of: text, startingAt: offset, language: nil, wrap: false, inSpellDocumentWithTag: tag, details: &details) This catches sentence fragments ("The.", "No.") and some agreement errors ("The is anyone.") but misses "Can I has pie?", "These are have", "This will be happened", and other subject-verb agreement errors that TextEdit highlights. What I've confirmed: "Check Grammar With Spelling" is enabled in System Settings TextEdit reliably catches all these errors with green underlines Both APIs are called with a valid spellDocumentTag from uniqueSpellDocumentTag() The text is passed as plain strings (no attributed string context) My question: How does NSTextView's grammar checking work internally? It must be using something beyond these two public APIs. Possibilities I'm considering: Does NSTextView use the NSTextCheckingClient protocol / requestChecking(of:range:types:options:) for asynchronous checking that produces different results? Does NSTextView provide additional context (attributed string, layout info) that improves grammar detection? Is there a private/undocumented API or framework that NSTextView uses for deeper grammar analysis? Any insight from anyone who has implemented programmatic grammar checking on macOS would be appreciated. NOTE: This post was composed with the help of Claude Code, which I am using to help write a word-processing application, but I am frustrated because Claude Code wants to give up and switch to a 3rd party grammar checker, like LanguageTool, and it seems to me that it should be possible to use native Apple tools to achieve this goal without requiring the user to send their data elsewhere for checking. I've spent a lot of time searching the web for answers and have found surprisingly little on this. Any pointers people might have would be very much appreciated! Thanks.

When disabling the opacity slider of color panels, my app crashes with unsatisfiable layout constraints. Feel free reproduce with a minimal test project: A macOS app based on the Xcode 26.0 template with only one line added to the ViewController's viewDidLoad() function: NSColorPanel.shared.showsAlpha = false The issue doesn't occur if this property is set to "true" or not set at all. I just filed a corresponding bug report (FB20269686), although I don't expect any feedback from Apple ... as numerous issues I reported were never updated or commented at all (after migrating from RADARs).

Context: Xcode 16.4, Appkit In a windowController, I need to create and send a mouseDown event (newMouseDownEvent). I create the event with: let newMouseDownEvent = NSEvent.mouseEvent( with: .leftMouseDown, location: clickPoint, // all other fields I also need to make window key and front, otherwise the event is not handled.   func simulateMouseDown() { self.window?.makeFirstResponder(self.window) self.calepinFullView.perform(#selector(NSResponder.self.mouseDown(with:)), with: newMouseDownEvent!) }   As I have to delay the call( 0.5 s), I use asyncAfter: DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, qos: .userInteractive) { self.simulateMouseDown() }   It works as intended, but that generates the following (purple) warning at runtime: [Internal] Thread running at User-interactive quality-of-service class waiting on a lower QoS thread running at Default quality-of-service class. Investigate ways to avoid priority inversions I have tried several solutions, change qos in await: DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, qos: ..default) call from a DispatchQueue let interactiveQueue = DispatchQueue.global(qos: .userInteractive) interactiveQueue.async { self.window?.makeFirstResponder(self.window) self.calepinFullView.perform(#selector(NSResponder.self.mouseDown(with:)), with: newMouseDownEvent!) } But that's worse, it crashes with the following error: FAULT: NSInternalInconsistencyException: -[HIRunLoopSemaphore wait:] has been invoked on a secondary thread; the problem is likely in a much shallower frame in the backtrace; { NSAssertFile = "HIRunLoop.mm"; NSAssertLine = 709; }   How to eliminate the priority inversion risk (not just silencing the warning) ?

When building in Xcode on MacOS Tahoe, it seems it is no longer possible to dynamically specify a "small" size toolbar for NSToolbar/NSToolbarItem. It works in MacOS code compiled and linked on earlier systems. I don't want to use "SFSymbol", or "templates". I have over 60 custom-made .png toolbars, in individual Image Set files, at the previous requisite sizes of 24x24 / 48x48, and 32x32 / 64x64. Sure -- I can configure an NSToolbar with whatever size .png assets I want. I just can't dynamically switch between the two groups of sizes. According to the Apple Coding Assistant, the only solution is to change the image names of each of the NSToolbarItems at runtime. OK -- but even when attempting that, the NSToolbarItems refuse to take on their smaller size... ...unless: they are attached to a custom view NSToolbarItem with an NSButton of style "Bevel". I have about 10 of those, and YES -- I CAN change those to a "small" size. Is this REALLY what I'm forced to do?! The Apple Coding Assistant just runs me around in circles, making coding suggestions that include properties that don't exists. I've gone around and around on these issues for over a week -- it can't be this hard, right? Is there no way to make multiple NSToolbar objects, one for "large" and one for "small"?

NSWindow objects with custom styleMask configurations seem to behave erratically in macOS Tahoe 26.3 RC. For example an NSWindow is not resizable after issuing .styleMask.remove(.titled) or some NSWindow-s become totally unresponsive (the NSWindow becomes transparent to mouse events) with custom styleMask-s. This is a radical change compared to how all previous macOS versions or the 26.3 beta3 worked and seriously affects apps that might use custom NSWindows - this includes some system utilities, OSD/HUD apps etc, actually breaking some apps. Such fundamental compatibility altering changes should not be introduced in an RC stage (if this is intentional and not a bug) imho.

We are currently testing our application under macOS 26 in Liquid Glass mode and noticed an issue with NSSegmentedCell. Our app makes extensive use of NSCell-based drawing. Since macOS 26, when running in Liquid Glass mode, NSSegmentedCell does not render at the expected location. The control itself appears visually correct, but it is clearly drawn offset from the rect it is supposed to occupy. In compatibility mode, everything renders exactly as expected (same code, same layout). To illustrate the issue, here are two screenshots of the same view: Liquid Glass mode 👉 (screenshot 1 – segmented control visibly shifted) Compatibility mode 👉 (screenshot 2 – correct rendering) The regression is obvious when switching between the two modes. This behavior has been present since the first macOS 26 release and is still reproducible with Xcode 26.2 (17C52). I have already filed a report via Feedback Assistant (FB reference available if useful), but I’m posting here to see whether others are experiencing the same issue or have found a workaround. Thanks.

Since we started building our application on Tahoe, all NSPopupButtons in the UI stop truncating when the window they're in is moved to a different screen. Even though their frame is correct, if the selected item string is longer than what can fit, they just draw outside of their bounds, overlapping other neighbouring controls. This is reproducible only in our app target even though they are not subclassed or overridden in any way. The same window copied to a test app doesn't have the issue. Initially good After dragging to another screen Frame is correct in the View Hierarchy debugger, but the contents are incorrect. Very simple constraint setup, with content compression resistance set lower to allow resizing below the intrinsic content size. This is what happens on this simple test window. The rest of the popups in more complex windows are all bad right away, without requiring you to move them to a different screen. When built on Sequoia, all is well regardless of which OS the app is run on. Looking for ideas on how to troubleshoot this and figure out what's triggering it.

I have a mac app using AppKit. I have a view that extends under the toolbar. It is very slightly blurred but still disturbs the readability of the toolbar items. In another window, I have a view that sits inside a NSScrollView and there the content is much more blurred and a bit dimmed under the toolbar. Is there a way to make the not scrolled view behave like the one in the NSScrollView?

I get warnings like this on each project I build while debugging.. Internal inconsistency in menus - menu <NSMenu: 0x8b4b49ec0> Title: Help Supermenu: 0x8b4b49f80 (Main Menu), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x8b5771720 Metal4C Help, ke='Command-?'>" ) believes it has <NSMenu: 0x8b4b49f80> Title: Main Menu Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu What am I doing wrong? I get these errors even if I create a default app with no code?

In an NSTableView (Appkit), I need to colour a cell background when it is selected. That works OK, except that the colour does not span the full cell width, nor even the text itself: The tableView structure is very basic: I see there is a TextCell at the end that cannot be deleted. What is this ? And the colouring as well: func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { let p = someDataSource[row] if let cellView = tableView.makeView(withIdentifier: NSUserInterfaceItemIdentifier(rawValue: "Cell"), owner: self) { (cellView as! NSTableCellView).textField?.stringValue = p if selected[row] { (cellView as! NSTableCellView).backgroundColor = theLightBlueColor } else { (cellView as! NSTableCellView).backgroundColor = .clear } return cellView } } I've tried to change size constraints in many ways, to no avail. For instance, I changed Layout to Autoresising : I tried to change TableCellView size to 170 vs 144: Or increase tableColum Width. I have looked at what other object in the NSTableView hierarchy should be coloured without success. Nothing works. What am I missing ?

I noticing that Monterey defaults to the NSWindowToolbarStyleAutomatic / NSWindowToolbarStyleUnified toolbar style, which suppresses the "use Small Size" menu item and customization checkbox. So I've set the window to use NSWindowToolbarStyleExpanded. However, the toolbar will no longer change to a smaller icon size, as it did in MacOS 10.14, 10.15, and 11.0. I've tried to set the toolbar item sizing to "Automatic" for all of our toolbar icons, but that results in bad positioning in both Regular and Small Size mode -- the height is way too big. The native size of the icon .png files are 128 x 128. What's odd is that if I resize the window with the toolbar to be wider, the NSToolbarItems in the overflow area will be displayed in the toolbar are 128 x 128, where the rest of the toolbar icons get displayed as a 32 x 32 icon. The only way to get it to layout remotely correct is to make the NSToolbarItem to have an explicit minimum size of 24 x 24 and maximum size of 32 x 32. And that USED to allow "small size", but on Monterey, it no longer does. Anyone had any success with small size icons on Monterey?

Hello, I am developing a macOS app using AudioToolbox's MusicSequence and MusicPlayer APIs to play Standard MIDI Files. The MIDI playback works correctly and I can hear sound from the external MIDI device. However, the user callback registered via MusicSequenceSetUserCallback is never invoked during playback. Details: Callback registration returns no error. MusicPlayer is properly started and prerolled. The callback is defined as a global function with the correct @convention(c) signature. I have tried commenting out MusicTrackSetDestMIDIEndpoint to avoid known callback suppression issues. The clientData pointer is passed and correctly unwrapped in the callback. Minimal reproducible example shows the same behavior. Environment: macOS version: [Tahoe 26.2] Xcode version: [26.2] Is it expected that MusicSequenceSetUserCallback callbacks may not be called in some cases? Are there additional steps or configurations required to ensure the callback is triggered during MIDI playback? Thank you for any advice or pointers. Execute playTest() in the viewDidLoad() method of the ViewController. extension ViewController { private func playTest() { NewMusicSequence(&sequence) if let midiFileURL = Bundle.main.url(forResource: "etude", withExtension: "mid") { MusicSequenceFileLoad(sequence!, midiFileURL as CFURL, .midiType,MusicSequenceLoadFlags()) NewMusicPlayer(&player) MusicPlayerSetSequence(player!, sequence!) MusicPlayerPreroll(player!) let status = MusicSequenceSetUserCallback(sequence!, musicSequenceUserCallback, Unmanaged.passUnretained(self).toOpaque()) if status == noErr { print("Callback registered successfully") } else { print("Callback registration failed: \(status)") } MusicPlayerStart(player!) } else { print("MIDI File Not Found") } } } The callback function was generated by Xcode and defined outside the ViewController. func musicSequenceUserCallback( clientData: UnsafeMutableRawPointer?, sequence: MusicSequence, track: MusicTrack, eventTime: MusicTimeStamp, eventData: UnsafePointer<MusicEventUserData>, startSliceBeat: MusicTimeStamp, endSliceBeat: MusicTimeStamp ) { print("User callback fired at eventTime: \(eventTime)") if let clientData = clientData { let controller = Unmanaged<ViewController>.fromOpaque(clientData).takeUnretainedValue() // Example usage to prove round-trip works (avoid strong side effects in callback) _ = controller.view // touch to silence unused warning if needed print("Callback has access to ViewController: \(controller)") } else { print("clientData was nil") } }

In this app I use tooltips extensively. They work perfectly well, except in a popover where they may appear or not (just some flash and immediately disappear). In the popover there are 12 colour buttons, each with its own tracking area and 3 control buttons, with their tracking areas. Here when it works, hovering over "C" button or "Annuler" button: But then, when I move to another colour button, a few 2 or 3 may work, but most don't display their tooltip at all. I know that the tooltip is set because I replicate the message in a help line at the bottom of the screen and this line always update: Let messageForColor = "Choisir la couleur…" if button.isEnabled { // show tooltip button.toolTip = messageForColor } else { button.toolTip = nil } if button.isEnabled { // Shows helpline at the bottom of screen button.helpMessage = messageForColor } Maybe it comes from some useDefault (I modified NSInitialTool TipDelay and I'm not sure I have reset to the default value) I noted that if I wait for 10 seconds or so (keeping the popover opened), everything seems to work properly again. Just as if there was some lengthy initialisation going on. So questions: Is there a known issue of Tooltips in a popover ? Are there other parameters to set in userDefaults to avoid immediate disparition of the tooltip in popover ? How to reset the factory setting for the UserDefaults in the app ?

This is a very basic macOS Finder-style test app using AppKit. I am experiencing a "jump" in the vertical scroll position of my NSTableView (inside an NSScrollView) specifically when the window is resized horizontally. This happens when columns are visually added or removed. Framework: AppKit (Cocoa) Xcode/macOS: 26.2 Code: https://github.com/MorusPatre/Binder/blob/main/ContentView%20-%20Scroll%20Jump%20during%20Resize.swift

I need to create a Mac application using Objective-C. The application has to use PHPickerViewController to provide user a familiar interface to pick photos. Here is the Objective-C code that used to present the photo picker. //ViewController.h #import <Cocoa/Cocoa.h> #import <PhotosUI/PhotosUI.h> @interface ViewController : NSViewController<PHPickerViewControllerDelegate> @property (nonatomic, weak) IBOutlet NSImageView *myImageView; @end // ViewController.m @implementation ViewController PHPickerViewController* pickerViewController = nil; - (void)pickPhotos { PHPickerConfiguration *config = [[PHPickerConfiguration alloc] init]; config.selectionLimit = 0; // Allow multiple selections config.filter = [PHPickerFilter imagesFilter]; // Filter for images pickerViewController = [[PHPickerViewController alloc] initWithConfiguration:config]; pickerViewController.preferredContentSize = NSMakeSize(800, 600); pickerViewController.delegate = self; // Set the delegate to handle selection [self presentViewControllerAsModalWindow:pickerViewController]; - (IBAction)clicked:(id)sender { NSLog(@"Button Clicked"); [self pickPhotos]; } - (void)picker:(PHPickerViewController *)picker didFinishPicking:(NSArray<PHPickerResult *> *)results { if (pickerViewController) { [picker dismissViewController:pickerViewController]; } } @end Can you please guide me to show the photo picker to a bigger size?

After updating to macOS 26.3 Release Candidate, all interactions for borderless windows are no longer working. In macOS 26.3 Beta, borderless windows behaved correctly: • Mouse clicks were received normally • Window dragging worked as expected • Interaction logic was fully functional However, in macOS 26.3 RC, all of the above behaviors are broken: • Click events are not delivered • Windows cannot be moved or interacted with • The issue affects all borderless windows This is a regression from the Beta build and appears to be system-level, not app-specific. Environment: • macOS: 26.3 RC • Window type: borderless / frameless windows • Status in 26.3 Beta: working correctly • Status in 26.3 RC: completely broken Could Apple confirm whether this is a known issue or an intentional behavior change in 26.3 RC? If this is a , is there a recommended workaround before the final release? Thanks.

I'd like to create a Quick Look extension for a file type for which a location or region on a Map should be shown as preview. However the MapView would only show a grid without any map. From within the MapKit delegate I can see from the "Error" parameter (a server with this domain can not be found) that this seems to be a network issue. The Quick Look extension seems to have no access to the internet and therefore the MapView can not load any map data. I've then also done some other tests via URLSession, which also only fails with connection errors. I haven't seen any limitations or restrictions mentioned in the API documentation. Is this the expected behavior? Is this a bug? Or am I missing something?

I have Mac apps that embed “Helper Apps” inside their main bundle. The helper apps do work on behalf of the main application. The helper app doesn’t show a dock icon, it does show minimal UI like an open panel in certain situations (part of NSService implementation). And it does make use of the NSApplication lifecycle and auto quits after it completes all work. Currently the helper app is inside the main app bundle at: /Contents/Applications/HelperApp.app Prior to Tahoe these were never displayed to user in LaunchPad but now the Spotlight based AppLauncher displays them. What’s the recommended way to get these out of the Spotlight App list on macOS Tahoe? Thanks in advance.