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
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006

Categories
Business
Software
General

October 2017
Sun Mon Tue Wed Thu Fri Sat
       

Privacy Policy

Site design: Skeleton

 

Mon, 03 Dec 2012

TextSweep in Mac App Store

I'm pleased to report that TextSweep has been approved for the Mac App Store. It was rejected a couple of weeks ago because of a crash, but I suspected that the crash was a freak occurrence unrelated to the app itself; after resubmitting the program, it went through without a hitch.

I guess patience pays off! I'm pleased that I now have two new apps in the App Store; this doubles the number I have there, and I'm hopeful that my sales will increase as well.

[/software] permanent link

Tue, 27 Nov 2012

FileMorph in Mac App Store

I'm pleased to report that FileMorph, my batch file-renaming app, has finally been accepted into the Mac App Store. It's been a long journey: I first submitted the app in July, had the app rejected multiple times, then decided in September to move out of the App Store; then, earlier this month, I decided to re-target the App Store. I'm hopeful that FileMorph will do reasonably well in sales in the Mac App Store and represent the first step to expanding my portfolio.

TextSweep, my batch search-replace app, has also been resubmitted to the Mac App Store, but hasn't yet been approved. I received a report from the App Store tester of a mysterious crash, and I'm still trying to track down the source of that. Hopefully we'll get that resolved soon.

[/software] permanent link

Tue, 13 Nov 2012

TextSweep 1.1

I've released version 1.1 of TextSweep, my batch search-replace app for OS X. This version adds compatibility with Mac sandbox requirements, as I have resubmitted the app to the Mac App Store. Version 1.1 also has improved error handling. The new version is available immediately from my website, and the Mac App Store version will be available after Apple approves it.

[/software] permanent link

Sun, 11 Nov 2012

FileMorph 1.1

I've released version 1.1 of FileMorph, my batch file renaming utility for OS X, and am in the process of submitting this version of the app to the Mac App Store. The new version is available immediately from my website, and the Mac App Store version will be available after Apple approves it. This release improves the app's error handling, and implements compatibility with app sandboxing. The technical issues I was running into with implementing certain functionality in the sandbox have been resolved, which makes it feasible for me to move ahead with a Mac App Store version.

[/software] permanent link

Fri, 02 Nov 2012

Consulting

I have decided to add one additional line of business to my website: helping companies port their existing Tcl/Tk software to OS X.

My expertise with Tcl and Tk on the Mac, my knowledge of the Mac software market, and understanding of Mac UI conventions have convinced me that I can add some value in this area. This type of work builds upon, rather than takes away from, my work on my own products.

For more information, see http://www.codebykevin.com/consulting.html.

[/business] permanent link

On second thought...higher prices and the Mac App Store

A couple of months ago I announced that I was leaving the Mac App Store, shortly after announcing that I was reducing prices on many of my apps. My plan was to remove myself from the technical limitations of the Mac App Store, recharge the sales of my products with lower prices, and move forward.

I've decided to reconsider that plan, in all its aspects.

In terms of revenue, lowering my apps' prices hasn't had the desired effect on sales. I tried lowering my prices by 20-40%, but unit sales of licenses have remained fixed (varying within a normal range of sales), and so I'm making less money: about 30-40% less. Not a huge decline in absolute dollar terms, but that's not the direction I want to go in, obviously.

As a result, I've raised my prices. If demand for my products is relatively constant, and lower prices will not stimulate more demand, then it makes no sense to maintain lower prices.

After reviewing my sources of sales, I've also concluded that the Mac App Store is too big of a sales channel, and too significant a source of revenue, to withdraw. Fortunately I haven't actually withdrawn my existing products from the Mac App Store; I simply had decided to release my two latest apps without including them in the App Store. Given their sales thus far, I think they would benefit financially from being in the MAS.

None of my deep frustrations with the Mac App Store have changed--its slow review time, the technical limitations that sandboxing imposes, and more. But a rational assessment of where my sales comes from says that I can't ignore the Mac App Store--it truly does enable sales that I couldn't achieve elsewhere.

Over the past 18 months I've spent a huge amount of time on software work in realms other than my main development platform--desktop apps for the Mac. I've tried, and abandoned, Windows. I've entered, left, and decided to enter again the Mac App Store. I've spent a lot of work on open-source projects. If you follow my work at all, you would be fair in saying that I've seemed to lack direction and focus. My desire was to broaden my revenue base and grow my software business, but if anything, the opposite has happened--as I've moved in more directions, there has been a corresponding erosion in my core software business.

