Private APIs
Now that my candidate is on his way to being sworn in and doing something about all our huge problems, I find my mind turning to other topics that once held its attention more fully. Like Apple developers for instance. I once worked in developer relations, I’m not an engineer, but I can speak geek well enough to get myself in trouble. I’ve already commented on one thread running through the Mac community, another has to do with iPhone development. Specifically the topic of private APIs.
To which my short reaction is: remember Mac OS 9? Remember how Apple couldn’t do anything, introduce any new feature, without breaking some application that was VERY IMPORTANT TO THE PLATFORM because that application had figured out how to make something work that wasn’t documented. (And was generally Photoshop, Word, or some utility.) Apple prefers it if stuff doesn’t break. *I* prefer it if stuff doesn’t break. It doesn’t make anyone look good. Ultimately it never makes for a great user experience. So doing no harm is a good thing. It is probably a little easier to break consumer workflows than business workflow. So, with iPhone, Apple may be more willing to break applications that use private APIs in order to fix things. But most people don’t like to. If you can get away with adding most of a new feature, and still let something else work, that’s the choice you might make, if you were an Apple engineer working on new stuff. And that leads to the situation that Apple faced with Mac OS 9.
It may very well be that OS X is far more superiorly architected than Mac OS 9 ever was, and all the whizzy NeXT things would prevent such a thing from ever happening. Obviously there aren’t as many fragile extensions in Mac OS X, and mostly, those can’t exist on iPhone. So maybe it’s not as big an issue, but to developers I’d say follow the golden rule: if you don’t like things breaking, don’t do something that’ll eventually break.
And if instead you are going to use a private API, because you’re so effing clever, perhaps you could let customers of your product know - say something like “Program XX works with this version of iPhone software. I’ll/company will do my/its best to keep it functional for 2 future iPhone software releases. Major updates to iPhone software may require a paid update to Program XX.” Own the problem, don’t make it Apple’s. Keep the iPhone experience great.
Another thread running through the developing world is a discussion of iPhone app store quality vs. quantity. Who judges quality? I think Apple is a poor judge. That is, Apple is a fine judge of its own app quality, but may not be impartial enough to rate others, design awards notwithstanding. If I were Apple, I would give select reporters, such as Walt Mossberg, David Pogue, Andy I, Jason Snell, Rik M. TidBits, and some freaking women. Why is it that most high profile tech writers are male, anyway? And iPhone select and premier developers, and high profile iPhone blog authors, I’d give them 12 “badges” that they could tag apps with per year. They’d get a profile page in the app store. Developers could not tag their own apps (and would sign agreement to reduce conflict of interest). Then you could see that an app had been tagged by someone. Someone with taste.
Reason #647 that I resigned my awesome job with Apple was that I could see this quality/quantity problem. I didn’t really want to be in the business of marketing Britney Spears or whatever the latest boy/girl band was. It’s not *my* taste. Apple would have had to pay me a LOT more to do a great job with that. Same thing with the app store. They kind of need to accept everything. It’s the difference between being the underdog, and the market leader. Once you are market leader, you can’t have as many opinions, or you’ll offend somebody, somewhere.
Curated editorial, however, might work. That is, Apple could have opinions about who has taste, and let them be the judge. Also, the Apple corporate machine moves way too slowly to have opinions about whizzy new apps. Why not let the market move nimbly.
Comment from Scott
Time January 17, 2009 at 11:14 pm
Most tech writers are male because they start with tech, then become writers. Most females start with writing. Then they get involved with tech, backing into it rather than pursuing it for its own value. If you “back into” writing on a subject undear to your heart, the gnawing fear that you cannot summon sufficient knowledge for a given topic will gnaw at you, and will avoid writing.
Mostly. In my opinion.
How do “techies”, “geeks”, and “nerds” get to be writers? Whenever you develop an application, you eventually have to explain it to the user. If you do a poor job of explaining, your reward is repetitively explaining the same thing over and over. Practice makes better, and the better you get at effective writing (i.e., your rewrites of your explanations and instructions for your code gets faster, with fewer rewrites), the more likely the outcome that you will continue to write for its own reward. Of course, some people had off all that writing off to someone who hasn’t developed the app, and we’ve all seen the results from that!
In my opinion, and only from anecdotal evidence (and a passing glance at several reports that back up this opinion (this methodology has a name, incidentally…”confirmation bias”)) women are not as attracted, by biology, to hardware and “science”-based stuff. I have my own two sisters, and my mother, as contrary examples, but for the population at large, I feel safe in saying that this is true. Thus, given that the overwhelming number of “techs by choice” are male, and a smaller subset of them are writers, and a smaller subset are effective writers, it is little wonder that a crushing majority of tech writers are male…