This blog post is based on Nik’s talk given at NSConference 2013

When I started at Realmac back in October 2007, there were just the four of us. As the company’s grown (there’s soon to be 11 of us), we’re always working to ensure that all the smaller details in our apps are as polished as they can be - and the larger team means that we can take the time to hit things that previously might have been a lower priority. One area of personal interest is the copy that we use in our apps, and at NSConference I spoke about how “Copywriting is Design”. Here’s how I described the talk:

For all the focus on UX, we're still pretty terrible at communicating with our customers. As developers and designers, we're in a unique position to make seemingly small changes that make a huge difference to how people interact with your apps.

In this talk, we'll explore some common communication patterns that our industry typically falls into, how we can avoid them, and most importantly build our own (great) patterns to ensure that the copy in your app is communicating clearly from 1.0.

Today I thought I’d share a few of the points from my talk, and explore how we write interface copy in the Realmac apps.

Our Medium and the Expectation of Knowledge

In the last few years, we’ve seen the perception of what we build change dramatically - previously what would have been known as “software” or “suites” or “applications” has taken a more colloquial term: apps.

This change is important. The informality of the term “app” reflects how approachable the concept is to the average user. “Software”, on the other hand, is more formal a term and perhaps something that you’d be given by your employer.

This approachable name, and the incredible ease of access to apps, means that more people than ever are using our products. As a result, the expectation of knowledge is something we have to consider when we’re writing copy to go into our apps.

Terminology, abstract concepts, implementation details and bad translations are all things that need careful consideration. Understanding your audience is key - for example, an app built for developers might reveal more implementation details as they’re more technically literate. But would you intentionally use the term API in a consumer app?

White Lies

Talking of terminology and details, we spend a fair bit of time figuring out the right level of detail that an app should go into - be it error reporting or state reporting.

One example of what we call “White Lies” is found in Analog. When the user shares a photo to an online service, we obviously have to prepare the image that’ll be uploaded. But given that Analog is a very consumer-focused app, we questioned the need to say “Exporting Image” - for the target audience we felt this was an implementation detail that didn’t need to be disclosed. Instead, we simply say “Uploading”, and once we start the actual upload, the progress bar appears.

Disclosure

With iOS 6, Apple built in much-improved (and much-needed) options to safeguard your personal data - developers out there should watch WWDC 2012 Session 710. As part of these disclosure steps, developers can specify a (localisable!) string that is shown as part of the system alert asking for permission to access your Contacts, Current Location etc. Very few apps actually seem to make use of this - and those that do often use broken sentences or state they “need” access.

When defining our own style guide (which I’ll talk about in a future blog post) we decided to avoid stating that our apps “need” access to offer a feature. Instead, we always try to follow this conversation:

Alert Title: “Your App” would like to access your Current Location Ask yourself: OK, how does “Your App” use my current location? Alert Description: “{App Name} uses your location to show the local weather forecast.”

Don’t Be Lazy

Whenever I use an app, I find myself getting annoyed at generic alerts that state, for example, “Your iPhone or iPod Touch isn’t connected to the internet”.

Firstly: it’s always iPod touch (Apple has a style guide - make abundant use of it)! Secondly, it’s actually pretty simple (and App Store-safe) to check the type of device you’re running on.

As a result, we require that our developers take the time to ensure that the device type is always accurate - iPhone, iPad, iPod touch or Mac. In case of being unable to determine the type of device, we fall back to simply “device”. There’s one particular situation that springs to mind where this is pleasantly surprising - iPhone-only apps, running on an iPad, mentioning the correct device name (iPad) in alerts - but maybe that’s just me!

These are just a couple of topics from the talk that I’ve taken from our work - and in future blog posts, I’ll be talking a little more about the style guides that we use to ensure we’re consistent in how we communicate.

In the meantime, if you’ve got any questions feel free to give me a shout on Twitter - you can also pick up the video of my talk as part of the NSConference 5 video pack which has just gone on sale.

Just before Christmas, the Clear for Mac team gathered around a box that had arrived from San Francisco. Inside, was a rather intriguing piece of hardware. Over the past couple of months, we’ve been stealthily working on adding support for this futuristic piece of hardware to Clear for Mac - and today we’re thrilled to announce that Clear for Mac will soon support the rather incredible Leap Motion controller.

