I have a Qt desktop app that I was shipping to users as a dmg on macOS. But now I'll need to kind of rebrand the app to different users, that rebranding involves changing the name and the icon of the app
I'm not sure how feasible that is on macOS but here's what I'm thinking: First I'll include all apps for all brands inside the app resources, and instead of shipping the app directly, I will ship and installer (either .pkg or a custom made installer app) that will be responsible for downloading the main app and also setting some environmental variables somewhere so that I can choose the icon from the resources based on the env var values. And then either change the app icon and name from the installer itself, or implement something inside the app that makes it change the icon and name on launch (both icon in finder and in dock) but maybe one of those methods (or both) will break the codesign/notarization of the app so I want to avoid that too
I'm not sure if someone has done this before or how feasible such scenario is. Is what I'm thinking valid? or is there a whole other way possibly easier than this to go about implementing such feature?
The purpose of this is that I don't want to have to create multiple releases for multiple brands when they're all the same application with different icons/names, and also when releasing an update it will be just one update for all brands
Thank you in advance and feel free to ask any further questions for clarification
This is is going to be tricky. An app’s icon is part of its bundle, and thus modify the icon will break the seal on the code signature. You don’t want to leave the user with an app with a broken code signature because sooner or later Gatekeeper look at the app, notice the broken signature, and kvetch.
Now, what you could do is something like:
- Build, sign, and notarise all the variants of your app.
- From those variants, construct an installer that only contain one primary variant of your app and the diffs for all the other variants.
- Have that installer install the primary and then apply the relevants diffs.
The end result is an app that’s correctly signed and notarised, and thus unlikely to hit notary problems.
However, doing this is quite a bit of work. The key problems is that critical parts of the code signature are stored within the app’s main executable Mach-O image. If you store the diffs as a list of files, you’ll need N copies of the main executable, which presumably is quite large.
There are ways you might get around this:
- Support intra-file diffs.
- Move the bulk of your main executable to a dynamic library, leaving the main executable as just a stub that loads and and calls that library.
However, this is a bunch of extra work, and it’s questionable whether it’s less work that just shipping N installer packages. Building a workflow that automates the process of customising, signing, packaging, and notarising N apps is pretty straightforward.
ps If you end up writing code that modifies Mach-O images, watch out for the issue described in Updating Mac Software.
Also, avoid modifying any app that the user has previously run. If you’re updating a live app, make a copy of it and then modify the copy, using APFS clone to minimise the disk space impact. I’ve talked about this idea a few times here on the forums, including here and here.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"