The Alt Alt Dub Dub schedule for Friday, June 6 is below. If you’d like to join us in the Parc 55, please contact Charles Perry by email at charles@metakite.com or on Twitter at @DazeEnd. In order to offset the cost of renting the room and equipment, there will be a $25 per day charge for admission. Sessions are already showing, so come on over.

Read More

The Alt Alt Dub Dub schedule for Thursday, June 5 is below. If you’d like to join us in the Parc 55, please contact Charles Perry by email at charles@metakite.com or on Twitter at @DazeEnd. In order to offset the cost of renting the room and equipment, there will be a $25 per day charge for admission. Sessions are already showing, so come on over.

Read More

tl;dr: Come join us in the Parc 55 to watch WWDC sessions as they they are released. Space is limited and there is a small daily fee to offset the cost of renting a room.

I came to WWDC 2014 without a ticket, as did a lot of other developers this year. Even if you don’t have a ticket, just being in San Francisco for WWDC is a great time, but not having a ticket makes it tougher to watch all the sessions you want to watch. Apple addressed this issue last year by releasing the videos of many WWDC sessions the same day that they were presented. But it’s no fun to hole up in your hotel room and watch technical videos. Alone, you miss out on the discussions and the shared insights of your fellow developers. Because I and a group of friends wanted a more social experience while watching videos, I rented a meeting room in the Parc 55, arranged for a projector, screen, and audio, and dubbed the result Alt Alt Dub Dub.

But yesterday, Apple made a big improvement to our WWDC experience. They dropped the non-disclosure agreement on WWDC sessions. That means that we can discuss what we learned in WWDC without legal worries hanging over our head. What that means for Alt Alt Dub Dub is that I don’t have to be as careful about who joins us for WWDC sessions. And so we are opening our doors to other ticketless developers who happen to be in San Francisco this week.

Space in our meeting room is very limited, but if you would like to join us to watch WWDC sessions as they are released, we would love for your to join us. In order to offset the cost of renting the room and equipment, there will be a $25 per day charge for admission.

We expect seats at Alt Alt Dub Dub to be in great demand. If you want to reserve a seat, please contact me by email at charles@metakite.com or on Twitter at @DazeEnd. We’re showing sessions starting right now, so the sooner you sign up, the sooner you can join us for sessions.

Our schedule for Wednesday, June 4 is:

Read More

Today we’re announcing that Leaf Hut Software is changing its name to Metakite Software. This change wasn’t made by choice, but because another company asserted their trademark over the word “leaf.” Although we maintain that our use of Leaf Hut Software did not infringe upon their trademark, it was decided that changing our name to Metakite Software was the quickest way to put this distraction behind us.

So what does this mean for all of our customers? Not much, honestly. If you use Benjamin, Action Lists, or Listmaker on your iOS device, your apps will continue to work just as they have in the past. The company has not changed hands, and you can continue to expect the same great support that you’ve received in the past.

The only change that our existing customers will probably notice is that the addresses that you use to contact us will be changing. Effective immediately, Metakite Software will be changing to the new domain metakite.com. That means you can get documentation and check out our other products at http://metakite.com, and you can get email support by contacting support@metakite.com. If you have a non-support question or comment, you can reach our general email box at metakite@metakite.com. All of the old leafhut.com addresses will be forwarded to their new metakite.com counterparts, so you’ll have ample opportunity to change your bookmarks and address book.

This episode has been a big distraction over the last few months, and frankly, it’s delayed a lot of improvements that we’ve been wanting to incorporate into our apps. But now that this is behind us, we hope to accelerate our efforts. Thank you for your patience, and thank you for choosing our products.

Read More

tl;dr

If you want to cut to the chase, you can just read my conclusions, then share your own results.

Introduction

Over the years, I’ve repeatedly heard people say that localizing an iOS app is important for maximizing the app’s audience and ultimately the app developer’s revenue. Apple urges developers to localize their apps every year at WWDC, and similar sentiments are often shared in conversations among developers whenever they get together. As the theory goes, people like to interact with their iOS devices in their native language, and they are therefore more likely to purchase an app if it’s available in the their native tongue. That’s all almost certainly true, but the key thing that no one ever talks about is the numbers. Does localizing an app really result in more sales? If so, how big of a difference does it make? In which countries is localization the most critical? How long will it take for the investment in localization to pay for itself? These are all questions that can’t be answered without some hard data to work with. Unfortunately, that data is hard to find.

