Notes
Selling Mac Apps
Hey you guys, can I ask you a question? I promise, this isn’t a bit.
Is it just me, or is it really hard to sell Mac apps? It seems as though, in order to really do a proper job selling Macintosh software, you have to set up your own online store, and then you have to write the code in your app and server-side to deal with licenses and serial numbers and stuff. After that, you (optionally) write code to prevent your application from being pirated. Once you’ve done all of that, then you can work on your software, the thing you’re actually selling.
That’s the process that thousands of Mac developers have to go through. Think about how much we’re collectively re-inventing the wheel here — thousands of people are solving the same problem over and over, yet each is starting from scratch to do the whole thing themselves. It’s as if every architect felt the need to design an entry-exit device vis-à-vis a house and/or home, and each one of them took the time to invent the door. Y’know who’s kinda got this shit down pat by now? The door people. Why do software developers keep doing this to themselves? How is this not a colossal waste of time?
These guys, they’ve already figured out.
If I had to pick the single biggest thing that Apple has done with the iPhone, one of my frontrunners would have to be that they’ve made the process of writing, selling and distributing software super-easy. As an iOS developer, you don’t have to worry about implementing your own secure credit card payment system or anti-piracy measures to stop people stealing your app. That stuff’s all taken care of by Apple, giving you more time to work on that insanely great app.
Maybe there’s an opportunity for something like that in the Mac space — a product that, out-of-the-box, gives developers some space in an online store and a framework that lets them quickly and easily implement the licensing and serial number logic with just a couple of delegate methods. Think Sparkle meets Shopify.
I think this could be a thing. Do you?
13 notes
Inside Macintosh Volume I
This book arrived today in the mail.
I kinda have a thing for the original Macintosh. There’s so much history surrounding it. There’s the stories, the signatures, the ad, the demo. This thing is an iconic product.
To help developers stand on the shoulders of giants and make great applications for the Mac, Apple published Inside Macintosh in 1985. Much like Apple’s Developer Documentation does now, Inside Macintosh details the inner workings of the Mac OS (referred to in the book as “The Macintosh System” at first, and then “the System” thereafter) and tells developers what they need to really harness the Mac’s power. One bit I really like is the very first set of User Interface Guidelines:
(btw, these images are linked to their hi-res Flickr versions if you want to be a dork like me and read the text)
From “The Mouse”:
The mouse is a small device the size of a deck of playing cards, connected to the computer by a long, flexible cable. There’s a button on the top of the mouse. The user holds the mouse and rolls it on a flat, smooth surface. A pointer on the screens follows the motion of the mouse.
Simply moving the mouse results only in a corresponding movement of the pointer and no other action. Most actions take place when the user positions the “hot spot” of the pointer over an object on the screen and presses and releases the mouse button. The hot spot should be intuitive, like the point of an arrow or the center of a crossbar.
For most developers, this would have literally been the first time they had to contend with this new-fangled mouse-pointy-thing, so Apple had to choose their words carefully. Related: I sometimes forget that “double-click” has only been a single word for about 25 years. Before then it was, to quote Jesse Thorn, “two discrete words, like ‘base’-‘ball’ in the 19th century.”
Another bit of the User Interface Guidelines I really liked was the section on modes, which I’ve transcribed and uploaded as a text file. Given that the Mac OS was really the first software that didn’t lean heavily on modes, the onus was really on Apple to explain to developers (who, in turn, told users with their software) what it meant to not have software be modal, when it was OK to use modes, and what kinds of modes were OK.
Why buy this book?
Well, reading this stuff is nostalgic for me. It harks back to a time when computers were simpler, but also a time when writing software was more complex because of the level of abstraction you had to work at. I like reading about this stuff because it gives me an idea of where software developers came from. Reading about how things were done Back In The Day is inspiring to me. The original Mac was built by geniuses who had to use all of their wit and cunning to coax every last resource out of their new machine. Reading about their hard work motivates me to make awesome things. That’s why I bought this book. Plus, when I went looking for it, I found it for, like, $10.
So, am I ever going to sit down and read Inside Macintosh from cover to cover? No. But when I need some inspiration, when I want to be reminded of the creativity involved in writing software ca. 1985, when I want to try and get some of that original Macintosh magic to maybe rub off on me, this book will be on my shelf waiting for me.
