Code by Kevin

PortAuthority 5.0

I've released version 5.0 of PortAuthority, my GUI for MacPorts. This is a big update for PortAuthority. Version 5.0 introduces a long-requested feature, the ability to install port variants; it improves the program's responsiveness during long-running processes, so it will be less likely to lock up; it now lists all dependencies of a specific port and their dependencies as well, to give a more accurate idea of just how much collateral stuff has to be pulled in to build a specific port; and, a feature that I'm personally proud of, robust AppleScript support so that PortAuthority (and, by extension, MacPorts) can be automated in various ways. AppleScript support seems to be an increasingly rare thing in Mac applications, especially as apps embrace the Mac App Store and its sandbox model, but I take pride in AppleScript support in my programs; adding this support to PortAuthority integrates it into the Mac OS at a deep level.

I believe this release reinforces PortAuthority's long-standing place as the leading GUI tool for MacPorts, and it is well worth checking out. As always, it is a free upgrade to registered users, and a great value if you have not previously bought a license. Give it a look.

Scripting languages for desktop apps on OS X: Why not?

I recently ran across a blog entry by Chris Adamson, in which he discounted the idea of a Ruby-based development environment for iPhone, and it got a bit of steam coming out of my ears. I have no special interest in using Ruby to develop iPhone apps, but the basis of his reasoning grates in my craw: a major effort by Apple to make scripting languages a "first-class environment for Mac development" was a bust, and therefore, scripting languages aren't suitable for application development. Here's a quote:

The reason I can say that is that Ruby was already tried and rejected as a first-class language for Mac development. In Leopard, Apple made Ruby and Python first-class languages for Cocoa development, creating Cocoa bindings for those languages and fully supporting them with Cocoa-Ruby and Cocoa-Python project templates in Xcode. Tutorials were posted... code was open-sourced... developer sessions were presented... And yet, there's no indication that there was any significant developer up-take. The Ruby and Python project templates disappeared in 10.6s version of Xcode, a seemingly quick admission of defeat, or at least irrelevance.

And this:

I'm not going to say that the C-based languages are ideal for desktop and mobile development, but the fact that they haven't been seriously challenged by the scripting languages, despite all the interest in and shared knowledge about scripting languages, makes me think that that they're the best choice we have.

To which I reply: the best choice for whom?

This circular reasoning--scripting languages with Cocoa bridges haven't become popular, therefore they are lousy choices for desktop development on OS X--grates in my craw. His corresponding assertion--that because scripting languages are unpopular, therefore C-based languages are the best option--is even more dubious. Speaking as the developer of a half-dozen commercial desktop apps, all in scripting languages, I find the suggestion that scripting languages are unsuitable for desktop development to be not only absurd, but patently false.

First, Mr. Adamson, popularity is not a measure of any intrinsic value. It simply measures the quantity of individuals who have a favorable opinion of something. No one should make development decisions using the logic of the Facebook "like" button.

Second, Mr. Adamson, your summary of Apple's push to make scripting languages first-class development environments is superficial. I'm not an expert on Ruby, but I can tell you that PyObjC (the Python-Cocoa bindings that Apple briefly supported in Xcode) existed long before the release of Leopard, and still exists even following the removal of the Cocoa-Python Xcode templates in Snow Leopard. PyObjC has been continuously maintained since the days of NeXT. Its developer community is small, but those developers are releasing successful commercial and open-source applications based on it.

Finally, Mr. Adamson, you appear fundamentally unsympathetic to the viewpoint that scripting languages can be used to develop desktop applications. Outside of arguing that scripting languages are unsuitable because they are unpopular, the only technical point you make is by referring to the "inescapable overhead" of a scripting language--i.e, that they are not as fast as a compiled language. But mostly you speak of popularity contests:

It is not plausible to think that lots of developers haven't already tried to use scripting languages for desktop apps. Surely they must have, and the results haven't yet been compelling enough to dislodge the compiled C-based languages.

