the injected code remains in Javascript.You might be able to get away with embedding the old JS code inside WKWebview instances from the WKWebKit framework, but that is very hacky and depends on the JS code’s complexity. the “global” or “background” part of the extension generally must be written in native code (Objective-C or Swift, instead of Javascript).Safari is using its own weird and different extension model for its new Safari App Extension system where: However, while all other browsers have moved to support the growing WebExtensions standard, making browser extensions easy to generate across browser platforms.
Like Google Chrome, Mozilla Firefox, and Microsoft Edge, old style extensions have been deactivated (with a scary and very disingenuous warning message that legacy extensions are “unsafe”). With the release of Safari 12 and macOS Mojave, Safari has taken a separate path from every other browser in terms of extension support, by creating a new “Safari app extension” model and deprecating old Javascript-based extensions. Using the webExtension standard would make everything much easier to maintain, and it is unclear for how long Apple would maintain the app extension model now that webExtensions exist. In any case, if you can afford to target Safari 14 only, I would hold off on making new App Extensions. The native app extension appears to still be around, but I’m not clear what role it plays right now. But hopefully the new API is standard and more JS-focused than this current hybrid system.
I have not had a chance to play with the new API. That is definitely progress in terms of documentation writing. They even have a listing of what the boilerplate files do, as I had below for App Extensions. There appears to be a porting utility for converting extensions from other browsers. These new style Web Extensions appear to follow the same API standard for Chrome and Firefox extensions. Apple’s Safari Web Extensions documentation now available, along with an associated WWDC session.
0 kommentar(er)
