I’ve written a lot of apps (and have used a lot of apps) so one thing I’m always on the lookout for is what is working when it comes to top apps – getting users, feedback, and ultimately monetizing your apps. The market is always changing and the trends are different in different app categories, and the key seems to be able to adapt quickly.
Pricing and Making Money
Games are completely different than productivity apps, which are entirely different than entertainment apps, just to name a few broad categories. In gaming, an upfront purchase is certainly the tried and true method, but as the market has saturated with $0.99 games, the most successful models have shifted to in-app purchases (IAPs) that extend the value of a free game. These IAPs can be either for additional game content or levels, or for in-game items that enhance the value of playing the game.
There are exceptions. Dan Russell-Pinson, the developer of the hugely popular Stack the States game available on iOS (often in the top 100 of top grossing apps) and Windows Phone, has discussed the monetization of kids games extensively in the Charlotte Game Meetup group. (If you’re reasonably to the Charlotte, NC area, you really should make it out to this meetup! Some app devs are amateurs, some are seasoned professionals!) The challenge with educational and children’s games, according to Dan, is that most institutions (and, in many cases, parental controls) prevent in-app purchases, so to be successful, the purchasing has to be simple/upfront.
Other games have more freedom. John O’Neill, founder and chief wizard at Sparkplug Games, has discussed this at length at a number of the Raleigh-area meetups. Effectively testing your app and gathering initial feedback by micro-launching an app can be a useful way to test a small market segment before going worldwide.
When it comes to pricing, however, starting at a high price point (within reason, of course, which is dictated by the current market) is usually the best approach. Many apps are put on sale at regular intervals, and if you stick with the lowest possible price point you lock yourself out of promotion opportunities. Besides, you can always lower the price of an app. Raising it – while technically possible – is seldom helpful.
Advertising
Placing ads in apps is a great way to bring in revenue, as Kevin Ashley discusses in this post. The key to make advertising successful, though, is that you need lots of users using your app for long periods of time. If users are in and out of your app, the amount of revenue your app will bring in will be disappointing.
For Windows apps, check out the Microsoft pubCenter. An SDK is available that makes it easy to plug into Windows 8 and Phone applications.
Publishing
While it’s a good idea to consider how you can make money with your apps, it shouldn’t be the main focus. The primary focus should be on creating a compelling application – and if that’s successful, the money will follow.
At our events we often rush the publishing process -- but in reality, this is something we should spend some time focusing on. When publishing an app, you’re presented with the following portal:
By the time you get all the way down to description, all you want to do is hit publish and be done with it. To further complicate the scenario, the Description section isn’t enabled until packages are uploaded (and, that’s not enabled until the previous steps are complete). First suggestion: upload a package file that you are using for testing in order to enable the description section. You won’t submit this for certification as you can simply upload the finished package when ready, but you want to start filling out the description section early:
Now that you’ve got the description field enabled, start filling it out. Revise it. Think about it. Create compelling screenshots. Create the promotional images. Think about the keywords. Have this section done ahead of time so when you are ready to submit your app for certification, this isn’t an afterthought. The reason why this is critical is because this is the first interaction – the curb appeal – of your app. This is your one chance to convince them to install your app.
Get the Word Out
You got the email:
Now it’s time to get the word out. Include a link to the app in your email signature. Include it in your blog. Send an email to your developer friends, local user group, or app dev club and ask, politely, for some peer reviews. Post in the developer forums that you just completed the app. Be proud of your work.
Why is this important? You want to hit the ground running. A few days after launching Brew Finder, I was seeing pretty good traction:
Looking at the downloads, I noticed a spike shortly after launch:
When I opened the Food & Dining category on the store, I saw the reason for the nice uptick:
This was great to see! The app is on its way – but a big part in making this happen is to get the word out early. Drive as much usage to your app in as short a period of time as you can. The other thing we want to do is encourage ratings. One way to do this is to add a ‘nag’ screen in the app. For example:
The above box shows up once every few launches and allows the user to permanently dismiss the box. When I look at the number of ratings I’ve received (15 ratings, as you can see in the screenshot higher on the page), I’m getting a 1:30 rating to download ratio. If I look at the apps where I did not ask for ratings:
That’s 1:192, 1:131, and 1:180 ratings to downloads. There is no question that asking users – politely – to rate your app will drive your ratings to download ratio. You can also add whatever logic you’d like into your rating reminder dialog. For example, only ask after so many minutes of usage or after a certain number of app launches.
So what about making money on the app? I ruled out charging for the app, While visiting my dad and describing the app, he looked up a similar app on his phone that charged a measly $0.99, and he didn’t buy it. I realized that this is a typical reaction – an up front purchase will turn away many users. In-app advertising is also a possibility, but, because of the specific nature of the app (breweries, beer, etc.), using an ad platform is likely to be detrimental to the app – it will bring in a little revenue, but potentially discourage use. The ultimately goal is to create a great app, encourage use, and find a way (perhaps through a partnership with breweries) to drive value and revenue.
Is this information useful? If so, let us know (comments, contact me, etc.). We’re getting a lot of feedback lately that marketing, monetization, and similar topics are really helpful. Good luck on your app, and if you publish an app, post a link in the comments and I’ll check it out!