I would challenge the statement that lots of developers have tried scripting languages for desktop apps. A sympathetic argument suggests that Apple has touted Objective-C/Cocoa for a long time, most developers have become competent with Cocoa, and are disinclined to try anything else. A cynical argument would point to snobbery on the part of some Cocoa developers, that they believe scripting languages to be developer toys and unsuited for serious development. (Mr. Adamson, I think you are guilty of this to a degree.) Regardless, a two-year effort to promote Ruby and Python as alternatives to Objective-C for Cocoa development isn't going to have a huge effect on the installed base of Cocoa developers.

I'd also like to make an alternative case for scripting languages, outside of the context of scripting language bridges to Cocoa. My preferred GUI toolkit is Tk, which is based on the Tcl scripting language, and which has bindings to a number of other scripting languages, including Python and Ruby. Tk runs on OS X, Windows, and various flavors of Unix, and it is the only major GUI toolkit that is optimized for scripting languages instead of being based on a C/C++/Objective-C framework.

I first gravitated to Tk as a beginning developer, about a decade ago. At the time, Cocoa seemed intimidating, but learning Tk was dead simple. The canonical beginner's exercise in Tk is this simple line of code:

pack [button .b -text "Hello" -command {tk_messageBox -message "Hello world!"}]

This code, saved in a script file or executed in an interactive session with the Tcl/Tk interpreter, draws a button that, when pressed, pops up a dialog saying "Hello world!"

This friendly, low-friction way of programming--quickly specifying a UI in code and testing it--led me to develop more complex programs fairly quickly. I began programming with Tcl/Tk in 2003, and a year later, I released the first alpha version of PortAuthority, my GUI for the MacPorts software installation project. Even with my relative inexperience, PortAuthority gained a user base because MacPorts at the time lacked any kind of GUI tool, and it has remained the leading GUI tool for MacPorts (and my best-selling program) ever since. Along the way, I also developed some skills with Python, and began releasing Python-Tk programs as well. Over the years I have developed a file search application; a GUI for another software installation system, Fink; a browser for man page documentation; a domain search tool; and a GUI for a command-line network monitoring tool. And I have other applications under development as well.

Tk's appeal reflects the appeal of scripting languages in general: the rapid development cycle, the ability to achieve great power in fewer lines of code, and the lower learning curve. Further information about Tk can be found at a superb documentation site by Mark Roseman, TkDocs, and the main Tcl/Tk website.

This brings me to the biggest objection against Tk: because it is cross-platform, it is not optimized for the Mac, and provides a poor user experience as a result. It looks somewhat out of place, and does not hook into a great deal of system-native functionality that is provided by Cocoa applications. That is a fair criticism, and the answer to it is to find ways to integrate Tk more fully into the Mac. I have attempted to do this by learning a good deal of Objective-C and writing various libraries to integrate Tk and the Mac, to the point where I am now one of the core maintainers of Tk on the Mac.