No more. All this experimentation has brought me back to where I started six years ago: trying to develop awesome commercial apps for Mac OS X, with a secondary focus on open-source work insofar as it complements, supports, and enhances my Mac apps. This is where I'm planting my flag. I'll wrestle with the challenges of the Mac App Store, and renew my focus on trying to develop new apps as well as enhancing my current apps. I'll continue to offer free upgrades for life, in keeping with the Mac App Store policies. And I'll focus on growing my business on the Mac desktop, confident that I've found the best niche and platform to work on--where I've been all along.

[/business] permanent link

Fri, 07 Sep 2012

Introducing FileMorph and TextSweep

I've just released the first new apps I've developed in several years: FileMorph and TextSweep. Both apps aim to provide a simple, elegant, and inexpensive option for running batch operations on files in a particular directory.

FileMorph allows you to change file names, file extensions, and file modification dates with just a couple of keystrokes. The app offers support for common file-change operations, without overwhelming you with options. The goal here is simple and fast. TextSweep allows you to do batch search-and-replace operations on text files in a particular directory. Again, the emphasis is on simple and fast.

There are dedicated commercial alternatives to both apps on the market, but they tend to be more expensive, and they can seem overwhelming with options and configurability. Other, less expensive alternatives exist as well, including shell scripts and AppleScripts, but such approaches can be fiddly and tedious to set up. Finding a sweet spot between moderate cost and power/speed was my goal here; both applications were born of frustration about the available options for performing modification of files and search/replace in multiple files.

For what it's worth, unlike many of the programs I've written, neither TextSweep nor FileMorph is a front-end to a Unix command-line tool on the Mac, although the system includes many such tools that provide similar functionality. The issue here, again, is speed and ease-of-use. By not calling out to command-line tools, each app is a bit faster.

Also, I've priced these apps moderately; each is $14.95. I was concerned that $25 might be a bit too much for utilities such as these apps.

Finally, neither app is available in the Mac App Store. Both were rejected multiple times by the App Store reviewers for reasons that I consider spurious, and as a result, I am no longer putting new apps in the Mac App Store, and will migrate my other apps out of the App Store in the coming months.

Both FileMorph and TextSweep are very useful tools if you need their functionality; give them a try and let me know what you think.

[/software] permanent link

Thu, 06 Sep 2012

Good-bye App Store

Two years ago Apple announced the Mac App Store, an Apple-developed sales channel to make finding and purchasing apps an easy process. There was a great deal of excitement among Mac developers about this new opportuntity to reach a wide user base with their applications. I was among those who migrated several products to the App Store.

Unfortunately, for many app developers, the App Store has proven to be a mixed blessing. While it offers many advantages, it also requires many changes to the ways application developers conduct their business. First, it requires submission of an application to Apple for review and approval against a stringent set of guidelines, every time the developer does a release. Apple can and does reject applications, sometimes for reasons that are not clear to the developer. Also, during busy periods at Apple, the review process can take weeks. For an indie developer who may need to push out crucial application updates on short notice--to fix a critical user-reported issue, for instance--this is less than desirable.

Finally, the most contentious part of the Mac App Store process is the requirement that apps run in a "sandbox." The sandbox is an environment of limited privileges for an application, in the name of keeping the user's system secure and preventing unauthorized access to other system resources: that's how Apple has presented the idea. However, in practice, what this means is that developers have to make potentially major changes to their applications' design to allow them to run in the sandbox; in some cases, essential functionality may have to be removed for the app to run at all in the sandbox. In the worst cases, the developer may decide to opt out of the App Store altogether, because the sandbox presents insurmountable hurdles.

An increasing number of developers are doing just this, choosing to leave the Mac App Store. And, effective today, I'm joining them.

Some of my apps have never been in the Mac App Store because their functionality cannot coexist with the Mac App Store guidelines. I've also had to remove an app from the App Store because the gradual implementation of sandboxing meant it would no longer function in that environment. But I've always made an effort to make an application work in the sandbox if all possible. However, I've reached a tipping point. Two months ago I submitted two new applications to the App Store, the first new apps I've developed in years. These apps have since been rejected three times by the App Store reviewers, and at least part of the problem was the permissions I was requesting for these apps in the sandbox environment. Specifically, the sandboxing environment won't let me call a system command-line tool to launch Safari (to view my product's web page) or Mail (so the user can contact me with questions).

