Posts

Post marked as solved
2 Replies
334 Views
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?
Posted Last updated
.
Post not yet marked as solved
2 Replies
369 Views
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!
Posted Last updated
.
Post not yet marked as solved
1 Replies
352 Views
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!
Posted Last updated
.
Post marked as solved
2 Replies
519 Views
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
Posted Last updated
.