[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.]

 

Q. I want to have my app load and show in-app purchase listings, but until the app is in the Store, such listing information won't be available. As a result, my app will look non-functional and could fail certification. What can I do about that?

A. The right approach is to remember that Windows.ApplicationModel.Store.CurrentApp.LoadListingInformationAsync is not ever guaranteed to work. Having no listing information in the Store is one case where it would fail, but so is lacking connectivity. Therefore you should always write your code to fail gracefully is no in-app purchase listings can be obtained. Arik Cohen of the Store team suggests these approaches:

  • Manage your list of in-app purchases in your own service (or have the list built into the app) and use the ListingInformation only for pricing.
  • Don't show the prices within your app
  • Show the purchases as presently unavailable and suggest the user checks back later.

Know too that the unavailability of ListingInformation doesn’t mean that you don’t have in-app purchase information; CurrentApp.LicenseInformation maintains a local cache of all durable in-app purchases that the user has made.

Gracefully handling the case when you're unable to retrieve in-app purchase listing information should avoid any problems in certification.

 

Q. Is there a way to add or edit in-app purchases to an app that is currently published without having to submit a new build of the app?

A. To change the listing information you always have to submit an update, but you don't have to upload a new app package or change the app's version number. And because you're not changing the package, certification should be quick.

To avoid having to resubmit, you'll need to manage your own in-app purchase catalog, which enables you to generate your list of available purchases dynamically. For more details, see Chapter 20 of (my free ebook) Programming Windows Store Apps with HTML, CSS, and JavaScript, in the section "Handling Large Catalogs" starting on page 1145.


One of Microsoft's evangelists working with students put together this list of common certification issues.

  • Make sure all your views work. On Windows 8, this means snapped and filled views along with portrait. On Windows 8.1, this means handling variable view sizes down to 500px, and possibly to 320px if you set that flag in your manifest.
  • If you use sounds in your app, make sure there's a clear way to turn them on and off, or set the volume (between 0 and full).

    • It's possible that the manual tester might not see the option in your Settings, so you might need to put a control on canvas if it won't get in the way (and that button can open settings, of course.)
  • Privacy statement

    • If you have ads, you need a privacy statement in your Help or other settings where the tester can see it.
  • Country/Age Rating

    • Make sure to pick your countries carefully: there are cultural differences that will allow/disallow various metaphors and imagery. The author of this list said that one of his apps with "kisses" in it was disallowed in some countries.
    • Age rating: be sure to study the requirements here, as this is a common stumbling point.
  • Logo graphics

    • Never, ever upload an app with the default Visual Studio logos and splash screen. Hopefully the WACK is catching these by now, but I don't want to see any more apps in the Store with the default graphics!
  • Test on different devices and in the simulator

    • If the simulator hangs on launching your app, there's a definite problem.
    • Use the simulator to test orientation changes and all view states on all canonical screen sizes.
    • If you have access to different devices, including Windows RT devices, by all means try them out there too. You'll get a various of scaling factors and screen dimensions.

A while back I was working with a partner who asked what it would take to convert their web app (in HTML5 & CSS) into a great Windows Store app. This wasn’t a question of a minimal approach to just get it to work, but of making a really good app while still minimizing the work. I put together the following list of priorities with some general estimates of the amount of dev work involved. I figured this might be a helpful list for other developers.

For further inspiration, also check out the Website to apps topic in the design inspiration section of the Windows Developer Center.

Necessities:

  • Has to meet Store policies, which is some of what drives this list. (1-3 days) Key considerations:
    • 3.5: touch interaction must have visual feedback (meaning proper animations)
    • 3.6: handling view states and process management
    • 3.9: disallowing remote script
    • 4.1/4.1.1: privacy statement
    • 4.1.2: opt in for use of personal information
    • 4.5 Network cost awareness (especially for any large transfers) (.5-2 days)
    • 5.1 and 6.2: content and age rating
  • Explore a horizontally-oriented design (though vertical can be done especially with the Windows 8.1 ListView). (1-3 day design; dev is variable depending on the design and where you’re starting from)
  • View states: handle portrait, snapped, filled along with landscape. (2-3 days for design, implementation, testing) [For Windows 8.1 this means handling variable sizing rather than view states]
  • Handles resolution scales well, both display sizes and pixel scaling. (1-2 days)
  • Must run within the app container security boundary, which excludes remote script and script injection. (1 day to check; possibly more if things need to be rewritten)
  • Works with mouse, keyboard, and touch input, the latter of which means that touch targets need to be the right size. (.5 day design; 1-2 days dev)
  • Move chrome/commands off-canvas, generally (2 days design; 3-5 days dev)
    • Search to Search charm
    • Sharing functions to share source, though you may retain what you have as it’s integral to the experience
    • Settings to Settings charm including logins and profile management
    • Other commands and navigation to app bars
  • Handling suspend/terminate/restart and suspend/resume. (1 day)
  • Migrate from page navigation based on <a href> to single host page with DOM replacement (using page controls) (1-4 days depending on how you’re doing it now)
  • Great splash screen and branding graphics (1 day design mostly; .25 days dev)

