Making Money From Your Windows Phone Apps

After reading my last few posts, and being inspired to develop your first Windows Phone app, now it’s time to talk about what options you have for making money from your app before you publish that bad boy to the Windows Phone Store!

First and foremost, we can all agree that building mobile apps can be a lot of fun, right? You know what’s also fun? Making some money from those apps! In this post, I will demonstrate how the Windows Phone SDK makes it easy for you to monetize your apps.

This post requires some interaction with your Windows Phone Developer Centre account. So if you haven’t registered for this account just yet, and you want to follow along, now is a good time! Remember, if you are a student with a DreamSpark account, or an MSDN subscriber, you can register for this account for free!

Pricing Options

You can choose to offer your app at a price, offer a trial version with your paid app, or offer it up for free. The type of app you offer determines the buttons and related actions that are available from your app’s page in the Windows Phone Store, as shown below.

Paid App Paid with Trial Free
clip_image002 clip_image004 clip_image006

The app submission page allows you to select a pricing increment from a list, which ranges anywhere from $0.00 to $480.49. The lowest price you can choose to sell your app for, if you are going with the paid app route, is $0.99.

If you decide to offer your app for free, just leave the base price at the default value of $0.00.

Got that? No? That’s ok, you’ll see I mean later in this post as we dive right into it!

If you choose to sell your app at a base price or offer it for free - without any advertisements or in-app purchases - there are no code changes required within your app to do this. You can simply submit your app to the Windows Phone Store. I will discuss publishing apps to the Store next week, so we won’t dwell on this right now. However, we will be touching on how to set the pricing structure for your app, so keep reading!

Offering Trial Versions

You’ve decided you want to offer your app up at a price. That’s great! What would make it more enticing to the general public and encourage downloads, would be to offer a trial version of your app. This allows the user to try your app. This is the user’s opportunity to discover the need for your app in his/her day-to-day activities, and decide to purchase the fully licensed version!

It’s important to note that the Windows Phone SDK does not allow you to offer time-based trials. That means that you can’t lock a user out of your app after “x” number of days. Instead, you will need to decide which features are only available to users that have purchased the app – we often think of these as the premium features. If you were publishing a game, for example, you could simply limit the user to play at the first level only. This gives the user the chance to try out your game, and the option to purchase the full version if they want to continue on. Trial apps will display both a “try” and “buy” button in the Windows Phone Store.

Offering trial versions requires some minor code changes. Three lines of code to be exact:

  1. Namespace declaration:
  2. Class level variable:
  3. Function call:

The call to the IsTrial() method should take place in the Application_Launching and Application_Activated events. If it returns True, the user is still running in trial mode. If it returns False, the user has purchased the app.

I prefer to just wrap up my license check code in a view model, and provide a public property that I can use for data binding. I can bind this property to a property on each of my page elements which will enable/disable features based on whether the user is running in trial mode or not. I’ve provided a sample project which you can download from my SkyDrive account.

In-App Advertisements

Ok, so you’ve decided to offer your app for free and include in-app advertisements. If you’re wondering why I’m making the assumption that you’re offering your app for free, it’s because you absolutely should not include advertisements within a paid app. Huge faux pas… and I mean huge. It’s a sure-fire way to get bad ratings from users that paid full price for your apps.

To include advertisements within your ads, the Windows Phone SDK also comes packaged with the Microsoft Advertising SDK. This contains the libraries that you will need to integrate ads with only a few lines of code, along with the inclusion of the Microsoft AdControl in the pages you wish to display ads on. The ads display as 480X80 banners which you should place at the top or bottom of your views to ensure they are unobtrusive, but still be available in plain sight to catch the user’s eye.

To setup your application to display advertisements, you will need to:

  1. Add a reference to the Microsoft.Advertising.Mobile and Microsoft.Advertising.Mobile.UI libraries within your app. You can find them within the Framework > Extensions section in the Reference Manager dialog.

  2. In your application pages, drag and drop the Microsoft AdControl from the toolbox onto the page, which will add this XAML to your page (along with the my namespace declaration in the PhoneApplicationPage root element):

  3. Next, you will need to log into your Dev Centre account to generate your application Id and ad unit Id. No Application Id, No Ad Unit Id, No Service.

    The reasoning behind this: Microsoft is able to push ads to the AdControl within your app, as well as track clicks and impressions generated from your app, based on a unique ApplicationId and AdUnitId that is associated to your app.

    These unique identifiers must be generated in the Application Submission page in your Dev Centre account, as shown below.

    To get to this page, you must click the Submit App link:


    In the Submit App page, click the Add in-app advertising link:


    You will notice that your Application Id, labeled as pubCenter Application ID, defaults to None. The Application Id will automatically generate when you create your first ad unit Id for this app. You will also notice that there are a list of different sizes that you can select for your ad display. For Windows Phone 8 apps, the only size you should use at this time is 480X80. The two smaller sizes are only available for backward compatibility for older Windows Phone apps. The larger size is for Windows Store apps. For more information, check out this MSDN article: Use the Recommended AdUnit Format Size and AdControl Size

    Next, you must enter a name for your ad unit, select 480X80, and click the Generate ad unit ID link.


  4. Now you can copy the Application Id and the Ad Unit Id into the relevant properties in each page that you included an AdControl. Be sure to explicitly set the Height and Width as well:


  5. Next, set the IsAutoCollapseEnabled and the IsAutoRefreshEnabled properties to True, so that the AdControl will automatically collapse on error or if no ads are available to display, and automatically refresh when it starts receiving ads again:

  6. It may take some time for ads to start appearing in your AdControl from the time that you first generate the Application Id and Ad Unit Id. Alternatively, you can use test Ids when launching your app in the emulator, just to see how the control renders ads:


Voila! You now have an ad-enabled app and you didn’t have to do too much to get it to that point.

In-App Purchases

Microsoft has made it easy for you to include in-app purchases within your apps. All you need to do is list your products, and include a few lines of code in your app to allow the user to purchase and receive the goods. Microsoft handles everything else, which includes providing you with product management tools through your Dev Centre account, providing the user with a consistent purchase experience, the ability to pay you in 190 countries or regions, and providing proof of purchase. In a nutshell, Microsoft handles all of the hard stuff.

Your app can be designed to sell consumable or durable products.

A consumable product is one that the user consumes, or uses up, and may need to buy more. For example, if you developed an app that is a virtual pet, you can sell virtual goods to the user to take care of the pet, such as pet food.

A durable product is one that the user buys once, and has forever. For example, if you developed a recipes app, which allowed the user to unlock a special package of recipes for each holiday, then that would be a durable product. The user only pays once for each recipe package, and then can access it for as long as he/she has the app installed on the device.

Defining Products For Your App

The first thing you want to do is decide what type of products your app will provide for sale. The second thing you will then need to do is define the products in your app’s page within your Dev Centre account. This requires you to start an app submission process, save it, then revisit the app in your Dashboard. You will then be able to click on the Products link, as shown below:


The Products link will take you to your app’s products page. Here you can add new products or view the list of products you’ve already defined for your app. Click Add in-app product link.


To add an in-app product to the catalog, you will set the basic properties: alias for the product, unique product identifier which you will use in the app, base price, default language, and market distribution.

You will also need to set the product name and description that will be displayed to the user, along with a product image. The image must be a 300X300 PNG file.

Wiring up In-App Purchases Within Your App

The final step that you need to take is to wire up the necessary code to display your products within your app to allow users to purchase them! All of the methods that you will need for this part are available off of the CurrentApp class, which is part of the Windows.ApplicationModel.Store namespace. You can do this in 5 easy steps:

  1. Check licensed products - when loading any views that may utilize purchased products, check the licenses to see which products have been purchased, and make those available to the user. You can check this through the CurrentApp.ListingInformation.ProductLicenses collection. The IsActive property indicates whether the product is licensed (True means that it is!). The IsConsumable property indicates whether the product is consumable (True) or durable (False).

  2. List the products - to retrieve a listing of products available for sale you can call LoadListingInformationByProductIdsAsync or LoadListingInformationByKeywordsAsync. Either method will return an object containing the products you requested. For example:


    You will receive the list of products through the ListingInformation object, info, within the ProductListings collection. Each product listing will contain the product’s name, description, image Uri, and price that you defined in the product catalog. Simply bind this collection to a list within your page and define the list’s item template to display the product information appropriately.

  3. Allow the user to buy products – provide a “buy” button, which will then launch the selected product’s purchase screen. You can launch the purchase screen by calling the RequestProductPurchaseAsync method, passing in the product Id. You must also indicate whether or not you want the method to return a receipt. If you do choose to receive the receipt on completion of this method, it will be returned as an XML string; otherwise, you will not need to check for a result to be returned. Example:


  4. Fulfill the order in your app - if the user bought pet food for his virtual pet, make that pet food available to the user within the app. Also, you will need to notify the Windows Phone Store that the order was fulfilled by calling the ReportProductFulfillment method passing in the product Id. If you do not fulfill the order in the Store, the user will not be able to repurchase the product later. Example:


  5. Retrieve the product receipt – if you didn’t opt in to receive the receipt during the product purchase, you can obtain the product receipt separately by calling the GetProductReceiptAsync method, passing in the product Id. The receipt will be returned as an XML string. Example:


I know that of all the monetization options we went over in this post, in-app purchasing seems to have more leg work. Once you’re familiar with the basics, it is fairly easy to get up and running! If you’re new to the concept of in-app purchases, I highly recommend you read the MSDN article to gain a better understanding of the framework and process flow when implementing this feature within your apps.

In Summary

As I demonstrated in this post, monetizing your app is as easy as including a few lines of code, and tweaking your app submission configuration in your Dev Centre account. Next week, I will wrap up the series with a post on publishing your app to the Windows Phone Store!