drbarnard

[drbarnard]

How to Game the App Store

I’ve been pestering Apple for years publicly and privately about the manipulation and outright scams going on in the App Store. Apple has made some progress here and there, but overall Apple’s strictness in some areas and hands off approach in others has disproportionately rewarded bad actors while stifling conscientious developers.

As I’ve said many times before, the App Store is not a free market. Apple can and does dramatically shape the App Store economy. Similar to how governments shape economies through tax law and other policies, Apple shapes the App Store economy through App Review policies, App Store implementation details, editorial decisions, the App Store search algorithm, and in so many other subtle (and not so subtle) ways. I’d love to see Apple wield that power to shape the App Store in ways that will sustain and encourage meaningful development instead of continuing to allow the deck to be stacked against it.

I know what you’re thinking… these are just the ramblings of a failed app developer who blames Apple for their own shortcomings. Quite the opposite. While not an “App Store millionaire”, for the past 10 years I’ve provided for my (growing) family solely on revenue from my apps. And 3 of my apps have grossed over $1M. While my net income (I spend a lot on design, share revenue with partners, pay Apple 30% on some of that, pay self employment tax, pay way too much for health insurance, etc) hasn’t made me a millionaire (or anywhere close), I’m still blown away that my apps have been downloaded by millions of people, been featured countless times by Apple, mentioned everywhere from indie blogs to the NY Times, and grossed millions of dollars.

My critique of Apple’s management of the App Store (which began in 2008) has never been about embarassing Apple or denigrating its employees or motives, I want to see this amazing platform Apple created be the best it can possibly be. The App Store is an incredible marketplace that has generated tens of billions in revenue while empowering billions of people around the world to do amazing things with these magical little computers we carry around in our pockets. But I do think the overall success of the App Store has blinded Apple to the need for various course corrections over the years. And as the financial incentive to build and maintain great niche apps dries up, the beautiful and diverse forest of apps that is the App Store will slowly start to look more like the unkempt Play Store.

So, let’s talk about how developers are gaming the App Store and why it matters to the future of the platform. Any one of these tactics might seem somewhat bland individually, but when tens of thousands of apps deploy multiple tactics across many categories of apps, the impact can be measured in hundreds of millions of users and likely billions of dollars.

I’ve been focused on researching the weather category the past couple years as I’ve been working on my weather app, Weather Up, but these tactics apply to pretty much every category on the App Store.

So, here are some of the top ways to game the App Store:

1. Find a keyword that drives a decent amount of organic search traffic. Obvious ones are keywords like “weather”, “calculator”, “solitaire”, etc, but those keywords are so competitive, and the rest of the tactics so powerful, you could get away with 2nd tier keyword targets. Now go to App Store Connect and name your app that exact keyword. “Weather” is already taken, and Apple doesn’t allow duplicate app names, so you’ll need to add a symbol. Let’s go with “Weather ◌”.

Here’s the thing, the App Store search algorithm gives a massive boost for an exact match to what the user searched, and the algorithm ignores symbols, so “Weather ◌” will get a huge search advantage, which will help to drive organic installs of the app. There are lots of other hacks to manipulate the App Store search algorithm. I haven’t kept up on all the “black hat” tactics, so I’m not sure what works and what doesn’t anymore, but here’s a fun one: the App Store search algorithm indexes multiple languages per App Store localization, so you can double your keywords in the US App Store, by stuffing keywords into the Spanish (Mexico) localization of your App Store page.

2. Search for an app template to minimize the amount of code you’ll have to write. The functionality of the app isn’t terribly important as long as it covers the basics a user might expect downloading a app called “Weather ◌”. This one looks perfect and only costs $90: iOS Weather App with AdMob

 But weather data costs money, and we’re trying to maximize revenue at all costs, so proxy a few weather apps as they request data and “borrow” any API keys you happen to find. I hear Apple’s weather app might be a good place to start.

3. Implement a tricky subscription page with high priced subscriptions and the price far removed from some sort of “Continue to Trial” button. Also, hide the button used to close this page (bonus points for completely hiding the close button for a few seconds) so that users feel compelled to tap the “Continue” button. Apple is starting to crack down on these things, but it’s tough to enforce so you might get lucky. And watch companies like Apalon for cues on just how user hostile Apple will allow the subscription page to be.

 If you need further inspiration for how to trick users, here’s a full list compiled from actual scams on the App Store:

Here’s a list @jmp146 compiled of scams developers have been pulling on the App Store. Many of these techniques are still in use by other apps on the App Store. You can see all the videos in @jmp146’s tweets: https://t.co/ccOnJr91Sb https://t.co/8hXSeaQjop https://t.co/CZGpJcFJpc pic.twitter.com/WZR5V5YTVV

— David Barnard (@drbarnard)

October 19, 2018

4. Trigger the subscription randomly while the app is running. This one is included in the above list, but is so cunning it’s worth a specific mention. Because the iPhone home button serves as a sort of universal back button, a panicking iPhone user is likely to hit the home button when trying to get out of something. Unfortunately, on iPhones with Touch ID, the home button is also how you confirm a purchase. So if the payment view is randomly triggered, many users will accidentally confirm the purchase while trying to exit.

 5. Sign up with Teemo, RevealMobile, Factual, and other firms (you can use as many as you want simultaneously) to sell your users’ precise location data for cold hard cash. I’m still baffled that Apple allows this given their stance on user privacy, but they do for now, so make some hay while the sun is still shining.

6. Display full screen ads every 60 seconds and/or when users tap certain buttons in the app. The user experience is horrible, but it’s shocking how much users will tolerate and the money is great! The eCPM for full screen ads is 3-5X what banner ads and other ads pay.

7. On app launch, randomly promote other apps. Again, terrible user experience, but hey, it works.

 8. Once your app is live on the App Store, start buying fake ratings and reviews. This is one of the more blatant violations of Apple’s rules, but they don’t seem to penalize apps that do it so ¯\_(ツ)_/¯ 

4/ Look at these reviews. The developer is clearly buying fake ratings to keep the average up against an onslaught of 1-star reviews from real users. pic.twitter.com/cGoOPhObMa

— David Barnard (@drbarnard)

October 26, 2018

9. Pay for a “Keyword Boost” campaign. Users are paid to search a specific keyword and download your app, which teaches the App Store search algorithm that your app is a great match for that specific keyword. A few thousand dollars will rocket your app to the top of important keywords which will be further reinforced as you get organic downloads from that keyword.

