It is signed, checked by Apple, and installed from a private page inside AgentUX. It is not on the Mac App Store. For a tool a few people use, a store listing is more work than it is worth.

The funny part is the order. Safari is finished and installed, and Chrome is still the one waiting on a store listing.

None of these were hard. They were just invisible.

• I turned off code signing to build faster. The build worked, and Safari simply never showed the extension. No error, no warning, nothing to search for.
• A wrong developer ID sat in the project for two weeks. Xcode signs with whatever certificate it can find, so everything looked fine the whole time.
• Safari has no way for code to open the extension window. Chrome does. So instead of fighting it, saved images go into a queue and the toolbar icon shows a small badge.

The extension itself is the same for both browsers. Same code that watches the page, same code that saves the image, same settings file.

Safari needs one small difference in how that code is packaged, so there is a second build step for it. That part was easy.

The part I did not expect: a Safari extension cannot just be code. It has to live inside a real Mac app. Apple gives you a tool that builds that app for you.

The usual advice is to run that tool again and copy your files into it after every change. We tried it and threw it away. Instead we saved the Mac app once and pointed it at the build folder, so now it is build, open, done.

The fastest way to save a screenshot on a desktop is a right click. No downloading it, no finding it again, no uploading it. We already had that in Chrome.

But our team works on Macs, and on Macs people open Safari. So the best way in only worked for half of us. That was the whole reason.

It was planned from the beginning. The first line of the Chrome extension picked a library specifically to keep the Safari version small later.