jcsteh
Add Native Mac Installer
This commit adds a new experimental native installer for OSARA on Mac (#1291).
The native installer for Mac can be built with scons mac-native-installer
The generated app bundle contains the installer executable, OSARA shared library, localization resources, and OSARA keymap. When built locally, the app bundle is ad-hoc (self) signed. When built via CI (Github Actions), official signing and notarization is supported. See doc/installer/mac/README.md for more details.
I considered a couple options for building the installer, but settled on the admittedly more complex choice of building it as a native c++ app and using WDL/SWELL for the GUI. While more complex, it provides some interesting advantages and flexibility:
- Full localization support
- Code could easily be made cross-platform to work on Windows as well, so we could have one unified installer
- I wanted to experiment with more advanced features such as keymap merging, with the flexibility to build them as Reaper OSARA actions/menu options or installer features.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hi,
Perhaps I misunderstood, but on my MacBook Pro running macOS 15.5, I still had to go through the double privacy settings process to get the installer to run.
However, After that, it appeared to run and install without issues.
HTH Tim
On 28 Jul 2025, at 12:16, github-actions[bot] @.***> wrote:
github-actions[bot] left a comment (jcsteh/osara#1295) https://github.com/jcsteh/osara/pull/1295#issuecomment-3125030789 Build 197 succeeded! https://github.com/jcsteh/osara/actions/runs/16558397991 Download for Windows https://github.com/jcsteh/osara/actions/runs/16558397991/artifacts/3625657338 Download for Mac https://github.com/jcsteh/osara/actions/runs/16558397991/artifacts/3625652391 — Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/pull/1295#issuecomment-3125030789, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGNKY27GU766YKDCMWJSNMD3KWBXRAVCNFSM6AAAAACCPTAPHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMRVGAZTANZYHE. You are receiving this because you are subscribed to this thread.
three things:
- By default, you still get the .dmg based classic installer so as to let us test the new installer without disturbing releases. The only way to get the new installer is to build it manually. I supposed we could add a workflow to build the unsigned Mac native installer as well, but right now signing is gated on running builds in CI, and I didn't want to break the release process.
- If you build locally without an Apple developer account, you'll get a self-signed app bundle, which should run fine on your own machine, but will make gatekeeper complain if you try to run it on someone else's machine.
- Once we've sorted out an apple developer account for the OSARA team, we can flip a switch in the workflows, and the Git Actions will build and sign the new installer.
On Jul 27, 2025, at 10:52 PM, Tim Noonan @.***> wrote:
TimNoonanVoice left a comment (jcsteh/osara#1295) https://github.com/jcsteh/osara/pull/1295#issuecomment-3125283807Hi,
Perhaps I misunderstood, but on my MacBook Pro running macOS 15.5, I still had to go through the double privacy settings process to get the installer to run.
However, After that, it appeared to run and install without issues.
HTH Tim
On 28 Jul 2025, at 12:16, github-actions[bot] @.***> wrote:
github-actions[bot] left a comment (jcsteh/osara#1295) https://github.com/jcsteh/osara/pull/1295#issuecomment-3125030789 Build 197 succeeded! https://github.com/jcsteh/osara/actions/runs/16558397991 Download for Windows https://github.com/jcsteh/osara/actions/runs/16558397991/artifacts/3625657338 Download for Mac https://github.com/jcsteh/osara/actions/runs/16558397991/artifacts/3625652391 — Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/pull/1295#issuecomment-3125030789, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGNKY27GU766YKDCMWJSNMD3KWBXRAVCNFSM6AAAAACCPTAPHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMRVGAZTANZYHE. You are receiving this because you are subscribed to this thread.
— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/pull/1295#issuecomment-3125283807, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQFHIIELGSPBZ7VPREHWO33KWM7JAVCNFSM6AAAAACCPTAPHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMRVGI4DGOBQG4. You are receiving this because you authored the thread.
This latest revision is getting closer. Moved the build system entirely to scons and removed the old installer bild files. New Mac installer builds by default. Signing and notarization should only happen on publish, not pull requests. Connected up my Apple developer account on my fork and debugging the signing and notarization process now on my master branch-- we should have signed builds over there shortly.
Added an uninstall process as well.
Shuffled code around such that the cross-platform bits are in .cpp files, and Mac specific stuff is in .mm files, hopefully got all that moved.
I started at looking at Windows possibilities for this code, but we don't really need a new installer on Windows, so that's probably a low priority. If we get cool stuff like keymap merging working in this code base, it might be worth looking at. Also might be worth looking at if we can get localization working in the installer.
Hope it is ok that a non-developer chime in here:
Is a zip simpler than a dmg for Mac users? I always thought dmg was the way things were done for software distribution on Mac (other than pkg). Can a user just open the zip and open the app from inside it (i.e. MacOS presumably extracts it somewhere temporary) or does the user have to extract it first?
I would probably say that zip is easier than diskimages. Diskimages are used quite often, but I see more developers make zip-files that the user just need to extract before the app-file is placed inside the Applications directory. No need for temp locations, just open the zip-file, and it automatically gets extracted at the current location.
I will be happy to test any build of this, if you need a few testers. I can test on both older Macs and a new one.
Sendt fra min Macbook Pro via Apple mail
Den 28. jul. 2025 kl. 12.16 skrev James Teh @.***>:
@jcsteh requested changes on this pull request.
Thanks very much for the huge amount of work you've put into this.
A few high level questions/thoughts before getting into the fine details of the actual code:
Code could easily be made cross-platform to work on Windows as well, so we could have one unified installer
One challenge on Windows is that there is no such thing as an app bundle. We could just zip it, but some users aren't going to be comfortable with that, so it needs to be self-extracting. There are undoubtedly tools that would help with that, though. There's also the uninstaller, which is a bit trickier, but maybe we just get rid of that; we've never had it on Mac anyway.
In .github/workflows/build.yml https://github.com/jcsteh/osara/pull/1295#discussion_r2235648638:
xcrun notarytool submit installer/osara_temp.zip \
-
--apple-id "$APPLE_ID" \ -
--password "$APPLE_ID_PASSWORD" \ -
--team-id "$TEAM_ID" \ -
--wait -
# Staple notarization to app -
echo "Stapling notarization..." -
xcrun stapler staple installer/build/OSARAInstaller.app -
# Verify stapling -
xcrun stapler validate installer/build/OSARAInstaller.app -
# Create final signed and notarized zip -
cd installer/build -
zip -r "../osara_${{ env.version }}.zip" "OSARAInstaller.app"
Is a zip simpler than a dmg for Mac users? I always thought dmg was the way things were done for software distribution on Mac (other than pkg). Can a user just open the zip and open the app from inside it (i.e. MacOS presumably extracts it somewhere temporary) or does the user have to extract it first? In .github/workflows/build.yml https://github.com/jcsteh/osara/pull/1295#discussion_r2235663630:
@@ -81,6 +89,62 @@ jobs: certificate-profile-name: ${{ vars.AZURE_SIGNING_CERT_NAME }} files-folder: ${{ github.workspace }}\installer files-folder-filter: exe
-
- name: sign Mac -
if: ${{ github.event_name == 'push' && matrix.os == 'macos-latest' && env.USE_MAC_NATIVE_INSTALLER == 'true' }}
For pull request builds, we can't (and shouldn't) sign or notarize. However, they should still use the same installer, so we'll need to have the installer uploaded as the pull request artifact.
In .github/workflows/build.yml https://github.com/jcsteh/osara/pull/1295#discussion_r2235688830:
@@ -13,6 +13,7 @@ env: publisher: James Teh VSCMD_SKIP_SENDTELEMETRY: 1 SCONS_CACHE_MSVC_CONFIG: 1
- USE_MAC_NATIVE_INSTALLER: false # Set to true when ready to use the native Mac installer with signing I appreciate the thought you've put into the migration path. However:
Waiting until we can sign and notarize before switching to the new installer means we're making two significant changes at once. We can't get wider testing of the new installer before we take the costly plunge to begin notarizing. I'd really prefer to separate those two changes. That also reduces the complexity here, because we don't need to maintain two installers. We'd just switch completely to the new installer, using this pull request to get the details right before we merge it. There's not a great deal of point in having the new installer in the code base if users aren't actively testing it, which they won't be if automated builds can only be generated once we can notarize. To that end, is there any reason we can't switch to the new installer first? Obviously, it will still throw up security warnings and barriers, but will they be any worse than the current situation? In installer/OSARAInstaller/Makefile https://github.com/jcsteh/osara/pull/1295#discussion_r2235695009:
@@ -0,0 +1,172 @@ +# Makefile for new OSARA Mac Installer Eventually, I'd like to get this into SCons instead of make so we aren't using two separate build systems. That will also be a prerequisite if we ever want to use this installer on Windows. However, I can take care of that in a follow-up; I realise SCons can be a bit tricky to get your head around.
In installer/OSARAInstaller/dialog_procs.mm https://github.com/jcsteh/osara/pull/1295#discussion_r2235714847:
@@ -0,0 +1,655 @@ +#include "installer_app.h" I realise this is a .mm file because it contains some Objective C for Mac specific things. However, this also contains code that is intended to be used on Windows in the future. I don't know if clang will even build a .mm file on Windows. Even if it does, it seems wrong to have pure C++ (from the perspective of Windows, since the Objective C code won't be included) in a .mm file.
Can we somehow split the Objective C specific bits into utility functions in a .mm file which we then call from a .cpp file? This would mean we'd only ever be compiling a .cpp on Windows.
In installer/OSARAInstaller/main.mm https://github.com/jcsteh/osara/pull/1295#discussion_r2235719744:
@@ -0,0 +1,97 @@ +#include "installer_app.h" Similar thing here regarding the .mm. That said, there are much larger chunks of OS specific code here, so perhaps these should just be split into main.mm and winMain.cpp or similar.
— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/pull/1295#pullrequestreview-3061655627, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGGLXRVZ6FSXCCVYPINPYI33KXZ7BAVCNFSM6AAAAACCPTAPHKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTANRRGY2TKNRSG4. You are receiving this because you are subscribed to this thread.
Whew! Apple tools are a pain!
I've got fully signed and notarized Mac Installer builds coming out of the master branch on my fork. Here's a sample based on the current OSARA master branch.
https://github.com/mulcahy1000/osara/releases/download/snapshots/osara_2025.8.19.1832.3564a332.zip
Now that signing and notarization are working, we can play with the installer itself.
I'm not married to this code-- although I think it has some merit, since it would allow us to eventually add more complex tasks to the installation/uninstallation process (such as keymap merging and the like), and would potentially allow us to have one standard installation/uninstallation process for Windows and Mac. that's not super important at the moment, since we don't really need a new Windows installer.
As for packaging options, I think a .zip file is the best option. It seems to be what folks are using.
As for the installer itself, we could switch to a .pkg based installer, and use all the same signing and notarization logic-- that's what we had years ago, and we could probably resurrect or re-create that pretty easily. I suspect that gives us a bit less flexibility in controlling how the installer works, but maybe that's preferrable to the app approach.
On the keymap merging front, I had Cline write me a full Reaper keymap parser in c++ based on the specs at:
https://mespotin.uber.space/Ultraschall/Reaper-Filetype-Descriptions.html
I've reviewed most of it, and it looks pretty good and complete (unit tests included) :)
There's an open question as to whether comments are included in some of the older keymaps, which would be key to making the functionality user friendly. This is one of the reasons I leaned toward building this in SWELL-- we could easily move it from the installer to an OSARA command if older keymaps can't easily be merged. And it looks like when you're running in the context of Reaper, you can ask it for the friendly names of all the built-in actions, which would probably get us what we need for entries without comments.
Great work, tested and works beautifully, once notarisation has been added as well will be so nice. Thanks for all the work Mark.
On 19 Aug 2025, at 1:20 pm, github-actions[bot] @.***> wrote:
github-actions[bot] left a comment (jcsteh/osara#1295) https://github.com/jcsteh/osara/pull/1295#issuecomment-3199074562 Build 206 succeeded! https://github.com/jcsteh/osara/actions/runs/17058568281 Download for Windows https://github.com/jcsteh/osara/actions/runs/17058568281/artifacts/3794658977 Download for Mac https://github.com/jcsteh/osara/actions/runs/17058568281/artifacts/3794654457 — Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/pull/1295#issuecomment-3199074562, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHSPFC3RY5TZUPOSFQ33KKL3OKJYFAVCNFSM6AAAAACCPTAPHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOJZGA3TINJWGI. You are receiving this because you are subscribed to this thread.
I believe I've removed all the Windows-specific code.
Changed the bundle identifier to "co.osara.installer" (probably doesn't matter too much :)
Consolidated handling of the cancel button across dialogs since it's always the same.
Did some additional research on .pkg installers-- looks llike our previous findings are still valid-- difficult to install in users' home directories, and potentially not possible to install in arbitrary directories for portable installs.
So I think bundling the app bundle in a .zip file as we have currently is our best bet.
I played with a single screeen installer, and I personally didn't like it. Not sure how we'd get everything to visually fit either-- especially with the license agreement. Seems like we'd probably need at least a couple screens in any case -- a welcome screen, install/uninstall (perhaps with the license screen), and an installation options screen. Not sure it's worth moving code around. What do others think?
I wouldn't spend any more time exploring single screen. Getting notarization incorporated into the CI here is gonna make more of a difference to more users, IMO best to have you focusing on that.
Honestly, while I do think it's ultimately simpler for users, my main reason for suggesting single screen is that it dramatically simplifies the code. As it is, there are ~2000 lines of code here for me to review (and for us to maintain going forward), and a lot of that is boilerplate for managing multiple screens. That said, I acknowledge the work involved in rearranging this and the concerns about fitting everything on one screen, so I can live with it. It's going to take me some time to get to reviewing something this large, though.
FWIW, the license text box is scrollable, so it doesn't need to be massive. But even so, I can see how this would get visually cramped without making the dialog scrollable, which is a whole other can of worms that we haven't even solved for OSARA itself.
Btw, please don't take any of this as unappreciative of the work you've put into this. I'm just trying to ensure realistic expectations about review and maintenance going forward. I think what you've come up with is probably the best balance between pragmatism and technical constraints; at least, I can't come up with anything simpler either. :)
Btw, please don't take any of this as unappreciative of the work you've put into this. I'm just trying to ensure realistic expectations about review and maintenance going forward. I think what you've come up with is probably the best balance between pragmatism and technical constraints; at least, I can't come up with anything simpler either. :)
No worries at all, this wound up being a lot of code.
I've got signing and notarization working, so trying to figure out if there's a faster path to getting signing working with something closer to the current installer. But I don't know of a way to sign a script-- I think we'd have to compile it into something. Happy to explore that further.
BTW, as I iterate and fix things, do you prefer squashing into a single commit, or a series of commits on the pull request branch and then squash before merging.
Latest commits remove Windows code, modify the bundle ID, and remove the progress dialog (it's overkill and not really needed since installation is so fast).
Keep 'separate commits coming, request a review when you're ready, squash and merge to master.
With this, and if we encourage users to install SWS/S&M via ReaPack instead of the manual copy and paste, installation of all the REAPER accessibility bits would be much streamlined. The installer that was the script before is already an improvement, but this would be even better. Thanks for doing all the work!
Rebased on top of latest master branch. Anyone who wants to play with this can grab a copy from my repo, which signs builds.
https://mulcahy1000.github.io/osara/snapshots/