OmniFocus for the Web: Under the Hood

If you listen to The Talk Show Live from WWDC 2019, near the beginnning (around 3:33) you’ll hear the host John Gruber talk about OmniFocus for the Web:

…instead, what these crazy people did is they’re using the same Objective-C and Swift code that OmniFocus for Mac is built with, and they’re running it on Mac servers, and they just have web output display from the same code. Crazy, right? And so for all of the consternation that people like us, and all the anger we have at developers who make web apps and put it in a shell and call it their Mac app, The Omni Group has done the right thing! They took their Mac app and now it’s on the web! Super-super great. It’s so very Omni to do something so nutty-sounding.

John’s right: it’s so Omni, and it does sound a little nutty — but only because it’s not what most companies do.

It actually makes complete sense!

Shared Database and Syncing Code

Our model code — the code that manages the database and syncing — was already shared between OmniFocus for Mac and iOS, and it’s a mix of Objective-C and Swift code.

For OmniFocus for the Web, we could have written a new version of this code in another language such as Go or Ruby. But that would have meant more work up front and more ongoing work, as both versions would have to be in step with each other.

And it’s likely that each version would have different bugs. Something that works perfectly in one place might not work in another, or might work subtly differently.

Given that this code is all under-the-hood code — it’s not user interface code — we realized that we could run it on the web, too, as long as we’re using Mac servers. So… why not?

And that’s what we did. It means that, when you’re using OmniFocus for the Web, you’re actually connecting to a sandboxed instance of that same OmniFocus code that’s running on your Mac, iPhone, or iPad.

That code is the heart of OmniFocus. But it’s not the only thing running on the web.

Web-only Components

In addition to that shared model code, the web version has additional components that aren’t shared — they’re only for the web app.

They are: API hosts, the coordinator, the notifications sytem, and the front end (the user interface).

API Hosts

API hosts sit between the front end and the shared model code. The front end doesn’t talk directly to the shared code — instead, we’ve created an API, and the front end talks to one of our API hosts, which then talks to the shared model code.

We run more than one of these, so that if we need to take one offline (for an upgrade, for instance) then OmniFocus for the Web will continue working.

Coordinator

The coordinator initiates an instance of the shared model code for each user, and makes sure that user is connected to that instance. It also cleans up idle instances and takes care of API host scaling.

This component is written in Python. (It may be a surprise to hear that we have a lot of Python experience. We do.)

Notifications Service

The notifications service, written in Go, had originally been written to send notifications to the non-Mac-App-Store edition of OmniFocus for Mac. In those days you couldn’t use Apple’s push notifications service with apps distributed outside the App Store. (Now you can.)

But we found this useful for OmniFocus for the Web — an API host gets a notification that something changed, and it triggers an update in the front end, in your browser.

This is how you can have OmniFocus open on your Mac or iOS device and have OmniFocus for the Web open, and a change made on your Mac, iPhone, or iPad will show up in your browser without your having to do anything.

Front End

The front end is the HTML and JavaScript that runs the user interface and that talks to an API host. This is what’s actually running in your web browser. The front end is written in React.

It’s served by a Content Delivery Network to make sure it’s as fast in Australia as it is here in Seattle.

Inside OmniFocus