I can't understand why there is a problem with sqlite3. Sqlite runs on android and iOS devices and they are all ARM processors. There a build for it done a month ago.
I'm still bemused how you have a working build for ARM. You might not be running Electron for ARM - look and see if LSRequiresNativeExecution is false in the plist file. In which case it's doing a binary translation using Rosetta2.
I don't know which plist file you are talking about, but when checking in Joplin.app/Content/Info.plist I do not find any LSRequiresNativeExecution key.
As I found they are mutlitple plist files in the application directory, I used a grep command and found nothing. (command I used : grep -R -i LSRequiresNativeExecution *)
Moreover, in the Activity monitor when I check for type it says "Apple" on every process as you can see here :
So I just tried to build v2.7.13 and I ran into the exact same errors as @davack above when using npm run dist or yarn run dist.
Running npx electron-builder is successful and gives me a working executable but in that case yarn run electronRebuild (electron-rebuild) is not executed. This is also my first attempt of building an electron app so I'm not sure what the consequences of omitting the electron-rebuild command are but the app appears to be working just fine.
After doing some digging, the openssl_flips error seems to be related to the electron-rebuild version. Apparently this issue should be fixed in version 3.2.5 but I'm running v3.2.5 and still getting this same error. From my understanding the sqlite3 error might not be a separate error but might be caused by the openssl_flips error.
Strange : following the instructions given above, I could build v.2.7.13 for M1 without difficulty. However, when trying to do the same with v2.7.15, I get the following error when running npx electron-builder :
• electron-builder version=22.14.10 os=21.4.0
• loaded configuration file=package.json ("build" field)
• electron-rebuild not required if you use electron-builder, please consider to remove excess dependency from devDependencies
To ensure your native dependencies are always matched electron version, simply add script `"postinstall": "electron-builder install-app-deps" to your `package.json`
• writing effective config file=dist/builder-effective-config.yaml
• skipped dependencies rebuild reason=npmRebuild is set to false
• packaging platform=darwin arch=arm64 electron=14.1.0 appOutDir=dist/mac-arm64
• skipped macOS application code signing reason=cannot find valid "Developer ID Application" identity or custom non-Apple code signing certificate, see https://electron.build/code-signing allIdentities= 0 identities found
Valid identities only
0 valid identities found
Checking if notarization should be done...
Either not running in CI or not processing a desktop app tag - skipping notarization. process.env.IS_CONTINUOUS_INTEGRATION = undefined; process.env.GIT_TAG_NAME = undefined
• building target=macOS zip arch=arm64 file=dist/Joplin-2.7.15-arm64-mac.zip
• building target=DMG arch=arm64 file=dist/Joplin-2.7.15-arm64.dmg
• Detected arm64 process, HFS+ is unavailable. Creating dmg with APFS - supports Mac OSX 10.12+
• building block map blockMapFile=dist/Joplin-2.7.15-arm64-mac.zip.blockmap
⨯ Exit code: ENOENT. spawn /usr/bin/python ENOENT failedTask=build stackTrace=Error: Exit code: ENOENT. spawn /usr/bin/python ENOENT
at /Users/rafjaf/Downloads/joplin 09-44-14-839/packages/app-desktop/node_modules/builder-util/src/util.ts:133:18
at exithandler (node:child_process:406:5)
at ChildProcess.errorhandler (node:child_process:418:5)
at ChildProcess.emit (node:events:527:28)
at Process.ChildProcess._handle.onexit (node:internal/child_process:289:12)
at onErrorNT (node:internal/child_process:476:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
Would anyone have a clue ?
I take this opportunity to insist that a M1 build represents a true added value : Joplin is much snappier than when running it on Rosetta.
I just found Joplin today and happen to have a Mac with the M1, so I found this thread while hunting for an ARM build and decided to give things a go. I had failures and then a success, details below.
I checked out tag v2.7.15. Running Node 17 (following brew install node instructions from Shamp0o above) I ran into the openssl_fips and sqllite errors encountered by davack. I perused the web and found a few Github projects encountering this issue when using Node 17, so I downgraded to Node 16 (using brew install node@16 and following the brew hints to add node 16 to my PATH), cleared my node_modules, ran the Build instructions from Shamp0o again, and had immediate success. Looking at the Joplin interface for the first time right now!
Could be an issue in Node 17, or maybe a dependency that would need an update for compatibility with Apple Silicon. Either way I jumped right into the deep end on this one and I'm super excited to give the app a shot now.
Note - as a new user I can't mention other users, apologies. Hope my info is helpful, and I'll go ahead and put my vote in for official Apple Silicon support!
Unless I am mistaken, the file you are referring to, available on Joplin website for download, is the Intel version, not the Apple Silicon. It works thanks to Rosetta but is (much) slower than an Apple Silicon build.
I finally understood why it was not working for me even with node 16. As it appears from the error message posted above, npx electron-builder could not call /usr/bin/python... because in the latest versions of Mac OS, Python 2 is not installed anymore by default (and cannot be installed in this directory without disabling some system-wide protection). Therefore, after installing Python 2, I had to modify joplin/packages/app-desktop/node_modules/dmg-builder/out/dmg.js where the path to usr/bin/python is for some unknown reason hard-coded. I finally resolved to write the following script to automate the process next time (and hopefully help other persons confronted with the same difficulties) :
if [ -z "$1" ]; then
echo "$0 [version]"
echo "Builds Joplin [version] in ARM64"
echo "Before running for the first time, you should install dependancies by running"
echo "brew install node node@16 yarn cocoapods vips jq jo macos-trash"
if [ ! -e "/usr/bin/python" ]; then
echo "You should also install Python2 from https://www.python.org/downloads/release/python-2718/"
# Changing path to force the use of Node 16
echo "PATH: $PATH"
# Cloning the requested version of Joplin from Github
git clone --depth 1 --branch "v$1" https://github.com/laurent22/joplin.git
# Modifying the target for the build (Apple Silicon instead of Intel)
VALUE=$(jo target=default "arch=arm64")
jq ".build.mac.target=$VALUE" packages/app-desktop/package.json > $TMP
mv $TMP packages/app-desktop/package.json
# Downloading and building dependancies - takes about one hour on my Mac
# If Python 2 is not installed by default, change the path which is
# hard-coded in the build files with the actual path to Python 2
# (obviously won't work if Python 2 is not installed)
if [ ! -e "/usr/bin/python" ]; then
sed -i '' "s|/usr/bin/python|$(which python2)|" node_modules/dmg-builder/out/dmg.js
# Let's finally build Joplin!
# Joplin.app will be copied to the root of the Download folder
cp -R dist/mac-arm64/Joplin.app ~/Downloads
# Remove the files downloaded from Github if all went well
if [[ $EXIT -eq 0 ]]; then
# Make a beep to signal it's over
I had tried something similar, but it didn't help for me because the Python script on which npx electron-builder stumbled was written for Python 2, not Python 3 (some dependencies did not work with a newer version of Python). However, if it works for you, good to know!
In case it's helpful to anyone, here is how I got Joplin running as a native Apple Silicon app on a 2020 MacBook Air (Apple Silicon M1, MacOS Monterey 12.3.1). I haven't noticed any problems so far in limited testing, but I make no warranties about the integrity of the binary below or what results you may encounter. It's working for me, but YMMV.
I downloaded the prebuilt Apple Silicon binary from github .com/noah-nash/joplin-arm64-darwin-guide/releases. (Notes from the person who kindly created that binary and documented the process are in this blog post: noahnash .net/blog/joplin-apple-silicon/ .) Note: the system is not allowing me to include links, so you'll need to remove an extraneous space from each of those links.
In terminal I ran the following command:
xattr -d com.apple.quarantine /Applications/Joplin.app
(Without this step, the application could not be launched because it was unsigned and produced an error stating that the the application was "damaged.")
I then launched Joplin with no problems. (I believe the very first time I launched the application I control-clicked Joplin and selected "open" from the resulting contextual menu.)
I followed these instructions and am running arm64 Joplin on an M1 Max computer with webdav sync. It is much more responsive than the emulated official x86 build. I especially notice that there is no longer a delay when switching between notebooks, something that had bothered me before. I didn't need to re-setup the program at all; all settings were retained.
I would encourage other apple arm64 users to try this. I hope it becomes an official build eventually.
Working for me, too - I use Dropbox for sync, FWIW. Looks slightly nicer, I think something in the Electron update maybe? at least the sync icon / bar is now green which it was not before. Love it, thanks to the folks that made this build / got things working. Joplin was the major app that was still running on Rosetta / Intel emulation, this should improve performance and battery life for me.
I reported an issue a couple of weeks ago that I couldn't get the Joplin CLI to install on M1, also. Not sure how widely-used the CLI is, though.
I'm also looking forward to an official m1 version. Unfortunately the intel version really works badly, despite what a lot of people are saying. It's slow to respond, it takes many seconds to start and sometimes to takes a few seconds just to switch between notes.
At this point this is the only app I'm using which doesn't support m1. Nextcloud has support for it, tunnelblick, element, discord, signal, dbeaver, even draw io has support for it.