10. Use a custom review prompt to filter users who are more likely to positively review your app (and beg a bit for good measure). Rule 1.1.7 of the App Store Review Guidelines now forbids custom review prompts, but it’s hard to catch, so you can probably get away with it.

 Those are 10 of the more obvious and widely used tactics for gaming the App Store, but there are hundreds more. I experimented with a few of these (the ones not explicitly against the rules) in my Mirror app (which I sold last fall), so I know just how powerful they can be.

Cumulatively, the apps using these tactics are creating billions of terrible experiences for iOS users. But it’s not just that, they are choking out the developers who care about building great experiences and respecting users. By employing these tactics, apps are far more profitable and can afford to pay more to acquire users. Which makes it really tough for apps not employing these tactics to compete in acquiring users. And by gaming App Store search, these apps make it nearly impossible for conscientious developers to get organic search traffic on high volume keywords.

There are absolutely ways to succeed on the App Store despite all of this (I know, I’ve been doing it for 10 years now!), but it’s a heck of a lot harder than it should be. And my bigger point in writing all of this is that Apple should be doing more to shape the App Store economy in ways that reward conscientious developers and punish bad user experiences. Given Apple’s genuine concern for privacy and great user experiences on iOS, I’m shocked they’ve allowed the App Store to fall prey to so much manipulation and outright scamming. But the icing on the cake is that Apple recently featured an app from one of the most notorious App Store abusers of them all, Apalon:

4/ I hadn’t used that app in a while, so I decided to check it out & figure out what Apple saw worth the honor of App of the Day. Alerts promoting other apps. Full screen adds every couple minutes. Subscription page pops up randomly. Sells user location data. “Creedon Republic”?! pic.twitter.com/UOjiuci0vY

— David Barnard (@drbarnard)

November 19, 2018

Featuring an app is a great carrot, and Apple doesn’t generally feature apps that so blatantly flaunt App Store manipulation and user hostile tactics, but the carrot of getting featured pales in comparison to how much money can be made by gaming the App Store. It’s well past time for Apple to employ more carrots to create great experiences on the App Store, and to use a bigger stick on those manipulating the App Store and creating terrible user experiences for Apple's customers.

david

[drbarnard]

Testing Auto-Renewable Subscriptions on iOS

**************************************************************

This post is out of date. See the updated and expanded guide to subscription testing here: https://www.revenuecat.com/blog/the-ultimate-guide-to-subscription-testing-on-ios

**************************************************************

Old, out of date post:

Subscriptions work differently in TestFlight, the sandbox, and live on the App Store, so testing them requires knowledge of those differences. This is my attempt to help sort out the mess and document it for others to reference. Please email me (david@contrast.co) if I got something wrong, left something out, or need to update the post due to changes made by Apple over time.

General Notes

Subscription length has been significantly shortened for testing purposes. This allows users to quickly test multiple renewals and expirations via TestFlight or with sandbox users.

Actual subscription duration -> Test duration

1 week -> 3 minutes 1 month -> 5 minutes 2 months -> 10 minutes 3 months -> 15 minutes 6 months -> 30 minutes 1 year -> 1 hour

The subscription will automatically renew 6 times per account per 8 hour window, then the subscription will automatically expire at the end of each subscription period. These renewals happen automatically whether the app is open or not, just like renewals on the App Store. Unlike the App Store, there’s no option to cancel, so there’s no way to directly test cancelation. There’s also no way to test subscription management while using TestFlight or sandbox users.

Each automatic renewal sends a transaction to the app. The transaction, or transactions, depending on how much time has passed, is processed the next time the app is opened. Validating these transactions triggers yet another password prompt. When the app is live on the App Store it shouldn’t trigger these additional password prompts.

TestFlight Testing

First off, subscribing in a TestFlight distributed app prompts the user 3 times for their Apple ID password and does not allow the use of Touch ID to complete the transaction. Sometimes, after starting a new subscription multiple times on the same device (after the first 6 auto-renewals), only 2 password prompts are displayed ¯\_(ツ)_/¯. It would be nice if the purchase flow while testing mirrored that of a live app on the App Store, but that’s just not the case for whatever reason. It’s a bit disconcerting to see so many password requests while testing, but rest assured, once the app is live on the App Store the purchase flow will work as expected (which is a single, Touch ID enabled purchase sheet on iOS 11).

That’s all out of date, seriously, go here:

Testing renewals and expiration:

1. Subscribe to a monthly subscription 2. Close the app and set a 5 minute timer 3. Launch the app 4. If prompt is displayed, enter password

At this point the app should continue to operate in the subscribed state. Repeat steps 2-4 several more times (or just close the app and wait) until 35 minutes has passed (6 renewals at 5 minutes each plus the original 5 minute subscription). The app should now revert to the un-subscribed state and allow the user to re-subscribe.

Test restoring purchases after expiration:

1. Subscribe to a monthly subscription 2. Close the app and wait 35 minutes 3. Launch the app 4. If prompt is displayed, enter password [app should revert to the un-subscribed state] 5. Tap “Restore Purchases” button

No active subscription should be found and the user should be shown a message to that effect.

Test restoring purchases during active subscription:

1. Subscribe to a monthly subscription 2. Delete app and reinstall within 5 minutes 3. Launch the app 4. Tap “Restore Purchases” button

Active subscription should be found and the app should change to the subscribed state.

Test restoring purchases across devices:

1. Subscribe to a monthly subscription 2. Install the app on a different device before the subscription expires 3. Launch the app 4. Tap “Restore Purchases” button

Active subscription should be found and the app should change to the subscribed state.

TestFlight Caveats

Note that since the subscription is only auto-renewed 6 times in an 8 hour window, some of the procedures above will change if those 6 renewals have already happened.

If the subscription is associated with an account and the subscription status maintained server-side, the testing procedures get much more complicated and are beyond the scope of this post.

One thing to keep in mind is that with subscriptions being so hard to initiate (3 password prompts, no Touch ID) and renew (another password prompt, no Touch ID), the subscribed state is likely to get significantly less testing from beta users than the un-subscribed state. Consider creating a secret unlock code/gesture to allow beta testers access to the subscribed state for longer periods of time without having to jump through hoops.

Production Testing

For an app that has yet to be released on the App Store, getting an early version of the app approved is a great way to test subscriptions:

1. Submit a beta version of the app to App Review. Make sure to set “Version Release” to “Manually release this version” so that the app is not released on the App Store. 2. Generate promo codes for the app. This can be done for free apps that are approved, but not yet on the App Store. 3. Download the app from the App Store using a promo code. 4. Subscribe.

