*This is part of a series I'm writing documenting my efforts to establish native messaging communication between my MarkDownload web extension and a native app. Go check out the [motivation](https://death.id.au/b4.0013) or my [previous efforts](https://death.id.au/b4.0014)*
Okay, so, where I left off last time was being able to communicate from the swift app → web extension (via a web view in the app) with no issues. However, communicating back to the app was a problem, in no small part because the web extension only ever sends messages back to an "app extension", which is sandboxed separately from the app itself. I set both targets to be part of the same app group, but still had troubles getting any sort of data through the App Defaults back to the app.
## Sending message from app extension → app (for real this time)
I was attempting to google my way through the issues I was having, when I discovered [this post](https://www.atomicbird.com/blog/sharing-with-app-extensions/) by [Tom Harrington](https://mastodon.social/@atomicbird), which among other things, suggested using `NSFileCoordinator` and `NSFilePresenter` to write to, read from, and get notified of changes to a file which lives in a folder shared within the app group. So what does this look like in the actual code? Something like this:
... not really much different from putting the data in the User Defaults, but I somehow feel better writing to a plain text file than some arbitrary data store (which turns out to be a .plist file in the shared folder, but I digress).
The differences show up mainly in the View Controller code, where I have to implement the `NSFilePresenter` protocol. This requires two new parameters: the url of the file I'm watching, and an operation queue. I'm still just getting my feet wet with swift, so I don't actually know anything about operation queues. I just copied some code I found online to simply use the `main` operation queue:
```swift
class ViewController: PlatformViewController, WKNavigationDelegate, WKScriptMessageHandler, NSFilePresenter {
@IBOutlet var webView: WKWebView!
/// Shared URL for the message json
var presentedItemURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.au.death.MarkDownload")?.appendingPathComponent("message.json")
lazy var presentedItemOperationQueue = OperationQueue.main
...
}
```
To actually start getting notified that something changed, I also have to implement the `presentedItemDidChange` function. In my case, as I've written json to a file, I can just read that and pass it directly to the javascript code in my app's web view like so:
```swift
func presentedItemDidChange() {
do {
let jsonString = try String.init(contentsOf: self.presentedItemURL!, encoding: .utf8)
I'm not sure how thread-safe the notifications are, so I decided to hedge my bets and specifically send the code to the web view on the main thread. I don't actually know if this is necessary, but it makes me feel a little better.
So, this seems simple enough. Time to run it and... it still doesn't work. It turns out I've missed one very important part: I have to register the View Controller object as a file presenter via the File Coordinator. After googling for this, I also found that it's required to remove the file presenter when the app goes into the background or closes, so I have this code:
```swift
override func viewWillAppear() {
super.viewWillAppear()
NSFileCoordinator.addFilePresenter(self)
}
override func viewWillDisappear() {
super.viewWillDisappear()
NSFileCoordinator.removeFilePresenter(self)
}
```
And guess what? It actually works this time!
## Putting it together
Now, I can achieve my main aim. I have a web view inside a native app that can send a message to a web extension, and a web extension can send a message back all the way to the web view.
let jsonData = try JSONSerialization.data(withJSONObject: jsonObject, options: .prettyPrinted)
let groupURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.au.death.MarkDownload")
let fileURL = groupURL?.appendingPathComponent("message.json")
try jsonData.write(to: fileURL!)
}
catch {...}
```
```swift
class ViewController: ..., NSFilePresenter {
var presentedItemURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.au.death.MarkDownload")?.appendingPathComponent("message.json")
lazy var presentedItemOperationQueue = OperationQueue.main
...
override func viewWillAppear() {
super.viewWillAppear()
NSFileCoordinator.addFilePresenter(self)
}
override func viewWillDisappear() {
super.viewWillDisappear()
NSFileCoordinator.removeFilePresenter(self)
}
func presentedItemDidChange() {
do {
let jsonString = try String.init(contentsOf: self.presentedItemURL!, encoding: .utf8)
Does this mean my safari is over? Of course not. I still have to implement / bring in code from my existing MarkDownload extension. And because I'm still aiming for cross-platform, cross-browser, I have to figure out ways of detecting whether the native app approach is necessary / viable. If the extension is running in Chrome on a Mac, with the app installed, should it communicate with the app, or stick to using the side panel? If so, how does the communication work? It's not sending message to the app extension, but the app itself, via the app's standard input stream. So how does that work?
While I have hit a major milestone, it's still time to set up camp. To see what the next leg of my journey will look like. Native app messaging between other browsers and the mac os app? How does the extension work on iOS Safari? Is there a potential need for Windows and Linux versions of the native app? What about Android?
As hinted in the previous blog post, I do have a way of listening to the standard input stream and write to the standard output stream in the swift mac app. This *should* mean I can communicate between the app and other browsers like Chrome and Firefox. This could be the next step.