Today I'm talking to Ken Case, founder and CEO of Omni Group, the makers of some of my favorite productivity software tools that I've been using for quite a long time on my Mac and iPad. We're going to be talking about productivity techniques, tools, ideas, and philosophies.

Ken, it's awesome to have you.

Ken Case: Thank you for inviting me. It's fun to be here.

You've been working on Omni Group for a long time, longer than most of the productivity tools that people are using today. Is that fair to say?

KC: That is fair to say—longer than some of our employees have been alive.

What year did you start Omni Group?

KC: The founding date I look at would be 1992, which is the year that we registered omnigroup.com. We had been working together as consultants before that, but we were working on various projects, sometimes together, sometimes not, and we were always getting paid by somebody else directly. 1992 is when we decided to make this a common endeavor and move forward that way.

It feels like the classic pipeline from the original days of productivity tools—folks who were building products for other people, getting paid as consultants and developers, who took the leap to create their own products. Do you think that shaped what you were doing at Omni Group?

KC: Yeah. I started seeing a shift in the eighties, really, between one set of philosophies where people were just using computers for fun and for productivity because of their passion for it, to "oh, maybe people can make money out of this." We got a lot more business majors starting to take computer classes in the eighties than just computer folks who were these odd geeks off in the corner.

But by trying to ground yourself in what people are actually trying to do and solve their specific problems—we started out as a consulting company building custom solutions for different businesses—you really have to listen to what people are trying to do and then think about how you can make that better for them.

You've been building for Apple platforms since the NeXT days, is that right?

KC: Yes, if you can count the NeXT days as being part of the Apple platform.

I think we can now, in hindsight. So what is the underlying belief about platform-specific software that keeps you loyal to that path?

KC: When I first encountered the NeXT platform, I was trying to develop software for as broad a range of Unix platforms as possible, because that felt like the best way to get the most value for the effort I was putting in. At that time, there were probably at least 15 different Unix variants that I was building for.

Then I discovered the NeXT platform, which had a very different way of working with AppKit and Objective-C, and I realized I could build much more polished products with a lot less code. That made me more productive with a much more productive result. But of course, you were then stuck to this tiny audience of the NeXT platform, which was not very big at that time.

I thought long and hard about that trade-off and decided I really wanted to be producing the best product I could, even if the audience ended up being smaller. The productivity gains made that worth it. So I focused on what I could do to help that platform grow and succeed so that the audience would get bigger and the work I was doing would be even more valuable to more people.

How did you help NeXT succeed?

KC: Let's build a web browser. Let's build image viewers—whatever we needed to do.

The web browser being OmniWeb, which is still updated today.

KC: That's true. It's the one I still use.

I use it regularly. It's either Safari or OmniWeb. Occasionally if I have to have some kind of Chromium product, it's Brave. But Safari and OmniWeb pretty much keep me going.

Once NeXT folded back into Apple and took on a new life with an injection of energy, how did that change things?

KC: We had just about despaired that NeXT was not going to make it, that we were going to have to give up on this effort to help NeXT succeed. They were turning into a Windows tool vendor with WebObjects for Windows, doing backend stuff, and though we did some WebObjects consulting and helped build some of those early websites, that really wasn't where our passion was as much as building productivity software for the desktop.

We started looking at other options. We started consulting for Sun and helping them maybe build Java into this same sort of thing—they were thinking maybe Java would be the desktop. Then in the last two weeks of 1996, we heard that Apple was buying NeXT. We were thinking, "How can we get out of this Java work we're doing and start going back to Objective-C and AppKit and the environment that we loved?"

When you were building productivity software at the time, what were the actual tools you were selling?

KC: Alongside our web browser, we were still mostly consulting, working on other people's projects, even when they were desktop productivity apps. The big vendor on the NeXT platform at that time was Lighthouse Design. They ended up getting purchased by Sun because Sun wanted to turn Java into this desktop environment.

They were taking their suite of productivity apps—things like Concurrence, which was the tool that Steve Jobs was using to do his presentations back then, like a version 0.1 of Keynote—and a diagramming app called Diagram, which is very much OmniGraffle. Those were the two we mostly helped out on. We also helped on some project management software.