Since this app has gone through approval, subscriptions will perform exactly as they will when the app is live on the App Store, including charging testers who subscribe and allowing testers to manage the subscription in the App Store app. Promo codes can be given to testers so that they can test the app for free. Subscriptions paid for via promo code work exactly like paid subscriptions, except that they don’t auto-renew.

Sandbox Testing

Finally, it’s also possible to test auto-renewable subscriptions via sandbox test accounts, but this form of testing has been well documented, so I won’t bother rehashing how that works.

Rejection

After going through all the testing mentioned above, my app was rejected for not properly disclosing the subscription in the app and in the App Store description. To save others time, here’s the relavent section from the rejection notice:

We noticed that your app did not fully meet the terms and conditions for auto-renewing subscriptions, as specified in Schedule 2, Section 3.8(b), included below:

You clearly and conspicuously disclose to users the following information regarding Your auto-renewing subscription: – Title of publication or service
– Length of subscription (time period and/or content/services provided during each subscription period)
 – Price of subscription, and price per unit if appropriate
 – Payment will be charged to iTunes Account at confirmation of purchase
 – Subscription automatically renews unless auto-renew is turned off at least 24-hours before the end of the current period
 – Account will be charged for renewal within 24-hours prior to the end of the current period, and identify the cost of the renewal
 – Subscriptions may be managed by the user and auto-renewal may be turned off by going to the user's Account Settings after purchase
 – Links to Your Privacy Policy and Terms of Use
 – Any unused portion of a free trial period, if offered, will be forfeited when the user purchases a subscription to that publication, where applicable

If you’re still reading, you shouldn’t be. Go read this:

Solution

Using The Atlantic app and the above text as a reference, here’s the text I used in my app:

Information about Weather Atlas Pro subscriptions: - Payment will be charged to your iTunes account at confirmation of purchase. - Your subscription will automatically renew unless auto-renew is turned off at least 24-hours before the end of the current subscription period. - Your account will be charged for renewal within 24-hours prior to the end of the current subscription period. Automatic renewals will cost the same price you were originally charged for the subscription. - You can manage your subscriptions and turn off auto-renewal by going to your Account Settings on the App Store after purchase. - Read our terms of service and privacy policy for more information.

david

[drbarnard]

The App Store as an Economy

We talk about the “App Economy”, but don’t often analyze it as such. And that’s a shame. As I’ve said many times before, Apple shapes the App Store economy (and the app economy more broadly) in ways similar to how governments shape economies, and in turn influence the global economy, through tax law and other policies.

Restaurants seem to be a favorite analogy of armchair App Store economists, so let’s run with that. “90% of restaurants fail, why should it be any different for apps?” Well, first of all, that 90% figure is untrue, it’s more like 60%. The failure rate of new restaurants is high, as is the failure rate of most business ventures, including apps. But the failure rate in and of itself isn’t especially interesting or informative (and even if it were, we don’t have authoritative stats on the failure rate of apps).

It’s obviously not a perfect analogy, but I think there are some interesting comparisons to be made between the economic and regulatory circumstances surrounding restaurants as compared to apps. Both businesses are highly regulated (at least on iOS, less so on Android), but the implications of those regulations on business decisions are quite different.

Restaurants must be built and operated to certain health and safety standards, but those standards are clearly documented and all restaurants are generally held to the same standards. Restaurants are routinely denied building permits and/or liquor licenses, but that happens very early in the process, not days before the grand opening after construction has been completed, staff trained, supplies delivered, etc.

Here, in contrast, is an excerpt from the App Store Review Guidelines:

We will reject Apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll know it when I see it". And we think that you will also know it when you cross it.

Any potential restaurateur or investor would balk at language like that being official government policy that could be capriciously enforced at any time before or after a restaurant has opened its doors.

Restaurant policy has evolved over the years not just to protect the public, but also to create the a healthy balance of economic incentives to encourage a vibrant restaurant scene, which in turn raises the tax base and influences other aspects of a local economy. Even today, restaurant policy is regularly revisited and new exceptions are created to adjust to the current economic conditions and needs/wants of citizens.

Food trucks are a great example of how restaurant policy has shifted to provide new business opportunities for restaurateurs and more options for citizens. The investment needed to open a food truck is generally quite a bit less than is needed to open a “brick and mortar” restaurant, which reduces risk and encourages experimentation. Some cities banned food trucks because they clearly violated existing health and safety standards, and rightly so. But many forward-thinking cities adjusted existing policies and/or created new policies to allow for food trucks while still addressing health and safety concerns.

For years, developers have petitioned Apple to allow paid updates and timed trials, and to change other App Store policies. But Apple has made very few meaningful changes to the sorts of policies that would empower developers to experiment with new business models, build more innovative apps, and better assess and manage business risk.

It may not seem as though Apple’s policies have in any way slowed investment in bringing new apps to the App Store, but I can tell you from personal experience that app review policies and so many other things within Apple’s control do absolutely shape the App Store economy. And that’s precisely the point of much of what I’ve written about since the inception of the App Store. The success or failure of any one app is not Apple’s fault, but it behooves Apple to pay close attention to the App Store economy and use policy levers to shape that economy in ways that best align with Apple’s stated goal of delighting customers and its ultimate goal of profitability.

To be clear, Apple has far more levers to pull in shaping the App Store economy than most people think. Here are some of the big ones:

Hardware - The Apple Watch and new Apple TV as well as hardware changes to existing devices (larger screens, better cameras, motion coprocessor, Touch ID, etc) have clearly shaped the way developers look at opportunities for building and updating apps.

Programming Languages - In the long run, Swift will likely empower even more developers to more quickly build better apps.

Frameworks - Every framework Apple opens up to, or hides from, its developers, and even the specifics of how those frameworks function, impacts what developers are able to build and how they build it.

Tooling - It may seem far fetched, but the capabilities of Xcode shape the App Store economy. By pushing interface builder and auto layout, Apple has encouraged developers to build universal apps and made it more cumbersome to build separate iPad/iPhone apps. Bugs, crashes, and other deficiences of Xcode likely cost developers millions of hours of productivity each year, which has obvious implications for the App Store economy.

App Review Policies - Need I say more?

The App Store - While seemingly trivial, every tiny detail of the App Store dramatically shapes the App Store economy. Changing the “FREE” button to “GET” changes the psychology of… ahem… getting an app. The App Store search algorithm dramatically shapes the success of many apps. And so on…

App Store Editorial - Which apps Apple does and doesn’t feature sends a clear message to developers about what Apple values and wants to see in the App Store.