Data on the sales impact of localization is hard to find, I think, because developers are reluctant to share too much financial information with the world. And rightfully so. But I realized after my own recent experience localizing an app, that the information that’s most valuable to other developers doesn’t have to be quantified in dollars and cents.

What follows below is an analysis of the sales data I collected after localizing one of my apps. This analysis is an attempt to collect and share data that I think will be valuable to other developers, but it’s also an attempt to model a process that generates useful data without revealing too much information about revenue. My hope is that the data will be useful to others, and that other developers will use a similar method to share their own experiences with localization. By sharing solid numbers, it gives all developers the opportunity to make decisions that are based on facts instead of guesses.

Background

In this study, I’ll be looking at just one of my apps, Benjamin for iPhone (hereafter, just Benjamin). Benjamin is a niche productivity app which sells for the relatively high price of $9.99. As a result of its small audience and high price, there are rather few daily sales – especially outside the United States. Benjamin has been available in the App Store for about a year and a half, and until very recently it was available only in English. As a part of a major update (version 2.0, released June (25° 20°)13), I decided that I should move beyond my English-only strategy and localize the app for other language markets.

To understand the language choices I made in localizing Benjamin, you first need to understand a little about the app and its audience. Benjamin is a task manager based on the FranklinCovey method of time-management. FranklinCovey is one of the world’s largest providers of time-management training, drawing their clients primarily from white collar workers in fields like healthcare, education, and other corporate environments. According to their own reports¹, FranklinCovey does business with 90% of the Fortune 100 and 75% of the Fortune 500. Their bread and butter are multinational corporations. As a result, their training is conducted around the globe and in many different languages. The multinational character of FranklinCovey’s operation was an important consideration in my decision to localize Benjamin. FranklinCovey conducts training around the globe, so it’s reasonable to expect that Benjamin has potential customers around the globe as well.

With this in mind, I decided to localize Benjamin into five additional languages: Spanish, German, French, Japanese, and Simplified Chinese (which is used in the People’s Republic of China, but not in Taiwan and other Chinese speaking countries). These languages were chosen because the countries in which they are primarily used have all widely adopted the iPhone and iPad, and they all have a large base of people trained in FranklinCovey time-management – with the notable exception of Simplified Chinese. FranklinCovey has only had a presence in China since 1998², but it’s a booming market with enormous growth potential. I decided to include Simplified Chinese primarily as a prospect, so that my app would be ready as the Chinese market grows and matures.

Assumptions

As much as I wish it were not the case, I don’t have perfect information about my customers. I don’t know where they come from, how they found my app, or even which languages they speak. Consequently, there were a number of assumptions that had to be made in performing this analysis. I list the major ones below so that you can decide for yourself if they are valid.

Geography and Language

Apple doesn’t provide any information about the language used by those who download apps from the App Store, but it is possible to determine from which country’s store a customer purchases an app. Unfortunately, geography is not a perfect analog for language. One only has to look at the growth of the Spanish speaking population in the United States to know that’s true. And don’t even get me started on linguistically confused countries like Belgium and Switzerland! But despite it’s imperfect nature, some general assumptions can be made regarding geography and language. In this study, I count the United States, the United Kingdom, Canada (my apologies to the Québécois), Australia, New Zealand, India, and Ireland in the English language group. I count Spain, Mexico, and all of Central and South America (with the exception of Brazil) in the Spanish language group. France is counted as the sole member of the French language group, Germany is counted as the sole member of the German language group, Japan is counted as the sole member of the Japanese language group, and the People’s Republic of China is counted as the sole member of the Simplified Chinese language group.

Promotion

I did my best to garner attention for the Benjamin 2.0 update, which hopefully affected sales positively. Although my efforts were global (since they were on the Internet), all my promotional materials and press were in English. My assumption, then, is that if different language groups have benefitted unequally from my promotional efforts, then English language sales have benefitted most from that inequality.

Companion App