Apple purchased NeXT, and you were still building some of these services. There was a bit of a leap that you eventually made to start launching the Omni products we know today.

KC: We had built OmniWeb back in 1994, and we actually sold it through Lighthouse Design—they marketed it for us. We didn't have any salespeople; we were just programmers who didn't know anything about that world. They printed the boxes and did the marketing. I even wrote the documentation, I think.

Software boxes. Good times.

KC: Yeah. I have them here on my shelf. I am one of those people who collects old software boxes—there's a lot of nostalgia wrapped up in those boxes.

We had OmniWeb, a few tools like OmniDiskSweeper that's still around, image viewing, a CD player—just whatever the platform was missing that we could do to help make things better. The other thing we were doing that was more consumer-focused was helping with game ports.

John Carmack was developing on the NeXT platform, building software cross-platform to run on DOS and Windows. We ended up helping him make Doom run better on NeXTSTEP/OpenStep. Then he contacted us when he needed a 3D driver for this Rendition graphics card prototype, and we started helping with porting Quake over.

As Apple bought NeXT, we started porting Quake to the Mac platform, and then helping other companies with games like No One Lives Forever and a whole bunch of games around that time using the Quake engine and other engines like in Giants: Citizen Kabuto. Some fun times.

You established yourselves as the people bridging the gap between what NeXT had been and what Mac could be, trying to help make sure the Mac was going to go somewhere. There were real concerns in 1997 about whether this platform would survive.

KC: Yeah, in the nineties it felt like it was dying, like Apple was not going to make it almost.

At what point did you realize that this is starting to get traction?

KC: For us, coming from the tiny NeXT platform, even going to the larger Mac platform—when that merger happened at the beginning of 1997, Apple was selling about as many Macintoshes every month as NeXT sold of their operating system during the entire lifetime of NeXT. So it was already operating on a very different scale from our point of view.

There was some success there, but the trajectory was going in the wrong direction. When Steve came in and simplified the product line and said, "Let's build an iMac, let's build a Power Mac, and just have one thing in each of these four quadrants," that drastically simplified things. That was when it started to feel like there was a better direction, and certainly when the iMacs started doing well, helping people get online. Then when Mac OS X finally shipped and the NeXT technology really was now the basis of the new Mac platform—that was when it felt like a great turning point.

What was the point where you started to launch the productivity tools that have really put your flag in the ground?

KC: As Mac OS X went into beta, we had our web browser ready, which was well received because at that time, most web browsers did not have great-looking fonts and typography, and that was something we had in OmniWeb. At the same time we were working on OmniGraffle, building our diagramming software. We had already started working on OmniOutliner as well, so we had all three of those products ready by the time Mac OS X shipped.

It still wasn't enough—not enough of the Mac community was ready to switch over to this completely new operating system for us to fully transition away from consulting right at that moment. But we started the transition at that point. We still wanted to do some more games because we thought that helped the platform, but maybe that wasn't going to be what we wanted to do forever. Let's focus on our own stuff and keep building OmniGraffle and OmniOutliner and make them better.

What was it about the productivity space that made you passionate about building in it?

KC: Just like I felt it was useful for me to adopt better tools as a developer—that was what made me adopt the NeXT platform—I felt like if we could do something similar for customers who are trying to get work done using their computers, then that would be a good thing for the world. If everyone can just be more productive, I don't know if it's an idealistic sort of approach to things, but that's just what motivates me.

Are we not idealists though? I think there's value in being idealistic, in having something that you hold up as a higher value. You've talked before about craftsmanship as a value. How do you protect that craft ethos in a software and business world that rewards speed and iteration and hype a lot more than polish?

KC: I guess we just tune out that part of the world for the most part. To some extent you can't, because there's a lot of money going in those directions and we see advertising for a lot of things that can dominate the conversation. But because our motivation isn't directly about money—obviously we need money to succeed, so we can't ignore money in the question altogether, or we wouldn't be able to keep doing what we're doing—but it needs to come secondary from our point of view to building great software in the first place.

If we can build great software and make enough money to keep doing it, and if we can help our customers feel more productive and hopefully have them enjoy using our software—not just be more productive, but have it be software that they enjoy sitting down with and using—then we feel like we're on the right track.