Apple Marketing - The way Apple positions its devices and in turn the apps on those devices shapes the App Store economy.

While it might be easy to write off this post as the ramblings of a disgruntled App Store failure who thinks Apple should bend to the whims of indie developers, that couldn’t be further from the truth. I’ve shipped (and failed to ship) quite a few apps on the App Store. Some were hugely successful, others not so much. I’m one of only a handful of people who has, since the very begining of the App Store, made a living (a good one at that) solely on iOS apps. I don’t think Apple should blindly implement every suggestion made by developers, but I do think the overall success of the App Store has blinded Apple to the need for various course corrections over the years. Apple’s incentives will never perfectly align with developers’, but finding a way to better align incentives will point the App Store back toward a more optimal trajectory.

david

(Disclaimer: I’m not an economist, nor have I spent much time learning about restaurant economics. I likely made some errors in my caricature of the restaurant business, but I think my greater points still stand.)

[drbarnard]

[Almost] Abandoning the Development of an Editors’ Choice App

A lot of people have been asking why it took so long for Launch Center Pro to get a widget. It’s kind of a long story and I can’t share all the details, but the gist of it is that Justin and I were scared of App Review and didn’t want to risk continued development of the app after seeing the capricious App Store policy decisions Apple made just after the release of iOS 8 last fall.

So, Justin got a job and I focused on my other apps (and took a lot of time off due to health issues and other personal matters). After a combination of public and private hints that Apple was loosening up, we started to feel more comfortable about starting to invest in the app again. But it took time to get back in the swing of things given the other commitments that had accumulated.

With the warm reception to Launch Center Pro 2.5, our schedules a bit less cluttered, and Apple seemingly much more open to experimentation, we’re hoping to keep moving forward with Launch Center Pro at a more reasonable clip.

Below is an email I sent Apple in the middle of the rejections and uncertainty last fall:

Date: October 12, 2014 To: tcook@apple.com, cue@apple.com, schiller@apple.com Subject: Abandoning the development of an Editors’ Choice app

WWDC was amazing! All the new APIs, the awesome new features in iOS and OS X, Swift, and, of course, the “hug a developer” theme. WWDC certainly felt like a big hug.

When my business partner and I got back to the office and started white-boarding all cool things we could do with Launch Center Pro on iOS 8, every conversation ended in “but Apple will probably reject that”. As a small indie development company, we don’t have the resources to spend months on features that might get rejected. So, we decided to work on other things and see what was approved when iOS 8 shipped.

And I’m glad we decided to wait. Launcher was approved, then removed.

The app “Workflow” has been in limbo for weeks.

And now it appears that launching other apps via URL schemes is reason for rejection.

The developer of Workflows tweeted that the App Review team told him that Launch Center Pro was grandfathered in, but seeing all these rejections, it doesn’t seem smart to continue investing in Launch Center Pro given the possible rejection of any feature we might add to the app. And that would be an absolute shame.

The value of Launch Center Pro has never been in replacing the iOS home screen for people who just want to launch apps. That’s not particularly compelling. URL schemes enable the creation of shortcuts that launch apps with content and context. And that’s not something that has been replaced by Extensibility.

URL schemes are a sort of API for native apps that enable some really cool (though admittedly very nerdy) interactions with apps that don’t have web APIs. Here are three quick examples combining native apps and web services in a way that’s only possible using URL schemes:

Tweeting todos into Clear Instagram photos sent to Day One Preview and tweet a new post

There are also tons of great shortcuts that can be created with URL schemes. Rather than typing my home address into Maps every day when I drive home and want to check traffic, I can create a one-tap shortcut in Launch Center Pro that takes me to the Maps app with my home address already set as the destination. I can create a one-tap shortcut to lookup my kids’ birthdays in the Wolfram Alpha app to see how many days, months, and years old they are. I can create a one-tap shortcut to take me to my son’s favorite Minecraft video in the YouTube app.

And those are just shortcuts based on URL schemes, Launch Center Pro also creates all sort of powerful shortcuts to native iOS features like Mail and Messages as well as web services like IFTTT and Dropbox. Creating shortcuts for repetitive tasks might be a bit nerdy, but there are a heck of a lot of nerdy iOS users, and we’d love to keep experimenting with ways to make shortcuts more accessible to the average iOS user.

We’re also quite excited about Apple Watch. With the limited screen real estate on Apple Watch, we think shortcuts are going to be HUGE! Triggering complex actions with a few quick taps on Apple Watch is going to feel like a super power.

But at this very moment, we’re contemplating abandoning Launch Center Pro. Investing our time in an app whose status with App Review seems to be in limbo is just untenable for us. We can’t afford to work months on features that might ultimately get rejected.

And that leads me to a bigger point. At this stage in the history of iOS as a platform and the App Store as the premier destination for mobile software, is it really necessary to nit-pick certain user experience issues and reject apps that find interesting and innovative new ways to do things on iOS? Why not let the App Store marketplace decide if launching apps with URL schemes or launching apps from Notification Center is a great experience or not? And why not give developers like us some way to get more clarity about App Review rules before we spend months working on apps/features that might get rejected?

I happen to agree that launching apps from Notification Center isn’t a great experience, but plenty of iOS users seem to think differently. We have gotten hundreds of requests from users to add a Today Widget in Launch Center Pro (and it was one of the first things we white-boarded when we got back from WWDC). I also happen think that many of the apps that have recently been approved, like GIF keyboards, are an even worse user experience than launching apps from Notification Center, but people seem to love those anyway.

I’ve been developing for iOS since the SDK was first announced in 2008. I certainly don’t plan on walking away from iOS development, even if Launch Center Pro doesn’t have much of a future. It’s an amazing platform and has provided a great living for me and my family over the years. Getting some clarity on the situation and feeling less apprehensive about the App Review process would go a long way in helping me to continue making a living on the App Store.

david

[drbarnard]

Fifty Shades of Ad-Blocking Grey

As with most things in life, ad blocking is… complicated. Reductionism comes off as smug and entitled. The truth is, most people on earth benefit in some way from the current morass of annoying ads, privacy invasion, and other crap. Anyone who uses Facebook to connect with family and friends is able to do so for free because of ads and privacy invasion. And even sites that boast about memberships, native ads, and premium ad networks benefit from products and services that worsen or at least maintain the status quo.

When things are grey, we all have to draw our own line in the sand and justify it to ourselves. Explaining where you drew your line, and why, moves the conversation forward. Insulting the intelligence of people who came to different conclusions is not only counter-productive, but shows a lack of self-awareness that one’s own line is merely a lighter or darker shade of grey.