Nice to Do:

  • Handling network connectivity or lack thereof (caching strategy/offline story) (2-4 days dev)
  • Live tiles: what can you surface on the tile? (1 day design; 2 days dev)
  • Roaming experience—what settings transfer to the user’s other devices? (1 day dev)
  • Globalization (making a world-ready, language-neutral app) (2 days dev)
  • Localization (1 day testing with pseudo-language; each language is likely an hour or less but needs to include time spent )
  • Accessibility (2 days)
  • Good use of progress indicators when transitioning pages. (.5 days design, .5 days dev)
  • Honing performance especially if using collection controls. (2-4 days day dev depending on goals)

 


One of the most significant changes in Windows 8.1 relates directly to the Windows Store but doesn’t involve any new APIs. This is the auto-update feature for app, which means that you no longer need to rely on users manually updating your apps from the Store. The primary impact of this is that if you make feature updates and especially add in-app purchases, those features will become available to all your customers unless they’ve specifically opted out of auto-updates. This should help quite a bit with monetization over time.

At //build 2013, Ted Dworkin’s talk gives the overview: Windows Store Overview for Windows 8.1: New Design, New Promotion and Monetization Opportunities (2-123).

As for new APIs, the key features here are added support for consumables (in-app purchases that can be re-purchased over and over), and support for large catalogs of in-app purchases (going beyond the 100 item limit of Windows 8). See the Windows.ApplicationModel.Store APIs, as well as the talk Monetization Opportunities for WIndows Store Apps in Windows 8.1 (3-121).

Speaking of the Store, there are a couple of other related talks from //build 2013:


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.

 


If you plan to use ads in your app with the Microsoft Ads SDK, be very aware that at present you must set the age rating of your app to 12+ or else ads will not appear. This is described on Submitting an App with Ads to the Windows Store. You can still submit an app with a lower age rating but no ads will appear, so you’ll wonder what’s going on. Also be aware that you definitely need a privacy policy for your app when using ads or Store certification will reject it.

Update: one developer has told me that his app in the Kid’s category of the Store is rated at 7+ and ads show up, so there might be an exception for Kid’s apps or the ads SDK has been updated to provide for a lower age rating. Check with the ads SDK for current status.


Before submitting your app to the Store, take some time to review your app’s manifest and the information and files it references. Mostly concentrate on the Application UI tab in Visual Studio’s manifest editor. If you haven’t noticed or installed recent Visual Studio updates, the VS team improved the editor by bringing all of the app’s UI elements into the Application UI tab. Earlier, bits of UI like the Store logo were on the Packaging tab, which made it easy to miss. Now it’s all together, plus, it shows you every scaled version of every graphical asset (there’s so much to scroll now you can’t get it into one screen shot):

manifesteditor1 manifesteditor2

Here’s what to pay special attention to:

  1. Make sure that all logos (logo, wide logo, small logo, and store logo) are all representative of your app. Avoid shipping an app with any of the default graphics from the VS templates. Note that the Store logo never shows up in the running app, so you won’t notice it at runtime.
  2. Double-check how you’re using the Show Name option along with Short Name and/or Display Name. Go to the Start screen and switch your app tile between square and wide, and see if the tile appears like you want it to. In the graphics above, notice how the app’s name is included on the tile images already, so having Show Name set to “All logos” will make the tile look silly (see below). So I’d want to make sure I change that setting, in this case, to “No logos.” However, if my square tile, perhaps, did not have the app name in text, then I’d want to set it to “Standard logo only.”
    manifesteditor3
  3. If you set Short Name, its text will be used on the tile instead of Display Name.
  4. Be aware that if you’re using live tiles, the XML update for a tile can specify whether the display/short name should be shown in the branding attribute. See my post on the Windows 8 Developer Blog, Alive with Activity Part 1, for details.
  5. If you don’t have specific scaled assets, reevaluate your choices here. Remember that if you don’t provide a specific version for each given pixel density, Windows will take one of the others and stretch or shrink it as needed, meaning that the app might not looks its best.
  6. Examine the relationship between the small logo, your specified tile background color, and any live tile updates and toast notifications you might use. Live tiles and toasts can specify whether to show the small logo, and the tile background color is used in both instances. If you have a mismatch between the small logo edge colors and the background color, you’ll see an obvious edge in tiles and toasts.

 


