I love Macs. The hardware is outstanding, and the operating system is beautiful and powerful. However, it’s the vast selection of high-quality, third-party apps that makes the Mac— and, by extension, iOS—the best choice for me. The quality, ease of use, and aesthetics of the applications on Apple’s platforms surpass those on any other operating system I’ve used.
In talking to my fellow US developers about why that is, I’ve found a common thread: By a large margin, the most interesting apps come from people who are out to solve a problem they’ve encountered themselves; I call it “scratching an itch.”
Sometimes those itches come from observing the friction in someone else’s workflow. But the idea is the same: If you can figure out a solution to a problem for yourself or for someone you know, chances are that a lot of other people are having the same problem and could also use a solution. If developers have anything in common, it’s that they love solving problems.
It’s not that developers aren’t concerned with paying the bills, it’s just that the best developers put the ideas first. If you can tap into a general enough problem, if you can generalise the solution to the point where it’s marketable, and if you can do all that without losing your passion for solving the problem, you have yourself a paycheck.
Many of my favourite third-party apps originated from independent developers who share this problem-solving approach: Acorn, Byword, MarsEdit, along with dozens of others. Those developers weren’t scouring support forums in search of random problems to solve just because they wanted to make a quick buck. They were scratching an itch that they, or someone they knew, had.
Knowing When to Say No
These apps have more in common than their inspiration. They also tend to provide a narrow range of tools in the most elegant manner possible.
The trick most of these developers have figured out is how and when to say no to user requests. If you’ve ever been on the customer-support side of a development project, you know that once users get to like an app, they start flooding the developer with requests for new features. Some of these requests make perfect sense. Others would require investments in time and money that wouldn’t pay off for anyone other than the one or two people who want them. Figuring out which is which is an important skill for any developer to have.
Independent developers don’t generally have access to the tools that would enable them to decide with statistical certainty whether adding a particular feature is a good use of their time. They do, however, have the liberty of deciding which features excite them and which ones best fit their vision for the app. The trick to avoiding feature bloat lies in finding the balance between practicality and passion.
Independent developers can do this. They get to choose their projects and make the development decisions personally. The result is a product that serves one purpose well and has a truly handcrafted feel.
It’s Not about Size
This isn’t to say that big companies can’t produce excellent software. I’ve seen many examples of amazing Mac apps from thriving companies with lots of employees; 1Password, Billings, OmniFocus, and ScreenFlow come to mind. Despite their developers’ size, those apps perform their functions superbly, with well-considered feature sets and well-focused, even beautiful, user interfaces.
Notably, these bigger developers still feel free to say no (diplomatically, of course) to feature requests from users; I’ve seen it happen repeatedly in their support forums.
Apple itself exemplifies this strategy in its product development. The company doesn’t put a lot of stock in customer surveys or consumer testing; it builds products that scratch an itch or fill a gap that the company sees. And as the markets attest, that philosophy has worked out extremely well—even for a huge company like Apple.