[For full details on working with the Windows Store, see Chapter 20 of my free ebook Programming Windows Store Apps with HTML, CSS, and JavaScript. Note also that CurrentApp refers to Windows.ApplicationModel.Store.CurrentApp for convenience.]
 

Q. Why does CurrentApp.GetProductReceiptAsync return a not implemented exception for a Windows Store app?

A. This API is not implemented for Windows, just for Windows Phone. Windows Store apps should use the CurrentApp.GetAppReceiptAsync API and examine the in-app purchase receipts contained within it. (In short, this is one area of non-convergence with universal Windows apps at present.) 

 

Q. Can an trial version of an app provide in-app purchases?

A. No, by design the CurrentApp.RequestProductPurchaseAsync API does not work when the app is running under a trial license if the app is paid. The API can be invoked, but will fail. However, if the app is free, then in-app purchases will work (see the next question).

This is important to understand when testing an app with the CurrentAppSimulator: by default, the simulator assumes a trial version, so CurrentAppSimulator.LicenseInformation.isTrial will be true and in-app purchases won't work. To fix this, make sure your WindowsStoreProxy.xml file contains the following:

<LicenseInformation>
  <App>
    <IsActive>true</IsActive>
    <IsTrial>false</IsTrial>
  </App>
  …
</LicenseInformation>

Q. I have a free trial app in the Windows Store with features that turn on when the full app is purchased. Can I change this to a free app (no trial) with in-app purchases?

A. Then question here is reall about handling the transition between licensing states, that is the information provided by CurrentApp.LicenseInformation. Prior to the app update, you'll have users with two possible states with the desired transition logic:

  • LicenseInformation.isTrial= true : convert to non-trial (full) version with no-in app purchases
  • LicenseInformation.isTrial = false : turn on licenses for in-app purchases that match the paid version.

When the update happens, it's important to note that the trial state of the all (isTrial) will continue to be true, but because the app is now free, in-app purchases will work properly. In this case, then, the app wouldn't bother to make any differentiations between trial and non-trial; that is, the updated app wouldn't ever check the isTrial flag at all.

The trick is then differentiating new installs of the app, which will have isTrial = false and isActive = true, from those who previously purchased the app and for whom these flags have the same values. You'll need another mechanism, then, other than the LicenseInformation itself, to differentiate the upgrades. 

This is straightforward to do. The best way is to CurrentApp.GetAppReceiptAsync to retrieve the app purchase receipt and check the receipt date against when you made the conversion. Any customers who purchases the app prior to that date were ones who paid for the license and should thus be granted all the rights that you otherwise now only grant through in-app purchases. Thus in your code to enable features, you would check that either (a) the appropriate in-app purchase license is set or (b) a previous purchase was made.

 

Q. I'm having trouble getting my licensing logic to work correctly; what's the best practice for checking license states?

A. The most reliable place to put your licensing logic is inside a handler for CurrentApp.LicenseInformation.LicenseChanged event. If you consolidate everything here, then you naturally handle any change made through purchase APIs, as well as trial expirations and other license-affecting events. You can check specific license flags after one of the async purchasing APIs completes, but as those should invoke LicenseChanged it's much cleaner to keep everything in the event handler.


If you have an app in the Windows Store that you’ve been offering for free, and later convert it to be a paid app, the question is what happens with those customers who acquired it when it was free?

The answer is that app licenses are granted as either full or trial; licenses don’t differentiate paid or free. So once a user has acquired a full license for the app at whatever price, they have that license permanently. Therefore a change in price only affects new customers–existing customers won’t suddenly be asked to pony up some cash for continued use, which is as it should be, and they can continue to reinstall the app freely.

The bottom line is that existing customers keep their existing licenses across app updates. So if a customer has a trial of your v1 app and you make an update to v2 that no longer has a trial, the v1 app will continue to work until the trial expires.

If you have a non-expiring trial or the trial period is not yet expired, a customer can install your v2 under that license. In this case, when you make such a change in your app, be sure that v2 checks for a trial license state and prompts the user for an upgrade and/or disable v2 functionality. You cannot force them to pay, however.

In short, unchecking the trial license in the Store dashboard for your app prevents new trial licenses from being granted, but exiting ones will still work for new app updates.

 