A new app, Benjamin for iPad, was launched at the same time that version 2.0 of Benjamin for iPhone was released. Benjamin for iPad was a long-requested product from my established user base, and has been well-received in the App Store. It’s reasonable to think that the availability of an iPad version has contributed to the sales of the iPhone version, especially since they sync with each other and are designed to be companion apps. But since Benjamin for iPad is localized into the same languages as Benjamin for iPhone, my assumption is that any effect that Benjamin for iPad has had on the sales of Benjamin for iPhone have been felt by all language groups equally.

Methodology

The easiest way to measure changes in the rate at which an app sells is by comparing its average daily sales over two different time periods. An app’s average daily sales (ADS) is the total sales of an app during a time period divided by the number of days in that time period. For example, if an app has 5 sales on Monday, 2 sales on Tuesday, 7 sales on Wednesday, and 3 sales on Thursday, then its ADS is 4.25 over those four days. A naive comparison of sales growth due to localization could then be made by comparing Benjamin’s ADS from before localization to its ADS after localization for each language group.

The problem with a naive analysis such as this is that it fails to take into account the natural growth of the app’s audience. Looking at the change in ADS for any language group in isolation, it’s impossible to say whether sales growth was caused by localization, or if it was caused by other outside factors. For example, if the ADS of the Spanish language group increased after localization, can the increase be attributed to localization? Or is it attributable to my promotional efforts? Or to the presence of a companion iPad app that makes the iPhone app more attractive to customers? To isolate any growth that was caused by localization, the growth in each language group must be compared to a baseline. In this case, the baseline I’ll use is the English language group, since that’s the language in which Benjamin was originally available.

In this study, two time periods were established. The pre-localization time period was Feb (25° 20°)13 to June (25° 20°)13, a span of 136 days. The post-localization time period was June (25° 20°)13 to October (25° 20°)13, a span of 97 days. These time periods were chosen because they are ordinary and uninteresting. There’s no particular promotional push that happened during those time periods, and there are no seasonal effects that should have influenced sales. They are representative of typical days in the App Store. Worth mentioning is that the post-localization period begins the day after the last effects of my release promotion efforts can be seen in sales reports.

Sales statistics for Benjamin were collected for both time periods, and broken down by language group. From these statistics, each language group’s ADS was calculated for both time periods, and growth between time periods was calculated for each language group. The difference between each language group’s ADS growth and the baseline (English language group) ADS growth can then be attributed to the effect of localizing the app for that language group.

Results

The pre- to post-localization change in each language group’s average daily sales (ADS) is summarized in the table below. The Change in ADS field represents the percent growth in each language group’s sales when comparing the post-localization ADS to the pre-localization ADS. For example, if a language group had a pre-localization ADS of 10, and a post-localization ADS of 15, then its Change in ADS would be 50%.

From the table above, you can see that our baseline (the English language group) experienced 11% growth in its ADS after becoming localized. If we assume that this 11% can be accounted for by the effects of marketing, the presence of a companion iPad app, and other effects that are common to all language groups, then we can subtract that 11% baseline from the other language groups’ growth to calculate how much of their growth is attributable to localization. This growth attributable to localization is summarized in the table below.

Note: The German language group has its results above listed as not available because of a division by zero error. In the pre-localization time period, there were no sales of Benjamin in Germany. In the post-localization time period, there were 5 sales.

Conclusions

From the results above, it’s clear that localization had a marked influence in increasing Benjamin’s sales in the regions for which it was localized. The Spanish language group in particular shows a growth in sales which I have high confidence can be attributed to the effect of localization.

It should be pointed out that that the number of sales in the German, French, Japanese, and Chinese (Simplified) language groups during the pre-localization time period are very low (in the single digits). Consequently, too much confidence should not be placed in the results for those groups. It took such a small change in sales to wildly influence the results in these language groups that it’s difficult to separate the signal from the noise. My gut (and my insight into the raw numbers) tells me that the there was a genuine improvement in sales that can be attributed to localization in the French and German language groups, though the magnitude of the improvement is unclear. The results for the Japanese and Simplified Chinese language groups, on the other hand, should be disregarded as pure noise, I believe. Sales in these groups were so low that I don’t think any valuable conclusions can be drawn.

