In App Purchases Work

As Posted at Microsoft Developer Connection on MSDN

In the Beginning

I started out developing for Windows Phone way back when Windows Phone 7 was the big thing.  Your options for monetization were pretty much advertising or charging for your app.  One great innovation that Microsoft provided to developers (and phone owners) was the concept of "Try" it before you buy it.  This did actually help out quite a bit.  With other platforms at that time (and some still today) if you, as the developer, wanted customers to be able to try your app before paying for it, you needed to create a special "free" version and publish alongside the "Pro or Paid" version that costs some money.  That created lots of extra work and management.  With the advent of Windows Phone 7 you could publish a single app with a bit of code inside that allowed a downloader of your app to play with it in either a feature or limited fashion and then when satisfied with the quality and usefulness just tap a button and update the app in-place to the full paid version.  All the work they had previously done was preserved because it actually was the same app with the light switch turned on.
This was all well and fine but as with most "innovations" it tended to be a good starting point.  Over the years of smart phones and app stores, many end users kind of got trained to look for "free" apps and, I think, had become averse to paying for apps.  Not all users, but certainly many stayed well clear of paid apps not realizing there was a try before you buy model.  I found this from personal experience. 

The coming of Windows Phone 8

Microsoft was listening.  In my opinion the single best part of Windows Phone 8, and there were lots of great bits, was the ability to do in-app purchases.  In-App purchases gave developers yet another way to monetize their apps.  Maybe the single best way if you ask many developers.  In-App purchases allowed a developer to release a clearly free app.  No Trial necessary.  However they could hold back some features like perhaps cloud storage or no advertising or coins in a game and allow the owner of the free app the option to get these neat features (for a small price) to make their favorite app even better. 

Mock or Not

For developers there was only two things you needed to learn.  When developing, add the Mock In-App Purchase Library to your app.  This library, available from the Windows Phone Dev Center lets you simulate the purchase of in-app purchase features.  This, in turn, lets the developer test out if their in-app purchase features are working without having to deploy to the store first.  For example, if a user of my app purchases the removal of advertising for $0.99, I can run my app in the debugger making sure that I properly disable the advertising feature of the app when purchased.  Also, while you need to check "durable" licenses each time you connect, if there is no network connection you will have had to have stored the information locally so the features are available anyway.  Basically you have an #if DEBUG statement that switches from the MockAPI to the store features depending on how you built the app.  Second, to implement in-app purchases for real you will need to become familiar with the "Windows.ApplicationModel.Store" library. It is within the CurrentApp class you will find everything you need to purchase in-app products and then, later, verify the purchase.  Once you have it working in test mode you will need to become friends with the "beta" system in the store.  You want to deploy your app as a beta where you can create the beta in-app purchase bits in the beta store, purchase them (for free) and then make sure everything is working properly.  Store Betas are critical to good apps in the long run.

Durable or Consumable

Microsoft provided options for in-app purchases that lets you be flexible.  Those purchases can be durable, like removing advertising, once done, done forever or consumable like buying coins in your favorite game to help you get past those nasty bad guys.  Even time expiring in-app purchases are available to you can provide a subscription model to your apps.  Each year to use those fine features, they need to pay some amount to keep using them.  The possibilities are endless.  I think, depending on the app, that a mixture is a good thing.   With Windows Phone 8.1 Microsoft gave developers the ability to synchronize in-app purchases across devices and platforms.  So, if I wish I can add the ability to purchase something for my phone app and then for the Windows 8.1 version have that purchase also appear.  This opens up many other options which I’ll reserve for a follow up post.

The Math