One of my few disappointments with the Surface RT that Microsoft gave me to play with last year is that it refuses to add music located on an SD card to my music library. (I’m sure Microsoft has heard the feedback many times by now, so hopefully it’ll be improved.) I encountered this because with a 32GB Surface model, there just wasn’t space to accomodate 19GB of music files on the built-in SSD, hence the add-on SD card.

Fortunately, I finally found a workaround that I’ll get to in a minute. What primarily prompted this post is more of my experience looking through the Windows Store for a media player that could play music directly from the SD card and not depend on it being in the music library.

In the Store, I searched for “Music Player” and got back over 1700 hits, but the top ones shown by relevance were appropriately relevant. Most of the top 10-15 apps have a price tag, so I started clicking through. This gave me a chance to make some observations about writing apps for the Windows Store.

The first thing I noticed almost counts as a cardinal sin: most of the paid apps did not offer at trial! Egads…very unlikely that I’m going to pay for an app just to see if it does what I’m trying to do (get music from an SD card)? Most apps clearly said, as expected, that they access the music library, but not (as yet) having a solution for the SD card problem, I wasn’t about to pay for any app that didn’t explicitly say that it would load music from an arbitrary location.

I did, some months ago, install an app called Metro Media Player (http://apps.microsoft.com/webpdp/app/8ea516f1-eada-4d0e-931c-557878093350) that does allow you to open and play arbitrary media files, but the downside it that it doesn’t (at least in the version I tried) give you an album view of a folder or let you play the folder contents as an album.

So the first lesson here is clearly: remember to offer a trial for a paid app, even if it’s just for a short period of time. And when the trial is installed, remember to appropriately nag the consumer to upgrade to the paid version. I say “appropriately” because you want the consumer to have a good experience of the app, but not ever forget that they’re freeloading. It’s a fine line to walk, but one that will help conversions.

The second observation is that a number of apps didn’t really fill out all the screen shots that you’re allowed to submit. Remember that your app’s page in the Store is the one and only place a consumer can learn about and get a clear sense of what the app does before deciding to purchase/install a trial. Truly, if you’ve spent many days or weeks writing an app, spend a few hours getting good screenshots and writing compelling copy.

With your app description, an important thing to know about the Windows 8.1 Store is that the first sentence or two of your description will surface in the search results. This means that any words in your copy that don’t immediately make a compelling case for your app are wasted words. For example, one app starts its description–which is what shows up on the search results page–with “This is my very first Metro app”. Um, that’s not very compelling to me :). A number of others start with a phrase like “This app” or “This application” which is inherent in browsing the Store.

So even just a simple change from “This app allows you to play music from your music library and sort by artist or title” to “Play music from your music library and sort by artist or title” says the same thing and gives you more words to show. Even so, you can make it more compelling with a little editing: “Enjoy browsing and listening to your music library and pin albums to your start screen” (the latter idea is in the second sentence, but doesn’t show on the 8.1 Store search results). Every word counts!

I highly recommend finding a friend or associate to help write and edit your copy–anyone who is not yourself can more readily take the viewpoint of a potential customer rather than a developer.

I did eventually install one app that looked promising, and was free, but limited itself to the Music Library. So no progress in solving my problem.

