Omni Roadmap 2020

by Ken Case on January 29, 2020

Looking Back at the 2010s

Welcome to the 2020s! Ten years ago (on January 27, 2010), Apple introduced iPad—a new device category that would, as Steve Jobs put it, “connect users with their apps and content in a much more intimate, intuitive and fun way than ever before.” Inspired by the announcement, we put many of our plans for the next few years on hold—and just two days later I shared our first public company-wide roadmap, “iPad or Bust!

When we completed “iPad or Bust!” a few years later, I found myself reflecting on 2012 and looking ahead to 2013. This established a pattern for the rest of the decade, as we started regularly sharing roadmap updates for 2014, 2015, 2016, 2017, 2018, and of course 2019.

Our roadmaps have never been perfect predictions of the future. Our world is constantly changing, and each year we have to be prepared to adjust those plans based on what we’ve encountered along the way:

Changes to the projected iPad or Bust! roadmap

But while our roadmaps don’t predict the future, they do state the direction in which we’re headed—and I hope you find them useful!

Looking Back at 2019

Before we talk about future roadmap, let me quickly summarize the major updates from last year:

(For more detailed notes on what we did last year, I recommend reading last year’s September roadmap update.)


Looking Ahead

In last year’s roadmap, I said that beyond shipping OmniFocus for the Web, we would continue to work on site licensing, JavaScript-based automation, sharing linked tasks, and improving the flow of using our apps:

“We’ll be reviewing the ways customers navigate our apps—making them easier to navigate on small touch devices, more efficient to use from a keyboard, and more accessible to the sight-impaired. We’ll be improving integration between our own apps (such as linking tasks between OmniFocus and OmniPlan), between our apps and others (such as OmniGraffle’s import and export of Visio and SVG files), and with the rest of the system. We’ll be tracking down and fixing rare crashes and other bugs. And we’ll be taking a hard look at performance issues, so our apps respond to your input faster.”

We did ship OmniFocus for the Web as planned—but when iPadOS was announced in June we took a pretty big detour from the rest of our planned roadmap. There was a lot of benefit in that detour: it’s great to have multiple windows on iPad, support for iCloud Drive and other document providers, and Dark Mode! But it did leave a fair amount of unfinished business from last year’s roadmap, and we’re continuing with that work this year.

Specifically, we will continue our work on sharing linked tasks in OmniFocus, and on improving integration both between our own apps (such as linking tasks between OmniFocus and OmniPlan) and between our apps and others (such as OmniGraffle’s import and export of Visio and SVG files).

We’re also continuing to improve the flow of using our apps—particularly on iPad and iPhone. We want easy navigation, so everything in the app feels like it’s right at your fingertips—whether your fingertips are using the mouse, touch screen, or a hardware keyboard.

As we do this work, we’re also actively listening to your feedback. When we hear that you’re repeatedly encountering pain points in our apps (whether you’re encountering performance or stability issues, or dealing with common workflow issues such as time zone changes in OmniFocus), we will be setting aside time for addressing those issues.

Using Automation for Custom Features and Integrations

With AppleScript, we’ve always had first-class support for automation in our Mac apps. This support for automation has enabled our customers to create some wonderful solutions, such as the Kinkless GTD scripts for OmniOutliner which inspired us to build OmniFocus.

But AppleScript had some big caveats: it was generally easy to read, but it was a fairly esoteric language that many developers found less easy to write. It was able to accomplish some amazing things, much faster and more accurately than working by hand—but it was generally slow enough that you could watch it work, and if it had a lot of work to do you could be watching and waiting for a while. And it was only available for the Mac platform—which was totally fine in the ’00s when that was the only place our apps ran, but was a lot less useful in the ’10s when our customers were increasingly spending their time on mobile devices.

To overcome those limitations, in 2015 we started working on Omni Automation: a technology which lets customers run JavaScript code in our apps using Apple’s highly-optimized JavaScript engine. Since then, we’ve shipped Omni Automation support for OmniOutliner, OmniGraffle, OmniPlan—and in 2020 we will be officially shipping support for Omni Automation in OmniFocus.

Why does this matter? If you don’t know how to program JavaScript, how does Omni Automation benefit you?

By providing automation technology in our apps, we make it possible for customers to extend our apps’ capabilities. People can build customized solutions to meet their own needs—and then share those solutions with others. We had thousands of customers using Kinkless GTD in OmniOutliner, even though most of those customers didn’t know AppleScript. I’ve been told that one of JTech Communications’ most popular blog posts was for a script for OmniGraffle which counts items on a canvas. With automation, people are able to create their own keyboard shortcuts to quickly perform actions like creating a task calendar from OmniFocus, or exporting Markdown from OmniOutliner—and those solutions can often be shared with others, making everyone’s lives easier.