So was localization worth the cost in time and money? I would say that it was. The Spanish localization has already more than paid for itself, and the German and French localizations are well on their way to doing the same. There’s an argument to be made that the Japanese and Simplified Chinese localizations were a waste, but my hope is that Japan in particular will become a region of future growth.

Now It’s Your Turn

I know that this was a long journey to take in order to arrive at the somewhat obvious conclusion that “localization improves sales.” The point wasn’t to just show that localization improves sales, though. The point was to demonstrate a way to measure the effect of localization on sales that results in meaningful data that can be shared with others. The method employed above allows developers to calculate and share the effect that localization has on their bottom line, without revealing exactly what that bottom line is. My hope is that other developers will use a similar methodology to publish the results of their own experiments with localization so that our community of developers can accumulate the information needed to evaluate in advance whether localizing for a particular language is a valuable use of our limited time and budget.

If you undertake a similar study of the effect that localization had on your app sales, please publish your results and contact me so that I can link to them.

Note: A version of this article appeared in Issue 12 (Oct (25° 20°)13) of The Loop Magazine under the title “Localizing Your App.” The version above includes updated sales statistics that weren’t available at the time it was first published in The Loop Magazine.

1. FranklinCovey Investor Relations ↩

2. FranklinCovey China ↩

Read More

There’s been a lot of talk recently about pricing apps on the App Store. Marco Arment thinks that mass market paid apps are dead. Joe Cieplinski, my co-host on Release Notes, thinks there’s still plenty of room for paid apps in the right markets. And Matt Gemmell thinks you should raise your price by a dollar, and then measure the effect it has. With all of this seemingly conflicting advice, what’s an app developer to do? We all want our apps to earn as much as possible, but what price point will achieve that goal? Two dollars? Five dollars? Ninety-nine cents? The fact is, most of us just guess. We pick a price that we think people will pay and we go with it. But what if there was another way? A way to make a reasonable estimate of the price point that would maximize the revenue for an app? A way that didn’t rely on gut feelings and best hopes, but rather economics and mathematics? Well, my friends, if we had that, we’d really be taking control of our software business.

Why would a business owner want to be careful with the price he sets for his goods? Because price influences revenue, and revenue’s what we all want. It’s all the money that comes in the door. Ideally, in large quantities. Unfortunately, the relationship between price and revenue isn’t linear, as is apparent to anyone who thinks about it for more than a minute. If it were, we’d all just charge $1000 per download and be App Store millionaires. Instead, as shown in the figure to the right, revenue starts to increase as we increase our price from free, but then we reach a point where revenue begins to decrease as we scare off potential customers with our higher prices. Our job as business owners, then, is to find the price at which revenue peaks so that we can earn the most from our investment in time and energy.

Finding that peak is the tricky bit, of course. Most developers aren’t trained in economics, and there’s not a lot of App Store-specific information available on the internet to guide us. One notable exception is a series of articles written by Michael Jurewitz, who is trained in economics. Jurewitz’s series on app pricing and the economics of the App Store (parts 1 2 3 4 5) has a lot of great information, and should be considered required reading for anyone who hopes to make a living in the App Store. My goal today, is to add to this existing work and describe a way that developers can calculate the price that optimizes revenue, rather than relying on experimentation. The calculation won’t be exact, but it should allow developers and business owners to find a price that’s close to optimum relatively quickly, and without having to rely on guesses.

Above, I wrote that a product’s revenue increases as its price increases up to a point, then revenue begins to decrease. Economists tell us that when you plot all of these price vs. revenue points, the resulting shape is a parabola.¹ This is a key insight, because we know a lot about parabolas. For instance, every parabola has a quadratic function that describes it, of the form:

y = ax2 + bx + c

We also know, using our knowledge of algebra, that the peak (or vertex) of a parabola can be found where:

x = -b / (2a)

In our particular case, the independent variable is price (P), and the dependent variable is revenue (R), so if we replace x with P, and y with R, our equations become:

R = aP2 + bP + c
P = -b / (2a)

So how is this useful? Well, if you know the equation of the parabola that fits your app’s price vs. revenue curve, you can use algebra to predict what price should result in the most revenue. There’s only one problem: You probably don’t know the equation of your particular parabola. Luckily, the equation can be found with just a little bit of price experimentation.

