Post

Replies

Boosts

Views

Activity

Codesigning/Testflight differences for macOS distributed apps for macOS 12 and 13/14
We have run into a very unique situation with codesigning and testing the apps under TestFlight under macOS 12 and macOS 13/14. We have existing apps on the macApp store and we are trying to basically update them. When we run the newly updated versions via Testflight under macOS 12, everything is working. However, the same apps under macOS 13/14 and Testflight crashes and we have narrowed it to a codesigned dylib issue of ours. We are getting a invalid code signature message when we try to load a dylib under macOS 13/14 and the app crashes as we cant get the dylib code pointer. Basically CFBundleGetFunctionPointerForName returns an invalid value. Just to explain we build our dylibs/bundles and codesign them outside - as these are built at the command line level and finally we package these within our apps under XCODE and go through the whole app building/archiving, code signing, validation and uploading that to the appstore. The crash log shows - Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2023-11-28 23:31:11.9903 +0900 OS Version: macOS 13.6 (22G120) Report Version: 12 Anonymous UUID: Time Awake Since Boot: 370000 seconds System Integrity Protection: enabled Crashed Thread: 7 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [91418] VM Region Info: 0 is not in any region. Bytes before following region: 4368842752 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 104674000-1047f0000 [ 1520K] r-x/r-x SM=COW ...essional 2017 Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x195a83de4 _kernelrpc_mach_port_deallocate_trap + 8 1 libsystem_kernel.dylib 0x195a85270 mach_port_deallocate + 28 2 QuartzCore 0x19d0cc458 CA::Context::destroy() + 512 3 QuartzCore 0x19d22135c invocation function for block in CA::Context::commit_transaction(CA::Transaction*, double, double*) + 100 We have double checked/triple checked the certificates and profiles and everything is valid. What is strange is that it works under macOS 12 and Testflight but not under macOS 13/14. For both Intel/Arm. Any ideas anyone?
1
0
515
Nov ’23
macOS Security scoping/exception for Plug-in with External Helper app
We have run into a security scoping issue with the newer macOS releases (specifically macOS 11.6.x and macOS 12). First and foremost, all of our code is signed and notarized. Our software is made of multiple parts and its mainly a plug-in for Adobe's software products (so its distributed outside of the app store). When you install our software, during the installation process a helper app is also installed in addition to the plug-in for Adobe's software. When the plug-in is invoked from the Adobe application the plug-in then launches an external helper that is installed in the Library/Application Support folder. The external helper app performs the brunt of the computation. We use openApplicationAtURL to launch the faceless background helper app but with newer macOS releases sometimes it gets terminated after launching immediately. The user needs to double click it once from what we have observed. We suspect this is due to a macOS security scope (thats the only conclusion we can come up with). This behavior never used to exist before (macOS 10.15 or earlier). This doesnt occur with all users but a handful of people and on newer macOS releases. We are wondering what can be done to solve this or what are we doing wrong? Do we need to file a bug report?
7
0
947
Apr ’22
initWithContentsOfFile image loading memory leakage?
We are loading image(s) from file(s) using initWithContentsOfFile. While the image(s) load properly we noticed that the memory our app is consuming is increasing even after calling a release on the loaded image(s).  We've observed this using Activity Monitor and looking at the memory our App is taking up.  Basically, the memory space is increase by the size of the image(s) we are loading (even after a release call). When our app starts up, it consumes maybe 20-30MB but as we start loading the images repeatedly and disposing this ends up growing to the Gigabyte range.  So, the question is how can we stop this memory leak from occurring? Basically we are executing the following code and observing an increase in our app's memory usage footprint: NSImage *image = [[NSImage alloc] initWithContentsOfFile:filepath]; [image release];
0
0
550
Mar ’22