My Mirror app shows ads (iAds even) for apps like Game of War that I think psychologically manipulate people into spending money they can’t (or shouldn’t) afford. I agonize over whether or not to pull ads completely, block certain ads, or find some other solution. But in the mean time that app helps me provide for my family and have the freedom to pursue other things that I think are more beneficial to society. If I ever do decide to pull those ads, I’m certainly not going to smugly insinuate that I’ve taken the moral high ground and that other developers should follow my lead.

Because even if I do remove ads, my comfortable middle class existence is still dependent on hundreds of thousands of low-wage workers in China building iPhones for entitled knowledge workers (like myself) all over the world. And on thousands of migrant workers who harvest the fruits and vegetables I eat. And on the guy who drives by my house every week to pick up the mountains of garbage I create.

Anyhow, I’m off to build myself a hut in a remote forest where I can live happily ever after at peace with my integrity. But I won’t be able to tweet and blog about it.

[drbarnard]

Paid App Marketing

With the cost of user acquisition being driven up, and market forces driving the value perception of most apps down, it’s tough to make the numbers work on most forms of paid app marketing. A few months ago Marco Arment released sales data on his recently released podcast app, Overcast. Having real data from a great app that converts well provides a flawed, but instructive example of how tough it is to make the math work on paid marketing.

Based on the numbers Marco shared, we see that his average revenue per user is 51¢ (318,996 free downloads generated $164,134 in revenue). Cost per install can vary significantly depending on the app, time of year, and other factors, but as a point of reference, Chartboost estimates the average cost per install on iPhone was $2.08 in December 2014.

Based on those numbers, it appears Marco could not have directly bought his way to profitability with Overcast at current market rates for app installs. To make paid marketing work, you need to find ways to drive the cost of marketing down, amplify the impact, and/or increase the revenue per user.

In the case of Overcast, the app is already converting well (14.7%) and at a relatively premium price of $5. Marco could try subscriptions, a higher price, additional IAP, and other strategies to increase the average revenue per user, but given the fierce competition in the podcast app market, it would be an uphill battle and might not be worth the time and risk to experiment given how well it’s already doing. But that’s not the case for most apps. Most freemium apps (mine included) aren’t monetizing particularly well. Experimenting with price, tracking and optimizing conversions, and working on other aspects of monetization would be time well spent and should absolutely be part of any developer’s long-term strategy.

But I’ll leave monetization for another post. This post is about the marketing side of the equation.

The cost per install numbers referenced above are an average based on mishmash of good and bad marketing strategies. With time and effort, I’m sure an enterprising developer could find ways to drive the cost of acquisition down below those averages. Free marketing helps to drive the overall cost of marketing down and can help boost the effectiveness of paid marketing. And paid marketing can increase visibility on the App Store which amplifies the impact even if the paid marketing isn’t directly cost effective.

Bottom line: unless you are tracking conversions, measuring ARPU, and otherwise tracking and optimizing, spending money on app marketing is likely throwing good money after bad.

Disclaimer: this post has been sitting unfinished for months. I decided to post it as-is. There’s a lot more to say about paid app marketing, but I hope this is a helpful take on the basics.

[drbarnard]

Cost Effective App Marketing

You can build the best app in the world, the slickest website, the most engaging ads, and the perfect monetization strategy, but the very first step to making any money is getting the attention of a potential customer. Once you have that attention, a certain percentage of those potential customers will eventually pay for your app (whether directly, via In-App-Purchases, by viewing ads, or taking some other desired action).

Though not a perfect model for understanding the flow of potential customers through the process of paying for an app, the concept of a sales funnel is a great tool for analyzing how and why sales happen and how that process can be improved.

The basic idea of a sales funnel is that each potential customer moves through some series of steps from first gaining awareness of your app to actually paying for the app. Though it may seem like an incredibly simple process for most apps, there is a lot that can be optimized in both who becomes aware of your app and the subtle details that encourage and discourage a potential customer from actually paying.

For example, one great source of attention for an app is getting featured by Apple on the front page of the App Store. Apple has never mentioned the number of shoppers who visit the featured section of the App Store in a given week, but one would assume it’s in the millions. Depending on where the app is placed on the page, the appeal of the icon, the name of the app, and many other subtle factors, a certain percentage of shoppers will tap on the icon to view the app’s detail page. Then depending on the screenshots, price, description, and many other subtle factors, a certain percentage of shoppers will download the app. For free apps, the funnel gets quite a bit more complex as the shopper then uses the app and is shown ads, completes an In-App-Purchase, or takes some other desired action.

You can work to optimize each step in a funnel, but none of it works without first getting attention. The more each step in the funnel is optimized the less attention you need, but lots of attention can also make up for problems and inefficiencies in that funnel.

So, how do you get attention for your app? There isn’t any one answer. I wish there were. What works for one app might not work for another and most successful apps employ a variety of strategies to generate and maintain attention. In my next few posts I’ll discuss some of the more obvious ones: paid advertising, press, being featured on the App Store, App Store search, Google search, cross promotion, word of mouth, network effect, and complimentary apps.

Disclaimer: this post has been sitting unfinished for months. I decided to post it as-is. I hope to write the follow up posts mentioned above, but it may take months, or years, or never happen.

[drbarnard]

App Review Psychology

This morning Apple told James Thompson he would have to remove or drastically change PCalc’s Today Widget. Having seen the writing on the wall over the past few weeks, I sent this email to Apple executives on October 25th:

I’m concerned that Apple is in the process of making a grave mistake in rewriting the App Store Review Guidelines to exclude features that have already shipped in many iOS 8 apps. I’ve been seeing apps pulled, hearing about rejections for things that were previously approved, and now PCalc appears to be in the line of fire.

The press may or may not make a ruckus, and even if they do it will quickly die down, but I think a policy shift this late in the game will have long term implications for the iOS ecosystem.

As I’ve mentioned in previous emails, I fear App Review. And that’s no small thing. So many decisions I make end up being filtered through whether or not I think something might get rejected. Which has a profound impact on my team’s entire development process — from what ideas we explore while brainstorming to how we implement specific features.

In the grand scheme of things my current apps aren’t particularly important to the iOS platform and if my team and I limit our thinking and don’t come up with any great new apps or features it’s unlikely Apple will be perceptibly worse off for it. But if a significant number of people involved in iOS development start to fear App Review the way I have the past couple years, that changes the game. And I’m not just talking about indie developers like me. Contractors may steer their clients away from taking risks. Project managers at companies like Facebook and Pinterest may think twice before pitching a new feature. Venture capitalists may pass on a fledgling company because its product is too dependent on an iOS feature that might get rejected.