We’re still hard at work finishing all the interactions for Clear + Leap, however to give you an idea of how you’ll be able to use Clear with the Leap Motion controller, here’s a short video showing some of our work so far.

Stay tuned for news about this next Clear for Mac update by following Clear on Twitter, and if you’ve not already picked up a copy of Clear for Mac you can do so for just $6.99 on the Mac App Store!

Earlier this year we started discussing our longer-term plans for OS X support in our flagship app, RapidWeaver. It’s something we’ve given a lot of thought to, and it was particularly interesting to see the feedback from discussions with the users who drop by the RapidWeaver forums.

During our planning for RapidWeaver 5 way back in the summer of 2010, we heard from a lot of people that support for OS X 10.5.8 Leopard was a massively important thing for them. Our stats for OS usage in RapidWeaver (more on that in a bit) supported the case too. The numbers were going down of course, but there was a substantial number of customers particularly in education, who heavily relied on Leopard. So we decided to support Leopard - and still do in RapidWeaver 5.3.1, even on PowerPC systems!

In the intervening years, OS X has undergone a massive overhaul. PowerPC hardware went bye-bye, and then Apple phased out support for building PowerPC apps. Xcode 3.2.6’s default build architecture was “Intel-only”, and Xcode 4 removed support for PowerPC entirely.

If you hadn't realised it, over the last few years Apple’s ability to continually push new technologies has intensified to near-dizzying speed. From an almost-leisurely 18-month+ cycle between OS X releases, we’ve got annual releases of iOS now being feature-paired with annual releases of OS X. The tools we use are being built to support only the newer OSes and given the pace of OS updates and the significant change to our toolset, that obviously affects all developers - especially small teams such as ours!

Given that there’s no user-friendly way to specify which point-release versions of OS X an app supports (i.e. “supports 10.6.8, and 10.7.4+ but not 10.7.0 - 10.7.3”) the minimum OS requirement of your app then becomes incredibly important. So today I thought I’d talk a little about the thought process for our apps as we’ve been doing a fair bit of thinking about this stuff of late.

So What Do We Support Currently?

Our app lineup is interesting to look at, in terms of OS X support.

As you can see, there’s a definite trend! I’ve noted our support for PowerPC versions of OS X 10.5.8, as we treat that a separate OS release that we QA alongside the Intel variant.

So what do we consider, when deciding which versions of OS X to support?

What’s Everyone Using?

Our non-Mac App Store versions of LittleSnapper and RapidWeaver 5 have, since their respective launch, had the option to send anonymous information such as OS X version to us. To show you how we’ve seen OS X adoption skyrocket, here’s some hard data! If you’re wanting to see some more graphs, the folks at the Omni Group also publish their opt-in data. Before you check our data, I should disclaim it:

• these figures are only indicative and from a sub-set of users who have opted to share them anonymously with us;
• the numbers are not from the Mac App Store versions of the apps (however, the Mac App Store requires OS X 10.6.6+, and we consider Mac App Store customers to be more likely to update to newer OS X versions);
• there's potential bias, in so much as we consider people who update their version of OS X to be more likely to check for updates (which is when the information is sent to us).
• Because of the massive skewing of the data in launch month (lots of software update checks) we look at 3-monthly data. So, the stats below are for the period from two months before a major OS X release through to one month after it.

With the App Store making OS X updates even easier, and uptake of new OS releases quicker than ever, there’s certainly an argument to be made that developers should be targeting the newest OS releases. But that’s not the only thing to consider, of course.

Technical Restrictions

Sometimes there’s a technology so critical (or non-optional), that it effectively determines the minimum OS version. One such example is sandboxing on OS X, which has been constantly added to and improved. Sandboxing arrived in OS X Lion 10.7.0, but it wasn’t until OS X 10.7.4 that the sandbox matured enough for us to start adopting it - and as we gradually roll out sandboxing to all our apps, we’ll have to raise the system requirements to ensure we can reliably offer a great user experience.

OS X Feature Adoption