This may be a small thing, but to me it's the proverbial straw that breaks the camel's back. I've used this functionality in my apps for years, I regard it as basic--the ability to contact me via an item in the help menu is simple customer service--and I am unwilling to remove it. Restricting such basic system access is simply ridiculous. So I'm not going to play in the sandbox any more.

What this means, in practical terms, is that I will be phasing out my apps' existence in the App Store; the next major update I release for these apps (QuickWho and Manpower) will coincide with their removal from the Mac App Store. I am simply no longer willing to limit my apps' functionality by playing by the sandbox rules. Any current customer who has purchased one of my products via the Mac App Store will be able to upgrade to a non-App Store version for free, per my policy of free upgrades for life. Please contact me privately to discuss the situation. You will not be penalized as a result of my decision to leave the App Store.

This is also going to mean a change in my development processes. For the past couple of years I have had a cramped and limited view of what my apps could do; I wanted to make sure they did not run afoul of App Store guidelines. No more. I will go back to developing the way I prefer: taking full advantage of the Mac's powerful resources.

I do understand Apple's concerns about user security and I do appreciate a different program the company has made available to help ensure user security: Gatekeeper. Gatekeeper allows users on Mountain Lion to configure their system's security settings to not install an application unless it is signed by a valid developer ID, provided by Apple. I am already making use of the Gatekeeper features in my apps and will continue to do so, to ensure that users feel secure with my products.

I'm not concerned about the impact of leaving the App Store on my business. My sales have been relatively steady since I migrated some apps to the App Store; the increase I was hoping for did not materialize. The App Store is not a silver bullet for a developer's bottom line. As a result, I do not see much financial downside in leaving. In fact, by holding up new releases for weeks and even months, I feel the App Store has cost me money. So this decision makes sense in many ways.

Look for releases of my long-held-up new apps in the near future, once I release them from the sandbox.

[/business] permanent link

Thu, 30 Aug 2012

Site updates and business adjustments

Thanks to some helpful feedback from the estimable Mac Software Business mailing list, I've made some modifications to the site and have adjusted some pricing on my apps. I'm also going to be moving forward with some new additions to this blog that focus on how my apps can help you solve specific problems. So keep posted for those.

[/business] permanent link

Tue, 14 Aug 2012

Adding a new language to the toolbox

For some time I've been seeking to add another programming langauge to my toolbox, which already includes Tcl and Python and their bindings to the Tk GUI toolkit; C and Objective-C; and AppleScript. Part of my reasoning for this is to keep expanding my programming skills; different languages can have different approaches to solving various problems, and getting some exposure this can make you a better developer. Also, languages have specific strengths, and not all languages are equally suited to solving a specific programming problem.

The language I've had my eye on is Ruby, a scripting language similar in many respects to Tcl and Python, but with some differences as well. Ruby has a rich set of libraries and extension packages, better in some respects than Python's, and a complete set of bindings to the Tk toolkit, which make it a good choice for desktop applications. Additionally, Ruby is an increasingly popular language, so the community surrounding it is large and growing.

Unfortunately, I've found that Ruby has a fatal flaw that prevents me from embracing as a suitable language for desktop development on the Mac: no deployment tools. There's no simple, actively-developed way to take a set of Ruby code, bundle it up with the standard Ruby interpreter and supporting libraries, and release it to end users as a standalone Mac application. All existing options are unsuitable: they are Windows-only (OCRA), do not support current versions of Ruby (rubyscript2exe and crate), or are based on an immature Mac-specific implementation of Ruby that does not yet fully support all features or libraries of the language and is incompatible with Tk (MacRuby). Python and Tcl have multiple ways to deploy a desktop applications, but Ruby has no viable way on the Mac, and this is deeply frustrating.

My initial response to this fact was to attack the problem in classic open-source fashion: roll my own. I started working on an app launcher that would intialize the Ruby interpreter, set some appropriate variables, and start the app. However, this approach eventually grew into a sprawling Rube Goldberg construction that piled ugly hack upon ugly hack. Eventually I decided this approach was untenable. Also, when I posted a mailing list inquiry about whether anyone else had interest in my project, it met with no response.

As a result, I began casting around for a different language. And it didn't take me too long to settle on a new one: Perl.

Perl was once the world's most popular scripting language, an enormously powerful but difficult-to-learn language with special strengths in text processing, and with a huge development community that contributed many, many extension packages for the language. Many other scripting languages take inspiration from Perl in one form or another, especially Ruby. While I had looked at Perl previously, I found that its focus on text processing didn't match what I was working on at the time, its dense syntax made my head hurt, and it didn't seem to have much of a constituency for development of desktop apps, particularly on the Mac.