I’m obviously incredibly biased, but I think it may just be worth allowing some arguably sub-par user experiences in the App Store to prevent the iOS platform from becoming a place where risk is avoided. The App Store is a beautiful and diverse forest of apps, a little pruning here and there might not seem like a big deal, but it’s always hard to predict how an ecosystem will adapt.

david

[drbarnard]

Seeing the App Store Forest for the Trees

Since before the App Store even launched, indie developers have been been writing and tweeting about perceived flaws in how Apple manages it. Conversations around those posts and tweets inevitably lead to comments like: “Apple cares about customers, not developers.” or “The App Store is doing just fine, Apple said $X billion was paid to developers.” or “I only use Facebook, the App Store doesn’t need any more apps.” or “Apple doesn’t owe you a living.” or “I don’t hear App Store shoppers complaining.” and so on.

The App Store is absolutely doing quite well, and billions have been paid to developers, but that doesn’t mean all is well with the App Store. And it certainly doesn’t mean the current trajectory of the App Store is optimal for Apple or iOS users. I think a lot of people, including people inside Apple, often miss the App Store forest for the trees.

While Apps like Facebook, Twitter, Snapchat, Instagram, Pintrest, WhatsApp, and others are certainly pillars of the iOS ecosystem and are indispensable to millions of users, it’s the tens of thousands of other great apps that makes iOS unique. Android has been gaining ground in attracting the big names to the Play Store, but outside those top apps, it’s generally a wasteland of crap and ripoffs. And that matters.

According to Nielsen, the average smartphone owner uses 26.8 apps on a monthly basis. Unfortunately, Nielsen doesn’t seem to have estimated the number of unique apps in use on a monthly basis, but it would likely be at least 100k. Even though the majority of people who own a smartphone use Facebook, they each have a unique set of apps that are important enough to use monthly.

To a surfer, a surf report app is essential. To a builder, a construction calculator is essential. To a nurse, a drug interaction app is essential. To a frequent traveler, a translation app is essential. To a musician, a guitar tuner app is essential. And so on.

Big apps like Facebook may be far more important to iOS than a guitar tuner app, but it’s important that a few great guitar tuner apps exist on iOS. If the financial incentive to build and maintain great niche apps dries up, the beautiful and diverse forest of apps that is the App Store will slowly start to look more like the unkempt Play Store. That’s why Apple should (and does) listen to feedback from indie developers.

[drbarnard]

Curated Automation

Ever since reading “The Internet of Things and Humans” by Tim O’Reilly, I’ve been thinking a lot about the role of human interaction in automation and connected devices. Ultimately, we want computers to automagically handle as much as possible without any input from us, but algorithms will never perfectly handle every possible scenario and some things are better off with just the right touch of human interaction.

For example, the Nest Thermostat has been driving my wife and I nuts. I don’t want to turn off all the smart features because the whole point of having a Nest Thermostat is for it to try and save us money, but Nest’s learning algorithm is having a hard time with our very irregular schedules (and my wife’s erratic manual overrides during pregnancy). The most frustrating failure was when Nest automatically set the temperature to 78º right in the middle of a party we were hosting.

Even if the learning algorithm were perfect (which it will never be), there are still times when as a human I want something different because of context that Nest will never be able to sense. If I spend the day kayaking and get a sun burn, I may want to sleep with the temperature at 70º. Implicitly providing that input via the Nest app or directly with the thermostat on the wall is the obvious solution for most of those cases, but I’ve also been wondering about opportunities for the Nest to proactively ask for input rather than making assumptions.

The new Nest Channel on IFTTT provides a great opportunity to start experimenting with “curated automation”.

The first obvious step is to just make it easier to control the thermostat. Nest’s app is designed to be a convenient home for anything you want to do with any Nest device you own. And that makes sense, but what I’ve really been wanting is just a 72º button. I tap it and the temperature is set to 72º. That’s now possible with a combination of this Recipe on IFTTT and this action in Launch Center Pro. Here’s a quick demo:

But things get really interesting when using Nest as a trigger on IFTTT to proactively ask for input. It takes 3 separate Recipes on IFTTT (1, 2, 3), but you can now be prompted to take action anytime the temperature goes above 75º (or the Nest is automatically set to Away, or the Nest is automatically set to Home, etc). Here’s a quick demo of how that works:

Another example of this sort of thinking is an IFTTT Recipe I set up to send Instagram posts to Day One on my iPhone. In theory, automatically sending an Instagram post to Day One without any human interaction would be perfect. However, you’d likely want to write something more personal in your journal than you would want to post publicly on Instagram. Here’s an example of adding a point of human interaction to an otherwise automated workflow:

I obviously don’t think these workflows represent the pinnacle of thoughtfully combining automation and human interaction, but I think it’s a fascinating step in the right direction and a great way to start experimenting with curated automation.

[drbarnard]

App Previews as a Tiered App Store

Since Apple announced app preview videos at WWDC, I’ve been thinking a lot about the implications. I may be wrong, but I’m hopeful this will be a big deal for quality apps, maybe even — dare I say it — paid apps.

For years now developers have been suggesting Apple clear the App Store of cruft. But as was evident again this year at WWDC, Apple loves to brag about the number of iOS apps in the App Store, no matter how meaningless the number is given how terrible a vast majority of them are. So, rather than culling the App Store by forcing developers to update apps or face removal, app previews may have a similar effect. Updating App Store screenshots (and I assume by extension app preview videos) requires the submission of a new binary, and submitting a new binary requires that the app be optimized for iOS 7.

My hope is that within a few months of the release of iOS 8, App Store shoppers will come to see app previews as a sign of quality, actively developed apps. I’m also hopeful that app previews will go a long way in demonstrating the value of an app and give developers another tool to communicate differentiation in a crowded App Store.

[drbarnard]

Interview: Facebook’s App Links — MacStories

An hour or so after App Links was announced today at F8, Federico Viticci asked me a couple related questions for a post he was working on. I quickly tapped out my response on my iPhone via Twitter DMs while relying heavily on Justin and Brock to fill in some of the technical details. Viticci’s post gives the full picture, but in homage to Vox’s cool idea of posting interview transcripts alongside some posts, I thought it worth posting my full response…