From my perspective, you are definitely on the right track. I still sit down and use the Omni products and feel a sort of lightness that I don't feel with other tools. I use OmniOutliner for most of my writing, OmniGraffle for social graphics and YouTube thumbnails, OmniFocus daily to manage my business, my writing, and being a parent with a 9-year-old. There is still a lightness and a joy to them that I find unmatched by a lot of the newer tools.

KC: Thank you very much. That's really nice to hear, and that's part of what motivates us—hearing things like that.

A huge number of productivity tools today are essentially web apps in desktop wrappers, whereas Omni by contrast continues to build truly native applications. What advantages do you believe native apps still confer in 2025? Do you think the industry is missing anything by drifting more towards browser-based experiences?

KC: This is an interesting progression that we've seen go back and forth many times over the decades. I think of web apps as being the modern incarnation of mainframe apps, where it's running on somebody else's computer that is hosted by them somewhere—you don't necessarily know where—and you connect to it from your local system with a terminal that's a window into that.

You're dependent on them continuing to keep that system running, and they're hosting all of your data. There are a lot of interesting things about that world. I used to be a Unix systems programmer, and it's fun that you have multiple users actively using the same computer at the same time, so you can do some interesting interactions.

Then you had the PC revolution where people were starting to move more of this power to their own desktops and have a completely independent computer under their own control. The network wasn't fast enough for them to do very interesting things on it yet, so most of what they did was just on their local machine.

I view the current world colored by my eighties perspective—this is really the same sort of thing happening again. But it's different because our computers, our local systems, are now powerful enough to run this stuff. I can run OmniFocus on my watch. And the network is now fast enough that it's much easier to reach the server. There's a lot more parity about what you could accomplish in either place, and you have some choices about it.

To get back to your question: what do the native apps do better? It gives you that control, that independence. You don't have to worry about what happens. How many of the services that you talk to right now can you be certain you will have access to in 10 years? It's really hard to guarantee any of those services you can't access, whereas anything that's running on your local device—if it can run on that device when it's unplugged from the internet, it'll be able to run on that device when it's unplugged from the internet in 10 years. There's nothing you lose control over that way.

Beyond that level of control and privacy—because if the data's in somebody else's computer, they have access to it—there are also just a lot of details you can do when you take advantage of your local processor in a way that's not just providing a terminal to the internet. A terminal to the internet is by design least common denominator, so you're not taking advantage of your local hardware's capabilities nearly the same way as a native app might be able to do. You're not necessarily going to have good Time Machine integration, Spotlight integration—all sorts of things that happen on your local device just don't happen in the cloud.

At the same time, there are lots of things that happen in the cloud that don't happen on your local device. So it's a trade-off for sure.

OmniFocus does have a web version, which is probably the closest anything at Omni Group gets to cross-platform. How are you thinking about those trade-offs when you're building OmniFocus for the web versus for the native device?

KC: Our primary focus is on the native app. That's where the features come first, that's where all the design work happens first. But we build OmniFocus for the web because we know people live in a world where they don't always have control over what device they're using. Maybe they're using a Windows box and they aren't able to run OmniFocus on it, like when they're at work.

To make it as good as it is on the Mac, iPad, iPhone, Apple Vision Pro, and the Watch, we would have to spend more effort than we currently spend. We could become web developers—and we have been in the past—but that's not really where our passion is.

My inclination would be, if we wanted to do something cross-platform, I would still want to take advantage of your local device more than just building something that runs in the browser. We wrote a web browser, so we're pretty familiar with what the limitations are. We would rather write something that's maybe a cross-platform Linux app that you can run on that hardware yourself, because then we don't sacrifice the control over where your data lives and we take advantage of more of your local hardware capabilities. I think that would be philosophically closer to where our heads are at than becoming web developers.

Part of the reason we decided to focus on one platform was because it would take us further if we could put our attention in one place.

We are in the middle of what some people are calling a new browser war, with AI browsers like the ChatGPT browser, Perplexity browser, Arc browser. Do you see OmniWeb making a comeback, making a great big splashy return at any point?

