It seems to me that English texts will get better hyphenation if the system language in macOS is set to English. It is hard to be sure, but I think that when my system is set to Swedish, I see a lot more hyphenations like "somet-hing". This is on macOS Big Sur, in an NSTextView with hyphenation switched on by setting hyphenationFactor to 1 on an NSParagraphStyle object in an NSAttritributedString, not a web view or anything like that. The application is not localized, so the app language is English. Setting NSAccessibilityLanguageTextAttribute to "en-US" seems to have no effect. I'd like to know if anyone can confirm this, and if so, is there anything to do about it?

I've implemented Core Spotlight indexing of the Core Data in my macOS app, using NSCoreDataCoreSpotlightDelegate, and it seems to be working. Any new or changed Core Data objects and attributes seem to be added to the index automatically and immediately, but searchable items for deleted objects won't be automatically removed. I guess this is working as expected? I've implemented the willSave: method in the relevant NSManagedObject subclasses, where I check the deleted property and run deleteSearchableItemsWithIdentifiers on the default Searchable Index. I also delete searchable items for deleted Core Data objects in my QuickLook extension's preparePreviewOfSearchableItemWithIdentifier method. I suppose what I'm asking is: Am I understanding this right and is this the best way to do it?

I've implemented Core Spotlight indexing of my app's Core Data without an index extension (CSIndexExtensionRequestHandler), and it seems to be working fine. Would it still be useful to have one? It is described in the documentation, but I'm not sure how to implement things like reindexAllSearchableItems for Core Data. The Showcase App Data in Spotlight sample code associated with the WWDC21 session does not have an index extension, or override the default reindexAllSearchableItems method of NSCoreDataCoreSpotlightDelegate. Does that mean that this is no longer needed?

Capturing an image of an off-screen window with CGWindowListCreateImage is a common way to create QuickLook-style zoom-in animations, but seems to give the wrong background colour, slightly whiter than the actual window has when it is shown onscreen. This causes a flash at the end of the animation which kind of ruins the effect. Does anyone have any idea why this happens and what can be done about it? If I set the window appearance to textured in Interface Builder this problem goes away, but then I have the problem that the window looks different (darker) than other windows in the app. I can set the window background to a custom color that makes it match the others windows, but then it still looks off in older macOS versions. I made a sample project that illustrates the problem here: https://github.com/angstsmurf/WindowCaptureTest.

I have an NSTextView inside an NSScrollView with magnification. Zooming in with a pinch-and-zoom gesture works fine, but if I then resize the window while zoomed in, it will eventually crash with the error The window has been marked as needing another Display Window pass, but it has already had more Display Window passes than there are views in the window. It does not always happen immediately, sometimes you have to keep resizing for a while to trigger it. I have made a video illustrating the problem here: youtu.be/M_JRQI2oDaY The original code is here: https://github.com/angstsmurf/spatterlight/tree/helpviewtest (The branch helpviewtest is a cut down test case created for this problem.)

It seems to me that setting the thumbnailData and thumbnailURL attributes on the CSSearchableItemAttributeSet has no function in macOS. The Spotlight interface will only ever show the application icon in search results. Is this the expected behaviour? Is setting this attribute useful in any way?

I have a Mac app that was accepted to the App Store when I built it using Xcode 13 (with code signing set to automatic, just like I do now), but with Xcode 14.2 I keep getting mails with ITMS-90288: Invalid Code Signing Entitlements and TMS-90286: Invalid Code Signing Entitlements, two very similar errors for each embedded dynamic library. The exact wording is this: TMS-90288: Invalid Code Signing Entitlements - The entitlements in your app bundle signature do not match the ones that are contained in the provisioning profile. According to the provisioning profile, the bundle contains a key value that is not allowed: '(My team id).' for the key 'com.apple.application-identifier' in 'Spatterlight.app/Contents/Frameworks/libc64diskimage.dylib' ITMS-90286: Invalid Code Signing Entitlements - Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, value '(My team id).' for key 'com.apple.application-identifier' in 'Spatterlight.app/Contents/Frameworks/libc64diskimage.dylib' is not supported. This value should be a string starting with your TEAMID, followed by a dot '.', followed by the bundle identifier . The post https://developer.apple.com/forums/thread/710598 seems to indicate that dylibs shouldn't have entitlements at all, but apparently Xcode is adding them anyway, making the app unacceptable to the App Store. How do I fix this?

After upgrading to Sonoma and Xcode 15, some of the NSTextViews in my app no longer show up. However, if entering Debug View Hierarchy, you can see them just fine. This only seems to happen with certain views that are created programmatically.

I used to be able to test my app by making it save files to a temp folder (with a file URL created in the XCUITest runner), and then comparing them to files in the test bundle, but in Sonoma, this will issue a blocking "[App name] wants to access files from other apps" security alert, which has to be dismissed manually. This breaks the test flow. It kind of makes sense, as I'm trying to save from the app to the temp folder of another app (the test runner.) Is there any way around this? Is there a temp folder that both applications can access without security alerts?

When my macOS Cocoa app displays a modal alert with beginSheetModal(for:completionHandler:), VoiceOver sometimes seems to focus on an "illegal" upper level, where any attempts at navigation will give the unhelpful response "Alert, dialog", until you "drill down" with VO + shift + down or switch apps. After that, things will work as expected. Is this a known bug? Does it happen to anybody else, or am I doing something wrong?