About Clarkwood Software

We design Mac software: Flowing Pennies, Multisite, & Peek-a-Boo iPhone software: ZibblerScribe, ZibblerPict, & Dingaling

What iOS Version Should Developers Target?



Here’s the punchline: iOS upgrades happen so damn fast that supporting the latest version shouldn’t be based on any complicated analysis of market share; just support the most recent version that you can safely develop on. Analysis done!

iOS 6 update stats

One of the reasons the Apple developer community is so awesome is that there are always fellow developers willing to share and help.

Statistics pages from David Smith and Game4Mob suggest that iOS 6 took less than a week to crack 50% share.

That’s right, the half-life of older iOS versions is a week.

Development Stability

As a general rule, I don’t like to develop for production using a beta SDK. (Things move so fast, though, that I may need to rethink this general rule.)

And I don’t like switching my development environment in the last “crunch time” of a project: keep the builds consistent is my opinion.

What this means, pragmatically, is that in the last month of development, I’m generally not going to update the SDK.

What this implies in turn is that it’s pretty much impossible for me to submit an app that requires a new iOS version until that iOS version has been publicly available for a month.

App Store Review Delays

Let’s not forget the week an app is likely to spend waiting for review. During this time, the rug is being pulled out (“forward”) from under the iOS version marketplace. If you submit an app on Day One of a new iOS version, then by the time it’s available over half of users will be able to run it!


This is amazing. I never collected my thoughts quite this way, but just looking at the raw reality, I have no idea why anyone would spend any time supporting an iOS version older than the current one. The only time it’s even worth a conversation is in the few days immediately following an iOS update, and then the time spent discussing it moves the window past the time where it’s worth caring about.

And although the data behind this post is derived from the first few weeks of iOS 6, each iOS version has penetrated the marketplace faster than earlier versions! This will become more compelling as time goes on.



Multisite Usage by the Numbers

We always enjoy learning how people use Multisite and have heard many stories over the years. Today though we head in the other direction to take a look at how people use Multisite from a statistical point of view. If you’ve ever wondered how your usage compares to that of others this is the article for you!

When you first started running Multisite you were presented with this dialog:

Only if you give permission do we gather anonymous data. We use this information to ensure we support meaningful configurations, understand usage patterns, focus our testing and to be aware of emerging trends.

To put this article together we took data from 608 unique (by IP address) customers pulled from a portion of April 2012.

The first chart looks at what version of Mac OS X people are using with Multisite in April 2012. This information changes (i.e. becomes outdated) fairly rapidly as Apple releases new versions of Mac OS X. From this chart we see that Lion adoption is well underway and that Tiger and Leopard have dropped off significantly.

Multisite Systems by Mac OS Version

Next let’s explore the topic of “how many sites do people manage?”. It turns out there are almost as many answers as people. After slicing and dicing the data we have the following:

 Number of Sites Being Managed

From this we see that 6% of Multisite users have a single site, just over 10% are managing 2 sites, 8% are managing 3 sites and so on. Combining everyone with 10 to 19 sites adds up to 19% and finally those with 20 or more sites cumulatively accounts for the final 20% of the population.

The first time we saw this data we realized 39% of people have 10 or more sites and 1 out of 5 people have 20 or more. This discovery made it clear that finding a particular site to work on is tedious for a lot of people. Since the next site they want to work with likely isn’t visible on screen and they’ll have to scroll to get to it. So in Multisite 3.1 we added search to quickly find a site by name as well as keyboard navigation so you don’t have to reach for the mouse to switch your current site – just use the Find (CMD-F), “Tab”, arrows, and the “Return” key for quick mouse free navigation.

Built in Memory

From this we see that 4 GB of memory is the most common and Macs with 8 GB are the next most frequent configuration.

Preferred Languages

Multisite is an English only application. However, by viewing what people have as their preferred language we see that 3 of 4 default to English. Put another way 1 out of every 4 would prefer another language if we were to localize the application.

