Charging for your app

You can set a price for your app. If you publish on Google’s Play Store or Amazon’s Appstore, you pay a 30 percent commission. That’s not bad considering that Google paid seven billion dollars to app developers between February 2014 and February 2015. (See www.theverge.com/google/2015/2/26/8112475/google-play-android-app-store-ads-sponsored-search.)

If you decide to charge for your app, what price should you set?* The following sections offer you some advice.

Offering an extended free trial

Google Play buyers can return an app within two hours for a full refund. If you want the trial period to last longer, you have to outfit your app. One way to do it is to have the app record the time when it was first launched and compare this to the current system time. Of course, saving this information in SharedPreferences isn’t foolproof. A user with some programming skill can hack the scheme and can share this hack with others. (Once your app has been hacked, there’s no going back. You can’t track down all sources of illicit information and stop them in their tracks. Bad information spreads very quickly. No matter what you do, a tip about hacking your app will be available online forever.)

Instead of storing times and dates on the user’s device, you can send this information to a server along with the device’s identification number. Have the app check that server regularly. Like the SharedPreferences scheme, this server-based scheme isn’t foolproof. But storing times and dates on a server is harder to crack than storing information on the user’s device.

On a phone, you get the device’s identification number by calling the TelephonyManager class’s getDeviceId method. For a device that’s not a phone, you can ask for the Settings.Secure.ANDROID_ID field.

Another way to implement a many-day trial period is to create two apps with two different licensing arrangements. The free trial app’s license expires in 30 days. But as the trial app breathes its dying breath, it reminds the user to visit the Play Store and purchase the paid app.

If you don’t like maintaining two separate apps, you can cut the cake in a different place. Create one app that implements both the trial version and the full version. Distribute this app freely. But as part of this dual-version app’s logic, have the app check the user’s device for the presence of a second, paid app. The second app does nothing except either exist or not exist on a user’s device. If the second app exists, the dual-version app behaves like the full version. But if the second app doesn’t exist, the dual-version app behaves like the trial version.

One way or another, the Play Store’s app licensing tools are more reliable than most home-grown date-checking techniques. Using licensing to police the trial period is a good idea.

For a few words on the Play Store’s app licensing tricks, see Chapter 1 in this minibook.

Freemium apps

A mobile app with a paid-only revenue model is rare indeed. By one count, there were ten times as many free apps as paid apps in 2013. (See and www.statista.com/statistics/241587/number-of-free-mobile-app-downloads-worldwide and www.statista.com/statistics/241589/number-of-paid-mobile-app-downloads-worldwide.)

In the freemium revenue model, one useful version of your app serves as advertising for an even more useful version. This form of advertising has several advantages over more traditional advertising modes.

• The advertising is well-targeted.

  People who install your free version are potential buyers for your paid version.

• It directly demonstrates your app’s benefits.

  Instead of reading about your app, or hearing about your app, users experience your app.

• It’s repetitive without being annoying.

  A potential customer probably uses the free version on a regular basis.

• It can be inexpensive.

  You incur an expense when you create the app, and you have to create the app anyway. But after you’ve published the app, the marginal cost of each free download is almost nothing. (This assumes that you don’t offer services for each active user. Yes, the free users might find bugs, and fixing the bugs takes your time and effort. But the effort you spend fixing these bugs doesn’t count as an advertising expense. You’d be fixing these bugs no matter who found them.)

• It enhances your reputation.

  This one is a “biggie.” With conventional advertising, you can come off as a snake oil salesman. But with a free version of your app, you’re a benevolent developer (a benevolent developer who might occasionally ask for well-deserved remuneration). Think back to the last few times you upgraded from free to premium. For me, it wasn’t because I needed the enhanced features. Instead it was because, through repeated use of the app, I had formed a certain respect for the originator.

As with several other revenue models, the main question is “how much?” In the freemium model, which parts of your app do you give away for free? Which parts do you keep for the paid version? As usual, there’s no prepackaged answer. But there are some general strategies:

• Divide your users into two categories — the high-rollers and the not-so-high-rollers.

  The high-rollers might be the corporate users; the others are individuals. The high-rollers need premium features and have the resources to pay for those features. The others don’t. Which features of your app appeal primarily to the high-rollers? Put those features in the premium version.

• If you don’t incur a cost each time someone uses a particular feature, give that feature away for free. If you incur an ongoing cost, charge for that feature.

  An app on a phone or a tablet can do only so much work. Maybe, to implement certain features, your app ships work out to a server. Access to the server costs money, and the amount of money depends on the workload. The more people use these costly features, the more revenue you must have. (Otherwise, you’ll go broke.) So tie the price of the app to the use of these features. The app’s premium version includes these costly features; the app’s free version doesn’t.

• If volume usage is relevant for your app, create a soft paywall.

  A hard paywall is an all-or-nothing restriction on the use of a resource. But with a soft paywall, users get 500 wha’cha’ma’call’its for free each month. Users who need more than 500 wha’cha’ma’call’its each month buy a recurring subscription. You can change the number when you see the need. But when you do, be aware of the impression you make on your existing users (both the free users and the paid users).

  For some good reading about recurring subscriptions, see this chapter’s “Subscription pricing” section.

• Advertise or nag in the free version.

  If the previous approaches are like carrots, this approach is like a stick. With this approach, you entice users to pay for your app by putting something undesirable in the free version. Unfortunately, Android has no emitUnpleasantOdor method. So, for the undesirable feature, most developers advertise or nag.

  Nagging involves displaying a pop-up alert box reminding the user to buy the retail version. You decide how often you want the pop-up to appear, and what the user must do in order to dismiss it.

  The advertising option has a few advantages over the nagging option. For one thing, advertising can be unobtrusive. (Who ever heard of unobtrusive nagging?) When advertising is unobtrusive, users tend not to associate it with the app or with the developer. So, with advertising, your image remains largely untarnished. And let’s not forget — advertising can bring you some revenue while you wait for users to purchase your app’s full version.

• (Not recommended) In the free app, include only enough functionality to demonstrate the paid app’s usefulness.

  Apps that involve saving data tend to use this strategy. With the free version, you put the app through its paces. You examine the results to see the how effectively the app does its job, but you can’t save the results. The user is disappointed because, in the final analysis, the free app is nothing but a tease.

  With this approach, you undermine some of the freemium model’s advantages. For one thing, you lose the repetition advantage. A potential user tries your app once to find out if it’s worth buying. Months later, when the need for your app arises in a more serious context, the user has forgotten about your app and finds another app in its place.

  More importantly, this approach ignores the benefits of customer loyalty. Instead of impressing users with your generosity, you annoy users with your stinginess. You lead a user to the brink of success. But then, at the last minute, you confront the user with a mean-spirited roadblock. Whether you think of your app this way or not isn’t relevant. What’s relevant is that users feel this way.

  If you have a killer app, and all you need to do is assure users that your app can perform its supposedly herculean tasks, then this approach is for you. Otherwise, you should avoid using it.

For most apps, the percentage of free-version users who become paid-version users is in the single digits. But that’s okay, because free users aren’t “deadbeat” users. Free users form an important part of your marketing ecosystem. They help spread the word about your app. If your app has any social aspects, the more users you have (free or paid), the better. And if anyone checks your app’s usage statistics, free users count. So, by all means, give the free users access to your app’s essential features.

Selling things with your app

Google’s Play Store and Amazon’s Appstore differ on the kinds of things you can sell. With Amazon’s Appstore, you can sell physical goods. (Amazon has never been squeamish about shipping physical items.) On Google Play, you can sell only digital content. So, if you publish a game, and you want to sell action figures of the game’s characters, you have to use Amazon’s Appstore. (You can sell action figures for a game on Google’s Play Store. You just can’t embed the purchase as a feature of the game.)

