I have a legacy OpenGL fixed-pipeline app which has been ported from Windows (32-bit) to MacOS 64-bit. The problem is that if I have a scene with a non-positional light, everything works great. If I add a positional spotlight the two lights interact, and I get incorrect results. This problem does not occur on X86_64 Macs. It does occur when the app is X86_64 running under Rosetta or native ARM64. So it's either an Apple Silicon OpenGL driver behaviour my code is triggering, or something with the on-chip Apple Silicon graphics. Here is the "normal" case: the spotlight is to the right: Here, I have moved the spotlight down (Y = 1). Notice the black areas on the cube. That's incorrect. Now, I turn off the spotlight by commenting out the "makeALight" call for the spotlight (light 6). Now, the cube is evenly lit. Here is the test code I use to generate the lights. You will need to install glfw with brew to build it. main.cpp

After creating an install with pkgbuild/productbuild and submitting for TestFlight, one of the errors I got was: 2024-03-03 16:51:36.715 *** Error: Asset validation failed The product archive is invalid. The installer package may not include install scripts. (ID: 78500c2e-db43-4bd3-8e23-215b2fc30e15) (90254) { NSLocalizedDescription = "Asset validation failed"; NSLocalizedFailureReason = "The product archive is invalid. The installer package may not include install scripts. (ID: 78500c2e-db43-4bd3-8e23-215b2fc30e15)"; NSUnderlyingError = "Error Domain=IrisAPI Code=-19241 \"Asset validation failed\" UserInfo={status=409, detail=The product archive is invalid. The installer package may not include install scripts., id=78500c2e-db43-4bd3-8e23-215b2fc30e15, code=STATE_ERROR.VALIDATION_ERROR.90254, title=Asset validation failed, NSLocalizedFailureReason=The product archive is invalid. The installer package may not include install scripts., NSLocalizedDescription=Asset validation failed}"; "iris-code" = "STATE_ERROR.VALIDATION_ERROR.90254"; } That seems pretty explicit. Are install scripts like postinstall no longer allowed?

We have an enormous legacy based application which has been ported from Windows. The build system is make and has literally hundreds of .cpp, .c, .h, .m, and .mm files. I've gotten it successfully running on MacOSX and managed to build nice installation packages using the "Packages" package which have been sucessfully signed, notarized and stapled, and install nicely on "clean" Machines. The .app/bundle format has been lovingly laid out to match the app. Now, I'd like to use Testflight to deliver the app, and eventually the Mac App Store. In my first attempt, I tried xcrun altool --validate-app .. to validate the Packages built app. It, not surprisingly, failed spectacularly because I guess it hasn't kept up with however packages need to be build to pass --validate. (It's an amazing tool though) So, I decided to use pkgbuild and productbuild to build the package: pkgbuild --root App_name.app --identifier com.mycompany.myapp --sign "Developer ID Installer: ...." --scripts Scripts --install-location "/Applications/MyApp.app" Distribution.pkg productbuild --synthesize --package Distribution.pkg Distribution.xml productbuild --distribution Distribution.xml --sign "Developer ID Installer..." --package-path . MyApp.productbuild.pkg xcrun altool --validate-app -f MyApp.productbuild.pkg -u username --type macos This fails with: { NSLocalizedDescription = "Could not find the main bundle or the Info.plist is missing a CFBundleIdentifier in \U2018MyApp.productbuild.pkg\U2019."; NSLocalizedFailureReason = "Unable to validate your application."; } I confirmed I have an info.plist and if contains a valid CFBundleIdentifier, and I extracted the package using Pacifist and confirmed it's there, too. I'm at a loss. Converting the package to XCode would be a monumental effort right now, and I'd really like to avoid it. Is there something I'm missing, or should this work? Thanks!

I have a sandboxed app in /Applications. I'm attempting to shoot a problem with LLDB, so I cd to /Applications/app-name/Contents/MacOS and do lldb programname. However, once I fire it off with "r" it dies instantly with: error: process exited with status -1 (lost connection) Should this work? Should I try signing the lldb executable? Thanks!

Hi, I've an OSX app packages up outside of XCode (because it's based on a legacy cross-platform build system). The layout looks like this: App App/Contents <- info.plist is here App/Contents/Frameworks <- Dylibs go here App/Contents/MacOS <- Main executable and bash startup script go here App/Contents/Resources <- Non-executable resources. There are no helper apps, etc that I know of. info.plist, the Frameworks, Main Executable and App are all signed. The Main Executable includes entitlements with the sandbox entitlements. On startup, we crash in the usual Sandbox place: 0 libsystem_secinit.dylib 0x7ff811fcc2a5 _libsecinit_appsandbox.cold.9 + 49 1 libsystem_secinit.dylib 0x7ff811fcb636 _libsecinit_appsandbox + 1749 2 libsystem_trace.dylib 0x7ff8044029e9 _os_activity_initiate_impl + 50 3 libsystem_secinit.dylib 0x7ff811fcaf20 _libsecinit_initializer + 67 4 libSystem.B.dylib 0x7ff811fe08a1 libSystem_initializer + 292 5 dyld 0x20905939f invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const + 185 (Even though I'm not signing the bash startup script, which invokes the main executable, it's still getting signed and has entitlements. And I'm not using --deep. I've tried setting com.apple.security.inherit - that didn't work. I've tried explicitly signing the bash startup script - that didn't work. It fails not matter how I start the app - by clicking on it, command line, just launching the main executable via the command line, and of course using LLDB. Any ideas? Crash report enclosed. ProgUhost-2024-02-17-171425.ips