This was discussed in another thread somewhere, but I can’t seem to find it right now…
The issue, as I understand it, is that OmniFocus doesn’t have a “custom” cloud server where your database is stored. Yes, Omni deployed the Omni Sync Server a while back, but that’s really just a WebDAV server, and the goal of OmniFocus’ original design was to allow you to store your data wherever you want.
Other apps like Things, Wunderlist, etc., have deployed their own custom protocols and servers. You’re syncing using their own “sync language” if you will, as opposed to simply uploading data to a file server. It’s more proprietary, but it allows them to take advantage of things like iOS Push Notifications for informing iOS devices that new data is available to be synced.
Omni has said they could theoretically do something like this with their Omni Sync Server, but it would make OmniFocus more dependent on that and would exclude those users who want to store their OmniFocus database on their own server, or some other WebDAV server, for whatever reasons (often privacy).
Until then, however, OmniFocus relies on the built-in background sync in iOS that schedules it to fire up periodically and check for new data. Unfortunately, that’s not even end-user controllable, but is determined by iOS itself based on some Apple algorithm that tries to see when and how often you open the app yourself. You can therefore apparently speed up the process by opening OmniFocus more often, but it still won’t provide an instant sync since there are no Push Notifications being employed.
It is a trade-off. These services may have implemented their own cloud back-end that can prepare delta changes on-the-fly for sync. On the other hand, apps like OmniFocus and 2Do rely on more or less client-only, file-based synchronization, so that a proprietary back-end service isn’t needed (in Omni’s case, you can easily build your own “backend”, i.e. a WebDAV storage). But a hit in sync time has to be taken, as there is no smart worker in the cloud to prepare everything for you.
Having that said, with the introduction of CloudKit, the lack of pushes for file-based synchronisation can be mitigated. For instance, per my observation, the Due 2.0 app (seemingly) uses CloudKit’s subscription to push sync signals, and Dropbox’s API to delta sync its database. But CloudKit’s problem is that it is restricted to only non-MAS versions. Moreover, silent background pushes are not reliable either, as iOS does not always guarantee a handler trigger when the device is not charging, but aggressively drops the silent pushes based on the app’s history of signal, power and data costs in background.
To me this sounds like excuses and justifications for an otherwise unacceptably slow synchronisation. This is a fundamental feature in 2015 with all our devices… they need to be updated instantly.
Omnifocus is by far the best GTD system I’ve used but the slow sync is making it feel clunky and useless. Things doesn’t have anywhere near as many features but it’s sync is flawless and I’m tempted to go back to using that.
I was curious about other sync solutions and saw this on the 2Do support pages. They are recommend using Dropbox, Apple Reminders, or Toodledo. Each solution has its own strengths and weaknesses. This will always be a tough cookie to chew on. Read on to see what those guys have to deal with whether they are using Dropbox, Reminders, or Toodledo.
It also depends on where those servers are. If you go from USA to EU or vice versa it means a latency of at least 100ms. If you do things locally it can be 10ms (or even less when using fibre). This is the main reason why Google services were faster than Apples .Mac and MobileMe. Apple was USA-only whereas Google stored it locally (they had servers all around the world to do so). Apple invested a lot in datacentres outside the USA to make iCloud and the stores faster for people outside the USA.
With applications like this (productivity apps) we need to keep in mind that these are quite often used a lot in businesses. That means that you must have an option to store data locally, either on the device or a server. A good example is the new Outlook client for iOS and Android from Microsoft which is just the old app from Acompli which Microsoft bought. That app uses Acomplis servers to connect to. Any account you add to the app is actually added to their servers so every communication goes through their servers. This poses a huge security and privacy risk which is why nearly every organisation has blocked the app and has forbidden the use of it.
Faster sync? Yes…but not at the expense of not having the option for your own sync server. Many organisations want to have the sync server on premise, not in someone else’s cloud. If they provide the software to run on say OS X and Linux it won’t be a problem if the new sync solution is proprietary.
And I would just like to add that OmniGroup must have done a lot lately to improve sync times. I am in Scandinavia and before it would take me between 15-60 seconds to sync. Now, it usually less than 10 - and often as low as 5. It means that I no longer experience that my Mac and iPhone are not synced.
I love OmniFocus but the sync issues and lack of a web API really drive my crazy. It also find it ridiculous that there is still no Android app.
I previously used Things for several years. Their sync is absolutely flawless. I don’t recall ever having a problem with it - it just worked without me having to think about it. OF sync is terrible in my experience. I get duplicate tasks often, and it can take ages to sync.
OmniFocus is great in its native apps, especially with features like sequential projects, review etc. Web-based services like Todoist (which is what I used before OF) are absolutely fantastic in how they integrate with other services, and how they are available on so many platforms. Unfortunately they don’t have some of the core features found in OF, though they are catching up fast. The moment a web-first service offers all the features in OF, it’s going to be hard to keep me to stick with OF.
Improved sync, and a web API to allow third party services to connect with it, and OF would be miles better. I would even accept a subscription model to get these features.