Windows Store apps are currently a great opportunity for the business. The Windows Store, like other brand's stores, gives a number of tools that simplifies the deployment and sell of applications to Windows Phone and Windows 8, removing the need of having your own sell interfaces, together with the availability of an effective visibility that would be very difficult to achieve with a custom solution.
From the developer point of view, there are a number of tools, that enable to add the capability of support selling, using directly the Windows Store or from inside your own application. This enables a number of scenario. Not only you can sell the entire application, but also you are allowed to sell parts that can be enabled, one-by-one, after the user pay the required price.
Currently there are alot of apps in the store that support this latest scenario. The application is freely downloadable and offers basic functionality, allowing the user to try the app and become loyal. Then the application proposes the buy of additional features, from inside the app. If the application is well designed and effective, the user can easily upgrade to a fully functional version, buying the modules that he needs.
The first step: supports trial mode
Usually, the very first try to become a seller in the store is made selling the entire application. From the Windows Store dashboard, you can set a price for the application and then the user is required to pay your fee before he can download the application. Enabling a price is not so effective as someone can think. It is widely known that few people buy an app without having a try with it, and if you just stop for a while thinking, it is perfectly understandable.
This means you have to deal with trial mode. To enable trials you have to set the price for the app and then the "Free trial period" as you can see in the following figure:
As the figure show, when you set a price in the left combo, you can also specify the trial period. The values in the field allow you to decide for the following choices:
1) No trial: you app will ask the user to always pay the price before to download the app. In this scenario the trial is not enabled.
2) Trial never expires: The user is able to download the application and it will work indefinitely. In this scenario usualy a number of features are hidden and they only appear when the user buy the app. During the trial the user can use a minimal set of features and it is solicited to buy the app to unlock the others.
3) Time trial: The user can download a fully functional app that will expires after the given time.
Every trial mode has its own advantages. You are in charge of deciding the way you want to provide the trial, on the base of your business model, and then to add the needed code to the application to enforce the rules. You can achieve this result using a class that exposes the current license: this class is named CurrentApp.
From the CurrentApp class you can get two services. The first is to retrieve the current status of the license. It is provided by the LicenseInformation property that is able to return an object that contains the information about the license acquired by the user. For the trial mode purposes there are two properties that let you enforce the rules:
IsTrial is a boolean value that inform about the app is in trial period. It is a good way to easily check the trial and switch off the parts you do not allow for unlicensed apps. ExpireDate is a value that contains the date of expiration calculated on the base of the period you set for your app. In the case you have set the trial period to expire after some days, it contains the exact date when the app can not be used anymore. If you set the trial period as "never expires" it always contains DateTime.MaxDate. After the trial period has expired, or if you do not allow a trial this property always contains DateTime.MinDate. This way you can always be sure you can have a valid value, no matter how you setted up the trial mode.
Using the IsTrial property you can also work at the opposite, enabling parts that a licensed user will not see. It is the case of in-app advertising, where unlicensed user use the fully functional app but also show ads inside of them pages. This code disables ads when the user has purchased the app:
1: LicenseInformation license = CurrentApp.LicenseInformation;
2: this.advertising.Visibility = license.IsTrial ? Visibility.Visible : Visibility.Collapsed;
License application modules separately
Since trial mode is something of useful but not always it suffice to persuade the user to buy your app, another way is to split the application in modules that can be bought separately, enabling the user to customize the application to his needs. In this scenario you have to provide a minimal viable product, that encourages the user to buy additional features. In this way your product become the seller of itself, and if you provide a good startup, with well designed, easy and useful features, the user should buy again and again other features, becoming loyal to your product.
There are a number of products that uses this strategy. The best example are multi level games that provide a basic set of game levels, asking the user to buy additional levels when he get to the end of the free package. For games this is probably the best way to make easy money, but also there are utility products that split in different ways the features, for scope, for consumption limits, etc...
The first step is to instruct the Windows Store about your features. For this purpose you can access the "Advanced Features" option, in the app configuration, using the button in the figure. This panel offers a simple interface that enables you to add simple "strings" that identify parts of your product. For each part you are asked to provide a price level and a lifetime. The lifetime is the limit of validity of the feature letting you to ask for periodic fees. In the figure below I show an example configuration.
In the figure I've configured the "Basic" Product ID for free features and an "Advanced" identifier for additional features. These have an endless lifetime so once the user bought them they does not expire anymore. In the third field I've specified a Product ID for features that expires once a year. It is like asking a fee of 1.99€ for each year. At the end of the year, if the user does not renew, the feature is not available anymore.
In the code you have to use the ProductLicenses property in the LicenseInformation class. This is a dictionary that exposes the licenses granted to the user, on the base of the Ids you entered in the store. So, if you want to check if the used has bought the "Advanced" features you can use something like this:
1: LicenseInformation info = CurrentApp.LicenseInformation;
2:
3: if (!info.ProductLicenses.ContainsKey("Advanced") ||
4: info.ProductLicenses["Advanced"].ExpirationDate < DateTime.Now)
5: {
6: throw new Exception("The feature is not licensed or has expired");
7: }
In my example I throw an exception but, of course, you can do whatever you need to notify the missing feature to the user. Also you can hide parts of the user interface on the base of this check.
Move to the next: enable in-app purchase
Specify a license in the ways I've explained in the previous paragraphs is for sure a great opportunity to ask the user to pay for some features but they need to redirect the user to the product page in the Windows Store to accomplish the trade. The CurrentApp class provides a LinkUri property to easily redirect the user to the web page of your app. It may seem a strangeness, but this transition may be an additional friction that prevents the user to accomplish the bought. The better instead is to stay in the app and provide an interface to complete the payment and enable the requested features. This is what someone means talking about "in-app purchases".
This is the second service provided by the CurrentApp class. Using the class you can start the purchase interfaces that are displayed inside your app using a popup dialog. You can use one of the following two methods:
RequestAppPurchaseAsync: this method starts the interface to allow the purchase of the the whole application.
RequestProductPurchaseAsync: this other method allow to request the purchase of a specific "Product ID" you specified for the application in the Windows Store. As expected it asks for a string representing the "Product ID".
The CurrentApp class also provide othe methods that are useful to inspect the license of the user to give detailed infomation about the payment of applications or products.
What about test?
Just after you added purchase options to the application, using one of the ways illustrated above, you may want to give it a try to ensure that the application correctly enforces the purchases without hiding payed features, or opening features not payed. Unfortunately the test of these features is not so easy using the CurrentApp class. This class acts as if your application has been downloaded by the store, and a test will complete a real payment on the store. Obviously this is not really a good choice: also if you can accept to pay once yourself for the test it will be a single-shot test because after the payment you cannot repeat the purchase again.
Luckily the framework provides an easy way of accomplish this test using a stub class called CurrentAppSimulator. This class exposes the same interface of the CurrentApp but has interfaces to return different results. So you can easily perform the test in various scenario. This is true only by words because these classes are static and they does not really implement a common interface as you expect, so switching between the simulator and the real implementation is not easy like a breeze. My suggestion is to use preprocessr directives to automatically switch the CurrentAppSimulator to the CurrentApp when you change the configuration fron "Debug" to "Release". Here is an example:
1: #if DEBUG
2:
3: LicenseInformation license = CurrentAppSimulator.LicenseInformation;
4:
5: #else
6:
7: LicenseInformation license = CurrentApp.LicenseInformation;
8:
9: #endif
10:
11: this.advertising.Visibility = license.IsTrial ? Visibility.Visible : Visibility.Collapsed;
After you implemented and tested your limits using the CurrentAppSimulator (in the figure a screenshot of the purchase interface that enables to return different error codes to the application), you switch the simulator to the real CurrentApp class and it is ready to be published. Please note that, there is not any risk that you publish the application with the CurrentAppSimulator enabled by error, just because the certification process checks automatically for the usage of this class and, in the case, the certification process fails.
Enjoy your earnings.
As I've said in the incipit of the article, the Windows Store is a good opportunity for making money with your works, taking advantage of a showcase that puts your app on the shelf where it is easily reachable by your potential customers. Given the completeness of the tools I've talked about in this article, it is now up to you to have the right idea to create a successfull application and there are not other obstacles in front of you. Enjoy your earnings.