David Barnard - Blog

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.

image
image
image

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

image

 

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.

image

 

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

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.

image

 

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 ¯\_(ツ)_/¯ 

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.

image

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.

image

 

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:

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

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

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:

  1. 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.
  2. Programming Languages - In the long run, Swift will likely empower even more developers to more quickly build better apps.
  3. 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.
  4. 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.
  5. App Review Policies - Need I say more?
  6. 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…
  7. 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.
  8. 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.)

[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

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.