Thanks for the shout-out! Credit for the intial development of this mechanism for Octave.app goes to @schoeps, though: he wrote the whole thing, I just took over maintenance and did some refinements.

This sounds like a promising approach. Let me know if there are tweaks I can do to Octave.app's octave-app-bundler or createdmg code to make it reusable for other applications like your OpenFOAM here.

Note that I'm thinking of migrating Octave.app from Homebrew to MacPorts for this mechanism. Homebrew only supports the latest 3 versions of macOS, and I want to have Octave.app continue to support macOS versions back to at least 10.14 Mojave. Partly because I use 10.14 myself due to being an Aperture and iTunes user, and partly because Octave.app is targeted at students and academics, and they seem to tend to use older macOS versions. I don't know if OpenFOAM has a similar userbase. Also Homebrew does not officially support installing to alternate prefix locations (like you need to do for this app bundler approach), and many of its "bottle" binaries are not relocatable, so you end up doing a build from source for lots of big packages, which will affect your CI run time limit here. I don't know how relocatable MacPorts are compared to Homebrew, but their binary system seems more amenable to users or extenders setting up their own binary build farm, so I think it would be feasible to have Octave.app do its own MacPorts dependencies builds to avoid having to build from source each time you build Octave.app, whereas it seems pretty difficult to set up one's own custom Homebrew bottle distribution. This migration to MacPorts would be a big project, so it's not happening any time soon.

Thank you for chiming in! And acknowledgements to @schoeps too in that case.

These alternative standalone builds are still in an early stage (I'm dog-fooding them right now), so for now I'm happy with the current scheme. Although, if this works out, I can see the point of having a generic dependency bundler, that takes a Brewfile (assuming Homebrew—or a similar list of requirements for a different "backend") and a directory (custom prefix), and takes care of installing the required dependencies there leaving as small a footprint as possible. Of course it could do more than that: caching builds/making and managing bottles for a custom prefix could potentially save a lot of compilation time, as you mention; and it could even perform some kind of version management. It'd take a bunch of development work though, but I see the point of it and there have to be other projects that could benefit too from something like that.

As for Homebrew vs. MacPorts and supporting older macOS releases, I'll have to stick with Homebrew at least for now, both for compatibility with the regular builds that are dependent Homebrew, plus the fact the app is currently built on GitHub Actions (Intel builds) and locally (Apple silicon), which already limits how far back I can go in terms of macOS versions. I do expect our apps to have similar userbases—although it has surprised me to see a lot of downloads for the Apple silicon variants recently (currently outnumbering Intel 2:1), but I don't really draw any conclusions from just that. Still, I'm curious: where do you run the Octave.app bundler script when making the releases? (I guess you can do it locally on your Mojave Mac). As it stands, supporting old versions of macOS with this app would imply more than just having compatible dependencies, so sourcing the dependencies from MacPorts might make sense but is not something I'd need for this project right now. I still think it'd be a good idea to try anything that might improve compatibility and/or reduce compile times for dependencies for use cases like ours. From my experience using MacPorts a few years back, I remember that it used to build a lot of stuff from source even on a default install (but that might have changed in the last few years). I did not attempt a relocated install with MacPorts.

All totally reasonable.

a lot of downloads for the Apple silicon variants recently (currently outnumbering Intel 2:1)

Huh! That's a lot more than I would have expected. But I agree: it's a simple data point to draw much of a conclusion on.

I remember that it used to build a lot of stuff from source even on a default install

This is my experience too. I'm running a default install of MacPorts on some of my Macs, and it builds a lot more stuff from source than Homebrew does. I'm just hoping that its greater customizability lets me put some work in to supporting my own binaries for custom builds and alternate install locations.