Automation is also a building block that can be used to integrate our apps with other applications and systems. We’ve had customers use AppleScript automation to sync OmniPlan with their internal bug tracking systems, so they can easily keep their project plans up-to-date as work gets completed and their tracking system up-to-date as their plans change.

It’s definitely true that writing JavaScript code isn’t for everyone! But automation solutions powered by JavaScript have the potential to benefit everyone—and we’ll be working to make it easier for all of you to share your solutions with each other.

Simplifying Licensing with Sign-Ins

In our ideal world, nobody would have to think about how our apps are distributed and licensed. You would simply install the app from whatever source is most convenient for you, and pick whatever licensing option works the best for you. This was how our software worked in the ’90s and ’00s: you could install our apps from CDs or our website, and you could purchase licenses for those apps from retail stores or our website—whichever was most convenient for you.

That picture has changed with the App Store. We can still offer app downloads and licenses on our website, but only for the Mac platform—to install on an iPad or iPhone, you must install from the App Store. We can offer trials and upgrade discounts and price protections in the App Store, but only when we use free downloads with in-app purchases. But in-app purchases can’t be made directly by businesses and schools—so those customers really need the option to pay in advance as well.

In our attempt to provide the best options to everyone, we’ve ended up with three different distributions of our apps: website installs (purchased from our store), free App Store installs (licensed with in-app purchases), and pay-in-advance App Store installs. (The pay-in-advance App Store option is certainly the most straightforward—but with no options for trials or discounts, it’s also the least friendly and flexible.)

Those who follow closely may have noticed that we introduced another approach to this problem last year: sign-in licensing, which is used for our cross-platform OmniFocus subscriptions. While the App Store doesn’t allow apps to be unlocked using license codes, it does allow apps to be unlocked based on signing into the app (as seen with Microsoft Office, Netflix, and many other apps). With the sign-in licensing model, you no longer have to worry about how the app was installed, or whether their subscription was purchased from within the app or directly from our website. You don’t even have to worry about which platform you’re using: the same sign-in unlocks OmniFocus on Mac, iOS, and web.

We think this provides a much better experience overall. But right now this experience is limited to individual OmniFocus subscribers—which means most of our customers still have to think about how they’re licensing our apps, because it doesn’t apply to any of the other licensing methods. To make this benefit universal, we’re working on supporting sign-in licensing in all our apps. We’re extending it to support teams, so organizations can purchase subscriptions for people on their teams. (This includes single sign-on support for our larger customers—many of whom have tired of managing spreadsheets with hundreds of license codes.) And we’ll also be updating our store to support sign-in licensing for one-time “à la carte” purchases of our apps, so customers who prefer that model can benefit from it as well.

OmniFocus for the Web

OmniFocus for the Web is still relatively new, having shipped less than a year ago. It’s been very useful and popular—but in terms of functionality, it still has a lot to do to catch up with its older siblings on other platforms! Aside from keeping pace with new features (like floating time zones), our top priorities are to add support for custom perspectives and for the Mac app’s Focus feature (so you can focus on your work projects when you’re on your Windows box at the office).

OmniPlan 4

We’ve been listening carefully to your feedback on OmniPlan, and I’m very pleased to share that we’ll be shipping OmniPlan 4 for Mac in the first half of this year! We’ve improved the discoverability and ease-of-use of OmniPlan’s existing feature set, and introduced a number of new features like Recurring Tasks and Task Roll-Up. We’ll be introducing OmniPlan 4 more fully as we start its public test period (soon!), but for now I’ll focus on just one of those features, Interval Tracking:

Many of our OmniPlan customers have asked for a way to report on the costs of a project over time, not just broken down by task or resource groupings. OmniPlan 4 solves this problem by adding Interval Tracking, which breaks down the cost over time of each item on the Gantt chart, based on your current Gantt scale:

OmniPlan 4 Interval Tracking

For those of you doing cost planning (or reporting), Interval Tracking makes it much, much easier to see exactly how much time or money you’re going to need to spend (or have already spent) on each item or group. (And if you just need to see the totals, we’ve got you covered! You can enable Interval Tracking for just the headers.)


Wrap-Up

I hope this year’s roadmap gives you a sense of where we’re headed next! When we think about what to focus on next, we think about how to build products that help you, our customers, be your most productive selves. You’re working on big projects, and you’re looking to us for powerful tools to help you with those projects. It’s our job to help you accomplish those projects efficiently and effectively, without wasted effort. As we work to improve our products, we hope that the improvements we’re making will help you do just that.


(Feedback? I’d love to hear from you! You can find me on twitter at @kcase, or send me email at kc@omnigroup.com.)

Omni Roadmap Update: September, 2019