KC: I don't know that the answer is yes necessarily. It's an app that I plan to not stop working on, but it's an app that has been relegated to my spare time now for the last 15 years or so. I certainly have been following that with interest and thinking about that space. Since at this point I'm not trying to sell OmniWeb, I'm just trying to use it, a lot of what goes into it is focused on what I need at the moment. That's not to say I wouldn't enjoy hearing from other people about what they need, but sadly I don't have a lot of time to invest in it directly. Maybe that would change.

I really appreciate using OmniWeb because I don't feel like there are chatbots about to be forced into my sidebar. It's not that I'm anti-AI; I just like for things to be in boxes. I like to be able to use my web browser and then if I want to use a chatbot, I can go and open that app.

KC: Yeah, if you think about how we've been integrating the Apple Foundation models into OmniFocus and now into OmniOutliner 6, you can imagine how we might do something for OmniWeb as well, where we would make it part of our plugin system that lets you make those choices as the user of how you want things to integrate. Or if you're a plugin developer, you could build something on top of the app as a platform, but without an agenda where we're trying to push something on people.

The work with the Apple Foundation models has been very cool to play with. I've been using "Plan for Me" and the plugin to estimate how long a task is going to take, and that's been quite useful. There's a nice, mindful approach to AI there. I haven't used the OmniOutliner 6 AI plugins yet, but I'd be keen to hear how you're thinking about which of these tools to build.

KC: Our first step is just to make that capability available to people and not propose a specific solution, although we built some example plugins like "Plan for Me" and "Estimate" just to help people have something they could use right off the bat without having to write their own code. That's not a great experience for people either if they see this thing is there but they don't know how to use it and it's just out of reach.

Hearing what people might be interested in or want to do with something is one way for us to guide what we would work on next. The other day I was playing with how we might integrate into OmniGraffle. In this case, I was using the Qwen3 Coder model running locally on my Mac. I noticed that somebody had done a SwiftUI architecture diagram where they had a little class and said, "Could you diagram this for me?" and they did a little text-based diagram.

I thought, if it can do that kind of text diagram, it ought to be able to do it in OmniGraffle. So I reproduced the same question in my session and said, "In OmniGraffle I can select this, build that same diagram and then use Copy as JavaScript—this is the JavaScript it gives me. Could you change that diagram and spit out the JavaScript that would make this thing?" And it did. Fun to play around with.

It put things in maybe surprising places—there are lots of different ways to think about how you diagram something—but it was interesting to play around with. I don't know whether that necessarily is the right thing that people are going to want, but it was also interesting that I could take a diagram I had built and paste the JavaScript into the chat session and ask it what the diagram is about, and it could actually come up with something interesting.

You've used the word "play" a few times here. You still think about building technology as a form of play, as something to enjoy and to explore without necessarily having a clear end goal.

KC: I sure hope it's play for me. I hope it's play for other people too. I know it's not for everybody, of course, but where it can be that, I love what I do and I want other people to enjoy what they're doing.

Obviously vibe coding has been a thing. How are you thinking about using AI as a developer?

KC: Not as a vibe coder, for sure. I define vibe coding as describing the outcomes you want and not caring about the implementation. I do care about the implementation deeply—it happens to be part of the fun for me. Why would I want to take the fun out of my coding process?

There are some things that large language models can help people save time on—maybe doing some repetitive tasks or translating from one programming language to another. But I really don't trust their work. Every time I play around with it, it saves some time on maybe rote work, but then it adds some time in terms of supervision time. Where that balance is, is a good question, but I'd want to be super careful with what kind of results I was getting out of it.

That's setting aside all the questions around how these things are being trained. When I do use them, I only run local models on my own hardware, so I know where the power's coming from and how much power it's using.

You are not about to turn all of Omni Group onto Cursor tomorrow.

KC: If somebody else has that idea and wants to ask Cursor to build the Omni Group apps, I would be interested in seeing what result they get out of it.

How protective do you feel about the way that Omni Group has built things? OmniFocus has a very specific point of view for how to work and how to get things done. If people started copying those features into cross-platform apps, how would you feel about that?

KC: People have and do. As we were coming over to the Mac platform and we wanted to make sure everything succeeded, we started publishing a bunch of our source code for people so they could learn from it and build things that maybe weren't what we were building but would help the platform as a whole. That's all stuff that moves things forward.