Then I came across Groove: Smart Music Player (http://apps.microsoft.com/webpdp/app/949988e3-de86-4e4e-9039-b261fdc56fd9). It didn’t have the open-a-folder capability I was looking for, but it did contain a note with a link to a blog post about how to get your SD card in your music library (and photos and videos). And with that solution I could get this app–and even the built-in Music app–to work with my SD card.

What I appreciated most is that Groove clearly understood and recognized an issue that many people have, it seems, and offered a solution right there on the Store page. Nice job of customer awareness and empathy!

To the solution now–see http://bit.ly/UrF44P for a process to mount an SD card to empty folder on the Surface’s primary drive through Disk Management, which can then be added to the libraries. To summarize:

  1. From the desktop (Windows Explorer), create a folder somewhere on the primary drive, e.g. c:sd or c:users<your name>sd. Doesn’t matter where.
  2. Hit Win+X and select Disk Management.
  3. Right click (or tap-hold) the SD card and select “Change Drive Letters and Paths” from the menu.
  4. In that dialog, tap “Add…”, select “Mount in the following empty NTFS folder”, and enter the path to the empty folder you created. Then OK out of the dialogs.
  5. Make sure that the folder names on the SD card match the library names under c:users<your name>. If your library is “My Music” make sure that your music on the SD card is in a “My Music” folder. Don’t know why this is needed, but it was essential for me.
  6. Back in Windows Explorer, select the Music Library, on the Library Tools/Manage ribbon tap the Manage Library button, then tap Add… and navigate to the mounted folder on c: with the appropriate media, e.g. c:users<your name>SDMy Music.
  7. Give Windows a little time to index the thing, and voila! Problem solved.

 


I found I had a collection of various questions and answers about the Windows Store, so I thought today to bring them all into one post.

 

Question: How do you detect that the user cancels an in-app purchase within requestProductPurchaseAsync? It doesn’t return an error in this case.

Answer: If the user cancels the purchase, the requestProductPurchaseAsync method will still invoke your completed handler, as the dialog was successfully displayed. It only produces an error if the dialog couldn’t be shown. What then determines whether the purchase was successful is whether or not there’s a change in the CurrentApp.licenseInformation object once the dialog is finished. An easy way to do this is to consolidate license handling within the CurrentApp.licenseInformation.licensechanged event. If the in-app purchase goes through, this event will be fired; if the user cancels, there won’t be any event and the app can just continue as usual. It all depends on whether you want to take additional action in response to the cancellation rather than purchase success.

Alternately, within the completed handler for requestProductPurchaseAsync you can get CurrentApp.licenseInformation, then call its lookup(productId) method and check the isActive flag for that in-app purchase.

 

Question: Is there a cached copy of the app’s licenseInformation object for offline scenarios?

Answer: Yes, license information is always kept up to date for apps, including in-app purchases. Apps do not need to cache license information separately for offline situations.

 

Question: Are receipts available offline?

Answer: No, you need to be online to access receipts.

 

Question: Is there a way to get the most recent version of my app in the Store so I can compare the current version that’s running?

Answer: At present the Windows Store and the WinRT APIs don’t support this. That is, you can get the running app’s version from Windows.ApplicationModel.Package.current.id.version, but there isn’t an API to get the version in the Store. Developers who require this for whatever reason typically create a web service endpoint that can respond with that information (clearly you’d update that service’s response when you update the app in the Store). Do be mindful to not pester the user about updates, because the Store already provides a means for that; use it sparingly.

 

Question: If I have an update command in my app, how do I send the user to the Store to install the update?

Answer: You can do this through Windows.System.Launcher.launchUriAsync with an ms-windows-store: URI (in an instance of Windows.Foundation.Uri). Use of this URI scheme is documented on Linking to your app. To link to your app’s page in the store, use a string created with “ms-windows-store:PDP?PFN=” + Windows.ApplicationModel.Package.current.id.familyName. To go to the overall updates page, use ms-windows-store:Updates.

 

Question: Can an app hide select in-app purchases? Say that I want to show a certain purchase only a particular date, perhaps to offer a special combination of features A and B together instead of separately. Can I do this, and will it affect certification?

Answer: The Store itself doesn’t show in-app purchases to the user: this is completely under the app’s control. That is, you simply filter the product listings you get from ListingInformation.productListings and show only those you want. In this case your combined A+B product would be a separate product listing that you create through the Store dashboard, but at runtime you’d determine when to display it. It just shows up as another in-app purchase so won’t be an issue with certification.

 

Question: Along these same lines, if in an update to my app I no longer want to offer A and B separately, just the A+B combination, how do I approach that?

Answer: Because you cannot remove A from the Store (you have no guarantee that all users will update the app), the app update will need to filter out those in-app purchases that it longer wants to appear. Simply said, because each product has its own Id, the updated app can basically have a built-in list of productIds that it just won’t show in its UI.

 

Question: My app failed certification because of a crash. How do I know what happened?

Answer: In late January 2013, the Store began to include crash reports from the certification process. For details, see Crash reports help you certify your Windows Store app on the Windows Developer Blog.

 


In Windows 8, the in-app purchases supported by any given version of an app must be defined with a product ID when the app is uploaded to the Windows Store. This means that you have to update the app in the Store to add additional product IDs. This can pose a challenge to apps that want to offer more dynamic content through in-app purchases, especially media content like books, recipe collections, and so on, where those content collections aren’t necessarily known ahead of time.

In these cases, and app can still download content once a license for the product ID is purchases; the Windows Store doesn’t produce a mechanism for download-on-purchase, but an app can certainly do that itself.

To work with dynamic purchases, the trick is to define a number of placeholder IDs for future in-app purchases when uploading the app. At runtime, when creating your in-app purchase UI, you’ll retrieve the list of product ID from the WinRT API, then have your service (likely the one from which you’d download the content), check those IDs and tell you which ones are presently valid, that is, which ones have real content assigned to them. The app then only displays those products are valid and ignores the rest.

Later on, if the user returns to the in-app purchase UI, additional content might be available and would thus appear. Of course, such an app would likely check with the service periodically to know when new content has been added so it can alert the user and encourage a new purchase!


Last week I shared a series of thoughts about monetization of Windows Store apps, and today I have one more–not about monetization, per se, but about this idea of an app store in general.

I get the impression that many developers have looked upon app stores as a way to easily make money with whatever apps they care to submit. That is, there’s an idea that app stores, like the Windows Store but also those on other platforms, will somehow bring customers to one’s app with less effort than it has in the past.

In my opinion, the real truth is that app stores are simply a different kind of distribution mechanism that just so happens to also handle transactions. On the web, which was the primary distribution mechanism before app stores (and still remains one), you typically had to incorporate some commerce engine into your own web site to conduct sales. But this is now built in.

That said, most apps have the same challenge as before: customers still have to find your app in the Store, just like they had to find your site on the web. With tens of thousands or hundreds of thousands of apps in a store, and search results showing maybe 30-50 at a time, I don’t really think this part of the picture has really changed that much.

Furthermore, the mistaken idea that its easier to make money with an app in an app store has led many a developer, I’m sure, to imagine that they can cobble together something that will pass Store certification thinking that it will suddenly earn them a comfortable living. It reminds me of a friend who thought that all she had to do with her home business was put up a web site and people would find her. I’m sure you laugh at that thought as absurd–and so too should you laugh at the thought that simply being in the Store is going to produce business. Maybe you’ll get some, but as the app count increases, discoverability in any given store becomes harder and harder.

This really means two things. First, you have to write good software to be successful, plain and simple. It’s really amazing to compare the experience offered by top-line apps and those that are produced by a hobbyist. It’s essentially like the difference between a professionally-crafted movie and something you’ve shot in your backyard with a $99 camera: there’s simply no contest. In other words, if you expect to make good money with an app, you should expect to really invest in it. And this has always been true in the software industry.

Second, you can have the best software in the world but it won’t matter if people dont’ know about it. This means making another investment in marketing, plain and simple. This too has not changed in all the years–promotion matters! Think about it: if you were to set up a small brick-and-mortar shop in your home town, you’d immediately engage in promotional activities of some kind, because the business will quickly go under otherwise. And you’d never question that need especially because you’ve invested so much in getting the business started, and the cost of failure is losing that investment. With apps, you can get something in the Store with a much smaller up-front investment, and so there’s less of a perception of risk of failure. As a result, developers aren’t as invested in the success of that app as they might be with a real business. But if you want that app to suceed and not just exist, then you really do have to treat it the same way.

What’s also true in business is that when you start to generate revenue from your initial promotions, you need to dedicate part of that revenue to continued marketing as well as expansion of the business. In other words, some portion of every dollar you earn with an app should be earmarked for marketing activities, because that’s how you’ll begin to build a sustainable flow. By also earmarking another portion for further development, you’re investing in the sustainability of the business when revenue from the first product begins to wane.

The bottom line, then, is that although apps stores have brought a new distribution method with built-in commerce, running a successful software business requires the same dedication and investment as always. Have a great product, and invest in the effort to let people know about it.


To complete this series from part 1, part 2, part 3, and part 4, the last topic is thinking about multiple apps together. In the Windows Store, apps must stand on their own (suites are not supported), and yet if you are selling more than one app it certainly helps create marketing relationships between them. In other words, you can build upon the idea of lite and full apps, and think about how a diversity of apps and monetization models can help you build your overall business.

For example, having some great free apps can help build a solid reputation for your business, thereby encouraging users to check out your other paid offerings. Because each app in the Store can include links to your website, each app is a doorway to the rest of your business as presented on the web. In this way, free apps can serve as giveaways (also known as loss leaders) that many businesses use to get customers in the door where they can then experience additional products.

Although the Windows Store certification policy does not allow apps to be interdependent (that is, you cannot require the installation of a second app to install the first), you can make them interoperate such that having those apps installed together makes additional scenarios possible. One of the most effective ways of doing this is through the Share contract, where you can use custom formats to exchange richer information than the standard formats allow. Another powerful means is protocol activation, wherein you use a specific URI scheme like bingmaps:// to allow one app to delegate specific tasks to another. This is limited to one-way communication, mind you, but can still be a powerful way to have those apps work together and light up more features.

And you can certainly advertise these interop features on each app’s description page in the Store. That is, while you can’t require one app to be installed to use another, Store policy does not prohibit making mention of what’s possible when you do. You can say, “By also installing the companion SuperApp, these additional features become available:….”

As a final note, I want to mention a growing opportunity that’s really just in its early stages. Many apps have a backend service that provide much of their runtime data. If that data might be useful to other apps, consider making your web API available and monetizing access to it. This way you have another facet of your business to develop that is focused on developers as customers, rather than just end-users. And you can also use services like Mashape and Mashery to help you in the process.

And with that, we conclude this series. I hope it’s been helpful and inspiring, and I look forward to any comments you have on monetization strategies.


Continuing from part 1, part 2, and part 3, let's now talk about using in-app purchases. The technical details and some useful design thoughts can be found on How to support in-app purchases on the Windows developer center. What I want to add to that discussion are some observations from a few other apps.

First, with the obvious case, you can use in-app purchases to turn certain features on. This includes turning off ads, meaning that you use an in-app purchase for this purpose rather than converting a trial to a paid app as in part 3. Here, you're thinking about how a user can convert money (their money) into added capabilities.

Second is thinking about how to introduce another level between the purchases and capabilities. This is a strategy used in a number of games that have their own in-app "currency" (coins, points, etc.), with which you can buy extra capabilities. Often you can earn by playing the game for a long time, but if you're impatient you can convert real money into in-app currency and thus shortcut the process. In other words, you're letting the user choose between patience/perseverance and a little bit of their money.

Two of the most popular games, both by HalfBrick Studios, are great examples in this regard: Fruit Ninja and Jetpack Joyride. Fruit Ninja offers the Dojo within the app where you can acquire different blades, backgrounds, and special (and temporary!) powers (like a bomb deflector). Some of these you can acquire by performing special feats within the game, like finishing with a specific number of points, slicing specific fruits in a certain sequence, and so forth. You can also acquire them buy exchaning "starfruit points" that are gradually earned by playing the game. But then you can also make an in-app purchase of extra starfruit points, allowing you to then purchase the add-ons with those points.

So if you're not as patient as my six-year-old son has been to save up 9000 points for the King Dragon Blade, you can just spend a couple of dollars and get it right away. Jetpack Joyride does something similar. By playing the game and completing missions you earn coins with which you can buy all kinds of extra gadgets, powers, fun clothing, and so forth. Again, you can earn all the points you'll ever need just by playing the game. But you can also just flat-out purchase coins with real money.

Because the Windows Store does not yet provide for in-app consumables (an in-app purchase you can buy multiple times [update: this is available in Windows 8.1]), Jetpack Joyride offers a number of one-time purchase options: 20,000 coins for $1.49, 50,000 coins for $2.49, 100,000 coins for $3.49, 250,000 coins for $5.99, and 1,000,000 coins for $13.99 (which would allow you to buy everything). So again, if you're willing to spend, you don't have to be patient. Jetpack Joyride also offers a brilliant in-app purchase that I thought was well worth $1.49: the "counterfeit machine" which automatically doubles all the coins you earn when playing the game. This is totally worth it!

So for in-app purchases, I strongly encourage you to look at what other apps are doing, especially the most popular ones, as they offer good insights into designing around this monetization approach.


Continuing from part 2 of this series, the next topic is about using ads for monetization. This is one of the most popular methods, especially with free apps, but you should also consider using them in trial versions of paid apps. As described in part 1, trials should frequently (but appropriately and respectfully) remind the user of the app’s trials status and invite an upgrade. Ads really serve the same purpose when you have a paid app as well: just as you might feature-limit a trails, having ads in a trial is a feature that many users would like to remove! In other words, running the app ad-free is a “feature” that’s enabled with purchase of the full app.

But let’s talk more of designing around ads. This is one place where I see many apps being somewhat lackadaisical.

First, if your app is always going to be free, then the whole purpose of using ads is to not just display them, but to get uses to click on them which should increase your revenue. In this way they should be placed invitingly, but not obnoxiously. For this I think you can find quite a bit of guidance in researching best practices for ad placement on web sites, as those are essentially free apps themselves.

Personally, I think the use of ads is most effective when you also have a path to a paid app, even if the paid app’s only added feature is removal of the ads. This way you give the users a choice of dealing with the ads, or ponying up a little cash for the privilege of removing them.

Here, then, is where you have many design approaches that could help increase your revenue (again, these are ideas and observations, not necessarily ones I’ve personally tested):

  • With static placement (within the app’s layout), ads needs to be visible, of course, and if you offer a means to get rid of them, you want to think about making the ads a distraction from the real content of the app. This encourages conversion.
  • As I suggested for trial reminders in part 1, use dynamic placement of ads to break up the flow of the app–to again be just annoying enough but not obnoxiously so, as an encouragement to get rid of those ads. This is what TV shows excel at doing: build up to a near-climax, but then break away so that your attention is transferred from the program to the ad. I’ve seen this strategy often with web games where you’re playing along and finish one level. You’re looking forward to the next but then app tosses in an “interstitial” ad that makes you wait for 15-30 seconds for your next dose of the game. You can’t make the user wait too long, of course, but a little wait makes them hungry and again more likely to upgrade.
  • An app can build some more intelligence around frequency of ad insertion within the flow too: an app can keep track of total elapsed usage time, such that at first the ads don’t appear as often, but as the user gets more and more involved with the app, you can increase the frequency of disruption. A friend of mine wrote a game that just displayed ads statically, and I suggested that he insert an interstitial between every 4 -5games, which meant about every 5 minutes of play time. It would not be difficult to say that after 30-60 minutes of total usage time, the ads showed up once every three games. After another 30-60 minutes, every 2 games, and then after another 30 minute have an ad show up after every game.
  • And don’t forget, when you show an ad, provide a link to your app’s page in the Store with a reminder that you can get rid of ads with an upgrade!

More thoughts? I’d love to hear your comments!

 


Continuing from part 1 of this series, the next topic is using trials of a paid app vs. free demos of those apps. There are distinct differences between the two.

A trial version of a paid app is either feature-limited or time-limited as noted in the previous post. What’s distinctive here is that the trial gives the user the same experience as the full app, such that if they upgrade they can then continue on and deepen that experience.

A free demo, on the other hand, is a standalone app, which would, of course, invite the user to visit the full app’s page in the Store. It must be noted that such a free demo app must deliver good value to the user in and of itself–it can’t just be an advertisement. This is why you see “lite” versions of apps, because “lite” makes it clear that you can do plenty with the app, just not everything.

Lite/demo apps can typically be used for any length of time, but while being useful, think of them as a way to showcase features of the full app–like a teaser trailer–rather than providing a complete experience.

Here’s an example I gave in Chapter 17 of my book: Let’s say you have a game with five distinct “worlds” through which a player would normally progress in the app’s full version [if you know the game Switchball, I wrote this example based on it]. A trial version would allow a player to start working through those worlds but would cease to operate completely after some short period of time, say 30 or 60 minutes. In that time, a player might not progress past the first few levels in the first world, so the experience of the overall game is incomplete. A free demo/lite version, on the other hand, could be played as much as one wished but would contain only one level from, say, three of the five worlds. This gives the user a broader taste of the app and, because it can be played many times, serves as a continual advertisement for the full experience without giving anything more away.

When offering a lite/demo app, you can forego offering a trial of the paid version, or make the trial relatively short. In the end, you’re always trying to use trials and demos to lead to purchase of the full app, so design a demo app with that in mind.

Other ideas? Please add comments!