However, my experiences with Ruby have prompted me to take a closer look at Perl, and, somewhat to my surprise, I have found that it meets all my Mac-specific requirements:

This is very heartening, rather surprising, and surpasses Ruby by a mile (classic Ruby also has no built-in mechanism for responding to AppleEvents or AppleScript).

So I think I'm going to be diving into Perl a bit more, trying it out, and developing a simple application before moving on to something more sophisticated. And, with some regret, I'll be leaving Ruby behind. But I'm excited to add Perl to the toolbox. Look for more discussion later.

[/software] permanent link

Sun, 05 Aug 2012

Back to the high-res drawing board

Well, both new apps that I submitted to the Mac App Store last week were rejected, both for minor issues. However, as Apple's guidelines are a continually moving target, I am now not able to re-submit them because they lack a high-resolution application icon optimized for the Mac's high-resolution Retina Display. So that means an as-yet-undetermined amount of work to get the apps looking crisp and clean on a high-resolution display. I'll keep you posted on how it's going...

[/general] permanent link

Mon, 16 Jul 2012

Finally, expanding the portfolio

It's been a couple of months since I posted here, but I have not been idle: I've just submitted two new applications to the Mac App Store. That is, two applications that haven't been previously released. This is the first time in almost four years that I've developed an application from scratch, let alone two.

It was just about a year ago that I wrote about my plans to expand my product portfolio, and it's taken longer to get to this point than I anticipated. I made a somewhat misguided effort to add Windows to my target platforms, which consumed the better part of six months, with no economic success. I've had somewhat better luck with iPhone development, with my first app, QuickWho for iPhone, doing better in sales than the Windows version of QUickWho did. iPhone development is a better fit for my interests, skills, and workflow than Windows was, and even though sales are off to a slow start, they have gotten off the ground.

While I do plan to do more iPhone development, though, expanding my portfolio of Mac products is really the key to growing my software business. My Mac apps earn far more per sale than my iPhone app does, and their sales volume is higher, so finally diving into Mac development with new products is important. iPhone development will be a complementary and, hopefully, growing business over the long term.

I'll talk more about the new applications when they're approved--hopefully soon.

[/business] permanent link

Wed, 30 May 2012

Apple's submission bugs

I've heard from Mac developer Michael Tsai that the recent issues I encountered uploading QuickWho to the Mac App Store were, in fact, a bug on Apple's end, and appear now to be fixed. That's good news, but what is unfortunate about this is that Michael had to use a paid Apple developer support ticket to get this addressed. As part of its developer program, Apple provides one or two "support incidents," in which you can have an Apple engineer take a hands-on look at a development issue you are encountering and are not able to solve through regular means (mailing list queries, diving into documentation, Google, etc.). You can also purchase additional support incidents if you want.

My complaint is that, according to Michael, Apple would not even investigate the upload issue at all without him utilizing a support incident--and that was also the response I got from Apple when I e-mailed the Mac App Store support group to report a possible bug. (Because I was able to find a workaround by modifying my application's internal layout, I didn't need to use a support incident.) It's certainly reasonable for Apple to direct a third-party developer to use a support incident to fix a problem with his or her own code, but I don't think it's reasonable to require the same when the issue is on Apple's end--and a critical one at that, which erroneously prevents an application submission from moving into the submission queue.

Regardless: Michael, thank you for pursing this issue. Many, many developers will benefit.

[/business] permanent link

Wed, 23 May 2012

Try the iPhone version of QuickWho

If you've purchased the desktop version of QuickWho, I have a suggestion:

Purchase the iPhone version.

The iPhone version of QuickWho has a different UI, optimized for the iPhone, but its domain search algorithm is identical: that piece runs on my server, which the iPhone version queries, downloads the data, and displays. It's a very handy on-the-go complement to desktop QuickWho, and better (in my view) than other whois clients on the iPhone.

And while it's not free, it's inexpensive: $1.99. Two bucks! It's definitely worth a look.

[/software] permanent link

Tue, 22 May 2012

QuickWho 4.0

I've finally released QuickWho 4.0 for OS X, nearly a month after completing substantial work on the new version. This release includes significant improvement in domain accuracy (previous versions did not handle .org and .edu domains gracefully), under-the-hood changes to accommodate new submission requirements to the Mac App Store, and minor bug fixes.