Viticci: How does App Links work differently from what is possible with URL schemes on iOS? Do you think it’s a big deal and why?

Me: From what we can tell so far, App Links is focused on deep linking to content, not passing data to an app that will take action on that data. Interestingly enough, this is not that different from the deep linking Apple promoted at WWDC last year [I later realized it was actually WWDC 2012]. It’s just that Facebook is doing it across platforms and native apps (Apple’s implementation only works in Safari) and is extending the idea. I wouldn’t be surprised if Apple has been planning something similar (except not cross platform) that will be introduced at WWDC.

Facebook’s code certainly makes it easier, but developers still have to handle navigating the UI to the content which has always been the most challenging part of implementing deep linking within an app (Yelp currently has several related bugs we reported to them).

App Links doesn’t do anything new that wasn’t previously possible with URL schemes, it provides a structured, cross-platform way to do it. The good news is, Facebook getting behind this means it should be more widely adopted than other deep linking solutions that already existed.

But this is Facebook we’re talking about, so the long-term goal is surely to sell deep linked ads and find other ways to monetize it.

This may or may not have much of an impact on productivity focused inter-app communication. App Links allows for the passing of data in the URL, but doesn’t provide a structured way to do it. So it really depends on how developers implement (and document) that aspect of App Links. 

Overall though, I think this concept is great for user experience on mobile devices. Jumping from app to app and back is something we all do. App Links should improve that experience for apps that implement it, but it’s going to take time for it to be widespread enough for it to make a huge difference in the day to day experience of most smartphone users. And if Apple introduces their own solution it could muddy the waters.

[drbarnard]

An Interview About Paid Apps

Last October, Andrew Hayward interviewed me for an article that ran in the print edition of MacLife. Since it was never published online, I completely forgot about the interview. Today, the article was posted on TechLife, a subsidiary of MacLife. Andrew used several quotes from our interview, but didn’t have room for some of my longer rants. Since the topic is just as relevant today, I figured it was worth posting the entire interview as emailed on October 30th, 2013.

How has the market for paid apps changed during your time selling premium apps in the App Store?

I’m not sure to what extent each factor is impacting the market, but it seems as though many factors have been at play in reshaping the market over the past couple years.

As the US smartphone market matures, it’s no longer more affluent early adopters buying iPhones and scouring the App Store for new apps, it’s less tech savvy users and more price sensitive consumers.

At the same time, the early adopters who are still upgrading their iPhone every year or two seem to not be as actively looking for apps. I used to buy 5+ new apps a week and now I hardly buy any. Not because I’m trying to spend less money, I’ve just already settled on 10-15 apps I use daily and am not seeing as many new apps that seem worth my time to check out.

It also seems as though there are enough free and cheap alternatives that people looking for specific types of apps end up using “good enough” free and cheap apps, rather than risking $3-5 on a premium app.

And I’m sure there are other factors at play as well. I’ve heard other theories about people no longer downloading and playing with apps as a form of entertainment in and of itself.

Have you taken any steps to counteract the changing market regarding the way you price and construct your apps, and have you seen results (whether positive or negative)?

I was hoping that as people upgraded to iOS 7 and went looking for iOS 7 compatible apps there would be a surge in sales for great iOS 7 apps. So, I decided to postpone more experiments with freemium and go with premium prices for the iOS 7 launch. But from what I’ve seen and heard from other developers, there wasn’t much of a surge in paid apps. In fact, it seems like sales of paid apps have been even worse since iOS 7 was released (which could be in part due to the App Store having so many issues since the iOS 7 launch). I have a few more experiments planned with premium pricing, then I’ll probably start working toward switching them to some sort of freemium model next year. Thankfully, Apple implemented App Store receipts in iOS 7, so developers can switch to freemium while still rewarding the early adopters who paid full price.

Do you think that there’s anything Apple can (or should) do to help buoy the premium app market?

There’s a lot Apple can do. Few people think of it this way, but Apple controls the App Store economy in a way similar to how the US government controls the US economy. The government doesn’t have complete control of the economy, but they work hard to shape it through a combination of tax incentives, monetary policy, and other means. Similarly, I think people underestimate just how much Apple’s policies shape the App Store market.

Currently developers can use IAP for all sorts of convoluted free-to-play schemes, but Apple has a rule against free trials, demo apps, and the like. With a single policy change, Apple could empower developers to use App Store receipts to roll their own free trials. Surely that’s no more user hostile than Candy Crush’s casino-like techniques for milking users for cash.

There are lots of other seemingly small things Apple could do that would end up rewarding developers who line up with Apple’s priorities. For example, there seems to be absolutely no search ranking boost associated with apps that were rebuilt for iOS 7. So, Apple pushed hard for developers to support iOS 7, but when you search for “weather” in the iOS 7 App Store, you see a bunch of apps that haven’t been updated in ages, much less optimized for iOS 7. Search is incredibly important to the App Store market, yet it’s absolutely terrible and Apple doesn't seem to care.

Not only that, Apple didn’t even bother optimizing search for the iOS 7 release. If you search “iOS 7 weather” in the App Store, you don’t get weather apps that were optimized for iOS 7, you get SEO spammers (and soon my Perfect Weather app since I figured out the issue).

What's your take on the trend (especially post-iOS 7) of developers releasing an entirely new app for a significant version release, as we've seen with Tweetbot and Screens of late? Do you think consumers will become more accepting of this approach as it continues?

There is a vocal minority that seems to be bothered by this, but I think it's absolutely the right thing for developers, and ultimately for users since it keeps developers in business and updating their apps. However, I will say that I think developers should be careful in how they do this. Charging frequently for minor updates does feel like nickel and diming users. One big paid upgrade every 12-18 months with lots of new features seems fair to me.

I talked at length about all this today on CMD+Space. Feel free to use anything from there as well: http://5by5.tv/cmdspace/68

UPDATE: One caveat about releasing paid updates in the App Store: they can kill search ranking. If your app relies heavily on search for user acquisition, a paid update could significantly reduce sustained downloads once the initial surge of upgrades slows. This happens because App Store search results seem to be very heavily weighted to all-time downloads, which obviously gets reset with a new SKU.

david

[drbarnard]

Shaping the App Store

From time to time I email Apple executives a “boots on the ground” view of the App Store and do my best to provide insight and contructive criticism rather than shallow complaints. Here’s my most recent email, starting with a quote from Andrew Webster at The Verge:

Angry Birds Go… features all of the right ingredients, including a cast of familiar and adorable characters, a charming and colorful presentation, and gameplay that's both easy to pick up and incredibly fun. But that potential is squandered — in the shift to free-to-play, Rovio has turned a great game into an annoying experience filled with incessant calls to spend more money.