It turns out that you only need three points (P,R) to find the equation of a parabola, and you probably already have two of them. You know that if you give your app away for free, you’ll have zero revenue from sales. So you know that your parabola goes through the point (0,0). You also should be able to find your app’s average daily revenue at its current price by looking at your App Store statistics, or by using a product like AppViz or App Annie. That gives you another point. So all you have to do is alter your price once, allow revenue to come to a steady state over a month or so, and then find a third point.

At this point, an example is probably called for. Let’s imagine that Alice develops an app called “Homecalc,” which is a calculator app meant specifically for real estate agents. Homecalc provides value to its customers by making many calculations that are common to the real estate market easy and convenient. Alice has charged $7.99 for Homecalc since its launch and she sees from her App Store reports that it makes an average of $181.45 per day. A very profitable app, indeed. Good for her! But can she do better?

To find out, Alice needs the equation of that parabola. She knows from her App Store reports that the parabola goes through the point (7.99,181.45). She also knows that the parabola goes through the point (0,0). But she needs one more data point. To get that last point, Alice decides to raise Homecalc’s price to $9.99 and see what happens. After waiting a month or two, Alice looks at her reports and finds that Homecalc averaged $207.89 per day in revenue after the price increase. That means that the parabola must also go through the point (9.99,207.89). That’s three points. Let’s find Alice’s equation.

I wrote earlier that the equation of an app’s price vs. revenue curve takes the form of:

R = aP2 + bP + c

Knowing that, Alice can take the three points that she found and plug them into the equation above. In this case, Alice has the points (0,0), (7.99,181.45), and (9.99,207.89). Plugging those values into our equation for the price vs. revenue curve, Alice gets three more equations:

0 = a(0)2 + b(0) + c
181.45 = a(7.99)2 + b(7.99) + c
207.89 = a(9.99)2 + b(9.99) + c

which, when simplified, result in the equations:

0a + 0b + c = (0° 63.8401°)a + 7.99b + c = 181.45
99.80001a + 9.99b + c = 207.89

You will no doubt recognize that what Alice has created is a system of three equations in three variables. This system can be solved in any number of ways, but the easiest way is probably to allow technology to do the work. Using an online system of equations solver Alice found that the solution to this system (rounded to two decimal places) is:

a = -0.95
b = 30.30
c = 0

When Alice plugs those values into our equation for the price vs. revenue curve:

R = aP2 + bP + c

she gets:

R = -0.95P2 + 30.30P + 0

which describes the price vs. revenue parabola that is unique to Homecalc!

Alice graphed Homecalc’s price vs. revenue equation to get a better feel for where she should set her price next. Looking at the graph (shown to the right), it’s clear that Alice still has room to raise the price of Homecalc and increase its daily revenue. In fact, it looks from the graph that the optimum price for Homecalc is between $15 and $16. It also appears that by raising her price to that range, she can make another $7 dollars per day. Of course, these numbers have been arrived at just by examining the graph. But if Alice wanted to actually calculate the optimum price for Homecalc, she could do that too.

To calculate the optimum price for Homecalc, Alice needs the values of a, b, and c that she calculated:

a = -0.95
b = 30.30
c = 0

and the equation for optimum price that we established earlier:

P = -b / (2a)

Plugging a, and b into our equation, we find that

P = -30.30 / [2 * (-0.95)]

or, simplified,

P = 15.95

With this knowledge, it appears that Alice would be wise to set Homecalc’s price to $15.99. If she does, our calculations show that she can expect an average daily revenue of $241.60 per day. Compared to where she started, that’s an increase in revenue of about $60 per day or almost $22,000 per year! Will everyone see results like this? No way. These numbers were chosen, for the sake of illustration, to exaggerate the shape of the parabola. But I bet that most will see some improvement.

A few warnings are in order before you try this on your own. First, you’ve got to use data that is unique to your app. You can’t just use your friend’s equation, or even the equation of one of your other apps. Each app is different and has different market forces affecting it. How the market reacts to pricing changes varies based on the usefulness of your app, the necessity of your app, your customers’ price sensitivity, the quality of your brand, and a host of other factors. Second, don’t take the optimum price point predicted by your calculations as gospel. Few things in life behave exactly according to theory, and the App Store is no different. In particular, this method assumes that the demand curve for your app is linear. In fact, it probably isn’t perfectly linear², but having a method like this to use as a starting place for setting your price is a far sight better than pulling a number out of thin air. Nonetheless, it’s probably safest to regard the optimum price that you calculate as merely a starting point that will need to be refined based on experimentation.

