The tipping point was May, 2011.

For the first time, the same number of people searched for app as software, ending software’s decades-long reign as the popular term for the stuff we run on computing devices. Program, application, software, applet, all replaced with a three-letter-word.

When Steve Jobs unveiled the iPhone App Store in 2008, it not only changed mobile development, it also changed the way we talk about software. Suddenly software invoked the old, boxy, expensive desktop relegated to the office desk. App invoked the new, the future, the next big thing you downloaded and tell others they should try. Software’s never been the same.

Yet perhaps software was the branding misstep. Apps were the software we were supposed to have all along.

What is software?

Software is “the programs (or series of coded instructions) and other operating information used by a computer”, or so says the Oxford dictionary.

Applications, then, are “a program or piece of software designed and written to fulfill a particular purpose of the user.” And app is a shortened form of the word.

Software does everything, the more at once, the better. You wanted the most bang for your buck when you bought software in a box. Even a single program wasn’t enough—Microsoft Office, Adobe Creative Suite, and more came as a bundle. You installed one thing to do everything.

Apps do a single thing, something that makes perfect sense on mobile with smaller screens and lower priced programs. A clock program might seem ridiculous on a computer; a clock app that does nothing more than tell the time seems normal on a phone. One app, one purpose.

You might then string them together. Text your friend about grabbing dinner, then open Yelp to find a good spot, tap a link to Google Maps to get directions, then tap their phone number to open your Phone app to make a reservation.

“There’s an app for that” wasn’t just a slogan. It restated an early philosophy that dated back before personal computers, to “make each program do one thing well.”

And with that, mobile apps brought computing back to the original Unix philosophy.

One thing at a time.

Long before there was a computer on every desk, much less every pocket, the Unix philosophy in the 1970’s declared, essentially, that apps should:

1. Do one thing well, so you build new apps instead of adding new features.
2. Speak the same language, so one app's output can be another’s input.
3. Iterate rapidly, so developers can test and discard anything that doesn't work well.
4. Lighten tasks, even if that requires building new tools to support the original idea.

Original software was simple, partly out of necessity, partly by design. There wasn’t much need for folders and tags in the email app, the mail command that still lurks in Terminal today. All it needed to do was to send and and receive email.

The Unix philosophy said that was enough for one program. Imagine you wanted to send an email newsletter. Unix said don't add a feature. Instead, you could list your email addresses in a text file, your email body in another, and edit both with vi. Then you could make a new program that would read both files, and send individual messages using the sendmail command. You don’t need to reinvent the wheel; you only need to invent the one new missing thing. You’d move fast without breaking as many things.

Decades before there was an app for that, there was a command for that. You’d string commands together to get work done.

Software interfaces abstracted it all away. Perhaps internally, they would still use the same commands to send mail and do other tasks. But to the user, the software was a monolith, a black box that did it all by itself.

Software that never sleeps.

Then Hotmail showed up in 1995, Salesforce in 2000, Google Docs in 2005, Dropbox in 2007. The web app race was on. Everything that could be done on the desktop could instead be a web app that worked on every computer.

Web apps took software back to their roots, again at first by necessity. They were simple tools focused on one thing at a time.

They started as a way to to build cross-platform software that worked equally well on Windows, Mac, and Linux (and mobile, once that revolution came along). But web apps quickly found their core competency as collaborative software that was better since it could be used together. The web apps built around collaboration took off and turned into positional software, business software that, for once, went viral.

Those web apps were, increasingly, built Unix style on the backs of other, simple apps. Code running on Amazon EC2 fetching data from S3, authenticating users with Google and Twitter, sending SMS messages with Twilio and emails with Sendgrid, accepting payments with Stripe, using Segment to send data to other apps, and on and on it goes.

It’s apps all the way down, one little service after another doing its part to keep the whole thing running. Some of the most valuable SaaS startups from the past decades haven’t been software consumers use directly—they’ve been the services that support the app ecosystem, Unix style doing-one-thing-best style apps that make the bigger apps possible.

Underpinning it all is the 2nd Unix philosophy of text outputs, so the data one app exports can be imported by another. That’s how you can export your address book from Outlook and import it into Gmail, and it’s the same principle that lets web APIs connect software with built-in integrations and connection tools like Zapier, IFTTT, Segment, and more.

Yahoo Pipes had the idea right in 2007, albeit a bit before web apps were ready to support it. It was based around RSS feeds and CSV exports, and let you remix the data into anything you wanted. Then as more web apps added APIs with webhooks and endpoints with JSON and XML outputs to share data, tools sprung up to translate each app’s APIs and connect web apps together. And an entire field of no-code development blossomed around apps communicating on their own.

Web apps won at first by letting people communicate together. Then with APIs, they cemented their position and replaced desktop software by letting apps communicate, too. It was easier than ever to build tools focused on doing one thing well, when you could outsource every non-critical function to other app’s APIs, and let your users expand your app by connecting it to any other tools they already used.

Software got back to where it’d started in Unix, just in time for a rebranding.

What’s in a name.

The word software had been under fire for years. Java applets started the trend; they weren’t software, they were something lighter, something simpler. Then came what were first called web applications, the newer software that ran in your browser. The Basecamp team shortened it to “web-app” in 2005. Salesforce founder Marc Benioff perhaps did the most towards the switch, branding his tool as the end of software with a logo to match. He then registered AppStore.com as the original name for Salesforce’s AppExchange that launched in 2006. It was only a matter of time before web app became the default new term.

And it spread from there. One day apps were things on our phone; the next, they were everywhere. One day software lived on its own; the next, our apps were talking to each other, automating work together.

Software the word is still around, though increasingly hidden inside acronyms like SaaS and CMS. App won—it’s searched over 5 times as often as software today.

“You still make software; you just deliver it differently,” Benioff recalls press complaining about Salesforce’s No software campaign. The delivery, though, is what made all the difference. It not only changed how we talk about software, it changed how we think about them, how we imagine they should work.

And now, there’s an app for everything.

Image Credit: Header photo by Umberto via Unsplash.