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.

 


With the option to create Windows Store apps with HTML5, CSS3, and JavaScript, developers often wonder what it will take to turn a website into an app. A while back I scribbled out some notes on the process that I thought to share here.

If you have other thoughts, please add them in the comments!

 

First are those requirements that come from the Store policies themselves. All of the requirements are important, of course, but the following are those that apply especially to converted web apps:

  • Section 2 is a key consideration: "Windows Store apps can display ads but are more than just ads or websites." This means, especially section 2.4, that you can't be a link farm that opens the browser all the time, and that you can't just repackage a website wholesale into an app and expect it to pass certification. However, pulling web content into the context of the app, where the user can see that they're in the app, is just fine.

    • Also note section 3.1: "You must use only the Windows Runtime APIs to implement the features of your Windows Store app." This does include HTML5 and JavaScript APIs, even though they aren't technically part of WinRT, and doesn't exclude using third-party libraries. It's really saying that you can't use local IPC or services which are blocked anyway.
       
  • Also skip down to section 5 of the requirements that deal with content (as well as age ratings). Some content will not be accepted into the Store at all, so if your web app deals with such, it's not a good app candidate.
     
  • The app must support touch input (section 3.5 of Store policy). Much of this comes for free, as touch events are automatically translated to legacy mouse events as web apps typically listen for. Nevertheless, you have to make sure the app is fully functional on a touch-only device. Note that requirement 3.5 also says "Your app must not use an interaction gesture in a way that's different from how Windows uses the gesture." Make sure to revisit any custom gesture work.

    • Note that this requirement also says "Your app must provide visual feedback when user touch interactive elements."
    • Typically, web apps being converted to Store apps also need a little work to make links and other clickable content large enough to work with touch. This often just means increasing the spacing around multiple interactive elements that are otherwise too close together.
       
  • View states: the app needs to handle snapped, filled, landscape, and portrait modes (requirement 3.6). Technically, the policy only speaks to snapped view (as a specific point of rejection), but really, aim to make an app that looks good in any view state.
     
  • Honor process lifetime states of suspend and resume, and have no close affordances in the app (requirement 3.6–typically not something a web app ever has anyway). It's important for apps that use online content to refresh that content if necessary when the app is resumed, as it may have been suspended for a long time.
     
  • Requirement 3.9 says, "All app logic must originate from, and reside in, your app package." Specifically, any code that interacts with the WinRT APIs has to be in the package and cannot be downloaded from a remote source. This means any libraries you use in the main app (the local context) must be bundled in the package (along with whatever those libraries depend upon). Parts of the app that use the web context are allowed to access remote script, as the web context cannot access WinRT. Avoid downloading such script and passing it between contexts to execute/eval it in the local context. This opens security holes and is a basis for rejection.

    • Related to this is the fact that the local context also disallows script injection, e.g. via innerHTML attributes, and imposes other security constraints within the app container. This can affect third party libraries.
    • The underlying purpose of this requirement is security more than anything, that is, to avoid having potentially untrusted code execute in the local context where it could possibly do some damage. Admittedly, this is a gray area. Clearly, something like a magazine, book, or other multimedia content is not "app logic" and can certainly be downloaded, processed, and displayed in an app. Definitions for new levels of a game fall into that same bucket, even though such configurations might ultimately drive how the app code executes. Downloading a program or script in some other language, on the other hand, that then runs as an app inside your app, will cause rejection. In the end, I think this is primarily about the difference between data that's rendered visually and instructional code or script that drives execution. Still, it's a gray area to me, so I think we'll see further refinements of this policy as new kinds of apps are developed.
       
  • Privacy policy (requirement 4.1, 4.1.1, 4.1.2)–essential if you're hitting the Internet in any way. You must also have a means for support (requirement 6.3)
     
  • Protect against large transfers on a metered network (requirement 4.5)
     
  • Be mindful of age ratings (requirement 5.1 and 6.2). This isn't something you deal with on the web, but is required when submitting an app to the Store.

 

Store requirements are, of course, the min-bar for Store submission and certification. To be a good app on the platform, however–which means creating an app that Windows users will actually want to install!–you'll need to go beyond those basics. The following, then, represents the core of platform integration:

  • Horizontal orientation: although web apps are typically designed for a vertically-scrolling experience, the design of Windows Store apps are primarily horizontal (except in snapped view). This may affect your app's interaction model significantly, but is what users will expect.
     
  • View states: again, support all the view states, not just landscape and snapped as required by policy.
     
  • Handle resolution scales well, both varying display sizes (what we call responsive design in the web world) and different pixel densities. The latter means having raster graphics that work well on 100%, 140%, and 180% scaled devices.
     
  • Beyond suspend/resume (as required by policy), the app should be able to be terminated while suspended and then restart where it left off. This means saving transient session state and being able to rehydrate the app from that state.
     
  • For any commands that are not essential to completing a workflow, move those commands/controls off the app canvas and into flyout controls like the app bar, settings panels, and the Search and Share charms. There are many guidelines for this found on Commanding design.

    • Note that it's OK to leave some search and sharing functions directly in the app; just think about how to also integrate with the charms.
    • Move app settings into Settings charm along with logins and profile management. You can have some on-canvas login/user controls, of course, but use Settings for additional features rather than separate app pages.
       
  • Minimize chrome (non-functional UI elements), which happens automatically when you move commands off-canvas, but also means using layout and typography to group functionality rather than lines, boxes, and so forth.
     
  • Migrate from <a href> navigation to a single-page model with DOM replacement. This will greatly simplify managing state in the app, although you can transfer state in other existing ways. It's just much easier to not have a new script context with every page.
     
  • Have great branding graphics including tiles, splash screen, Store logo, etc.

 

 

Beyond that, some additional considerations will take the app to the next level:

  • Handle variations in network connectivity or lack thereof. On the web, you assume connectivity because the app has to be loaded into a browser from the web. An app exists on the client, however, and can be run without connectivity. So think about your offline behavior and caching strategies.
  • Live tiles: what can you surface on the tile more than your logo?
  • Roaming experience—what settings transfer to the user’s other devices when they have the same app installed?
  • Localization (depending on your target markets)
  • Accessibility
  • Good use of progress indicators when transitioning pages. In browsers, users come to depend on the browser's indicators about page loading. In a Store app, you need to indicate such states yourself, and implement strategies to minimize wait times and increase responsiveness.
  • Honing performance especially if using collection controls.

 

Your thoughts and/or experiences?