A bit overdue, but I just realized I never really announced the APIMASH project we’ve been working on. It’s up on github. The purpose of the project is to illustrate how to go about constructing a mashup application from a variety of data sources. We’re adding to the project all the time, and have both Windows 8 and Windows Phone app starter kits to get you going. What makes the APIMASH concept so fun, to me, is that we’re consuming real-world data. Whether you use one of our APIs we consume in the kits, or find one through a site like Mashery, Programmable Web, the Azure Datamarket, or others, mashup applications are a LOT of fun to create. Because many mashup applications use similar patterns, consume similar JSON data, etc., you’ll see it’s easy to adapt the code to just about any scenario. I’ve got a couple of examples in the APIMASH project, and more to come soon. The first one is an earthquake sample that illustrates how to consume a data feed from the USGS that contains earthquake information for a given time frame. That data is then plotted on a Bing map. This starter kit is available as both a Windows 8 app and Windows Phone app. The starter kits are very bare-bones (intentionally) – a more complete version based off these templates is available in the Windows Store as an app called Earthquake Explorer. Conceptually, the apps are the same, but the finished app in the store illustrates what you can do by adding a bit of polish to the app. You can read more about creating a great mashup using this app as an example here in these blog posts. Starter Kit: Completed app: The other project I created in the APIMASH project is called Messier Sky Objects, which is available in the Windows Store as Messier Object Explorer. This is a mashup (of sorts) that combines Worldwide Telescope with the data of all Messier objects, a collection of objects like nebulae, galaxies, clusters, et. al. By using the Worldwide Telescope JavaScript API, it’s simple to create great-looking astronomy apps (in fact, many of my apps, listed in my side-bar on my home page, use this as a template). So what’s next? I just released Brew Finder for Windows 8. This app uses the brewerydb.com API to show local breweries and is available in the Windows Store here. I hope to have a nice sample in the APIMASH project soon based on this project. Have another sample you’d like to see? Leave a comment and we’ll review it on the next team meeting!

One of the most frequent questions/concerns I’m seeing in community is: what application changes do I need to consider for Windows 8.1 development? Is there anything I should be doing today in my Win8 apps to make it easy to move to 8.1 in the future? There’s a ton of great info that came out of the recent //build conference. In my opinion, the main design consideration to take into account with applications in Win8.1 is to handle multiple screen sizes and states effectively. Conceptually, this is nothing new: when developing web applications or desktop apps, you have to assume the application will be viewed on a variety of form factors and handle the layout effectively. When Windows 8 first shipped, apps would run either full screen or in snapped view. Further, the minimum resolution requirement were 1366x768, and snapped applications have a width of 320px and full height. This simplified the design slightly, and as a result, many samples had code like the following (C#): private void Current_SizeChanged(object sender,
Windows.UI.Core.WindowSizeChangedEventArgs e) {
if (Windows.UI.ViewManagement.ApplicationView.Value ==
Windows.UI.ViewManagement.ApplicationViewState.Snapped) {
//handle snapped view -- hide stuff, etc.
}
}
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
Here, we’re handling the screen size changed event and if the view is snapped, rearranging/hiding elements as necessary, or if it’s not snapped, doing something equally appropriate. A far better approach, though, is to not worry about snapped view specifically, and simply return to the tried and true method of examining the current app dimensions and scaling appropriately. In JavaScript, we can do something like:
window.addEventListener("resize", handleResize);
function handleResize(eventArgs) {
var screenWidth = window.outerWidth;
var screenHeight = window.outerHeight;
if (screenWidth <= 320) {
//should be snapped
}
//handle other combinations
}
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
This is a far more flexible approach, and because Windows 8.1 will support a wider array of screen dimensions and snapped combinations, it’s just best to consider how your app will work at any given resolution. Particularly for HTML/JS apps, it’s just smarter, too, as we don’t have to have any Win8 specific code and instead can leverage the same logic regardless of platform.
To test your apps, I enjoy using ModernMix from Stardock. ModernMix is a tool that allows you to run Windows 8 modern/store apps in a window on the desktop. While you can also use the Windows Simulator to simulate different resolutions, ModernMix is lightweight and also allows you to instantly resize your apps, making it easier to test/debug screen and layout issues. I like using it to debug non-screen issues, also, as it minimizes the flipping back/forth from desktop to full screen modern apps on a single monitor. The simulator is still very useful for a variety of other scenarios, like screen rotation. Disclosure: I paid for my own copy of ModernMix, and this is solely my opinion on its use as a tool for helping to build applications. Use at your own risk.
Effectively handling virtually any screen size is the best way to future proof an app. You don’t necessarily have to handle every conceivable screen resolution – put the plumbing in place now to make it easier as the platform evolves. You’ll be glad you did.

At the Columbia Windows 8 DevCamp this weekend, the topic of side-loading apps came up in a few different scenarios, but it was particularly appropriate during the app showcase. We had a number of developers working in the lab room, all competing to come up with the coolest app at the end of the day. During the showcase where developers pitch their apps to the audience, it works best to have all the apps on the same machine. Here’s the best way to do it without having to copy source code/solution files: From within Visual Studio, select Project > Store > Create App Packages: In one situation, where there happened to be multiple projects in the solution, these options were disabled. Why I’m not exactly sure, but you can also create the app packages by right clicking on the project in solution explorer, and selecting Create App Packages in a similar way: On the dialog windows that pops up, select No to build packages to upload to the store, as we’re not doing that: On the next screen, configure any path/build options (defaults are usually ok) and click Create: Once the packages are created, you’ll see the following folders: We can ignore the .appxupload files for now. For loading on another machine, we’ll need to copy either the x86 or ARM (or both) to the target machine (for the devcamps, we just pass around a USB key and have everyone copy the files there). On the machine you’d like to install the apps, run the PowerShell script (right click file, select Run with PowerShell). Of course, if you’re on a Surface or other ARM device, you’d need to run the PowerShell script from the ARM folder, otherwise use the x86: Once running, you may be prompted to install a certificate and need to accept a UAC prompt. You’ll then see the app install: Viola! The app should be installed on the Windows 8 Start Screen.