Why building Safari App Extensions is a nightmare in 2020
Safari App Extensions is the new way of Apple to develop Safari Extensions along with Cocoa Mac apps. Integrated into the App Extensions environment, it was a logical step to harmonize the ways to extend your Mac apps’ functionalities.
It came with a promising and innovative tech stack for a browser extension: a Swift/Javascript combination rather than a full Javascript experience.
With this in mind, I was pretty excited. I mean: develop for the web with Swift ? This is the best news since the release of Vapor !… Right ?
Or so I thought. I decided to give it a shot, and I discovered how unstable the development experience was.
Why though ? I’ll explain.
The Debugger kills your process abruptly
Yes, you heard me. While you run the “hello world” example that Xcode provides, after 1 or 3 minutes, Safari closes itself, and so does your extension.
You might think that’s a Safari crash, but that’s in fact a part of the dev process. From what I have seen, the Xcode debugger kills the browser if no interaction/messaging is found during a certain lapse of time.
So to avoid this, what you have to do is to write that code inside your injected script :
This will send a ping to the app every second, just like a keep-alive, begging the debugger not to kill your process. However, this should be done only while debugging and not for production code.
Also, under release configuration, this does not apply, and the Safari App Extension runs without killing the browser.
In addition, the docs do not mention this debugger behavior at any time. Well almost, as this archive paper proves that an App Extension can be killed anytime by the system if it takes long to load.
The extension sometimes fails to install to Safari
When you’re developing Safari App Extensions, you might run into that error in Xcode’s debug console :
Computing the code signing dictionary failed for extension with identifier com.developer.myapp
This might happen more often when your extension’s certificate is self-signed.
To avoid this, you have to:
- Close and quit all instances of Safari
- Click Product → Clean build folder
- Run your Cocoa Mac App first by changing the scheme in Xcode’s toolbar.
- Run the Safari Extension by changing the scheme in Xcode’s toolbar.
My theory is this happens because self-signed app certificates might expire sooner than Developer Program Certificates. And that’s why we have to rebuild the app almost every time we run the project: to renew the local certificate.
Recommended articles
Being totally honest, those frustrations were a bit legitimate.
I believe it is a common developer behavior to start digging into the code without really understanding how everything works.
Great programming guides from Apple explain the interactions between a Safari App Extension and the Containing App. Reading them toned down my anger and made me understand the overall functioning.
So, I highly recommend to read:
- App Extension Programming Guide: Understand How an App Extension Works : The guide that explains it all. The Why, the When and the How.
- App Extension Programming Guide: Creating an App Extension
- App Extension Programming Guide: Handling Common Scenarios
- Safari App Extensions | Apple Developer Documentation
- Building a Safari App Extension | Apple Developer Documentation