In-App purchase make sense even when cannibalizing your existing revenue streams.  For example you have a free app that has been downloaded 10,000 times and you are making a bit of money from advertising but really not enough yet so you decide to add an in-app purchase option to remove advertising as you have had a number of customer requests for this ability through the "email me" feature in your app (you have of those right?).  But you are concerned that if you do a durable in-app purchase to remove advertising you will get some up front revenue but on-going revenue from ads will dry up.  The thing is, it won't.  If you have 10,000 (and growing) users of your app, the majority don't really care about advertising or don’t want to spend their own money.  If you managed to get just 10% to remove the ads you have added an extra $1000 to your revenue but you still have 90% of your advertising coming in with more being added all the time. This give you the option to continue a revenue stream from those that don't want to pay or can't afford to pay while offering a premium option for those that wish.  Everybody ends up loving you.  That's living the dream baby!  Remember, you could even charge $0.99 to remove the advertising for just 1 year, then they have to renew each year or the ads come back.  I haven’t seen this done much yet, but the year is still young.

The Results

Because of Microsoft’s constant growth of the Windows Phone OS, the options for making money from your app development continue to grow and the outlook for making that money continues to get brighter.  Combine that with the growth in Market share we are seeing in Windows Phone add in some great ideas, some great marketing and a little bit of creativity and you might have to put on a fancy pair of sunglasses.  It's never going to be easy and you will have some wins and losses.  Learn from what people like.  Listen to what they want.  And then charge them for it what they want using in-app purchases.

App Certification (and Failure) is a Very Good Thing!

Windows Phone App - Fails Certification