To set up in-app billing, you make additions to your app’s code. You create a service, a broadcast receiver, an AIDL file, and some other stuff. You add a permission in the app’s AndroidManifest.xml file:

<uses-permission

      android:name="com.android.vending.BILLING" />

On Google’s Developer Console, you visit the in-app billing pages. You select the kind of billing you want for your app.

For help getting to the Play Store’s Developer Console, refer to Chapter 1 in this minibook.

• Managed product: The Play Store manages this one-time sale.
• Unmanaged product: You manage this sale.
• Subscription: The Play Store manages this recurring sale. (See the next section.)

In the Developer Console, you give the product a name (a title). You enter a description and you specify the price. You can accept the default conversions into other countries' prices, or you can name your own local prices.

The Play Store can manage the billing for your product, but the Play Store doesn’t deliver content. Delivery of the purchased content is up to you.

For some of the gory details about in-app billing, visit http://developer.android.com/guide/market/billing/billing_integrate.html.

Subscription pricing

Some apps require care and feeding when they run. They consume data that needs to be updated periodically, or they consume services that you must provide. For apps of this kind, subscriptions might be appropriate.

A subscription charges the user repeatedly. As an app’s developer, you get to choose what “repeatedly” means. The options are monthly, yearly, and seasonal. (The seasonal option is like the yearly option, except that renewal occurs only during a certain part of the year — a part that you specify with start and end dates.)

If your app’s content requires regular refreshing, the subscription model is worth your consideration. You can build up a steady income flow, and that’s worth a lot.

Subscription pricing works only if your content requires it. I’ve seen apps with artificially imposed subscription policies (having the app self-destruct after a certain period of time). Apps of this kind work well for big business clients, but they have little appeal for individual users.

For more information on subscription billing through the Play Store, visit https://developer.android.com/google/play/billing/billing_subscriptions.html.

Earning revenue from advertising

There was probably a time when you had to jump through hoops before you could display ads inside your app. You’d find people who wanted to advertise their goods or services, write code to display their ads, strike up an agreement on the price for your advertising, and so on. Nowadays, it’s not difficult at all. It’s a smooth-running assembly line.

In this section, I outline the steps you need to take in order to display ads in your app. I don’t provide much detail because the details change frequently. Instead, this section’s outline describes what you can expect to do when you dive into the advertising game. Google’s AdMob facility handles all the nitty-gritty details, and the AdMob web pages guide you through every step of the process.

Here’s the outline:

1. Visit https://apps.admob.com/admob/signup.

2. Sign in with a Google account.

   You can use the same account that you use when you sign in to the Play Store’s Developer Console.

3. Enter the required information about yourself.

   Don’t worry. It’s not too much information.

4. Click a Monetize New App button, or something like that.

   When you do, you see a page where you enter the name of your app. AdMob finds your app on the Play Store.

5. Enter some information about the ads that you want to display.

   How do you want the ads to appear? The choices are banner or interstitial.

   • A banner ad appears as a small band somewhere on the app’s screen.

     A banner ad can appear or disappear any time during the run of your app.

   • An interstitial ad takes up a large part of the device’s screen.

     An interstitial ad shows up only when the user won’t be terribly annoyed by the ad’s appearance. For example, if your app is a game, you might code your app so that an interstitial ad appears only between rounds.

   If you’re familiar with time/space tradeoffs, you’ll recognize where the two types of ads fit in. A banner ad consumes very little space but can appear almost anytime. An interstitial ad consumes less time in order to gain some space.

   In this step, you also specify the refresh rate for ads, and some other things.

   The refresh rate is the amount of time that each ad remains on the user’s screen (before being replaced by another ad). Research shows that a rate of 60 seconds or longer works best.

   At some point, the web page displays an ad unit ID. This ad unit ID number goes into your app’s code. When a user runs your app, the app sends this ID number to the AdMob servers. The more the AdMob servers receive your ID, the more money you earn.

