From 2003 to 2004, O’Reilly Media ran the O’Reilly Mac OS X Innovators Contest, sponsored by Apple via the Apple Developer Connection (now just Apple Developer). I still think of these winners as some of the high watermarks of app innovation. Many concepts we take for granted today were either introduced, or popularized, by apps on this list. Here are a few of my favorite examples:
NetNewsWire, while not necessarily the first RSS feed reader, was one of the most popular early ones. RSS feed readers are the origin of consuming media through streams of content, now exemplified by Twitter and Facebook’s Newsfeed.
SubEthaEdit was one of the earliest practical implementations of multiple simultaneous live document editing, a concept later brought to a much wider audience by Google Docs in 2006.
LaunchBar popularized many features we take for granted in search user interfaces today, such as seeing search results live as you type, fuzzy string matching, and combining search results of various types, such as apps, bookmarks, contacts, events, and files all into one unified interface.
I’ve listed the winners below, and linked to all the ones that are still maintained, so you can see visually just how many these apps are still around. All of these apps are over fifteen years old now.
Personally, I wish Apple had different priorities. I’d like to see more apps like Sketch, an industry-leading creative app that’s built top to bottom on Apple technologies. But Sketch was released in 2010, and Apple hasn’t created any new frameworks like Core Graphics and Core Image that support these kinds of apps in over a decade. So I wasn’t holding my breath for them to announce anything new for these kinds of apps at WWDC this year.
Since Apple isn’t prioritizing powerful desktop apps with their own technologies, that means supporting these use cases mostly falls on third parties. This is where companies like Adobe, Avid, Maxon, and Microsoft come in. While Apple’s priorities regarding their own technologies have been clear for awhile now, what hasn’t been clear is their priorities for third-party apps, in particular, ones that aren’t sandboxed. The trend for the last few years has been making it harder to develop these kinds of apps for macOS. AEpocalypse (2018), Catalina’s security features (2019), and Notarization (2018) are all examples of this trend.
The overarching reason behind the changes that make developing these kinds of apps harder is “Security”. And unlike cross-device feature parity, it’s unclear exactly where this all ends. Because after all, the most secure system there is is the one that doesn’t run any software at all. That’s why it’s such a pleasant surprise, that, as far as I can tell, Apple has done everything they can to make Big Sur, and the accompanying transition to Apple Silicon, as seamless as possible, even for apps that aren’t sandboxed.
I’m still frustrated that there probably won’t be another Sketch for the foreseeable future, but that ship sailed a long time ago. And no other platform has a Sketch either, an industry defining app that’s a platform exclusive, so while Apple has lost a unique advantage that only they had, they haven’t lost anything that other platforms already have. Other platforms can run powerful modular software that’s distributed outside the Mac App Store, but today, so can new Macs running Big Sur. Here’s to hoping that the dust has settled, and the last of the restrictions on third-party apps are behind us now.
These features have all since been built-in to every subsequent popular text editor. In addition, the scope selectors and theming implementation that TextMate pioneered form the basis of themes, syntax highlighting, and scoping language-specific functionality in every subsequent popular text editor.
That’s already an impressive list of features to all stem from a single app, especially one that entered an already mature category, and we haven’t even gotten to TextMate’s greatest influence: TextMate was the first popular text editor to be built around extensions. It’s this change that would entirely re-shaped text editor market forever, solidify the niche status of every text editor that came before it, and pave the way for the eventual dominance of Visual Studio Code, more than a decade later. Based on how subsequent text editors have all been built around TextMate’s use of extensions, it’s fair to call Sublime Text, Atom, and VS Code, “TextMate-likes”.
Gus Mueller has my favorite take on the news that Apple plans to announce the transition to their own ARM chips at WWDC. Of the various predictions people are throwing around, the only one Mueller gives any credence to is the prospect that ARM Macs will only running sandboxed apps1:
Assertion: ARM Macs will only allow sandboxed app.
This could happen. I give it a 50/50 shot at happening. Personally, I hope it doesn’t happen as there are still many problems with the sandbox on MacOS that have yet to be resolved, even though developers have been complaining about it for years.
Personally, I do not think that this is going to happen. In my overview of creative apps, I was stunned at how ineffectual sandboxed software has been. I keep a mental list of applications that aren’t sandboxed that the Mac absolutely cannot afford to lose, here’s the list2:
If the Mac were to lose everything on that list, then they lose the following groups:
Motion Graphics Artists
For creative professionals, essentially the only remaining users would be the tiny subset of developers, music producers, and video editors that work exclusively in Xcode, Logic Pro, and Final Cut Pro respectively. A Mac cut down to just those users is a dead platform.
This is a short list. There are many more applications I suspect should be on this list, but these are all applications that I’m familiar enough with both the application itself, and more importantly, the community around it, to know that people would rather move to another platform, then lose the application. ↩︎
We are in danger of losing one application from this list either way: Blender. As Mueller states:
Assertion: OpenGL is going away on ARM for MacOS.
Yea, this is totally happening. OpenGL and OpenCL have been deprecated for a while now in favor of Metal. Apple will use this opportunity to drop them.
My understanding is that this means Blender would have to support Metal in order to run on new ARM Macs. I think there’s enough intertia in the Blender community to support Metal, if the alternative is to lose the Mac as a platform, but I’ll be worried about this until that actually happens. ↩︎
Before I switched to being a full-time developer in 2010, I worked as a user-interface designer for seven years. Something that always bothered me during that time is that so much of what I was learning was just how to use Photoshop really well. After I switched to development, I was hesitant to ever invest that much in just learning a big software package again. “What if I choose wrong? And waste all those years of learning by switching to another software package?” I asked myself. Recently, I’ve re-evaluated that decision, based on my analysis of the market share of major creative applications. It turns out if I’d just chosen which software I want to learn ten years ago, for most categories, it would still be the same today. For some categories, it would still be the same if I’d chosen twenty years ago, and it’s often the first software that was ever introduced to solve a problem, even if that application is over 30 years ago, that’s still the best choice today. So it turns out I was overcorrecting relative to the risk in learning big complex packages, so now I’m investing in doing it again.
This is the list of software I’ve chosen to learn:
Some of these I already know quite well (Vim, Photoshop), and some I’ve barely touched (Premiere Pro, Final Cut Pro). I’m not happy with the duplication, and frankly, this is probably just too much for one person. Learning any one of these applications is an lifetime of work, let alone all of them. But I can’t decide what to cut, so here we are.
The new Productions feature set for Premiere Pro was designed from the ground up with input from top filmmakers and Hollywood editorial teams. Early versions of the underlying technology were battle-tested on recent films such as “Terminator: Dark Fate” and “Dolemite is My Name.” Special builds of Premiere Pro with Productions are being used now in editorial on films like David Fincher’s “MANK.”
When Apple pushed FCP to the industry pros five or six years ago, they did some hardcore outreach. They brought out Walter Murch, for God’s sake. The man cut Cold Mountain on it for God’s sake.
Versus Adobe Team Projects
Adobe already has an existing feature for video collaboration called Adobe Team Projects, that’s designed around a cloud workflow, Bedient describes the difference:
Productions is designed for collaborators working on shared local storage. Team Projects is built for remote collaboration: assets can be stored locally with individual users; project files are securely stored in Creative Cloud. The two toolsets are distinct and currently cannot be combined. Productions is part of Premiere Pro and is included with all licenses. Team Projects is part of Team and Enterprise licenses for Premiere Pro and After Effects. In order to support users working from home due to COVID-19, Adobe is making Team Projects available to all users from April 14 through August 17, 2020. See this post for more information.
Collaboration & the Future of Creative Apps
Collaboration is the word of the day, and it’s great to see Adobe taking it seriously, especially with a vision that isn’t web-based. The web is the platform that makes collaboration the most straight-forward, the easiest way to share something is through a URL, but a web app isn’t necessarily the best trade-off for all use cases.
The question at the heart of Figma’s success is whether it winning the user-interface design market means web apps are also destined to win other creative markets which have otherwise been the stalwarts of desktop native apps. But another way of looking at it is that the native app they are competing with, Sketch, was doubly harmed by Apple’s policies:
Figma may have only been able to succeed because Sketch was built on a platform that’s at best indifferent to their use case, and at worst actively hostile to it. That’s a big difference compared to the cross-platform native desktop apps that are still relevant: Microsoft will fight tooth and nail to make sure Microsoft Office stays relevant, and Adobe will do the same with Adobe Creative Cloud.
Pre-2004:BBEdit, Emacs, and Vim are all great text editors in their own right, but all have idiosyncrasies that, while beloved by people like me, prevent them from ever being the most popular text editor.
2004:TextMate is released, with its focus on packages to extend the editor and add support for different programming languages, but its API is still too limited to truly be a platform.
2008:Sublime Text is released, with a more sophisticated API, facilitating more powerful packages, but package management is still an afterthought.
2014:Atom is released, bringing package management to the forefront, but Atom has performance problems.
2015: Visual Studio Code is released, keeping packages front and center while also solving Atom’s performance issues. As far as I can tell, this essentially represents the final form for (mainstream) text editors.
I don’t see how VSCode can ever being contested again, unless its team makes a grave strategic error. We’ve seen over and over again, that once a platform takes off, its momentum creates a moat that’s almost impossible for challengers to overcome.
Zapier releases a new tool for annotating screenshots called Zappy, in the tradition of Skitch, and, my favorite, the unfortunately discontinued Napkin.
I’m fascinated by this problem, it seems so simple on the surface: Just share what I’m looking at on the screen and be able to mark it up. But this problem is wonderfully devious in ways that emphasize our expectations when using computers. For example, once something is digital, we expect it be perfect. A poorly-drawn digital line is somehow worse than the same line drawn on a whiteboard.
Consider editing text, one of the first things a new computer user learns, and almost immediately they can produce pixel-perfect text every time. The comparative skill for just editing a line, is a Bezier curve tool like the one found in Adobe Illustrator, which is extraordinarily difficult to master by comparison.
Sharing an annotated screenshot brings out two truths about computers:
We expect digital artifacts to be perfect.
Editing anything graphical with a computer is very hard to master.
We believe VS Code is an excellent product. That is why Theia embraces many of the design decisions and even directly supports VS Code extensions.
As to distinctions from VS Code, as previously mentioned it’s designed as both a desktop and cloud IDE, there’s some details about what exactly that means in the Architecture Overview:
The frontend process represents the client and renders the UI. In the browser, it simply runs in the rendering loop, while in Electron it runs in an Electron Window, which basically is a browser with additional Electron and Node.js APIs. Therefore, any frontend code may assume browser as a platform but not Node.js.
I’m curious what benefits this entails in practice over using VS Code with the open-source code-server.
Another major component is the Open VSX Registry, which is described in a The DEV Community post as “an open-source implementation of a VS Code extension registry that we have developed under the umbrella of the Eclipse Foundation” with the rational being:
Unfortunately, Microsoft prohibits non-Visual Studio products from installing any binaries downloaded from their marketplace (see terms).
Acorn grew out of upgrades to another app of mine, FlySketch, designed for screen capture and sketching. Customers asked for new features, I started adding brushes and layers and multiple windows, and all of a sudden I had a full-blown image editor. But Acorn still serves different needs than professional-level editors. Acorn is powerful, but nimble and approachable. It also has excellent documentation that we’ve worked hard on for years.
Unlike most browser-based email, which is server-based, Superhuman can store and index gigabytes of email in the web browser itself. This is possible by leveraging today’s more powerful APIs in the browser, along with the faster CPUs and hard drives on our computers.
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.
There are a couple of interesting products to look at for the future of creative apps: The first is Figma, the first-ever web app to gain traction with creative professionals, another is Lightroom CC, Adobe’s newer alternative to Lightroom Classic. Lightroom Classic is the same application Adobe has been shipping since 2007, it has more powerful features1, in particular fine-grained control over how your image files are managed on disk. Lightroom CC is a newer alternative, and it’s the only version available on mobile. Lightroom CC has no control at all over your image files (“the era of the file is over”—Scott Belsky, Chief Product Officer at Adobe). Instead, all of your image files are synced to Adobe Creative Cloud. While it’s still behind Sketch, Figma has clearly been a resounding success with professionals. It’s harder to gauge how successful Lightroom CC has been, on one hand, it’s not marketed to professionals to begin with, but on the other, it’s hard to interpret Adobe’s choice of the word “Classic” in the name as anything other than an attempt to drive users to the newer app.
The reason why I use it is that I’m used to it. I used Final Cut Pro from the very beginning of my career. For now — regarding sound mix and the workflow — it’s really simple to use. However, I haven’t been able to update my OS for four years.
BushelScript is open-source and community-driven, meaning it can undergo necessary changes and gain useful features rather than remain stagnant as a side project on life support.
The real tragedy of AppleScript is not its becoming obsolete or irrelevant; tons of Apple-supported macOS apps still have healthy scripting interfaces. No, the tragedy is that the language through which such functionality is presented, with all its quirks and weak points and even utter failures, is extremely unlikely to receive any badly needed improvements in the future, if any changes at all. It is stuck in maintenance (read: bugfix and security hole-filling) mode and will be for years to come if we, the users, don’t replace it with something better whose fate we can control.
On the WebKit blog, Apple announces they’re putting a “7-Day Cap on All Script-Writeable Storage” for privacy reasons:
Back in February 2019, we announced that ITP would cap the expiry of client-side cookies to seven days. That change curbed third-party scripts’ use of first-party cookies for the purposes of cross-site tracking.
However, as many anticipated, third-party scripts moved to other means of first-party storage such as LocalStorage. If you have a look at what’s stored in the first-party space on many websites today, it’s littered with data keyed as various forms of “tracker brand user ID.” To make matters worse, APIs like LocalStorage have no expiry function at all, i.e. websites cannot even ask browsers to put a limit on how long such storage should stay around.
In iPadOS 13.4 and Safari 13.1, all forms of offline storage for web apps will be purged after seven days. When I wrote about how iPadOS’s new mouse support will benefit web apps, there’s an additional observation that I neglected to mention: There are only two ways apps can target that iPad, either as a native app available through the App Store, or as a web app accessed through a browser. Since App Store rule 2.5.6 prevents browsers from using third-party rendering engines on iOS, this effectively means Apple has complete control over all methods of software distribution on iOS. And, since native apps are more of a differentiating feature for iPadOS than web apps, as the coming iPadOS mouse support starts to make desktop-class web apps usable on the iPad for the first time, we can expect Apple to correspondingly start hindering web apps in order to give native apps an advantage on their platforms.