OK, I will create a feature request. But considering that none of the feedbacks (or radars) I filed since 2018 in the screensaver area ever really got any feedback, I think this feature request will just collect dust on an Apple server.

Thanks. Those are interesting pointers to explore.

"codeSigningID" : "testException-55554944e0bd51c1d54834c8a36f3f6a2e7a6e6b", "codeSigningTeamID" : "", "codeSigningFlags" : 570425861, "codeSigningValidationCategory" : 10, "codeSigningTrustLevel" : 4294967295, <--- here "codeSigningAuxiliaryInfo" : 0, testException-2025-06-02-234012 copy.txt

In 2025 and in macOS Sequoia, the bug is still there. It can be easily reproduced for instance with this Swift project https://github.com/yichizhang/NSTextView-LineNumberView

to collect console.app logs It's not the console.app logs. These the are the system wide logs. Run the following command in the Terminal: % sudo log config --status You will probably get: System mode = INFO As they explain in the log man page, DEBUG is a level below INFO, so you may try to change the system level with: % sudo log config --mode level:debug This allows to get the debug logs when you run: % sudo log collect --last 7m i.e. the logs on the Mac. I don't know whether it works for this --device-udid option as I'm not running on a macOS version where this option is available in log(1).

Its not SIP. It's probably just Full Disk Access (FDA). If you're running your script from Terminal.app, maybe just granting FDA to Terminal.app is enough.

Is there some restriction which prevents access to the user selected, when it’s not strictly clicked by the user or am I missing something here? There are restrictions. From the documentation: This method returns valid values only from the Finder Sync extension’s menuForMenuKind: method or from one of the menu actions created in this method. If the selected items are outside the extension’s managed directories (for example, when the user clicks on the toolbar button), this method returns nil. https://developer.apple.com/documentation/findersync/fifindersynccontroller/1501575-selecteditemurls?language=objc

I watched WWDC 2022-10107 session and, though this session is very interesting, it still does not explain why the scroll position is wrong with RTL.

Unless the application you're planning to distribute is very huge or is using a cross platform framework that makes it a nightmare to support multiple localization in an app, the best solution would be to just include all the localizations in your app and support files. There is not really a way to support what you are tying to achieve with the localized text files. At best, you could create a custom installer plugin to display the ReadMe file in multiple languages but this would still not allow you to do the same with the Welcome (and Conclusion) steps. And synchronizing the language selected in the fake ReadMe step would not be easy or possible. Allowing to install a different version of the app and some support files depending on a selected language could be possible using choices and using the custom installation mode by default. But again, there's not really a way to synchronize the selected language in the License pane (or your custom fake ReadMe pane). Honestly, your 2 best options are: when in macOS do as the macOSians do: let the system language settings decide which localization to use for the app and the Welcome, ReadMe (and Conclusion). And have an application bundle/components that include all the localizations distribute 1 installation package per language. I don't believe that merging the Welcome, ReadMe and EULA in a single file and use that file for the License step is a user friendly solution.

I found a solution from a webpage on the Apple's Developer site while looking for another problem with NSSearchField (not displaying the magnifying glass on the right side). "\U200E%2$@ - \U200F%1$@" Ref. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/SupportingRight-To-LeftLanguages/SupportingRight-To-LeftLanguages.html Strangely, the example in the documentation is incorrect for macOS. \u does not work. \U does work.

Thanks for the suggestion. Unfortunately, localizedStringWithFormat: produces the same result as stringWithFormat: For what it's worth, whatever the order of the parameters provided after the format string, I always get the "LFT Text - RTL Other Text" output. The "RTL Other Text" is actually a localized NSDate (Date + Time) if that makes any difference. unless running under an RTL locale Not 100% sure I'm getting this. The app is run with a RTL language selected as the Preferred Language in System Preferences. Is this what you have in mind?

FB10026850

OK. I will try to figure out how to use the C API. Display problem with the documentation -> FB9956926. If you use Google Chrome, it's a bit better.

I would just use the - (pid_t)pid private API if I had to get this value insecurely.

Thanks for the info. I don't remember where I saw this but indeed, there seems to be some checks with paths such as /System/, /Library/Apple/, /usr/bin, and bundle identifiers such as com.apple.* , Motion,… The issue with the com.apple.* pattern is that when Xcode crashes (yes, it happens), you end up with something incorrect where the Xcode binary and its linked embedded frameworks are not considered user code but its embedded Swift Libraries are…