While the current wave of free-to-play games are doing incredibly well financially, I worry that they are undermining the long-term strength of the iOS platform. Instead of building meaningful productivity and entertainment experiences, more and more developers are focusing their efforts on manipulating users into spending more and more money via consumable in-app purchases. I think John Gruber put it well: “…in-app purchases are driving game design more towards addiction and less towards fun.”

And another quote from independent developer Justin Williams: “The post-PC revolution won't happen without the software that the current App Store economy makes it nearly impossible to build and sustain.”

I absolutely love the “Your Verse” iPad ad that was released this week, and on the surface it appears that the current state of the App Store isn’t preventing amazing “post-PC” apps from being developed. But things are not always as they appear on the surface. It would be interesting for Apple to study various “post-PC” apps in the App Store (including ones featured in the “Your Verse” ad and featured on the App Store in recent months) to better understand the financial viability of creating and maintaing those apps. If the apps Apple brags about and features aren’t financially viable, we will inevitably see fewer of those apps being built over time.

As I’ve mentioned in previous emails, Apple can and does dramatically shape the App Store economy. Similar to how governments shape economies through tax law and other policies, Apple shapes the App Store economy through app review policies, App Store implementation details, editorial decisions, the App Store search algorithm, and in so many other subtle (and not so subtle) ways. I’d love to see Apple wield that power to shape the App Store in ways that will sustain and encourage meaningful development over the long-term and not let the current success of the App Store blind it to issues that are impacting the trajectory of the App Store.

david

[drbarnard]

Contrast

When I founded App Cubby in April of 2008, my vision was to create a suite of data logging apps for the iPhone. App Cubby was to be a ‘cubby’ of apps, and each app a cubbyhole for data. The name always felt a bit juvenile, but the metaphor was just too great to pass up.

I released Trip Cubby in August of 2008, then Gas Cubby that November, and Health Cubby the following January. I was incredibly proud of my work and all three apps were quite well received. But over time, App Cubby branched out beyond data logging apps, and the wood themed icons and interfaces that were once so fresh and beautiful began to look rather dated.

Within a few months of launching the new App Cubby site in October 2011, I was daydreaming about new branding and another complete redesign of the site. Then in the spring of 2012 LogMeIn launched Cubby App in the App Store and it became apparent that it was time for me to move on.

After months of search and deliberation, and many more months of work with several talented artists, I’m thrilled to announce that App Cubby is now Contrast and has a brand new website at contrast.co.

I’m a bit sad to leave the App Cubby name behind. It has, after all, been like part of my family for these past 5 years. However, I think Contrast is a much better fit for the projects I’m currently working on and the vision I have for the future of the company.

david

[drbarnard]

Trip Cubby Turns Five

Five years ago today, Trip Cubby landed in the App Store. After months of hard work, it was such a relief to finally have an app for sale. But it was also incredibly scary — I put it all on the line to build Trip Cubby. Would people find it useful? Would it actually sell? Were there any bugs that slipped through our testing?

Trip Cubby wasn’t a runaway success, and it didn’t make me an App Store millionaire overnight. But people did find it useful, and it did sell, and there were a few bugs we scrambled to fix.

Here we are five years later, and I’m embarrassed to say the app hasn’t been updated in almost two years. It’s still a decent mileage log, but it’s woefully out of date — especially under the bright lights of iOS 7. Because Apple does not allow paid upgrades, and the App Store is such a challenging place for niche apps to achieve profitability, updating the app for iOS 7 was not an easy decision to make. In fact, I’ve been thinking for months now that I would just pull the app from the App Store this summer.

I’ve been forced to pull apps from the App Store in the past, and, as painful as it was to feel like I’d abandoned users and given up, I justified pulling the apps because doing so would allow me to stay in business and keep building apps. Fortunately, things are a bit different this time. I still haven’t made millions, but I’m finally in a position where I can reinvest in an app like Trip Cubby without putting my entire financial future on the line.

So that’s exactly what I’m going to do! Last month, I hired Overcommitted to completely rewrite Trip Cubby from the ground up for iOS 7. Harold and Jonathan have been amazing to work with, and we’re pushing hard for a fall release.

Along with the fresh pixels and bits, Trip Cubby will also get a new name and be launched as a new, paid app. Existing users will be able to keep using Trip Cubby indefinitely or easily export their current data from Trip Cubby and import it into the new app. While we’re working on the new app, I’ve decided to make Trip Cubby free. You can download it today and start tracking your mileage in anticipation of importing your data into a great new app this fall.

david

[drbarnard]

Human Authenticity

I love debating the appropriate use of minimalism, exploring ways to make user interfaces simple without regressing to simplistic, and working within the constraints of the medium. But trying to approach design with “digital authenticity” is the furthest thing from my mind.

There is nothing inherently authentic about anything created digitally. There’s nothing genuine about 0’s and 1’s and any particular sequence that describes pixels on a screen. Humans created the hardware and software that sequence those bits, and unless we’re talking about some sort of futuristic research project, everything created digitally is created for some ultimate form of human consumption. Whether the output is high art or a calculator app, the point is human involvement — both in the creation and in the appreciation of the created. Even algorithms designed to create things autonomously were created by humans with the output intended to involve humans at some level.

And in user interface design, leaving humans out of the equation — or minimizing their importance — leads to poor choices. There’s a reason Apple uses “Human Interface Guidelines” to describe their most important design resource. If anything, we should strive to design with human authenticity in mind.

The use of realistic textures and real world metaphors was not done — at least at a higher level — merely because we could, but because those designs were ultimately more relatable to humans. Though obviously overused in many cases, there are concrete usability improvements in relating interfaces to the physical world. As we make an aesthetic shift away from texture heavy interfaces, it’s more important than ever to keep humans at the center of design. I see too many designers unwittingly throwing the baby out with the bathwater and telling others to do the same.

Many have touted iOS 7 as Apple’s break from skeuomorphism, and that’s true if we apply its strictest definition, but in iOS 7 Apple chose to double down on physicality and the use of real world metaphors. Creating a physics engine for the user interface is most certainly not digital authenticity. While designing for iOS 7 and beyond, usability should always trump ideology and aesthetic. Beauty can enhance usability, but ultimately we’re creating software for people to use, not stare at in awe. That’s where texture heavy design went wrong, and that’s where “digitally authentic” design will likely stumble as well.

Interface design is about the human, not the computer.