Wow you’ve made it through the charts and now have a better feel for the stats of Multisite users and their hardware. It was a lot of fun analyzing the data and creating the charts. I hope you’ve enjoyed it!


Enhancing Creative Professional Introverts’ Effectiveness

Who Speaks for the Introvert?

Introverts work in environments constructed by extroverts, leading to work environments structurally biased against introverts (especially in creative professional spaces such as software engineering). Pushing back against this systemic bias can lead to enhancing introverts’ productivity. This is what is known as win-win.

Even saying introverted is “this close” to saying shy which is “this close” to saying weak. These associations are wrong (introverted and shy and weak are three separate things, of course), but simply starting a conversation (or essay, article, or blog post) about introverts, in other words, is starting out with a playing field tilted against introverts, just by the nature of the English language. I hope that acknowledging this bias in vocabulary will help ameliorate it.

Business Implications

I don’t know whether to blame human nature or reality, but the universe contains certain cruelties. One of these cruelties is the way human biases tilt our relationships in a way that expands the gaps between introverts and extroverts.

Organizational Structure in the Twenty-First Century

Who tends to zero in on technical career tracks? Introverts. Who tends to ambitiously climb the corporate ladder? Extroverts.

Neither of these phenomena are bad; indeed, they’re both good: the best people to handle technical problems are people comfortable in their own skin digging seven levels deep into such problems, and the best people to manage people are people people.

But the end result is that the people deciding how other people work are biased towards the extroverted end of the spectrum.

This is really the crux of this essay. If everything else gets ignored, fine, as long as we acknowledge this: introverts are working in environments constructed by extroverts.

If you don’t think this is a problem, that is evidence that you are part of the problem.

Whose Complaints Are Vocalized?

For some environments (a meeting-heavy open-space social vibrant environment, say), you won’t hear any complaints.

The extroverts won’t complain because they’re working well within their comfort zone.

The introverts won’t complain because introverts tend to suck it up and not be vocal complainers.

The absence of complaints, in other words, is not evidence that everything is cool.


I have found that Peopleware (DeMarco & Lister) perfectly articulates my opinions about a lot of things; most relevant to this essay is their opinion about meetings. “The ultimate management sin is wasting people’s time,” say DeMarco & Lister.

For meetings like daily stand-ups in Agile methodologies where everyone is expected to actively contribute, not only are Peopleware’s objections in play, but the introvert/extrovert schism can hamper effectiveness. I have not seen anyone acknowledge the drawback that for introverts, such meetings are emotionally draining.

Dilemma Mitigation

Obviously human interactions must take place. Building a strong team requires bonds between humans; and productively working requires communication.

The most common advice when mentioning an introvert/extrovert dichotomy is directed towards introverts about how to be effective in an extrovert-friendly environment. This is another example of a cruel universe being biased against introverts.

Solving the problems needn’t be forcing an introverted square peg into an extroverted round hole. There are solutions that are more introvert-friendly that still fit well in an extrovert-friendly environment. Here are two.


Lower the barriers. A social gathering is never going to be rejuvenating for an introvert, but it can be less wearying with some chemical assistance.

I grew up in a teetotalling environment, so this isn’t a natural thing to say (and let me add: sorry, Mom & Dad), but years of introvert observation suggest that alcohol is a good way to reduce the impedance mismatch between introverts and extroverts for a short while.

Status “Meetings”

Status “meetings” don’t have to be meetings. A daily “developer log” on a wiki, or a daily blog post, is a perfect workaround to let introverts participate fairly and non-uncomfortably. I’ve been contributing to a developer log (“devlog”) like this for years, very successfully.

(And this isn’t a case where comfort for introverts costs comfort for extroverts. Writing instead of talking can be done effectively by anyone in a creative-professional environment, whether they’re introverted, extroverted, or anywhere in between.)

And what’s more, an environment where daily status, plans, updates, and issues are created in a social-networking way not only provides the same information as a daily stand-up meeting, but provides it in a way that’s faster, less interruptive, and — maybe the most surprising advantage — intrinsically archivable.