by Ken Case on September 12, 2019

Welcome! With iOS and iPadOS 13 right around the corner, I thought now would be a good time to share the latest news regarding our plans for 2019.

In January’s roadmap, I shared that we would be launching OmniFocus for the Web, along with the optional OmniFocus subscriptions needed to support that service. We successfully launched on May 28, and the service has been very stable as we’ve scaled up to thousands of subscribers and added new features like Forecast, new keyboard shortcuts, support for Dropped Actions, and localizations for German, Spanish, French, Italian, Japanese, Korean, Dutch, Brazilian Portuguese, Russian, and Simplified Chinese.

Of course, the bulk of our attention remains focused on our native apps for Mac, iPhone, iPad, and Apple Watch. The OmniFocus team has been working towards collaboration, adding support for Dropped Actions which we feel is an important status to communicate when sharing tasks. The OmniGraffle team shipped a new wrap-to-shape text formatting feature early in the year, then spent several months focused on improving drawing performance in the Mac app. And the OmniPlan team added support for Omni Automation, which lets our Pro customers build their own custom app integrations, workflow improvements, and reports using cross-platform JavaScript that runs on both Mac and iOS.

All of the above was according to the plan we laid out in January. But we always know going into the year that our plans will need to change mid-year—and right on schedule, in the first week of June, Apple announced new operating system features which would be shipping in the Fall. So we paused work on our January roadmap, making and sharing new summer plans which were all focused on updates to our iPhone and iPad apps. We also decided that this was the right time to adopt Apple’s standard document browser.

Which brings us to the present! Apple has announced that iOS 13 will be shipping next week, with iPadOS 13 following along at the end of the month. So we’ll be returning to our regularly scheduled roadmap soon. But what have we been working on all summer? What have we been doing to prepare for iOS 13?

Well, first of all, we think it’s essential to make sure we have apps that behave well on iOS 13 on the day it launches—so we have a few small bug-fix updates that will be shipping before iOS 13 ships, such as the OmniFocus 3.3.6 update that is currently in TestFlight.

But while these day-one bug fix updates are important, we have much bigger updates coming to each of our apps which we’ll be shipping as soon as possible! When I look at the work we did across our apps this summer, I classify it into three broad areas of change:

  1. We added support for the new native Dark Mode in iOS 13. This means that we had to review and update nearly every pixel our apps draw to the screen, since those pixels now have to draw in different colors based on the user’s chosen preference—and also have to be ready for those preferences to change on the fly.

  2. We added support for multiple active windows from the same app in iPadOS 13. The platform never supported that feature in the past, and every bit of logic which managed application state and user interactions had to be updated to support the possibility of user interactions coming from and going to multiple windows at once.

  3. Adopting Apple’s standard document browser (replacing the home-grown browser we’ve been using since iOS 3.2) meant that we needed to change much of the code which reads or writes or syncs our documents. Of course this affects the main document being edited, but it also affected the template chooser for new documents, the stencil browser in OmniGraffle, and the theme picker in OmniOutliner.

That’s a lot of change. We touched pretty much everything involving drawing, managing document/application state, or reading/writing/syncing data. (And that’s just the general cross-app overview. Specific apps had other specific work to do for other operating system changes—like the vastly improved Shortcuts in OmniFocus, or the gestures overhaul in OmniGraffle to avoid conflicts with some of Apple’s new system-wide gestures.)

If you’re impatient to try out these great new features, and don’t mind living on the edge, we currently have public TestFlight builds for OmniOutliner, OmniPlan, and OmniGraffle which you can download and start using today. We also have a public iOS 13 TestFlight for OmniFocus, which is focused on its bug fix release today but will be switching over to its feature update very soon.

For any long-time customers who might still be running our older v2 apps for iOS, please know that you’re welcome to continue using those older apps as long as you wish—the license you’ve purchased will never expire. But you’re responsible for maintaining an environment where those apps can run—and if you’ve been reading closely, you may have noted that even our current v3 apps needed to be updated in order to be compatible with iOS 13. Our older v2 apps haven’t been sold in quite some time, and are no longer being maintained—so I’m afraid they’re not going to be compatible with iOS 13. If you’re planning to upgrade to iOS 13, please also make sure you plan to upgrade your v2 app to the current version. (Our v3 apps come with free two-week trials, and every v2 customer is eligible for a 50% upgrade discount!)

For customers who have already purchased our current v3 apps: these updates, major as they are, are absolutely free. Thank you for your support, and we hope you enjoy Dark Mode, multiple windows, more flexibility in where you keep your documents, and more!


(Feedback? I’d love to hear from you! You can find me on twitter at @kcase, or send me email at kc@omnigroup.com.)

Adopting Apple’s Standard iOS Document Browser