For this post, let’s focus on section 3.5 of the requirements:

3.5 Your app must fully support touch input, and fully support keyboard and mouse input

Your app must provide visual feedback when users touch interactive elements.

Your app must not use an interaction gesture in a way that is different from how Windows uses the gesture. The Windows 8 touch language is described in Touch interaction design.

There are a number of things going on here that are worth thinking about more carefully.

The first sentence basically says that the app has to support multiple input modalities. To “fully support touch input” means that the app must be fully usable with only touch, which should be obvious given the increasing number of touch-only devices. This means that an app cannot have UI or features that are only accessible through a mouse or through a special keystroke. Usually this isn’t much of an issue, because using pointer events lets you handle touch and mouse with the same bit of code anyway.

The second half of the scentence is a little sketchy to my mind. Depending on how you read it, it might say “the app must be fully usable with only keyboard, as well as with only mouse,” or it can be read that “the app must be fully usable with keyboard and mouse together.” From what I’ve seen, certification makes the latter interpretation.

At the same time, I strongly encourage developers to provide complete keyboard-only interfaces as well as mouse-only interfaces. In doing so, you make the app much more accessible for people with disabilities. That’s really the reason why the UI guidelines for desktop apps that have been around for many years suggests things like keyboard accelerators for menus that can also be used with a mouse.

In this context I often think of a classmate of mine within the Electrical/Computer Engineering department at the University of Washington when I was an undergraduate there. Sometime in our senior year, he severed his spinal cord in a skiing accident and became a quadraplegic. But he still completed his degree, often using a computer keyboard with a rod that he held in his mouth. To this day I admire his determination to carry on despite his permanent injury, which means making a little extra effort of support full keyboard interactions and not rely on the mouse for some of it.

Anyway, the last two sentences of section 3.5 above apply only to touch interaction, and are pretty clear. The visual feedback requirement is important because it lets the user know that the app has detected the touch–a piece of glass, in other words, doesn’t give the tactile response that a keyboard or mouse does, so the acknwoledgement of input has to be visual. For this, the pointer down and pointer up animations in the animations libraries provide standard visual responses.

As for gestures, the point here is to avoid forcing users to retrain themselves for the sake of your app, which ultimately lowers their efficiency across the rest of the system. It’s a reminder that your app is not the only one running on the device, so be a good, cooperative player and avoid “innovating” in places like input where you’ll just cause confusion.

The last thing I’ll add regarding input is not part of Store ceritification, but also good to think about: sensors. As I wrote in my book, I like to think of sensors as another form of input, one that is a fresh area that’s open to all kinds of innovation. And because there’s nothing in Store certification related to how you use inclinometer, the compass, gyros, etc., you can be very creative here!


The Windows Store Certification requirements (section 4.5) stipulates that apps doing data transfers must avoido doing large transfers over metered connections (you know, the ones that charge you outrageous amounts of money if you exceed a typically-small transfer limit!). At the same time, getting a device set up on such a network can be time consuming and costly (especially if you exceed the limit).

There is certainly room here for third-party tools to provide a comprehensive solution. At present, within Windows itself, the trick is to use a Wi-Fi connection (not an Ethernet cable), then open up the Settings charm, tap on your network connection near the bottom (see below left, the one that says ‘Nuthatch’), then in the Networks pane that appears (below right), right click the wireless connection and select Set As Metered Connection.

network settings  Wifi menu

Although this option doesn’t set up data usage properties in a network connection profile, and other things a real metered connection might provide, it will return a networkCostType of fixed which allows you to see how your app responds. YOu can also use the Show estimated data usage menu item (shown above) to watch how much traffic your app generates during its normal operation, and you can reset the counter so that you can take some accurate readings:

Wifi usage

It’s also worth noting that Task Manager has a column in its detailed view, on the App history tab, for metered network usage, where you can track your app’s activities.

Task manager app history

It’s good to know this as a user, too, as you can see if there are any misbehaving apps you might want to reconfigure or uninstall.

 


First, we’re sometimes asked whether it’s possible to give out promo codes for paid apps, or otherwise gift apps? Answer: not at this time.

Second, if you have an app that’s certified but just waiting to go live according to your indicated release date, can you change the date so that it publishes earlier? Answer: same thing, not at this time. Another good idea for future implementation, as currently you have to resubmit the app and go through certification again.

On the subject of release dates, the documentation for this says that the date guarantees that the app won’t be released before that date (GMT time), but can’t guarantee that it will go out on that date. The latter caveat is there because the app might not have made it through certification yet; otherwise, if it’s certified, the release should happen pretty quickly. At present, it’s also not possible to set the release for a specific time.