As noted previously, issues with submitting the new version to the Mac App Store caused the delay. I had to do some unplanned changes in the application's under-the-hood layout to get it through the Mac App Store submission process. Once that was complete, Apple's approval of QuickWho was quick, as I expected. The improvements in the new version make it worth a try, and as always, it's a free upgrade for registered users.

[/software] permanent link

Wed, 16 May 2012

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.

[/software] permanent link

Fri, 11 May 2012

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.

[/general] permanent link

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.

[/software] permanent link

Sun, 29 Apr 2012

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.

[/general] permanent link

Fri, 13 Apr 2012

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.

[/software] permanent link

Sat, 17 Mar 2012

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.

[/business] permanent link

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.

[/business] permanent link

Tue, 13 Mar 2012

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.

[/general] permanent link

Mon, 27 Feb 2012

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.

    [/software] permanent link

    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.

    [/general] permanent link

    Sun, 26 Feb 2012

    TclGrowl

    I've released TclGrowl, an updated version of my MacGrowl Tcl library that provides a Tcl interface to the Growl notification system.

    I've written previously about recent changes in Growl that broke Growl support in my applications--and many other applications as well. Because of other demands on my time, I have not been able to seriously review options for Growl support from Tcl. One options, developing an entire Tcl implementation of Growl's network protocol, was unappealing from a time and complexity standpoint. Just over the past few weeks I settled on a private solution for my own applications involving the "growlnotify" command-line tool, but this was less desirable as a general-purpose approach because it required compiling a specific binary.

    Happily, I recalled a version of my older, AppleScript-and-Tcl-based MacGrowl package created by Steve Landers of Digital Smarties for use in the TkChat application. Steve's version was more compact than mind and worked within a wrapped-up Tcl/Tk application binary.

    Coupling Steve's version with some modifications that the Growl team made to their AppleScript API to work with all versions of Growl, I was able to bring the TclGrowl package to a point where it worked with the new version of Growl. Testing it with the TkChat application, it works like a charm.

    As a result, I'm ready to release the tclgrowl package as a supported Tcl library. It can be downloaded here: http://www.codebykevin.com/opensource/tclgrowl.zip. Thanks to Steve Landers for his contribution, and hope others find this useful.

    [/software] permanent link

    Mon, 06 Feb 2012

    Still alive

    Seems like most of the recent activity on this blog concerns my "shutting down" this or that project or initiative. I am still alive, so here's an update about more productive things...

  • I'm taking a little time to put on my open-source hat, in preparation for doing some additional updates to my desktop apps. I just did a major commit to the Tk source tree to address some serious bugs with text input (thanks to Adrian Robert for the patches). Next thing I'm going to tackle is how to re-activate Tcl support for Growl, the venerable Mac notification system. The Growl team has recently done some major updates to Growl's internals that make the current Tcl implementation incompatible. Growl support has been broken in my apps for some time. I have a few different options here, ranging from providing a full Tcl interface to Growl's internal API to simply wrapping up Growl's external "growlnotify" command-line tool so it can be used from Tcl. (The Growl developers discourage using growlnotify for this purpose, which puzzles me; however, Tcl plays so well with external tools that growlnotify might be the simplest way to proceed.)

  • As noted, I've been doing some work on porting one of my desktop apps to run on the iPhone, and while that hasn't gotten off to a roaring start, the app has been accepted into the iOS App Store and I have learned a great deal in the process.

    I've talked at great length over the past year or so about my desire to expand my product portfolio, and hence my revenue, and the various projects I've undertaken have all been toward that end. Sometimes these initiatives work, and sometimes they don't. My foray into Windows development was clearly unsuccessful from a revenue standpoint, but it did help me clarify my priorities and focus: I am definitely a creature of the Apple world, and I will focus on work that fits with that profile. iOS development, while thus far no more successfully financial than my Windows work, is nonetheless a better fit, because it builds on work I am already doing on the Mac, and just as importantly, it does not require me to move to an entirely different platform (e.g., a Windows PC) to get work done. It feels more comfortable, and I am more comfortable being patient over the long term with my iOS work.

    So, look for more good news here as the year goes on.

    [/general] permanent link

    Thu, 19 Jan 2012

    No more user forums

    I've removed the user forums from my website, as they were becoming overrun with spam and with few postings from customers in months. This doesn't mean I am uncommitted to providing support; simply e-mail me at kw@codebykevin.com and I will respond to your inquiry in a prompt fashion. Thanks for your understanding.

    [/business] permanent link