Code by Kevin

About
Code by Kevin, Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.



Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

Archives
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006

Categories
Business
Software
General

Privacy Policy

Site design: Skeleton

 

Thu, 31 May 2007

Entering year two

I had a lot of good responses to my blog entry about my first year as an independent Mac developer. I received numerous e-mails, was interviewed on the YourMacLife online radio program, and had comments from other bloggers.

What was especially interesting was the response from the Mac Software Business mailing list. A few of the folks there were encouraging, but many of the developers there were not. Specifically, they dismissed my work as "ugly" because I don't develop in their framework of choice, Cocoa. Instead, I develop in Tcl/Tk and Python, with Python's Tk bindings. "Your interfaces look wrong. You don't use native toolbars. You don't use native search fields. The applications look clunky. How can you sell anything?" Phew. "Learn Cocoa," they said. "It's the best way to develop on OS X."

Well, yes and no. A lot of independent Mac developers use Cocoa, and it's also true that this is Apple's recommended approach. However, there are Mac developers who also use Apple's Carbon frameworks, either directly via Apple's Xcode environment or through a higher-level wrapper such as RealBasic. (Non-Cocoa developers tend to be fairly quiet on the Mac SB list about their choice of frameworks; they often get shouted down by Cocoa developers, who are, shall we say, evangelical about their tools.)

I've written about my choice of programming languages and frameworks before, and why I've opted not to develop in Cocoa up until now. It has basically been a business decision: up until now, I've decided that I can achieve more revenue by putting my applications out there in their present form, and continuing to enhance them, than I could by doing a major rewrite of them in another toolkit. End users can't purchase a program that isn't released.

Of course, it's necessary to occasionally revisit your business strategy. You always want to make sure you are in tune with what your customers want. Are my end users clamoring for Cocoa applications, or at least more fully Aqua-specific, without emulation of certain things like the search field? That's something I'd find much harder to disregard. Unfortunately, my customer feedback on this question is mixed. I've had some users complain about the "look" of my programs; I've also had some complain that certain features/functions are missing. On the other hand, I've also had compliments about my programs, from paying customers. And sales of my programs, such as PortAuthority, have improved as I've added new features and enhanced the interface of my programs with new icons--updates that greatly improve the program without requiring a complete rewrite.

So the evidence is, at this point, inconclusive.

I can say that, as year two progresses, I will begin exploring some different approaches. This is also necessary. There's a lot I can accomplish with my current setup, and some things that I can't. My experiments with some different approaches to application development may find their way into my product mix; these experiments may also convince me that my current approach is sound. In any event, I'm looking forward to it.

[/business] permanent link