User Profile

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?

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?

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];

We have a question with respect to the Live Text feature shown in the Keynote. Is there an API or Framework available for this? Also, if there is a Framework/API available can we leverage it on macOS?

We have a set of questions about Notarization. We create plug-ins for various 3rd party software. Our plug-ins operate under the 3rd party software. So for example Photoshop (our is not a typical Mac App store app - we make these also so we know how Mac App store code-signing etc works).Our infrasturcture is something like "plug-ins" for each version of Photoshop we support (which gets installed in the Photoshop plug-ins folder). Then component libraries that are installed in Library/Application Support/OurProduct folder and the Applications folder (we also create a folder in the Applications folder and stick in various other parts and libraries, readme, userguide etc). So its basically a set of libraries really thats all over.Then we take all of those components and we package (using Package Maker under 10.11.6) it and create flat package installers (which contain installer plug-ins at the end) which we deliver to our end user. The final installer are signed using th Apple 3rd party install certificate.None of these parts are code-signed as we never had to.So, we have multiple questions here. Do we have i to codesign each library/plug/bundle/component included in the pkg file? When we submit for notarization, do we just submit the final pkg (the pkg can contain other pkg files) file. Now when the Photoshop plug-in access our other libraries/bundles (they are loaded dynamically) will it cause loading/binding/excution problems?