Post not yet marked as solved
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.
Post not yet marked as solved
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
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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?
Post not yet marked as solved
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.
Post not yet marked as solved
I would just use the - (pid_t)pid private API if I had to get this value insecurely.
Post not yet marked as solved
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…
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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;
}
Post not yet marked as solved
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/SearchFields/Articles/MenuTemplate.html#//apple_ref/doc/uid/20002245-BABFIBIA
Post not yet marked as solved
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.
Post not yet marked as solved
I hope that a delay of 11 days for the reply is not going to cause you a psychological shock again.So I performed tests on my side and the outputs are a bit less optimistic than yours:- time to build the products and the archives to upload: ~2 minutes- time to upload the archives: ~4 minutes.- time for the notarization process to be performed on the server and the result to be available: 2-3 minutes.So basically, this means multiplying the a job build time by 4 on a CI server.I'm glad this is not an issue for you. For me, it is.Of course, these results were before the release of macOS Catalina.Because, since then, the time a notarization request can take on Apple's server has quite increased:- in the best cases, it takes 3-4 minutes.- it's no more uncommon for it to take 9-10 minutes. And having to wait 10 minutes is quite irritating.- worst case I've experienced so far was 30 minutes.And if I am to believe the feedback I'm seeing in the forums, there are even worse cases.Regarding the private island idea, considering that an app is worth $0.99 or nothing on Apple's platforms, I find the scenario you suggested a bit unrealistic.