The App Store has been great for independent software developers. It’s given us a completely new market, and simplified things like billing and distribution, which used to be real chores. But it’s also complicated our job. In many respects, the App Store is a black box and we don’t have access to a lot of the information that we’d like. We only get sales statistics once a day, and it’s really hard to do things like A/B test different price points. In an information poor environment such as this, choosing the right price for your app is harder than ever. I hope that the method I’ve described helps take some of the mystery out of the pricing process, and I hope you make more money as a result.

1. This assumes a linear demand curve, but more on that later. ↩

2. Florian Kugler points out that not only is our demand curve probably not linear, but that it’s impossible to say with certainty exactly what shape it is. We should therefore take any calculations based on the demand curve (such as this one) with a grain of salt. ↩

Read More

What if we lived in a world without the iPhone, where we didn’t have the Internet in our pockets and the world at our fingertips? What if we couldn’t instantly check the Web to settle a bar bet, or get driving directions to our destination after we had already left home? What if we didn’t have the instant access to information that we all now take for granted? For millions of people with disabilities, these aren’t just hypothetical questions. It’s their reality. Many of the apps that most of us take for granted simply can’t be used by those with disabilities like vision and motor impairments. And as a result, they’ve been shut out of many of the conveniences of mobile information that we take for granted.

Now, don’t get me wrong. The iPhone is a wonderful device and Apple has done amazing things to make mobile software accessible to those with disabilities. Apple’s VoiceOver technology, especially, has made it incredibly easy to build apps that can be used by the blind and vision impaired. But a lot of iOS developers don’t realize that they have to do their part as well. There are lots of decisions that need to be made in the process of designing an app, and the cumulative effect of all those decisions can make a profound difference on whether those with disabilities can make effective use of an app or not. But if making an app accessible requires effort on the part of developers and designers, the natural question to ask is, “Why bother?” After all, accessibility is a feature, and features take time – time to plan, time to implement, and time to test. Why should those who build apps take the time needed to make sure that their software is as accessible as possible?

I would hope that developers and designers would implement accessibility in their apps simply out of altruism. More so than most, those who create mobile software should recognize the power of the ubiquitous information and communication that their apps make possible. This is not just a matter of whether or not someone can play the hottest new game. Accessible apps make it possible for those with disabilities to make efficient use of public transportation and to more easily find jobs. Accessible apps make it easier for those with disabilities to access news and government records so they can remain active and engaged citizens. Accessible apps empower those with disabilities to remain self-sufficient and independent. Through their work, app creators have the opportunity to improve the lives of millions, and it would be a shame if they failed to take advantage of that opportunity.

But even app creators who aren’t motivated by altruism should be motivated by simple self-interest. Chances are that the authors of today’s apps will someday need accessible software themselves. It’s just a fact of life. The older we are, the more likely we are to experience vision loss, become hard of hearing, have motor disabilities, and suffer cognitive decline. According to U.S. Census Bureau statistics¹, people who are at least 80 years old have a 70% chance of experiencing a disability of some kind. To be blunt, as we age, we either become disabled or we die.

Today’s app developers and designers need to ask themselves what they want the world that they grow old in to look like. Do they want a future where they can continue to use apps and online conveniences to improve their daily life? Or do they want to live in a future where their aging eyes and dimming sight keep them from enjoying life to the fullest? If today’s developers prefer the former future to the latter, if they want a future where they can continue to use their smartphones into their old age, they had better get busy building that future today. By making their own apps accessible, and by helping to build a culture among developers and designers in which accessibility is treated as a first-class, non-negotiable feature, today’s app creators can help ensure that they will never be locked out of the technology that they now take for granted.