One of the really good things for Windows Phone Users is that Apps fail certification for the Windows Phone Store.  It's actually a good thing for developers too but it's a bit hard to swallow at the time it happens to you.  It happened to me. :-(

Good for the Windows Phone Owner

Why is it good for the phone owner?  Well, as a Windows Phone user, I can safely have a certain amount of trust in apps I put on my phone.  I know that most apps I install are not going to harm me.  I know they are not likely going to do something other than what they say they are going to do.  I know that somebody other than the developer has checked the app for honesty and a certain amount of stability.  There is no guarantee and the certification does not protect users from their own folly (although I suspect they try), but it certainly is considerably more than nothing.  I also know that an app I download is not going to hurt my phone.  I know that it's not going to act as some sort of virus.  I know it's not going to be used to attack other computers.  When I, a developer, submit an app to the Windows Phone Store, it generally takes about 5-7 days to certify or fail because it takes time to check all this stuff.   If a developer submits his app to a store and that store certifies the app in less than one minute, I can't imagine that the app has been vetted in any way as "safe".  I prefer my apps to be checked and failed if they are not good enough so that I better preserve the goodwill of my customers.

Good for the Windows Phone App Developer

It takes time to test and certify an app for the store.  Knowing that a thorough check is going to be done on the app provides strong motivation to "get it right" and build a great app.  The certification process gives lots of guidelines to make a safe app.  A good app means more downloads.  Lots of downloads means more opportunity for monetization.  A good app means that people who download it are likely going to download other apps I have done.  Yeah!

Guidelines for the Windows Phone Store can be found at MSDN. 

Why it Helped Me

Apps submitted to the windows store have to contain certain things.  In my case, I used the location services.  It did not have a clear privacy policy.  I failed certification.  But if it had passed it would have implied that I could do anything I wanted with your phone.  Who would care?  You should!  There would be nobody to check to make sure I was doing what I said I would.  My app now clearly states that the app will NOT transmit any of your location data to me.  I will not share it at all without their permission and will only store data on their phone or their SkyDrive (if they provide permission).  So once stated, Microsoft will check during the certification process that I am doing just that in the app.

Where it Might not Catch a Bad App

In Canada there are a number of major banks.  Once such bank refuses (so far) to create a Windows Phone version of their banking software.  However they do have a web page where you can do banking.  An enterprising developer saw an opportunity for app that he no doubt thought was a great idea.  They created an app that basically wrapped the banks web site.  Gave a nice little logon screen to make it easy.  I saw the app and initially thought it was from the bank.  It wasn't.  There were actually quite a few glowing reviews of the app.  Now take a moment to think about this.  A developer that you do not know, allows you to enter your BANK PASSWORD into his app so you can have a nice interface to your bank web page?  I couldn't believe it.  This app had the potential to be extremely nasty to those that freely gave up their banking information.  This is one of those apps that MIGHT have been malicious (probably wasn't) and it made it through certification.  But somebody at Microsoft was on the ball.  The app disappeared from the store shortly after publishing perhaps because of a customer complaint or somebody just had an "ah ha" moment. 

Knowing What I Know Now

I would never allow my kids to have a phone that does not have a proper App Certification process, too scary.  I honestly prefer Windows Phone as more suited to the way I work and it has the pre-requisite app certification process and I will continue to mutter politically incorrect words each time an App submission fails certification but mutter words of thanks each time I install an app on my phone.

Mark Schramm
@markbschramm

Windows Phone 8 and Beta Tests

The App

You've written the great app.  You are pretty sure it will pass.  You've tested it on your emulator and on your device (the only device you own).  Good enough, ship that baby!

But hold on a moment.  Is it as great as YOU think it is?  I've found over the years that something I think is great isn't nearly as great as I thought once other people start looking at it.  You put buttons in places that make perfect sense to you but a friend, looking over your shoulder points out that you probably don't need buttons at all.  Or you are showing off your fabulous app to your 15 year old son and, after he stops laughing, points out that your app is "quaint" but probably too much work.

Beta Test Mode

So you want to get your friends to try it first right?  But you can't side load onto friends phones (well maybe your 2 best friends, but what of the rest?  Beta testing in the Windows Phone Store works mostly pretty good.  There is one gotcha that I find most annoying but do not know how to fix it.  I'll talk about that later.  Basically Beta test allows people you know to download your app and install it on their device (even devices not developer registered) using the phone store itself.  Beta Test Mode gives you a nice way to test in-app purchases with actual items (listed as free during beta process).  Otherwise you are just simulating the  in-app purchase process.

What happens

You submit the app for certification.  At the bottom of part 1, you click the "more" indicator then check the beta button.  Then, just paste in the email addresses of those that will be able to try out your fabulous work of art.  All you need to do is finish your submission as you normally would.  The certification process usually happens within one to two hours (they don't do a lot of checking) at which point you will receive an email with a link to the app in a non-public part of the store.  Just put together some test notes (if you want) and send the link to your testers.  They can click the link on their phone and the store will load up with your app read to be installed.

Report Back

Hopefully you put some sort of link in your app so they can email you all the glowing wonderful comments they will undoubtedly have for your app.  They can also just do ratings in the store with review comments.  It's generally hard to get comments just like on ratings and reviews in the store, so stay in communication with your testers through email or twitter or something else.

The One Thing

Maybe it's just me but I find with a beta app, the "update" feature doesn't seem to work.  I publish beta version 1.0.1.0 and then publish an update (like you would for in-store apps).  When your tester goes to the private app store location, they see the update but it is the original version.  I could not figure a way to get the update available and on the phones.  So I end up creating a new beta for each version.  A bit annoying but workable.

When You are Done

When you are done with the beta, you can re-submit the app as a new app in the store.  Just fill in all the blanks and submit it like you normally would.  You can then delete the beta app if you wish (recommended).

What I think is the #1 preventable cause of WP App Cert Failure

The Disease - Certification Failure.

I am an experienced developer.  I have been writing code for more than a quarter of a century.  Let me pause for a moment... HOLY CRAP!!!  Now back to our regular programming.  As I said, I've been writing code a long time.  Mostly the final arbiter on whether I wrote good code or bad was if a customer called me up to complain or give me their visa card #.  Things are a bit different now.  Now I write awesome, fabulous code and instead of getting a customer to check it, Microsoft kindly does it for the customer in their store certification process (well, at least as a first pass).  That's really nice of them.  Well, it is until they decide my app is NOT wonderful and awesome.  I have published over 25 apps to the Windows Phone store and I STILL fail certification occasionally and there usually is no excuse except plain and simple laziness.  At least in my case, the certification failure is almost always because I forgot one of the steps in my checklist because I was in a stupid hurry to get the App in the store.  For me, at least, the #1 cause of certification failure is that stupid "light theme" on the Windows Phone.  I don't know anybody who uses the light theme but they can and sometimes I forget to check my App.

The Symptoms

Microsoft's Store certification report is quite useful.  It shows what went wrong and specifically what rule it breaks.  They then give you good steps to reproduce the problem.  If you, as the developer, have set up proper unit and functional testing before submission, you rarely should find surprises.  Out of the 26 apps I have submitted to Windows Phone I have probably had about 5 or 6 failures.  Of those 5 or 6, 90% are light theme.  You'd think I would learn my lesson.  But I don't.  Things that they note are buttons that disappear with a light theme, missing text, and entire chunks of UI that simply become essentially invisible.  Quite honestly it's embarrassing when it happens.  I should know better.  It's really easy to catch these things if you bother to check.  However to assist, I'm going to cover some stuff you can do to reduce the possibilities of it happening to you.  If you don't mind the ten to fourteen day turn around to fix that stuff and resubmit, but by all means use Microsoft as your QA department.  No need to read further.  I prefer to pass the first time in so I can start racking up those downloads.

The Medicine

First, the obvious.  Test your application.  Run through every function in BOTH themes, light and dark.  If you, like I, re-use components, build them to handle the different situations you might run into.  Most controls when dropped into your XAML designer don't need the "Foreground" and "Background" property assigned as they just default to the standard theme.  But what if your app has a background image that is pretty dark?  When a light theme is applied all the standard textblock or button will automatically switch to using "Black" for their colors.  Well, that won't be too visible on your fancy background you, no doubt, spent hours designing and creating.  So you set the foreground and background to White ensure it visible.  This code you wrote is pretty slick so you use it on another app, but that app has no background.  So when the phone user switches to "light" your text disappear.

One way to deal with this is assign "StaticResource" names using standard values.  MSDN provides a menu of theme resources from colors to fonts on this page: http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff769552(v=vs.105).aspx.  You can set resources at the top of your XAML page that you can then use globally throughout your page.  In this example I'm setting the Foreground to the standard PhoneForegroundBrush which will automatically flip between black and white based on the theme.  You could just as easily put in "White" for the value of foreground.

<phone:PhoneApplicationPage.Resources>
   <Style x:Key="LabelStyle" TargetType="TextBlock">
     <Setter Property="HorizontalAlignment" Value="Right"/>
     <Setter Property="Margin" Value="15,5" />
     <Setter Property="FontSize" Value="{StaticResource PhoneFontSizeExtraLarge}" />
     <Setter Property="Foreground" Value="{StaticResource PhoneForegroundBrush}" />
   </Style>
</phone:PhoneApplicationPage.Resources>
<Grid x:Name="LayoutRoot" Background="Transparent">
    <TextBlock Style="{StaticResource LabelStyle}"
       Grid.Row="0"
       VerticalAlignment="Center"
       HorizontalAlignment="Center"
       Text="Hello World"/>
</Grid>
 

 For me, anyway, I like to make sure I have assigned values that I can then fix in just one place.

A fellow by the name of Jeff Wilcox came up with something called the Windows Phone Theme Manager which lets you globally set the theme in your app.  It's available through Nuget and lets you force your app into a particular theme.  This is for you to decide but it can let you control the effects of a user changing the theme.  Much like the Mail App is always "light" them (although this is changing) you can do the same thing to your app for either light or dark.  Read his warnings about battery consumption and overriding a users wishes.  I know that I always select dark on my phone and get annoyed with I get blasted by a bright white interface so change at your own risk.

http://www.jeff.wilcox.name/2012/01/phonethememanager/

It always comes down to testing, testing, testing...  Try all your apps functions in all the themes. If you use the Accent Brush, test against the colors available.  If you use a blue background with the accent brush used for text because you use a red accent color and think it looks cool (hey... it could happen) but somebody else prefers a blue accent color, the text is going to disappear.  But that is for another conversation!