It’s also in the Documentation Archive )-: With no good reasons. It's like deprecating the gestalt API and not providing a replacement API. As to what you should do about this, it depends on whether you actually need to support 10.14 or earlier systems? If it were up to me, I would like to support from 10.6.6. But at least, if there are known versions of OS X/macOS that do not support this option as expected, then it would be great to clearly advertise from which version there are no gaps in support. I guess I will have to file a feedback ticket again.

Done. FB20250705

It doesn't seem like I can specify the timeout for a package postinstall script, only if I specify a script for a specific bundle. Would you agree? According to the man page, the timeout attribute can not be customized for global preinstall or postinstall scripts. According to the PackageInfo file that is created by pkgbuild tool on macOS Sequoia, the timeout attribute is set for the global preinstall or postinstall scripts and the value is 600. So it would be interesting to check whether just incrementing this value works (as one would expect) or this is not possible because of a hardcoded maximum value for the timeout for global scripts. It is possible to edit the PackageInfo info by: expanding the .pkg with pkgutil --expand editing the PackageInfo file with your favorite text editor. flattening the directory to produce a new .pkg with pkgutil --flatten. e.g. <?xml version="1.0" encoding="utf-8"?> <pkg-info overwrite-permissions="true" relocatable="false" identifier="inc.acme.emptypayload" postinstall-action="none" version="1.0" format-version="2" generator-version="InstallCmds-860.14 (24G90)" auth="root"> <payload numberOfFiles="1" installKBytes="0"/> <bundle-version/> <upgrade-bundle/> <update-bundle/> <atomic-update-bundle/> <strict-identifier/> <relocate/> <scripts> <preinstall file="./preinstall" timeout="600"/> </scripts> </pkg-info>

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