Thanks for all your info. Enough to go back with specifics to the Electron-builder folks. I mean maybe most people aren't using native node modules like sqlite3, but that surprises me. Maybe they are just all distributing direct. Anyway, if I find a solution I'll add it to the thread in case other's have the same issue. Going native, I've thought of it. Maybe. Cheers,Steve

Thanks for the input. I edited my last message to fully break out the Frameworks directory, and I added the Libraries directory which only has a login helper which I assume is for apps that require login (mine doesn't). Well, this is shedding more light on the situation, including a possible catch-22. In your link to the Apple docs after listing the folders where code is expected it says:"putting code into other places will cause it to be sealed as data (resource) files. This causes this code to be sealed twice; once in the nested code, and once in the outer signature. This wastes both signing and verification time and storage space. Also, this can break the outer signature of apps that use their own update mechanisms to replace nested code. If this nested code is being treated as resources, the outer signature doesn't know that this nested content is actually code."But then it says:"Note that a location where code is expected to reside cannot generally contain directories full of nested code, because those directories tend to be interpreted as bundles. So this occasional practice is not recommended and not officially supported. If you do do this, do not use periods in the directory names. The code signing machinery interprets directories with periods in their names as code bundles and will reject them if they don't conform to the expected code bundle layout."So maybe it's a damned if you do damned if you don't situation. And that may explain why this issue doesn't seem to have been resolved by Electron-builder. It's open source, so run by voluteers doing it on their free time, and maybe they tried tacking this issue and gave up. Only guessing. That would be bad news for me cuz if they can't figure it out, I don't know how I would.

Thanks for the input. When you say "One way to simplify this would be to ensure that your app bundle has all of the files it needs, already unpacked." I probably should have shown the file structure because if I understand your statement correctly, the 3rd party binary files are already unpacked when the app bundle is built. Here's the structure below. The app.asar binary folder is where my app's code is and the app.asar.unpacked folder is where the signed 3rd-party binary files are.MyApp.app |- Contents |- _CodeSignature |- CodeResources (xml file with keys pointing to code signatures including sqlite3) |- Frameworks |- Electron Framework.framework |- MyApp Helper.app |- MyApp Helper (GPU).app |- MyApp Helper (Plugin).app |- MyApp Helper (Renderer).app |- Library |- LoginItems |- MyApp Login Helper.app |- MacOS |- MyApp (binary file, not sure what it does) |- embedded.provisionprofile |- Info.plist |- Resources |- app.asar (binary file containing app's code including node_modules) |- electron.asar (binary file containing Electron's code) |- MyApp.icns (App Icon file) |- app.asar.unpacked (unpacked node_module path to 3rd party library binary file) |- node_modules |- sqlite3 |- lib |-binding |- electron-v6.1-darwin-x64 |- node_sqlite3.nodeI don't know, I may be just not understanding something since this is my first Electron app but everything seems like it should be working.

Thanks for the input. Here's the entire error message:A JavaScript error occurred in the main process Uncaught Exception: Error: dlopen(/Applications/MyApp.app/Contents/Resources/app.asar.unpacked/node_modules/sqlite3/lib/binding/ electron-v6.1-darwin-x64/node_sqlite3.node, 1): no suitable image found. Did find: /Applications/MyApp.app/Contents/Resources/app.asar.unpacked/node_modules/sqlite3/lib/binding/ electron-v6.1-darwin-x64/node_sqlite3.node: stat() failed with errno=13 at process.func (electron/js2c/asar.js:138:31) at process.func [as dlopen] (electron/js2c/asar.js:138:31) at Object.Module_extensions..node (interval/modules/cjs/loader.js:828:18) at Object.func (electron/js2c/asar.js:138:31) at process.func [as .node] (electron/js2c/asar.js:148:18) at Module.load (internal/modules/cjs/loader.js:645:32) at Function.Module_load (internal/modules/cjs/loader.js:560:12) at Module.require (internal/modules/cjs/loader.js:685:19) at require (internal/modules/cjs/helpers.js:16:16) at Object. (/Applications/MyApp.app/Contents/Resources/app.asar/node_modules/sqlite3/lib/sqlite3.js:4:15)That last line references a function in the sqlite3 node module that calls the node_sqlite3.node binary file.Some further background: As part of the build process, the entire app is put into a binary file called app.asar so that users can't just read or mess with the source code. That includes any native dependencies/libraries such as sqlite3. Apple requires these libraries to be signed but Apple cannot verify the signing certificate if it is in the asar binary file and will throw the "Developer cannot be verified" error. I confirmed this by unpacking the binary asar file and verifying with codesign that the signing certificate is there. Per a comment in one of electron-builder's github issues pages this behaviour started with Catalina and the solution is to unpack all .node binary files outside the asar.app bundle (in a folder called app.asar.unpacked). Then Apple can confirm the signature. But there was no mention of this errno=13 problem.Does that shed more light on it? Looking at John's message I believe everything is self contained in the app so within the sandbox. I was thinking maybe moving the binaries to the separate folder is causing the issue, but it looks like it is going to the right path where the binary file is if I read it correctly.---------------------------------------------------------------------------------------------------------------------------------FEB 11, 2020 EDITIn case anyone encounters the same issue you can skip the discourse below. Here is the issue encountered and the fix.For some reason the unpacked executable files have their permissions/ownership changed when they are flattened into the .pkg file which is causing the error. I don't know why this happens but there is a fix:• Run the mas buildelectron-builder --mac• Keep the MyApp.app file that gets generated but delete the MyApp-1.0.0.pkg file.• Change the permissions to allow read and execute access to all directories and files in the app.asar.unpacked folder. From MyApp/dist/mas run:sudo chmod -R 755 MyApp.app/Contents/Resources/app.asar.unpacked• Then create a signed pkg file:npx electron-osx-flat "MyApp.app" --verbose

Thanks for the confirmation. After quite some digging I found out how to sign the dependency.(For anyone else encountering this issue I added "asarUnpack": ["**/*.node"] to the build > mac key in the package.json file which takes all .node binary files out of the asar package, otherwise even if it is signed Apple can't read the signature and will throw an error).So the signing part is taken care of, and the code signature error is gone but now something is happening that I don't know how to interpret.Quick background:A) Packaging Electron apps: Electron does not package apps for distribution directly. Instead they recommend a third party packaging utility called electron-builder. You add configuration to a package.json file to build for a target platform, in this case the Mac App Store, then run the build utility. It will return (1) an executable app for that configuration, and (2) the same app inside a .pkg file ready for submission to the Mac App Store for review. From my understanding the two apps are identical, but one happens to be wrapped in a pkg installation file.B) Incorporating Node packages (i.e., libraries) in an app: Electon is build on top of Node.js and Chromium, both of which are included in the app. If your app needs third-party Node.js packages (referred to as native dependencies) such as Sqlite3 to use sqlite database then they will be installed as binary executable files having a .node extension. Getting these signed was my original problem.To test my app I created a second "volume" on my Mac running on Catalina OS with no developer certificates so simulating some random user. Until now I have been getting the same results whether I execute the generated app or install it from the .pkg file. But in this case, if I launch the generated app it opens with no errors. But if I use the .pkg version to install it first then launch I now get this error:A JavaScript error occurred in the main process Uncaught Exception: Error: dlopen(/path/to/node_sqlite3.node, 1): no suitable image found. Did find: /path/to/node_sqlite3.node: stat() failed with errno=13So I am still having some issue with the third party node package/library. And it's not specific to Sqlite, I installed a different node package and got this same error only for that package.I don't know what errno 13 means. From search engines I found this unofficial explanation: "when stat() fails with errno=13, usually it's a permissions problem."So if that's true what would be causing it? I confirmed the binary is signed in both the generated app and the one installed from the .pkg file. In either case, if I run:codesign --display --verbose ./path/to/node_sqlite3.nodeI get:Executable=/path/to/node_sqlite3.node Identifier=node_sqlite3 Format=Mach-O thin (x86_64) CodeDirectory v=20200 size=15436 flags=0x0(none) hashes=475+5 location=embedded Signature size=4816 Signed Time=Jan 29, 2020 at 2:06:51 PM Info.plist=not bound TeamIdentifier=myID number Sealed Resources=none Internal requirements count=1 size=192Is it possible I am getting this error because I didn't install it from the Mac App Store and if I submitted the pkg file as is to Apple for review they would not get this error?Anyway, not sure what the problem is or how to proceed. Any help will be greaaatly appreciated. Thanks.

I'm using an Node.js package called SQLite3 to interact with the database. Part of it's process in writing to the database includes creating a temporary file in the same directory as the database file with the same name appended with -journal. I am not sure exactly how it works but my understanding is the temp file is a copy of the original database, and if there is a connection failure during the write it will just put the original version back in place. Without this you could end up with a corrupted database.