So after we’ve figured out where we have to set the system requirements, we get to the more subjective matter: which OS X technologies determine OS support - and is the developer feature mature enough.

Depending on the scale of the feature involved, sometimes a feature can determine the version we need. It’s not always the case, and sometimes we’ll progressively enhance our apps depending on the OS X version. For the next major upgrade to RapidWeaver, that’s likely to be what we do: offering specific features to a particular version of the operating system but still supporting an earlier version of the OS.

For Clear, whilst iCloud was available in OS X Lion it wasn’t until Mountain Lion that things settled down behind the scenes. Given the extra developer features and maturity of iCloud in OS X 10.8.2 which includes the improvements also found in iOS 6, we felt that this was the best version to target - and it seems we’re not the only ones to come to this conclusion!

Commercial Considerations

Knowing who to support, and the demographic you’re targeting is incredibly important. There will, depending on the scope of the app, be times where longer-term OS support is required - and if you’re supporting apps using iOS 3.x or iOS 4.x you’re probably running into issues that we face supporting OS X Leopard. They’re not insurmountable problems, but they’re definitely something to evaluate and plan for: the longer QA and development is something you’ll have to consider for every changeset and release, not to mention the speed at which you can adopt new features.

Decision Time!

So what’s the right choice? Unfortunately there isn’t one. Deciding the OS support obviously depends on what you’re building, who you’re building it for, and what makes sense from a technical and product marketing standpoint. Here at Realmac we want to offer (and are expected to offer) the latest technologies to the people who use our apps - and treading the line between cutting edge, supporting older systems and the experience our apps offer is a fine art! Our plans tend to be either:

1. Latest-only: When we launch any new apps in future, it’s highly likely this is the path we will take. Given that we’ll be under 12 months away from the next OS release, we want to be in a position to quickly iterate. Caveats are the potential lack of API maturity, and less widespread adoption, however a much smaller number of target OSes makes it easier to iterate the codebase and adopt new technologies.

2. Latest-minus-one: For example OS X Mountain Lion, and OS X Lion. This treads a better balance in terms of installed base - and depending on the versions you support, there’s pairs of releases that work pretty well together (10.5/6, 10.7/8). Obvious caveats however include the possibility of substantial changes between two releases for technologies that (for the end user) are perceived to be identical - again, iCloud for example.

As you can tell, there’s no right (or particularly easy) answer. There’s ways to support older OS versions if you absolutely have to, but it comes at the expense of a less modern and more convoluted codebase which may hamper your plans to iterate quickly. If longer-term OS support is required (either contractually, or philosophically) be sure to budget for the time needed to fully support these versions of iOS or OS X - but at the same time, be pragmatic about what you do support!

If you’ve got any thoughts, I’d love to hear them in the comments below - or just give me a shout on Twitter: I’m @nikf.

Since we launched Clear v1.2, we’ve seen plenty of people tell us that the removal of Google Maps from iOS was the reason they weren’t upgrading to iOS 6, which this version of Clear requires. As a result, I was particularly keen to see what effect a Google Maps app for iPhone would have on the number of people updating Clear - and last week I got a chance to see this in action!

So, here's a graph showing the number of updates to Clear downloaded from Sunday 9th December to Sunday 16th December inclusive. We’ve also looked at the sales data for that timeframe, however as Clear for iPhone is featured in the App Store Best of 2012 collection that makes it impossible to deduce if any of the extra sales are from the increased iOS 6 userbase.

It should be said that the number of updates being downloaded on each of the last four days is still less than 2% of the updates downloaded on launch day for Clear v1.2. However, with Google Maps seemingly the tipping point for many iOS 6 holdouts, the increased uptake of iOS 6 can only be a good thing for developers wanting to use iOS 6-only technologies.

Last night saw Apple launch its “Best of 2012” lists for the App Store and Mac App Store - and we were absolutely thrilled to see Clear for iPhone and Clear for Mac highlighted by Apple in their respective stores!

Clear for iPhone was featured in the “Intuitive Touch” collection, and in the US Clear for Mac was featured in the Best Apps of 2012 collection!

We’re truly honoured to be selected, and cannot wait to bring you plenty more awesome updates - and some new apps - in 2013!