Review the Introverts Dilemma

With just a couple of structural tweaks, and looking at the dilemma from a non-extroverted perspective, it’s not a foregone conclusion that introverts must work outside their comfort zone: solutions exist that allow introverts and extroverts to excel in the same well-crafted environment.


ZibblerTrip: Speedometer & Trip Analysis

ZibblerTrip is one of our recently-revealed iOS apps. It was under wraps and in development for nearly a year before we released version 1.0.

ZibblerTrip, on its surface, is a perfectly capable GPS-based speedometer app. But the driving force behind its design is to be even more useful later, after your trip is finished.

Whether it’s a drive, a hike, or a bicycle ride, the data stored by ZibblerTrip can be analyzed after the fact. You can review your trips directly on the device, even replaying trips at 60 times the speed. (Think of it as a second in the replay equalling a minute during the actual trip.)

Mount St. Helens Hike

Mount St. Helens Hike Data

This gives you a very clear overview of what portions of the trip may have more stoplights, or maybe were surprisingly fast.

(I have surprised myself when reviewing trips to find that stretches of my commute route that felt slow were actually faster because they were not interrupted by traffic lights; and other parts that felt fast were an illusion because I was accelerating and stopping so often.)

So even the on-device post-trip analysis tools can be useful.

And ZibblerTrip 1.0 is a first cut. We will be building on this foundation for a long time yet. In the future, expect more trip analysis features on the device.

But even today, you can export trip data. You can email the raw data to yourself and import it into a spreadsheet. The GPS support offered by Apple’s iPhones (and some iPads) is really amazing in the amount of data it supplies. You can see very fine-grained speed data, elevation data, and more. A few minutes in Numbers.app or Excel and you can wring out fascinating meaning.

Elevation Profile

Elevation Profile for Bike Ride

I’ve even used a spreadsheet to compare alternate routes, and I’ve found that my commute can be split into different legs that can be combined in interesting ways; I’ve also found that the optimal route to work can be different than the optimal route away from work.


ASCII Astro: an iPhone game with a retro twist

We’ve recently released a new iPhone app, and just for kicks this one is a game.


When I was younger, every time I got my hands on a new model of computer, I had to write a variant of this spaceshippy ASCII obstacle course. I think the very first iteration was on the TRS-80 Model 3 that was in my eighth-grade classroom. (I’m not sure how wise it is to be dating myself on the internet, but that’s how it went down, so there ya go.)

It was a BASIC program that printed out new lines to the bottom of the screen, while an ASCII spaceship on the top of the screen could be controlled by the arrow keys (or, for the especially ancient versions of this program, the comma and period keys). The program would PEEK the screen (ahh, PEEK and POKE, the hacker tools of the mid-80s) to see if a crash was imminent.

Variants of this program moved to my first Very Own Computer, a Commodore 64… and the Very First Computer That I Got Paid For Using, an Apple II. (I think it was actually an Apple ][.)

(Not to brag or anything, but I became familiar enough with the addresses that needed to be PEEKed and POKEd that I was able to sneak into department stores’ computer displays and enter a quick version of this program for the next customer to play. This was a favorite coming-of-age activity for those of a certain generation.)

This program never had a name, and honestly it never needed one. It was simple, fun, and if someone tripped over the power cord it was lost forever. (Unless a nerd like me wandered by again.)

Somehow I omitted a PC version, and I never got around to a Macintosh version either. But there were HP calculator versions for both the HP 42S and the HP 48 SX. (PEEK and POKE weren’t quite as exposed as they were in the olden days, though, so the program got more complicated.)

I’ve been using and developing for iOS devices for long enough that it is finally time to face the inevitable: the iPhone needs this app.

During a Clarkwood Retreat, ASCII Astro was a primary focus. The retro ASCII obstacles scrolling up were necessary, of course, but with a device as sophisticated as the iPhone, we could let the accelerometer control the spaceship.