Even though I prefer developing with scripting languages, being a maintainer of Tk on the Mac has forced me to become competent in a number of Cocoa APIs and design patterns, as well as C and Objective-C. Apart from having a basic knowledge of NSView, NSWindow and other APIs for maintaining Tk's Cocoa port, I've written Tcl/Tk extension packages that hook into the NSServices API; drag and drop; printing; icon display and manipulation; and more. (Browse the Subversion archive at http://tk-components.sourceforge.net for examples of my Objective-C code.) Nonetheless, although I can find my way around these APIs, I have no interest in using them for application development. My view is that Objective-C is a low-level systems programming language, necessary for accessing native APIs and necessary at times for raw speed; in these respects it is very powerful. But embracing the entire Cocoa application development gestalt, writing applications in a complicated low-level compiled language and trusting my entire development process to Xcode and Interface Builder, is uncomfortable for me. Xcode and C/Objective-C are heavy, complex, and cumbersome, when my development practices stress lightweight, simple, and agile practices: write my code in a text editor, run my code in the Terminal.

I suspect that my long experience in writing Tk GUI's in code has made it harder for me to embrace the Xcode approach. Most of the main code packages of my applications don't exceed 2,000 lines of code, and the no-compliation nature of coding in a scripting language means that I don't have long delays in trying out different ideas, then waiting for the application to compile again. If your experience with GUI development is coding UI's in C++ or C, then perhaps the Xcode/Interface Builder approach is a big win. (One of the reasons Tk become so popular on Unix in the 1990s was just this--the prevailing method of coding UI's, using the Motif C API, was extremely painful, or so I'm told.)

To bring this back to the main point of my rant, and the suggestion that lack of popularity signifies that scripting languages are unsuitable for desktop application development, let me conclude with a challenge: Do you want proof that scripting languages can be used to develop desktop apps on the Mac? Just download one of mine, and see.

QuickWho for Mac OS X still in review

I'm pleased to report that QuickWho 1.1 for iOS is now available in the iOS App Store. I had submitted this release to Apple at the same time as QuickWho for Mac OS X, but the OS X version has been delayed over a period of weeks because of issues that Apple's automated upload process had flagged with the Mac version. These issues, which had not been previously flagged by Apple, required some significant under-the-hood restructuring of the application before the upload would even go through. That process is now complete, and now QuickWho for Mac OS X is now being reviewed. Hopefully it will be released soon.

The specific technical issues that Apple's automated upload process flagged concerned how some supporting libraries, or "frameworks," were bundled inside the QuickWho application package. Apple's guidelines require these libraries to be organized in a certain way, and the automated upload tool said that some files were missing from my upload. After correcting this issue, Apple still said the files were missing, although they were correctly included in the package I uploaded. After several efforts to get the application submitted, it became clear to me that either Apple's tool was in error or the application package was somehow being corrupted during the upload. Regardless of the cause, I had to shift gears and do some significant adjustments of how QuickWho is laid out "under the hood." This required moving away from the tool I had long used to build QuickWho, py2app, to cx_freeze, which structures its applications a bit differently and avoids the issues flagged by Apple. (This also required me to do some coding on cx_freeze's internals themselves, because cx_freeze's support for OS X is quite new and untested; this is a classic case of yak shaving.)

Now, finally, I've gotten QuickWho sucessfully uploaded, and I hope that it will be approved in a timely fashion.

If you're reading this and you're a Python developer who is submitting Python applications to the Mac App Store, I'd recommend checking out cx_freeze as a potential tool to add to your toolbox. py2app is terrific and handles things in a more Mac-native way, but I'm glad I was able to find an alternative deployment tool; otherwise I would have been stuck because Apple's opaque submission process left me unable to troubleshoot the problem via py2app.

QuickWho updates in the works

I've submitted new versions of QuickWho for Mac OS X and QuickWho for iPhone to Apple for updates in their respective app stores. I'm hopeful these will be approved and released in the near future.

It's been an interesting experience working on these releases, and I wanted to share some observations. First, I've moved to a unified development and release cycle for the application, so that the iPhone and desktop versions will remain in sync. Improvements in one version will also make their way into the other version. That was the case with this release: the code that searches domain information, which is written in Python, underwent a significant improvement, and I was able to incorporate this into the desktop code (for the OS X version) and the server-side code (for the iOS version). While the Mac and the iPhone are different beasts, I want an application developed for one to offer substantially the same functionality as the other; that, to me, is the real value of a mobile app.

I continue to learn as I go in the realm of mobile development, and as I gain more experience, I'm developing a set of best practices that will guide me going forward. Part of the process of updating QuickWho for the iPhone was updating its "shell," the PhoneGap (now called Cordova) application wrapper. I don't automatically update libraries because integrating an update can be a lot of work, but this update fixed some critical bugs in the library, so the update was necessary. Working with PhoneGap also isn't fun because it is tightly tied to Apple's Xcode IDE; I prefer to do most of my development with a plain text editor, the Terminal for running commands, and Safari for testing my web code. In desktop development, I find that this approach is more lightweight and flexible. I'm finding the same to be true for mobile development, although I also understand that this approach for mobile development means that I am deploying a less-native application than the PhoneGap shell, which gives access to many native API's on the phone, allows. For the apps I'm developing, this is sufficient.

Going forward, I'm looking forward to continuing a round of updates on my desktop apps, and developing mobile versions of them when it makes sense to do so. I think this will offer more value to my customers.

PacketStream 5.0

I've released version 5.0 of PacketStream, my GUI for the tcpdump network monitoring utility in OS X. This version introduces a configuration assistant to set the preferred network interface, which replaces the previous auto-detect mechanism that has proven to be inconsistent and unstable. The application also features smoother display of the network data in the data display, which previously had a tendency to lock up the application during a long-running scan. Finally, this version introduces more robust support for AppleScript. It's a strong upgrade, worth looking at if you are interesting in monitoring network data, and as always it's a free upgrade to registered users.

Free upgrades for life

Since I've raised the price of NameFind back to $24.99 and will keep my other apps at the same price level, I'd like to clarify my upgrade policy.

Except for a single product update dating back to my earliest days as a commercial software developer, I've never charged an upgrade fee for my programs. The chief reason for this is that it adds complexity to recordkeeping and licensing that I prefer not to wrangle with. I have a relatively simple licensing scheme that keeps honest customers honest, and does not require me to modify it if I do a major version release of a new product.

The introduction of the Mac App Store, which does not provide support for upgrade fees for products, has caused a lot of discussion among the Mac developer community. Many Mac developers rely on upgrade fees as a revenue stream for their products, to support continued development, and have found themselves wrestling with how to proceed in the wake of the Mac App Store. In my case, however, the App Store's free upgrade policy has not presented any issue at all, since free upgrades have always been my practice, if not my formal policy. My current licensing scheme and revenue model have integrated the Mac App Store with very little disruption.

Because of these developments, and because I have decided to resist the trend to lower app prices by keeping my prices at $24.99, I've decided to make my upgrade policy formal: registered users of my programs will never have to pay an upgrade fee.

Some developers may argue that I'm leaving money on the table by this decision, or at the very least may argue I'm limiting my future options. That's true. Some developers have boldly stated that they will never charge for upgrades, then economic factors forced a reversal of this decision.

I've had an unwritten policy of no upgrade fees, however, for about five years now, and have never felt the need to charge them. The huge impact of the Mac App Store makes the question of upgrade fees, like the question of prices themselves, a much more challenging one than in years past. My own answer to each question is to simply continue my current practice: hold the line on prices, and not to charge an upgrade fee. The only difference is that now I am making the no-upgrade-fee policy explicit, and official. Free upgrades for life.

So: if you buy one of my products, you will get the benefit of continued updates, without additional charge, regardless of where you buy it--directly from me, or from Apple. I think that's a pretty compelling proposition.

NameFind back to $24.99

Call it a failed experiment.

Last month I lowered the price of NameFind, my file search app for OS X. My hope was that this would stimulate more sales of the program, which was a slow-but-steady seller in the Mac App Store before Apple's sandboxing restrictions forced its removal. I was especially hoping that the lower price would encourage more impulse purchases, since ten bucks is the cost of lunch out at Arby's or Wendy's--and lower prices are an emerging trend in the wake of the Mac App Store.

Increased sales haven't proven to be the case. NameFind continues to sell at its previous, very modest, pace. My concern is that there won't be an offsetting increase in revenue to make up for the lower price.

Hence, I've decided to raise the price of NameFind back to its previous level of $24.99. If the sales volume doesn't change much with a lower price, then the higher price is actually necessary, because the revenue funds continued development.

Despite the fact that it doesn't sell a great deal, I am fond of NameFind, use it a great deal myself, and have plans for its continued development. Some forthcoming changes in OS X may require some under-the-hood retooling of NameFind, and I will be most inclined to take on such work if the programs remains viable, however modestly.

To the customers who bought NameFind at its lower price: thank you, you got quite a good deal. Enjoy. And to those who were contemplating the purchase of NameFind but didn't pull the trigger in time: it's still a great app, and worth the higher price. And to those cusotmers who purchased NameFind in the Mac App Store and can no longer upgrade to the latest version through that channel, please contact me for a free serial for the version downloaded from my website.

The same policy, by the way, will apply to my other apps: I no longer plan to lower their prices. They will stay at their current level, to fund continued development and to help compensate me for the time I put into them.

My websites--now mobile-friendly

Since joining ranks of smartphone owners by buying an iPhone 3GS, I've noticed that a lot of the websites I visit are optimized for mobile display--and the various websites I host are not.

Not any more.

Over the past couple of days I've tweaked the layout of my sites to make them display equally well in a desktop browser or a mobile browser. If you are looking at one of the poetry books I've published, a "purchase link" in a mobile phone will take you to a mobile version of the book's Amazon page. If you are looking at the same page in a desktop browser, the link will take you to Amazon's standard website for purchase. Seeing that effect is pretty neat.

This improvement was ultimately achieved by adding a slightly modified layout Cascading Style Sheet (CSS) for iPhone, and by adding a few lines to my sites' HTML to determine which type of browser was accessing the page. I got things working with my current HTML setup, some Googling, and a lot of trial and error of different design tweaks. Seems simple, right?

In one sense, yes, it's simple--a few dozen lines of text. But don't be mistaken: it's not a small project. The two business I run, poetry publishing and software development, host a dozen separate websites under various domain names on a Mac OS X server in my office. My sites have hundreds of static HTML pages, as well as three separate blogs running under a dynamic server setup, Blosxom.

Fortunately, my setup is designed so that large-scale changes are relatively easy to implement. When I started doing web sites for my business a decade ago, I used a popular HTML tool, Dreamweaver, to generate much of the HTML for my sites, although I used other tools as well, such as exporting HTML from Microsoft Word. Like many people using such tools, I had little understanding of HTML, but just wanted to get my web pages on display. Dreamweaver also has useful features for managing website structures, uploading pages, and more.

After a few years of this approach, which over time had generated several dozen web pages, I found it to be unwieldy. Because of the mishmash of tools I used to create web pages, I found that making any significant changes to the design of my websites was difficult: I often had to make changes to each individual page, which was time-consuming. Worse, some of the HTML was incredibly hard to change because under the hood it had vast amounts of unnecessary markup (especially the HTML generated by Word).

Finally, desiring to do a significant redesign of my sites and to make their long-term maintenance simpler, I bit the bullet and spent weeks diving into the HTML of my websites, ripping out all unnecessary HTML markup and formatting, leaving just basic HTML for each page's text, a simple page layout template applied by Dreamweaver, and a new styling tool I had recently discovered, CSS, which puts all formatting commands into a single file which are then applied by the browser when the web page is displayed. Instead of changing the formatting of dozens of individual pages, I can make changes to a single CSS file and then have those changes reflected in the site.

That's the structure I use to this day, and on this project to convert my sites to a mobile layout, it saved my bacon. Rather than develop a separate mobile version of my sites, I simply did some modifications to the core Dreamweaver template (to add some commands to detect the type of browser), and added a second mobile-specific stylesheet.

I'm not sure if my setup for websites of this scale--hundreds of static HTML pages with a similar design--is optimal, but it continues to work for me; I don't use Dreamweaver's design functionality much anymore, but I continue to rely on its site management features, which are robust. Migrating to a different kind of site setup, for instance using some kind of dynamic content management system (CMS), seems like a formidable and complex task of uncertain reward. So I'll most likely continue with this present setup, as I am far from outgrowing it.

NameFind 6, now outside the App Store, and cheaper too

Today I'm releasing version 6 of NameFind, my file search tool for Mac OS X. This release does offer some useful new features, including restored support for the Growl notification system, and other bug fixes, but this release is more significant from a business standpoint. Let me outline how this version of NameFind is different and what it means for the future direction of my software business:

Because of Apple's sandboxing requirements, NameFind is no longer available in the Mac App Store, but only from the Code by Kevin website. Apple has pushed back its sandboxing deadline to June 1, 2012, at which point all apps sold in the Mac App Store must comply with the Mac's sandbox API. As I've written before, sandboxing is a terrific idea from a security standpoint in that it forces each application to run in isolation and limits their access to other parts of the system. This is designed to prevent malware from taking over an application and possibly compromising user systems. In some cases an application can adapt to sandboxing without much trouble--both QuickWho and Manpower are now sandboxed apps.

However, in other cases, an application simply cannot function within the sandbox--its functionality requires access to a wider range of system resources than the sandbox allows. NameFind, an application that quickly searches your entire hard drive to find files matching a specific name, is such an application. According to bug reports filed with Apple, the search algorithm that NameFind uses simply cannot be made to function in the sandbox environment. If an application's core function cannot work in the sandbox, that makes sandboxing the application impossible. Hence, my decision to remove NameFind from the App Store and sell it solely from my website.

I'm not alone in opting to remove an application from the App Store if it cannot work in the sandbox: prominent Mac developer Manton Reece is another. There are others, as well. One significant reason for moving ahead with moving away from the App Store is that Apple is implementing another security API for Mountain Lion (the forthcoming OS X release, due this summer) called Gatekeeper. Gatekeeper is a system security setting that, at its default level, prevents users from installing a third-party application unless the application is signed with an Apple-provided developer ID key. Apple encourages developers to obtain this key, and if malware is found to be linked to a specific developer ID, Apple can revoke the ID, which means that users will be unable to install their products unless they set Gatekeeper's setting to "install everything." Gatekeeper is a nice middle ground between the "Wild West" mentality of installing anything that can be downloaded, and the locked-down safety of the Mac App Store. NameFind is signed with my new developer ID from Apple, and all of my other applications will be signed as their new releases come out.

I'm lowering the price for NameFind to $9.99. As I get used to browsing and purchasing apps from the Mac App Store as a customer, I notice that most simple utilities seems to be priced between $10 and $20. Extremely powerful, sophisticated applications can certainly bear a higher price, but my sense of the market is that all of my applications fall into the simpler end of the spectrum. They do one or two things very well. I've come to the conclusion that $25 is a bit overpriced for a one- or two-feature utility. Another data point for this conclusion, apart from a broad survey of the market in and out of the Mac App Store, is that my sales have declined over the past few years after I raised my applications to the $25 price threshold--not just in unit sales, but in actual dollars. I've long tried to justify the price of my applications by pointing out that they save the user time, but when it comes to voting with my own wallet, I prefer to focus on apps in the $10-15 range. An app that costs $25, for me at least, presents a somewhat higher value hurdle to clear: I'm going to weigh my options a lot more with a $25 app than with a $10. That may not be 100% rational, but I don't think I'm unique in this regard.

I've always said that the first place I begin in developing an app is to scratch my own itch: create an app that solves a personal need. If I need an app and it works well, the chances are that others will agree, as well. I think the same should be true of pricing. I'm quick to buy simple, inexpensive apps that solve a focused problem and save me time. I'm slower to buy an more expensive, albeit more robust, app.

Note to customers who have bought NameFind in the Mac App Store: If you have bought NameFind from the Mac App Store, you will not be able to update to the latest version through the App Store. Please contact me privately to discuss the situation.

Up to date

With yesterday's release of my TclGrowl package, I am now up-to-date on all outstanding open-source projects. That's a good thing, because my open-source work is the foundation of my commercial work.

Look for a lot of activity in the near future on my commercial projects as well.