Some additional info: using the vertical scroller with the mouse to scroll vertically just works fine (dragging the thumb or clicking below the thumb). using the Home and End keys just works fine.

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/SearchFields/Articles/MenuTemplate.html#//apple_ref/doc/uid/20002245-BABFIBIA

I think it's a bug in AppKit that exists in 10.14.x, 10.15.x and 11.0.1. The NSTextView scrolling methods do not seem to take into account vertical rulers and horizontal scrolling at the same time by assuming the scroll point will always have x = 0 for key scrolling that goes through the scrollDown: and scrollUp: methods. 2. The following code looks like to address the issue and work for 10.14 and later (on Intel at least). It can certainly be improved. (void)_scrollDown:(CGFloat)inOffset {     NSScrollView * tScrollView=self.enclosingScrollView;     NSView * tDocumentView=tScrollView.documentView;     NSRulerView * tVerticalRulerView=tScrollView.verticalRulerView;     if (self!=tDocumentView ||         tVerticalRulerView==nil ||         tScrollView.horizontalScroller.isHidden==YES)     {         [super _scrollDown:inOffset];         return;     }     NSRect tOldFrame=tDocumentView.frame;          /* Offset the text view frame to take into account the vertical ruler width */              NSRect tNewFrame=tOldFrame;              tNewFrame.origin.x-=NSWidth(tVerticalRulerView.frame);              self.frame=tNewFrame;          [super _scrollDown:inOffset];     /* Restore the text view frame */     self.frame=tOldFrame; }

FB8913004 Side note: In macOS BS, the default icon is apparently built from a SF Symbol. But using a NSImage built from a SF Symbol does not display the image but keeps displaying the magnifying glass. Sigh.

This may be related to the sandboxing of Installer Plugins. It might be preferable to only disable the Continue button if the conditions are not met and invite the user to quit the application. Side note: The issue when you check requirements through an Installer Plugin is that these requirements will not be checked when the installation is run from the command line or through a deployment solution (b/c the Plugin will not be loaded). So this would end up in the erroneous installations you mentioned.

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…

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

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.

FB10026850

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?

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.

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 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.

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

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.