That’s why the only instructions included in the game are these:


That’s really all there is to it.

And that’s really a quick brain dump of how ASCII Astro finally made it to the iPhone, where I daresay it’s the most satisfying variant of this 2.5-decade-old chestnut yet.


Peek-a-Boo and the Mac App Store

We (Clarkwood Software, LLC) in general and I (Bob) in particular are thrilled that after months of work, Peek-a-Boo is finally available on the Mac App Store.

The Two Variants of Peek-a-Boo

The Mac App Store is a new channel for us, so we’re still exploring how, exactly, we’re going to manage the two Peek-a-Boo variants or “flavors” going forward. And we’re going to have this conversation publicly (here!) so if you have opinions about what we’re doing right or (especially!) wrong, then please drop in a comment.

The plain old vanilla “Peek-a-Boo” name is migrating to the Mac App Store. If you use the variant of Peek-a-Boo downloaded from the Clarkwood Software web site, it will be named Peek-a-Boo ST.

(ST stands for Supplementary Technology because, as you’ll see, there are things that Peek-a-Boo ST can do that Peek-a-Boo cannot do.)

Mac App Store Technical Restrictions

There are some technical restrictions for applications that get sold through the Mac App Store. Peek-a-Boo needed to be changed for the Mac App Store version to avoid violating these restrictions. Basically Peek-a-Boo used to ask for authentication in order to extract process information (and perform some process management tasks) that require special OS permission.

(Some background is in this article about authentication.)

Peek-a-Boo ST still requires this authentication, and can still perform these tasks.

Peek-a-Boo Architecture Differences

Peek-a-Boo through version 2.8.5 installed a helper process (PeekHelperB) to do the low-level process information extraction, and to handle some of the more powerful process management features.

Peek-a-Boo ST continues to install and use this helper process.

But Peek-a-Boo (from the Mac App Store) does not install a helper process. Peek-a-Boo now relies on top. It turns out that with OS X 10.7 Lion, the included top command-line utility includes much of the raw information that Peek-a-Boo uses in an easy-to-parse format.

Peek-a-Boo Feature Differences

These are all mentioned on the Peek-a-Boo web pages, but here is a list of the differences between Peek-a-Boo ST and Peek-a-Boo all in one tidy bulleted list.

  • Although the major process information properties are available in both Peek-a-Boo and Peek-a-Boo ST, there are a few properties only available in Peek-a-Boo ST. For example, Peek-a-Boo can get the CPU time used of a process, but only Peek-a-Boo ST can extract how much of that CPU time is user time and how much is system time.
  • Peek-a-Boo ST lets you “kill” a process. It escalates through four increasingly-severe mechanisms (see the “kill” section on the process actions page). The final two mechanisms — the “most severe” — require the PeekHelperB daemon, so Peek-a-Boo omits these.
  • Peek-a-Boo ST lets you “halt” a process and “continue” a halted process. Peek-a-Boo omits this feature.
  • Peek-a-Boo ST lets you “renice” processes; Peek-a-Boo omits this feature.
  • Peek-a-Boo ST gives you much finer control over the speed with which most of the windows update. (Some background information is available in the performance tradeoffs with a shout-out to Heisenberg article.) Peek-a-Boo removes many of these timing options.
  • Since the Mac App Store handles updates whenever a new version of Peek-a-Boo is released, Peek-a-Boo no longer includes the (wonderful!) Sparkle autoupdate system. Peek-a-Boo ST continues to use Sparkle for automatic updates.

Peek-a-Boo Price Differences

Peek-a-Boo has been priced around $20 for its entire lifespan. We felt a little guilty charging a full $20 for a version of Peek-a-Boo that does not support the full feature set of Peek-a-Boo ST. We’ve priced the Mac App Store version of Peek-a-Boo at $9.99. I guess here’s how I think about it: 90% of Peek-a-Boo ST for half the price.

