With every WWDC, Apple announces more and more cool stuff for developers that make writing apps ever easier.
So that makes me wonder about the process of deciding what apps to develop. Assuming you have a ton of good ideas for apps, there are two basic ways to approach the decision:
1. Pick one that should be easy to implement because Apple has already given you most of what you need.
2. Pick one that should be difficult to implement because you have to invent a bunch of stuff from scratch.
For instance... when NetNewsWire 1.0 shipped, there was no WebKit for displaying HTML. There was an XML parser, but there was no object-oriented, easy-to-use Cocoa XML parser. The Cocoa bindings technology didn’t exist. HTTP networking was poorly supported. The XML-RPC support (for weblog editing) was so crashy at the time that I had to write my own XML-RPC client.
(When I was a boy, we used to have walk ten miles through the snow before we could retain an object. If we wanted to use
autorelease we had to go without lunch.)
You can’t draw a conclusion from one example, but I’ll give it a try anyway. The conclusion might be that #2—pick something difficult to implement—is the better choice.
I say that because it gives you a chance to be first at something, to do something new. If it’s a good idea and you’ve done a good job, your chances of success are good.
On the other hand, you could probably do three easy apps in the time it takes to do one difficult app. So there’s definitely that to consider.
However, while I can’t talk about most of what happens at WWDC, I can tell you it’s utterly predictable that, in six months or less, there will be 15 apps that do X, 20 that do Y, and 30 that do Z—just because X, Y, and Z have been made so darn easy to do. But those aren’t apps, they’re statistics.