6. Make a note of your ad unit ID.

   Meanwhile, back on your development computer …

7. Use the Android SDK Manager to install the Google Repository.

   You’ll find the Google Repository entry in the Android SDK Manager’s Extras category.

8. Add stuff to your project’s files.

   Here are a few of the things you do:

   • You put your ad unit ID in the strings.xml file.

     This identifies your app so you can earn money for displaying ads.

   • You put a com.google.android.gms.ads.AdView element in your activity’s layout.

     This element can display ads.

   • You add code to your app’s activity.

     The code loads ads into your layout’s AdView widget. For a banner ad with AdMob, the code is pretty simple:

     AdView adView = (AdView) findViewById(R.id.adView);

     AdRequest = new AdRequest.Builder().build();

     adView.loadAd(adRequest);

   Visit https://developers.google.com/mobile-ads-sdk/docs/admob/android/quick-start for all the details.

When your app goes live, the amount that you earn varies from one advertiser to the next. In most cases, the amount hangs on a “cost per something or other” measure. Here are a few possibilities:

• CPC: Cost per click

  Your payment depends on the number of users who click on the ad in your app.

• CPM: Cost per thousand impressions

  An impression is the appearance of an ad on a user’s screen. A single impression isn’t very impressive. So for every thousand ads that appear, you get paid.

• CPA: Cost per action

  You earn money whenever a user performs a certain action. What constitutes an action depends on the advertiser. Examples of actions are clicks, sales, and registrations.

One way or another, advertising is a relatively low-maintenance way to earn some money for publishing your app.

Variations on in-app advertising

Your app is a place where others can advertise. Given that fact, there are dozens of ways you can tweak the advertising model. If your app complements an existing company’s business, get the company to sponsor your app. You can meld references to the company’s products and services into your app’s interface. If you do it tastefully, users don’t feel that they’re being pressured. (This isn’t a new idea. In the earliest days of U.S. television, shows integrated ads into their regular scripts. George and Gracie would move seamlessly from a kitchen comedy routine to a minute-long discussion of Carnation Evaporated Milk.)

Incentivized advertising is another option. With this option, advertisers reward users who perform certain actions within your app. For example, your app stores and displays recipes. For every ten recipes that the user completes, the app rewards the user with a coupon for cooking utensils. The advertiser gets the business, the user gets the goods, you get the revenue, and your app gets used. Everyone wins.

Both sponsorship and incentivized advertising are very well targeted. You’re not promoting automobiles for ten year olds or weight-lifting equipment for me and my fellow college professors. Instead, you’re riding a wave. It’s a synergy wave between your app’s theme and a company’s wares.

Donationware

If you’re not trying to earn a fortune, but you’d like some spare change from your most loyal users, try this strategy. Use in-app billing as in the “Selling things with your app” section. But instead of delivering a product, deliver a “thank you.”

The rate of return will be very small. But I’ve done some donating for my favorite apps. So for all the apps that have ever been published, the return rate isn’t zero.

Offering your app for free

You might argue against my decision to put this “absolutely free” subsection inside the “Choosing a Revenue Model” section. But let’s face it — for a novice developer, “absolutely free” is a choice worth considering. For one thing, a free app attracts more users than a paid app. With your free app, you can start building your reputation among users. This reputation might be for you as a developer, or for the apps in your ongoing development plans. Besides, when you publish your first app, you learn a lot about the process. That’s worth something even if it’s not monetary.

Revenue or no revenue, an unmeasurable benefit is derived from giving freely to the community. When you think about publishing apps, don’t forget about giving.

Getting paid to develop apps for others

Don’t forget about this option. Find a local business or a big company. Write code or design user interfaces. Create the artwork for apps. Do what you do best and leave the rest to the business moguls.

Brick Breaker Master: An app marketing case study