But that last 10%. Wow, that can be a doozie, if those features are features that you care about! So if you need the strong-arm tactics of a full-blown unix kill command, then Peek-a-Boo ST is still available downloadable from the Peek-a-Boo web site.

Pricing decisions are always an ongoing conversation, though. We may fiddle around in the months and years ahead.

Moving Toward the Future

Maintaining two variants of Peek-a-Boo — especially when their internal architectures differ as much as Peek-a-Boo ST and Peek-a-Boo — is tricky. We may try to merge these products.

One option — and this is me thinking out loud here — would be to have a single variant and a separately-purchasable downloaded component that handles the extra features of Peek-a-Boo ST.

In any case, we’ll be thinking about how best to continue moving Peek-a-Boo forward. Peek-a-Boo has been around for almost twenty years! Figuring out how it fits in with the Mac App Store is a very rewarding chapter in Peek-a-Boo’s story.


What Is Special About Peek-a-Boo?

Peek-a-Boo is Clarkwood Software’s OS X application to watch processes.

There are several factors that we think make Peek-a-Boo special; this blog entry explains some of the decisions behind Peek-a-Boo’s design philosophy and why Peek-a-Boo has been maintained, updated, and used for two decades.

Side Discussion: What is a Process?

Basically a process is a program running on your Mac. When you start up your Mac and begin to work, there are dozens of processes running simultaneously behind the scenes to keep your Mac working.

Each application that you open is another process, and each process may spawn even more.

Use Peek-a-Boo to explore processes

Peek-a-Boo is the most intuitive way to explore what’s happening in the universe of processes on your Mac.

Peek-a-Boo offers a wide choice of ways to help you explore the processes running on Mac OS X; you can choose between watching overall system behavior in a variety of windows, or zooming in to scrutinize individual process behavior.

Use Peek-a-Boo’s innovative OpenGL-powered Process Throb window for a hypnotic (yet useful) display of your OS X system’s processes. Or use the traditional Process List window to watch whatever process attributes you care about.

Many Pieces of Information Available

A primary design philosophy of Peek-a-Boo, since its 1.0 release in 1993 (well before OS X; in fact, System 7 was the current Mac operating system), has been that it should be able to show as many items of process information as possible, and allow the user the freedom to pick which of those items are important to view. That’s why you’ll never see a version of Peek-a-Boo with a handful of process information items hardcoded to what we think is the most important set of process information properties.

There are two common kinds of processes encountered on OS X (and a third rarely encountered kind), and Peek-a-Boo is the only utility able to display information about each kind.

  1. OS X Applications are processes which are OS X native and offer a user interface. Generally if a process has an icon, it’s an OS X Application.
  2. Darwin processes are generally lower-level processes, which do not offer a friendly user interface. These can be seen from command-line tools like ps and top, as well as from Peek-a-Boo.
  3. Classic Applications are applications running in the Classic compatibility environment. (These are becoming rarer, as more of the installed based of Macintosh computers are Intel-based; Intel-based Macs do not support the Classic compatibility environment.)

Virtually any piece of information can be seen in Peek-a-Boo’s process list. The View menu contains one submenu with many pieces of information that Peek-a-Boo knows how to extract (the Built-in Items submenu), and another submenu with all the pieces of information extractable by the ps (process status) Darwin/Unix utility.

Many Sources of Process Information

OS X offers several different ways to extract process information, and Peek-a-Boo uses all of them.

  • OS X’s Unix foundation supplies many pieces of information for each process (except individual Classic applications).
  • The ps command-line tool offers several dozen pieces of information for each process (except individual Classic applications).
  • The Carbon Process Manager offers information for each running application (but not low-level Darwin/Unix processes).
  • The Classic Process Manager supplies additional information for each running Classic application.

Peek-a-Boo is the only utility available which can extract information from all these sources and coalesce all the information into one easy-to-understand interface.

Focus on Processes