Moving things forward is my goal, and it's not necessarily that people have to be buying our software for it to be moving forward. If other people are taking our ideas and building other great ideas beyond that, then I guess we've succeeded in a sense—we got to move things a step forward and somebody else picked up the ball and moved it further again. Every time I see an OmniWeb feature in another browser, that's how I try to feel about it.

Vertical tabs.

KC: Yeah. Every time I see a new app come out and they announce vertical tabs, I'm like, "I remember vertical tabs. That's what I use in my current browser, OmniWeb."

It's a little disappointing to me if they never give credit, if people never acknowledge where things came from, but it's more important for me to just see things keep moving forward. I do live in this world where I want things to be moving forward, not backward.

I'd love to hear about how you personally organize your work, how you use OmniFocus and OmniOutliner and how you approach your day at Omni Group using the tools that you have.

KC: I have both apps running all the time. I have a lot more OmniOutliner windows open at any one time than OmniFocus windows. OmniFocus might often be hidden, in fact, because a lot of the tasks I do for work, we track in our bug tracking system, which is something we built back when we registered omnigroup.com—in 1991, the OmniBugZapper.

That's where my work lives—tracking what's going into the next version of OmniOutliner, for example. Here's a list of things with milestones associated with them, priorities, who's assigned to it, what the current status is, all that kind of stuff. So none of that work is in OmniFocus.

OmniFocus helps keep track of the stuff that is not being tracked by OmniBugZapper. Sometimes it's to capture things that aren't yet in BugZapper that need to get there eventually. I have things tagged for OmniBugZapper, and sometimes I'll just say, "Oh, remind me to do this," and later I'll see that thing in my OmniFocus database and I'll go file a real bug for it that other people can see.

Through the day, I'm not living in OmniFocus as a place to act on plans so much during my workday. It's a place where I'll capture things for doing stuff later so I can basically move on with my life and not be distracted by something or worrying that there's something I forgot that I need to get done.

Whereas OmniOutliner is a place where every time I'm working on something—if I'm working on a blog post, I might outline it in OmniOutliner. If I'm taking notes in a meeting, I'll take those notes in OmniOutliner. When I used to do meetings in person, I would usually write with pen and paper, and then later I would go back and write up those notes in OmniOutliner. The process of outlining the notes I had just taken was often a way to help clarify the ideas for me and made it more useful, even if I never looked at that outline again. The chance to do the rewrite really helped me process it and make it more useful to me.

I have a lot of outlines around things like "What are the product features we're trying to emphasize for this next version of an app or for this release?" I use both apps a lot.

What non-Omni tools do you use? Are there any non-Omni tools that you love?

KC: Of course. I use Apple's built-in tools—Mail, Messages. For work we use Mattermost. We use Discourse for forums for communicating with customers in a long-term way where you actually have history that lasts. We also chat with customers on Slack. You'll notice there are a bunch of these web tools that are the non-Omni tools and non-Apple tools.

Some of the native third-party tools I'll use are little things like SF Symbols for thinking about which symbol I'm going to use when I'm designing something. There are a lot of little things like that, but I spend a lot of my time either in Omni tools or in Xcode or in Terminal. Terminal's a big part of my life for sure. A lot of open terminal windows.

Before we wrap up, OmniOutliner 6 went out for testing yesterday. I started using it and I'm already falling in love with it. I would love to hear some thoughts about how you got to OmniOutliner 6 and what questions you were trying to solve.

KC: The first thing on our minds as we were designing OmniOutliner 6 is that we wanted it to be a universal app. When I say universal, obviously I'm talking about Apple platforms. It had started out as a Mac app at the start of Mac OS X. We had brought it to the iPad when the iPad came out with our "iPad or Bust" initiative back in 2010. Then we were in this world where we were going back and forth—now we'll do a Mac release, now an iPad release. We wanted to get away from that back-and-forth development process and instead do a unified development process, much like we've already done for OmniPlan and OmniFocus, where we release a new version for all the platforms at the same time.

Which has its own challenges, but it's easier now than it was 15 years ago because instead of having completely different UI frameworks—AppKit or UIKit—we now have SwiftUI where we can write shared code that runs on both at the same time. Not all of our code has been moved to SwiftUI, but there's a lot of common code now that can be shared. We wanted the feature set to a place where it had a lot more parity across all the platforms, where you buy the app once and you use it across all your devices. That's just how we think people work these days.