The epistolary novel has a long and noble history. In Rousseau’s Julie, or The New Heloise, two lovers pass letters back and forth. Goethe’s The Sorrows of Young Werther is a collection of letters from Werther to his friend William. Shelly’s Frankenstein includes a sea captain’s letters. More recently, such notables as Stephen King, Gary Shteyngart, and Daniel Handler (writing as Lemony Snicket) have featured diaries, news articles, and letters written by their novels' characters.

As far as I know, this section is the first use of the epistolary style in a For Dummies book.

I can’t claim full credit for this accomplishment. The interchange that’s documented here is mostly real. It’s a bunch of excerpts from an email conversation between me and a reader. In these email messages, the reader (Daniel Levesque) does most of the heavy lifting. All I do is ask the right questions. I’ve trimmed some paragraphs to keep it relevant, and this book’s copy editor will probably make some useful changes. Otherwise, the words that you see here are true and unadorned.

From: Daniel Levesque

To: Barry Burd

February 25, 2013

Good morning Barry.

I’m about to finish the book Beginning Programming with Java For Dummies. Then I will start later this week Java For Dummies …

From: Barry Burd

To: Daniel Levesque

February 25, 2013

Daniel,

I’m glad that you’re enjoying my books. Have you noticed the last name of the project editor? (When your email arrived, I thought he was contacting me.) …

From: Daniel Levesque

To: Barry Burd

February 25, 2013

Yes I saw his name when I bought the book …

Many emails later …

From: Daniel Levesque

To: Barry Burd

August 14, 2013

Hi Barry,

A while ago you helped me with a couple of questions when I was reading your Java and Android books For Dummies. After all this “study,” I finally published my first game!

Many emails later …

From: Daniel Levesque

To: Barry Burd

June 12, 2014

Hello Barry,

I just published my second Android game of 2014: “Space Garbage!” The goal of the game is very simple: survive in space while avoiding the floating objects! …

Many emails later …

From: Daniel Levesque

To: Barry Burd

February 1, 2015

Hi Barry,

I thought I would let you know that I just released my first game of 2015. It is my very first game using a game engine, and I am quite happy with the result. The game is currently number 20 in the Google Play “Top New Paid” category!!!

Check it out when you have a minute: http://play.google.com/store/apps/details?id=com.d14studios.brickbreakermaster

Best regards,

Daniel Levesque

From: Barry Burd

To: Daniel Levesque

February 3, 2015

Daniel,

I’d love for you to send me some tips on your getting to the number 20 spot. I’m revising my Android All-in-One book, and I’d like to quote you in the chapter on publishing apps. Do you have any advice for up-and-coming developers?

Barry

From: Daniel Levesque

To: Barry Burd

February 4, 2015

Hi Barry,

It’s very difficult to do any marketing when you have a very small team or if you work on your own. Here’s what I did with Brick Breaker Master to promote installs:

I figured out that Google uses some kind of algorithm to rank “new paid apps” and “new free apps,” so I tried to generate several installs EVERY day for the first month.

I sent a message to my 200+ LinkedIn contacts asking them to install the game and give me a good rating (not sure how many actually did it).

I built a new App page on Facebook and asked all my family members and friends to “share” the page with their contacts (I figure that I probably got 50 shares through this, although the potential was more like 500).

I sent messages to my followers on Twitter every three days with a screenshot of one of the game levels (I didn’t tweet too often — didn’t want my followers to get upset and then unfollow me).

I updated my website as soon as I published the game on Google Play and on the Amazon Marketplace.

I submitted a summary of the game to the top ten Android review sites with the hope that they would publish a free review (most of them have an automated reply saying that they receive too many requests to guarantee a review but that for $100 they will … you get the picture). I didn’t want to spend $1,000 for ten reviews without knowing in advance what rating they would give my game! Unless you know for sure that you have a knock-out app, this approach is very risky.

I hope this will help with your chapter in the book.

Best regards,

Daniel

From: Barry Burd

To: Daniel Levesque

February 4, 2015

Thank you, Daniel

Barry

Notes