Apple recently previewed iOS 7, which introduces a look that is radically different from earlier versions. As a result, a lot of developers and designers are going to be completely rethinking and overhauling the user interfaces of their iPhone and iPad apps in the next few months. I suggest that this is an opportunity. It’s an opportunity to think about accessibility. It’s an opportunity to implement VoiceOver. It’s an opportunity to help build a future where everyone can take advantage of the easy access to information that mobile software provides. It’s an opportunity to do the right thing, and it’s an opportunity that I hope all iOS developers and designers will take advantage of.

Note: A version of this article appeared in Issue 5 (July (Boyavele, Nord-Ubangi, DR Congo)13) of The Loop Magazine under the title “Designing Apps for Everyone.”

1. Americans With Disabilities: 2010. U.S. Census Bureau. July, 2012. ↩

Read More

At WWDC this year, one topic of conversation that came up over and over was how to design for iOS 7. Like a lot of indies, I usually do much of the interaction design of my apps myself and use a proper designer only for the graphical design. This was feasible for me in the past not because I’m particularly gifted at interaction design, but because I always had plenty of examples to draw inspiration from. Apple’s built-in apps were, of course, the archetype for how an iOS app should behave, but lots of third-party apps also gave great examples of how to tackle the interaction problems that I encountered in my own apps. Now, of course, I see the weakness of that strategy. It worked great under iOS 6 because of all the third-party examples I could draw upon, but iOS 7 is a reset. Right now, there are exactly zero apps in the App Store that are designed for iOS 7, and that lack of example and inspiration is going to be a problem for me and for a lot of other indies as we prepare for the launch of iOS 7.

My concerns over iOS 7 preparations lingered during WWDC, but once I returned home I realized my mistake. In fact, there is already an app in the App Store from which I can draw inspiration for this new style. An app that adopts the look and feel of iOS 7 by elevating the content over the chrome. An app that uses color and animation in the style of iOS 7 to clarify content. [pullquote align=”right”]”For all intents and purposes, Vesper is the first iOS 7 app in the App Store.”[/pullquote] I realized that, for all intents and purposes, Vesper is the first iOS 7 app in the App Store. Despite being an iOS 6 app, Vesper adopts the major idioms of iOS 7 and serves as a great example of how developers can adopt those same idioms and still retain an individual identity for their app.

You may already be familiar with Vesper. It’s a notetaking app that launched towards the beginning of June 2013, just a few days before WWDC, and got a lot of press coverage in Mac and iOS circles. Vesper was created by Q Branch, which is made up of three people familiar to the iOS developer community: John Gruber, the writer behind Daring Fireball; Brent Simmons, the creator of NetNewsWire and Glassboard; and Dave Wiskus, a respected designer and the co-host of the Unprofessional podcast. It was clear from the beginning that these three created a great app, but it wasn’t until after WWDC that I realized Vesper actually anticpated a lot of what makes iOS 7 different.

One of the first things you notice when you launch Vesper is how clean the interface is. As you can see in the screenshot to the right, Q Branch used the bare minimum interface needed to support the functions of the app. In his post-mortem on the design of Vesper, Wiskus commented on the influence of the bare visual style of Letterpress:

As it happened, we were all heavily addicted to Letterpress, and we wondered aloud if that visual style might be where the puck was headed. If so, what would that mean for UI in general? The only way to pull it off well … was to strip away everything and add back only the pieces that we needed.

As it turns out they were right on the mark. This style of clean, edge-to-edge design that emphasizes content and deemphasizes the interface was exactly where iOS 7 was headed. As Jony Ive explained in the WWDC keynote address, “In many ways, we’ve tried to create an interface that is unobtrusive and deferential. One where the design recedes, and in doing so actually elevates your content.” And that’s exactly the effect we see in Vesper. Without toolbars, without even separator lines between table view cells, Vesper draws users’ eyes to the content so they can quickly access their information and be on their way. This deference to content is going to be a hallmark of iOS 7 design and will be something for all developers to keep in mind as they plan for the future.

In the end, though, Vesper is an iOS 6 app and there’s only so far that Q Branch could go in removing interface chrome and still have it fit visually within the iOS 6 ecosystem. The current iOS 7 beta goes even further than Q Branch could in removing interface elements, going so far as to use white navigation bars that blend in with backgrounds, and reducing buttons to mere words with no edge. With so few interface elements remaining in iOS 7, how can a developer draw attention to important parts of the display? The answer is color.