If you have all of your data across all the devices, what does that mean for not just the capabilities of the app but how you treat your data, how you have data linked to itself? We realized we had a problem there to solve, and that's where OmniLinks came into the picture.

Early versions of OmniOutliner already had support for links to other documents, so that isn't itself a new feature, but those links were based off file aliases and other Mac-specific technology that never made the transition over to iOS, which was originally a file-less system. All of that technology had to be rethought about how you make this portable from one system to another.

Back when we wrote the linking for the Mac, there really wasn't as much expectation that you'd be using multiple systems throughout the day. It was already a little bit broken if you went to share a document with somebody else and their username was different, so the paths were different. As the world started syncing and using completely different platforms, all that ability to reference content from another outline got lost. We wanted to get that back into place. That's really the problem we set out to solve with OmniLinks, and that's a big part of the OmniOutliner 6 push.

Another big interesting thing that happened was just this last summer, Apple introduced Liquid Glass, which is the first time they've done a design system across all of their platforms at once. Having a design system that's designed to be consistent—even if it's not perfect—is a big improvement. Having buttons that actually look like buttons on every platform, having the consistency so that now it's easier for us to document or take screenshots and have it look the same across platforms—there's a lot of value there. We wanted to take advantage of Liquid Glass. That's also an important part of doing a universal app now that works across everywhere.

We also set out specifically to add features that were missing on iPad. Full control over styles—when we originally did the iPad app, we were trying to make sure all the semantic content came over, but UIKit didn't even support rich text very well yet at that time. We had to build our own RTF reader. We didn't even try to match the appearance of the documents very much back then, but it became clear over time that what we actually wanted was to have full control parity. The ability now to inspect styles and see what's contributing, have full hierarchical styles and named styles and all of that—exactly the same on the iPad—with controls like vertical line or indent controls. That was another big piece of what we were working on.

Multi-window support on the Mac was another big feature we wanted. When I say multi-window support, we've always had multiple windows where each window was its own document, but we wanted the ability to open multiple windows on the same document. Maybe you're working on a really long outline—when I helped my mother with her doctoral dissertation, she was working in Word at the time, and we pulled it into OmniOutliner so we could restructure things in a much easier way than trying to move paragraphs around in Word. Once we got it the way we wanted, we exported it back out to Word and she went on and published her dissertation.

In that process, we were working with a very long outline, and it would have been great to be able to see the top at the same time as you're looking at the bottom, or have one view where all the elements are collapsed and the others are open. That's another big feature that we now have on the Mac.

To come back to OmniLinks—another problem we wanted to solve is that a lot of people at Omni use outlines a lot through their days, and we share these outlines. We want to be able to send somebody a link to an outline instead of saying, "If you go look in my staff folder and get into the documents, you'll find the latest plans from this meeting or whatever." Instead, I could just send you a link and have it be something that is shared and that they can open as easily as a link.

That's one of the things I think has been driving people away from native apps recently to cloud-based apps—this ability to universally link to content and share it and reference it that way. That was another problem we set out to solve with OmniLinks, and I hope what we have done.

I've already started using OmniLinks to much more cleanly manage the documents that apply to tasks. It's been great—I'm only a day into using it, but it has been great.

KC: Yeah, and it's nice that you can share those links anywhere. You can link to them from your wiki page or guide. We call it Guidebook internally, but you could put a link into OmniFocus and then just pull up that reference content.

It's been very smooth. So congrats on that. Here's the hot question: Are we going to see a Liquid Glass OmniWeb?

KC: Oh yes, for sure. What exactly that all looks like—well, you can imagine what some of that would look like.

I'm keen to see it. That is everything I had on my list of questions, except for one thing which I always ask everyone: Is there a question that you wish somebody would ask you?

KC: Oh goodness. I have not thought of that question. Thank you for asking that question. There probably is, but I probably don't know what it is.

A fair enough answer. This has been fantastic, Ken. Thank you for sitting down and chatting with me. Congrats again on OmniOutliner 6, and it's just been great to connect.

KC: Thank you so much for your time and for reaching out. It's been great to have this conversation with you.