Peek-a-Boo’s design philosophy is heavily biased towards being able to analyze information on a process-by-process basis, as opposed to a system-wide basis. This focus can be seen in features such as the CPU Usage History windows and the Logging windows which also enable logging information to a file.

Highly Customizable

Peek-a-Boo has a history of being very highly customizable. The tyranny of being bound to eight pieces of process information is over! The View menu allows extraordinary customization of which process items you see (only a few if you want, or a plethora of arcane process data if you’d prefer), and the Preferences panes allow further view-specific customization.

Easy to Monitor Process Behavior

Peek-a-Boo makes it easy to monitor resource usage. Memory information takes the guesswork out of knowing when adding memory will improve performance; and Peek-a-Boo’s graphical CPU interface makes it clear when performance is CPU-bound.

Peek-a-Boo makes it easy to notice processes that are using a surprising amount of memory or CPU time. The logging windows can be very helpful for detecting processes that may leak memory over time. These features can be particularly useful to developers and quality assurance departments as well as anyone who simply wants to know what’s going on with the applications they are running.

Easy to Manipulate Processes

Peek-a-Boo makes it easy to perform process-specific operations such as bringing an application to the front, hiding an application, or killing a process. Obviously some of these features must be used with care, but having many common “tools” at your fingertips makes Peek-a-Boo an even more useful process-watching utility.

Psst: On The QT, You Need Peek-a-Boo

Peek-a-Boo has been described by one long-time user as “the utility I didn’t realize I needed, until I’d used it for awhile.”

Peek-a-Boo focuses on two things: clarity and flexibility. From the moment you first launch Peek-a-Boo, it will be clear what is happening with processes on your Mac. And you will find the flexibility to explore any process-related questions you face.

Peek under the hood of your Mac OS X system using Peek-a-Boo! Use this
powerful and beautiful tool to twirl into process-comprehension nirvana.

We’re confident that even if your frustration (towards the Mac’s complexity) is at its peak, a quick peek under the hood will pique your curiosity and lead you upwards, onwards, and forwards, twirling into process-comprehension nirvana.

Give Peek-a-Boo a try; see if you would also describe Peek-a-Boo as the utility you didn’t realize you needed.


Multisite 3 Supports Lion

We’re excited to release Multisite for iWeb 3 and add support for Lion, Mac OS X 10.7.

The release has gone well and while it may look like OS upgrades go smoothly, sometimes things are bumpy behind the scenes. The first time we tried Multisite version 2 with iWeb and Lion we had that jaw dropping moment of realization that it didn’t work. Upon further investigation we identified a solution but it meant that we had to make significant internal changes.

The most visible change for users is that in version 2 we stored data for the sites in the “Documents” folder in the file “Multisite for iWeb Data.mfi”. One part of the overall solution to working with Lion was to move the storage of data to the more traditional location at ~/Library/Application Support/iWeb/.

Ultimately we reengineered nearly half the application, upgraded code, adopted newer API’s, dropped the PPC instruction set, dropped support for Tiger (OS X 10.4) and Leopard (OS X 10.5).

Multisite 3 only supports Snow Leopard (OS X 10.6) and Lion (OS X 10.7).

This is a lot of change and the reason it’s good, is that Multisite is now modern and ready for the future. It will be easier for us to build upon as needed and we’ve already come up with one significant feature we’re excited to add in an upcoming release. More on that later and until then we hope you like Multisite as much as we do.


You’ve found the Clarkwood Software blog. Thanks for stopping by!

In this blog we share product news, tips and tricks, and occasionally other bits and pieces we think will be of interest. Even the occasional article on Clarkwood Software.

We’re located in the Pacific Northwest (of the United States) and formed Clarkwood back in the 90’s. After having started in the era of system 7, 8, and 9 it’s amazing to have been using Mac OS X for a decade and there’s also lots of excitement in the mobile space with Apple’s iOS on the phone and iPods. It’s great to see innovation and we’re always on the lookout for ways that Clarkwood can make products that surprise and delight our users.

Over the years we’ve written a handful of articles which you can find here.