Posts

Post not yet marked as solved
4 Replies
961 Views
Crash in fileproviderctl Invoking fileproviderctl from the Terminal.app results in crash. ot@wpg-img-mbp bin % fileproviderctl --help zsh: killed fileproviderctl --help Checked the Device log for more details, and found this, default 10:35:47.810676+0530 kernel mac_vnode_check_signature: /usr/bin/fileproviderctl: code signature validation failed fatally: When validating /usr/bin/fileproviderctl: dynamic: com.apple.fileproviderctl disallowed without com.apple.private.amfi.version-restriction entitlement default 10:35:47.810733+0530 kernel proc 58397: load code signature error 4 for file "fileproviderctl" default 10:35:47.811297+0530 kernel ASP: Security policy would not allow process: 58397, /usr/bin/fileproviderctl default 10:35:47.811420+0530 kernel fileproviderctl[58397] Corpse allowed 1 of 5 default 10:35:47.828366+0530 ReportCrash Formulating fatal 309 report for corpse[58397] fileproviderctl default 10:35:47.838691+0530 osanalyticshelper creating type 309 as /Users/ot/Library/Logs/DiagnosticReports/.fileproviderctl-2023-09-14-103547.ips default 10:35:47.852670+0530 osanalyticshelper Saved type '309(<private>)' report (25 of max 25) at /Users/ot/Library/Logs/DiagnosticReports/fileproviderctl-2023-09-14-103547.ips default 10:35:47.853184+0530 ReportCrash client log create type 309 result success: /Users/ot/Library/Logs/DiagnosticReports/fileproviderctl-2023-09-14-103547.ips default 10:35:47.853323+0530 ReportCrash no MetricKit for process fileproviderctl type 309 bundleId (null) default 10:35:47.852983+0530 osanalyticshelper xpc log creation type 309 result success: /Users/ot/Library/Logs/DiagnosticReports/fileproviderctl-2023-09-14-103547.ips And also found the fileproviderctl in the Crash DiagosticsReports, looks like a codesigning issue. I'm not sure how I got into this issue, but I need this to be fixed. Any help is appreciated! Added the Crash Report and Device Information below, Crash Report of fileproviderctl Crash Report Device Information
Posted Last updated
.
Post not yet marked as solved
3 Replies
3.8k Views
Some context from the Human Interface Guidelines. It says that the AppIcon should be square in shape with no rounded edges. But when I build my app with the same image specs using Image Asset Catalog, it does not seems to be rounding the corners automagically. I know it does in iOS and iPadOS, but does it work macOS 11. And what about Icon shapes in older macOS Catalina? Will this change affect them. Square without rounded corners looks kinda ugly.
Posted Last updated
.
Post not yet marked as solved
4 Replies
981 Views
Hello, I'm using osacompile to compile and AppleScript to an .App file and use it in my application. osacompile -x -o "Application.app" "AppleScript.scpt" So, when I compile the scpt in macOS Catalina, it works well and good. The problem is after compiling the same app in macOS Big Sur, now the compiled app works well in macOS 11 but not on macOS Catalina. The same app does not run stating that minimum macOS requirement is not satisfied. Something which goes like this, You can’t use this version of the application “Application.app” with this version of macOS. You have macOS 10.15.7. The application requires macOS 11.0 or later. The underlying problem was the load command LC_VERSION_MIN_MACOSX is not present in the objdump of the excitable built form macOS 11, it instead has LC_BUILD_VERSION set to 11.0 otool -l <path to executable> The executable from Catalina has LC_VERSION_MIN_MACOSX set to 10.6 and works fine because of that. And surprisingly, when I try in one another macOS 11 machine the LC_VERSION_MIN_MACOSX load command gets emitted and set to 10.6 So what is the ideal behaviour of osacompile, is it reliable to use. From where are these load commands getting emitted? Looks like osacomplile does to honour MACOS_DEPLOYMENT_TARGET environmental variable nor it has any compile time flags that can be set like in gcc (-mmacosx-min-version) Someone please guide me through this. Thanks in advance.
Posted Last updated
.