Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
As this roundup at Michael Tsai's blog shows, an increasing number of Mac and iOS developers are having a hard time making a go of indie development. Even the developers of Vesper, considered the best notes app for the iPhone, have been unable to turn it into anything other than a part-time gig, and this is truly shocking considering the talent behind the app: Brent Simmons, a pioneer of indie Mac developers, who took a full-time gig at Omni; John Gruber, one of the leading Mac bloggers (and who, to be fair, likely doesn't need the income, as his blog generates upwards of $450,000 a year in advertising revenue); and Dave Wiskus, a talented app designer/UI specialist.
One culprit is the iOS and Mac App Store's drive for low app prices. As a result, some developers are raising prices. If lowering prices doesn't move the needle on sales, then raising prices certainly is worth a try. It's one reason I've continued to maintain a $30 price point for my own apps. If demand is relatively constant, then higher prices means more revenue.
Still, one thing that many developers do not seem to have admitted: there simply may not be room in the market for so many indie developers. Even if I concede Gus Mueller's cranky point that maybe my apps just suck, and Michael Tsai's observation that "fake is drawing a bunch of pixels into a plain NSView so that it looks like a text field or toolbar" (and to which I readily plead guilty), I think it's still true that the Mac and iOS app markets have changed in fundamental ways. When Brent Simmons has to take a full-time gig, what does that mean for the rest of us?
In other words, I'm afraid that for many of us, "sustainable software" may be less a strategy than a pipe dream.
As I work on updating my apps to take advantage of the improvements to Tk-Cocoa that I've overseen, I realize I am moving in a different direction than I did a few years ago: more Tk, less Cocoa.
What I mean by this is that I am gradually adjusting the balance my apps strike between native elements and aspects that don't hook directly into native API's. This process has been going on for a while, especially with the user interface of my apps; I've moved away from trying to use as many native Cocoa elements as possible at the user level. This gives me more flexibility in making changes when necessary, and also simplifies the development process, because by default Tk is easier to work with than Cocoa. However, I've also started doing this at a lower level in my apps, and also within Tk's internals, as the maintainer of the toolkit on the Mac.
One of the big architectural changes of Tk that I oversaw was removing a lot of Tk's direct use of Cocoa-based widgets, such as NSButton. Tk's drawing model simply can't handle multiple NSView-based widgets in a single window; it functions best when it draws everything itself, within a single NSView. Fortunately there is a Mac API to draw elements with a native appearance, HITheme; this allowed me to hand drawing of these widgets (buttons, scrollbars) over to Tk and still retain the native appearance. The result is more stable and faster drawing. Nonetheless, the balance here is more Tk, less Cocoa.
Another example of this is how I choose to implement Mac-styled features in my apps. In recent years I've gone deep into Cocoa to integrate these elements into my apps. Sometimes that works well, and sometimes it does not; for instance, my use of the 10.7 "fullscreen" API is not very stable, and crashed constantly when I was updating PortAuthority. (It had required a huge amount of code at the Objective-C level to work with Tk, and the result was not very satisfactory.) As a result, I re-worked my "fullscreen" Tk package to hook into Cocoa at only a couple of points--to set the fullscreen button in the window--but to otherwise pass management of the fullscreen transitions to Tk. (In technical terms, I wrote a category on NSWindow that overrides the "toggleFullScreen" method call to emit a Tk event, to which I could bind Tk's standard call to "wm attributes $w -fullscreen.")
Going forward, the question I will ask in going with a Tk-based or Cocoa-based approach will depend on a few factors: how smoothly does the Cocoa feature integrate with my apps, and how robust is a Tk-based alternative? The answer will likely vary on a case-by-case basis. For instance, my "macsheet" package, which displays Tk windows as modal sheet windows, works reasonably well in its current implementation, which uses Objective-C at a low level to set some basic properties, and uses a lot of management at the Tk script level to control the display of the window. It would be possible to implement a pure-Tk approach to the sheet window, but it's not necessary. As an alternative, while I've developed a package that wraps a Cocoa WebView to display HTML content in an app, I'm likely going to keep using a pure-Tk approach: the Tk script code I have works fine, and integrates well into my apps. I use the same approach for my app updating mechanism, which implements a Sparkle-style UI in Tk (while, in fact, hooking into Sparkle's XML appcast format under the hood).
Bottom line: it's sometimes necessary to hook into Cocoa at a low level, and at those times my apps will do so. But Tk offers considerable strengths in terms of simplicity, and at those times I am going to favor Tk.