by Ken Case on July 30, 2019

When we launched our first iPad apps in April, 2010, the iPad platform was completely new. (We launched our first apps the day the App Store launched!) At that time, there was no built-in document browser, or even a rich text editor: if we wanted those features—essential to apps like OmniGraffle and OmniOutliner—we had to build them ourselves.

There was also no built-in mechanism for syncing documents: iCloud itself didn’t exist in 2010, and iCloud Drive didn’t exist until it was introduced with iOS 8 (in September, 2014). We knew how important it was to be able to easily sync documents between multiple devices, so in May of 2013 we shipped our own syncing solution, OmniPresence.

A document browser with integrated cloud syncing was a great solution—for 2013. But time marches on, and in 2019 we now have lots of cloud storage options which integrate strongly with Apple’s standard document browser—a browser which is now built into iOS and available to every iOS app. It’s understandable that, more and more, we’ve been hearing from customers who find it frustrating that they can’t easily use the cloud syncing service of their choice within our apps.

In 2019, we think it’s time to retire our custom document browser in favor of using Apple’s built-in document browser—and with our iOS 13 updates this fall we’ll be doing just that. Instead of seeing our custom file browser, you’ll be presented with the standard iOS document browser—just like in Apple’s own iWork apps. Using Apple’s browser, you’ll be able to store and sync your documents using Apple’s built-in iCloud Drive, or third-party commercial options like Box—or even in cloud- or self-hosted collaborative git repositories using Working Copy.

Syncing through OmniPresence will still be an option, but it will no longer be the only integrated option. In fact, it might be the least privileged option: since OmniPresence isn’t its own separate app, it won’t be listed in the document browser’s sidebar where you find your other document storage solutions. Instead, it will present itself on iOS much like it does on Mac—as a folder of synced documents. We’re not trying to drive people away from using OmniPresence—but in 2019 we don’t think it makes sense to push people towards it either. OmniPresence is not a core part of our apps or business, and in 2019 there are lots of great alternatives. Seamless document syncing is essential to our apps—but exactly where and how those documents are synced is not!

Adopting the standard iOS document browser will make it easier than ever for you to choose where you want to keep our apps’ documents. If you’re already testing the iOS 13 betas and would like to help test our apps, please sign up for our iOS 13 TestFlights!


(Feedback? I’d love to hear from you! You can find me on twitter at @kcase, or send me email at kc@omnigroup.com.)

Open Test of OmniFocus for the Web Drawing to a Close

by Ken Case on May 22, 2019

Hi, all! Thanks for all of the great feedback during the open test period of OmniFocus for the Web!

I just wanted to give you all an early heads up that the public test of the web app will start to require a paid subscription late next week (after we’ve updated our online store to offer a $5/month web-only add-on subscription).

Subscribers will be welcome to continue to use the public test if they wish (continuing early access to features like the Forecast perspective that are still in development), or to switch over to the more stable production site.

For reference, here are links to both sites:

Whether or not you end up subscribing, thank you very much to all 20,000+ of you who signed up for the public test! Your participation and feedback have been very helpful!


(Feedback? I’d love to hear from you! You can find me on twitter at @kcase, or send me email at kc@omnigroup.com.)

Compatibility warning: macOS Mojave 10.14.4 cannot display some OmniOutliner and OmniPlan documents

by Ken Case on April 12, 2019

UPDATE (May 13, 2019): The compatibility bug referenced by this blog post has been fixed in macOS 10.14.5. See our follow-up post for more information. What follows is the original blog post, unedited.


Good afternoon, readers! It’s incredibly rare for us to have to do this, but I need to let our Mac customers know that the 10.14.4 version of Mojave which shipped a few weeks ago (on March 25, 2019) has a drawing bug which makes windows with large CoreAnimation layers fail to draw. In particular, OmniOutliner and OmniPlan customers have been telling us that since upgrading to 10.14.4, they will open some documents and end up seeing… nothing. Perhaps some empty borders around the window. (Or if another window is dragged over the space where that window should be drawing, they’ll see a trail of its old pixels.) This is most likely to affect customers who are using older hardware, but it also affects large documents on newer hardware.

We’re working with Apple to get this resolved as soon as possible, but for now it appears there’s nothing we can do to resolve this on our own. We’ll provide an update as soon as a fix is available. In the meantime, I’m afraid we need to recommend that any OmniOutliner or OmniPlan customers with older hardware or large documents hold off on updating to 10.14.4. (Earlier versions of Mojave are fine.)


UPDATE (April 14, 2019): Good news! We’ve been working with Apple and tested a fix that will be in the next Software Update to macOS Mojave. (I don’t know the timeframe for that update shipping to the general public, but I’m glad this fix is on its way!)