Replacing binary within app (in-situ upgrade) without breaking signing?

Question

Created Apr ’25

Replies 3

Boosts 0

Participants 3

Yes, this is very likely the completely wrong way to do things but I would like to ask regardless.

Currently with windows/linux I can perform an in-situ upgrade of an application by performing a download of the binary 'foo' and then doing a rename-and-replace and subsequently requesting the licencee to restart the program and all is good.

With macOS, as the binary is within the foo.app ( Contents/macOS/foo ) I imagine I cannot perform a similar operation without breaking the signing of the foo.app itself?

....or, can I individually sign the binary foo for macOS and perform the same type of operation?

Download new foo as foo.new
rename current foo.app/Content/macOS/foo -> foo.old
rename foo.new -> foo
Restart application

Again, I know this is very likely an un-macOS way of performing the task but as you can imagine with supporting cross-platform development it's usually easier to maintain a consistent method even if it's "not ideal".

Boost

Answer 1

Etresoft OP

Apr ’25

Accepted Answer

There is no meaningful concept of "the binary". The entire app bundle is signed. If you change any part of the app bundle, you must also replace the signature with a valid one for the new bundle.

Replacing an entire app is a bit tricky as there are OS-level complications. The recommendations I've seen here on the forums are to duplicate the existing app bundle, swap out the parts, then move the new app bundle into place.

But that's really a lot of pointless work. Just post a new app bundle and let the user replace the old one with the new one.

1

Answer 2

inflex OP

Apr ’25

Thank you Etresoft for taking the time to reply; at least it saves me time in terms of not trying to chase down a non-existent solution.

0

Answer 3

DTS Engineer OP

Apple

Apr ’25

Etresoft’s answer is spot on, but I wanted to expand on this point:

Just post a new app bundle and let the user replace the old one with the new one.

That’s a good option for standard apps. There are other good options that might be of interest to you:

If you put your app on the Mac App Store, the system takes care of all of this for you.
There are third-party update libraries, most notably Sparkle.
There are circumstances where it makes sense to do this yourself. Getting that right is tricky [1].

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] There are lots of potential pitfalls here:

Privilege escalation — See BSD Privilege Escalation on macOS.
Don’t overwrite Mach-O images — See Updating Mac Software.
Beware app bundle protection — See the link in Trusted Execution Resources, and my thoughts on it here.

0