The developing convention in iOS 7 seems to be to colorize interface elements that are tappable or active, and to remove the color from elements that are inactive. Apple uses this convention in iOS 7 by desaturating interface elements that are “covered” by alert views, for instance. Vesper also uses this convention to great effect when the “hamburger” button is used to access the “basement”, as illustrated in the video to the right. As you watch the video, notice how the navigation bar smoothly animates from slate blue to white as it slides to the right. This color change is a subtle, but very effective way to communicate to the user that the navigation bar and its contents are no longer what is important in the interface once it’s slid out of the way.

Speaking of animation, it’s become clear from the WWDC Keynote that animation and movement are more important than ever in iOS 7. With so much of the interface chrome removed, animation has become the new affordance, giving hints to the user as to how different interface elements should be used. Animations in iOS 7 also serve the purpose of deference to content, which was mentioned earlier, by helping to provide continuity during screen transitions. This use of animation is illustrated very well by Vesper’s transition from a list of notes to an individual note.

As you watch the video of Vesper’s screen transition to the right, notice that it lacks the usual slide animation that we’ve come to expect when “pushing” content onto a navigation controller. Instead, the thumbnail content smoothly animates to it’s final position and is replaced by the full content. By never pushing the visible content off the screen, and instead animating it into place, the eye is able to track the visible content through its journey, and thereby continuity is established between one screen and the next. This continuity immediately orients the user to the placement and purpose of the screen’s content in a way that a simple slide animation never could. This type of animation is used throughout iOS 7 and I think developers will find that clarifying animations such as this will become expected in apps as the iOS 7 ecosystem matures.

One concern that I repeatedly heard from developers at WWDC dealt with their ability to maintain individual identities for their apps when adopting an iOS 7 look and feel. After all, if most of the interface chrome is removed from apps, how can one app be distinguished from another? How can an app avoid being mistaken for a system app, or worse, a competing app? This problem is exacerbated because of the example Apple has set in the built-in apps shipping with the iOS 7 beta. Perhaps in yet another nod to deference to content, all the navigation bars in these built-in apps are either white or black, with color primarily found only in buttons and other controls. Under these conditions, it’s hard to see how an app based on a navigation controller can establish its own identity.

Vesper shows us a way, though. First it bucks the trend of the built-in iOS 7 apps by using color in the navigation bar. Yes, it’s flat color, but it’s still color. With the navigation bar extended under the status bar, lighter weight fonts, and perhaps a bit of transparency, it’s easy to imagine Vesper’s navigation bar fitting in nicely on iOS 7. The second way that Vesper creates its own personality is through its use of typography. Again in his Vesper post-mortem, Wiskus wrote:

Fonts were probably our single largest expense. We tried many, many faces in Vesper to see what felt right, and striking a balance required a lot of careful consideration.… Eventually we landed on our beloved Ideal Sans. But the story of Vesper’s typography doesn’t end there. We still had to consider weights, colors, placement, cap style, number style, then throw it all away and go back to Helvetica, only to realize what a huge mistake we’d made and beg Ideal Sans for its forgiveness.

The result of Q Branch sweating the details of typography is an app that feels at home on iOS, but that has a subtle style all its own. With the typography improvements in iOS 7 that were alluded to in the WWDC keynote, developers now have the ability to go beyond what Q Branch did with Vesper and create an even more impressive typographic style that’s all their own.

With so much of iOS 7’s new design anticipated by Vesper, it’s natural to wonder how much of this is coincidence. Did Q Branch get tipped off? Or is this just a matter of great minds thinking alike? Who knows. With this group of characters, it could be either or both. Ultimately, though, it doesn’t really matter. What matters is that now we all can see the new direction that iOS is heading. We know that in iOS 7, content is king. We know that in iOS 7, color and animation are more important affordances than ever before. And thanks to Vesper, we now know that it’s possible to combine these traits of iOS 7 to create a unique app that retains an individual identity while at the same time fitting into the rest of the iOS 7 ecosystem. If you’re one of the many now thinking about your own app and its transition to iOS 7, I suggest that you consider what lessons you can take from Vesper. It’s a great app, but I think we’ll soon see that it’s a great iOS 7 app as well.

Read More