From a background task, it's perfectly allowable to issue a tile update, for instance, when procedding a raw push notification in that task and updating a tile in response. With secondary tiles, you might also want to update the tile's arguments so that it launches into different content relevant to the tile update. However, secondary tile arguments are statically defined when the tile is pinned and cannot be changed later.

To work around this, you can use a set of static identifiers that you then dynamically map to your variable data. It's simplest to just keep a table of secondary tile IDs mapped to their dynamic arguments, in which case you're probably not using the static arguments at all.

Another question with background tasks is whether it's possible to do file I/O therein, because clearly if you're modifying a table of secondary tile arguments in a file you'll be doing file I/O. The thing to remember here is that if you use any kind of async APIs in the process, you need to make sure the background task stays active until the async work is complete. To do this, you use the deferral mechanism.

In C#, the general pattern is like this:

public async void Run(IBackgroundTaskInstance taskInstance)
    var deferral = taskInstance.GetDeferral();
    var contents = await DoAsyncWork();

In JavaScript, the deferral is found on the WebUIBackgroundTaskRuntimeClass object. You retrieve this in the worker with Windows.UI.WebUI.WebUIBackgroundTaskInstance.current, then call its getDeferral method, do your async work, and then call the deferral's completed method when you're done.

var task = Windows.UI.WebUI.WebUIBackgroundTaskInstance.current;
ver deferral = task.getDeferral();

DoWorkAsync().done(function () {
    close();  //Shut down the background task

Note that JavaScript it's also necessary to call close() when the task is finished (which is WorkerGlobalScope.close()).


A partner we worked with had some troubles with a live tile image not appearing, and the process of working them out helped us understand better how to debug live tile issues.

First of all, make sure of two more global that affects tiles:

  • Live tiles don't appear in the Visual Studio simulator for Windows Store apps (though I believe they do on the phone emulator). Run locally or on a real device.
  • Make sure that live tiles for your app on the Start screen are not disabled (right-click to check).
  • Some live tiles won't look right if you've turned off system animations in PC Settings > Ease of Access > Other Options > Play Animations.

Second, the tile updater is quite sensitive to properly-formed XML. If you have any kind of glitch, the update payload will be ignored and you'll be left scratching your head. Here are some things that can trip you up:

  • The XML lacks the <?xml version="1.0" encoding="utf-8"?> header.
  • There is a space or linefeed before the <?xml> header.
  • The XML isn't properly formed (e.g. missing closing tags) or doesn't follow the Tile schema.
  • The elements you indicate for a tile template doesn't match the template itself.
  • You have a mismatch between the indicated template and the version number in the <visual> element.
  • You are using accidentally using <img> tags rather than <image> in the XML. Tile templates are not HTML: they use <image>.

If you think your XML is good but it's not working, try simplifying it to include only a single tile size payload, and try them one at a time. That can narrow down where an issue might be. Also use App Tiles and Badges sample as a reference point, specifically scenario 6 that lets you build payloads.

Next, a tile update can have proper XML but its image references might be invalid. If you're using http[s] references, double-check those links in a browser. If you're using the baseUri attribute anywhere in your XML, do that combining manually and check the URIs. Also check image references with any URI parameters that are added with the addImageQuery attributes. See "Using Local and Web Images" in Chapter 16 of my free ebook (page 897) for details.

Other allowed reference URI schemas are ms-appx:/// and ms-appdata:///local. You cannot use ms-appx-web:/// or ms-appdata:///[temp | roaming] — doing so will cause the update to be ignored.

Thirdly, remember that tile images must be 1024 pixels or less in both dimensions, and must be less than 200KB in size. This means potentially resampling an image to make it smaller, and it especially means being aware of the image format and quality as that significantly affects the size. Here's how I wrote about this issue in my book, page 899:

Sidebar: PNG vs. JPEG Image Sizes

When considering tile images for the larger 140% and 180% scales, the encoding you use for your images can make a big difference and keep them below the 200K size limit. As we saw in “Branding Your App 101” in Chapter 3, a wide tile at 180% is 558×270 pixels, a medium is 270×270 pixels, and a large is 558×558 pixels. With the wide and large tile sizes, a typical photographic PNG at this size will easily exceed 200K. I encountered this when first adding tile support to Here My Am! for this chapter, where it makes a smaller version of the current photo in the local appdata folder and uses ms-appdata:///local URIs in the tile XML payload. Originally the app was capturing PNG files that were too large, so I borrowed code from scenario 11 of the App tiles and badges sample, as we’ve been working with here, to create a smaller PNG from the img element using a temporary canvas and the blob APIs. This worked fine for a 270×270 medium tile image (a 180% scale that can be downsized), but for 558×270 and 558×558 the file was too large. So I borrowed code from scenario 3 of the Simple Imaging sample to directly transcode the StorageFile for the current image into a JPEG, where the compression is much better and we don’t need to use the canvas. For this second edition’s example I just capture JPEGs to begin with, which are already small enough, but I’ve preserved the code anyway for reference. You can find it in the transcodeImageFile function in pages/home/home.js, a routine that we’ll also rewrite in Chapter 18 using C# in a WinRT component. 

Such considerations are certainly important for services that handle the addImageQuery parameters for scale. For larger image sizes, it’s probably wise to stick with the JPEG format to avoid going over the 200K limit. 


The 200KB limit turned out to be the issue with the partner–all the images referenced in the live tile were larger than 200KB and therefore ignored. More specifically, the images were saved as PNGs, which again for photographic images produces larger file sizes than JPG. In this partner's case, even the 150×150 tile image was too large; if it had happened to be smaller, the partner would have seen it appear but not images for the other sizes, which might have revealed the problem more quickly.

What confused the process of tracking down this problem is that an invalid image will cause that particular tile update (for that size) to be ignore in toto, meaning that the text won't appear with an invalid image. This is a reasonable behavior because otherwise end users would see oddball tile updates with text but blank spots where images should be. Personally I'd love to see a debug option in the system that you could turn on so some kind of placeholder image would appear, or an error message if a tile update is invalid.

The other thing that can be confusing is that the system will always download an image from a valid URI, and then check whether it's too large to display. This makes some sense as it's difficult to know from a URI whether the image is too big or such. The system could do a round-trip to the network to check the size first and not download it, but it doesn't work that way: it will download, and then ignore the image. This means that just watching fiddler traces or such isn't deterministic in checking image validity.

If you have a service, by the way, that dynamically generates images for periodic tile updates, then it's possible to have some variance in image sizes that are being supplied in tile updates. For debugging, make sure your service is logging requests and the dimensions and file size of every image returned. Then you can see whether any images exceeded the allowable limits.

Today I’m picking up a couple of smaller additions/changes to Windows 8.1, as yesterday’s post was quite lengthy.

First is that there’s much deeper SkyDrive integration in Windows 8.1. You can learn about this in the //build 2013 talk, What’s New for Working with Files (2-119). I haven’t gone into this in detail yet, so I’m not sure where it intersects with the WinRT API.

Second is that there are new tile sizes (small and large) with associated tile templates, along with some expanded capabilities in secondary tiles. With the latter, you can now provide multile tile sizes and multiple images per size so that the user can select their desired tile size and image directly in the consent popup, rather than having to do it on the Start screen. You can see more in The Windows.UI.StartScreen.SecondaryTiles class, as well as the Secondary tiles sample. My own talk at //build, Alive with Activity (3-159), covers all the tile changes.

On the subject of tiles, there are a couple more talks on push notifications and Windows Azure Mobile Services that are relevant:

Following from yesterday's Store Q&A, I have another collection for live tiles. Note that WNS here refers to the Windows Push Notification Service.

Question: The code sample on Quickstart: Sending a push notification is written in C# but says C++ in the title. How do I do this in C++?

Answer: This code on MSDN is meant to be used from a ASP.NET web service, not an app, hence being written in C#. All that you need to do from an app is post a channel URI to that service, then the service uses the code in PostToWns whenever it needs to send an XML payload to that channel. Presumably this service is running all the time, so push notifications happen regardless of whether the app is running at all. Posting to WNS from an app is generally unnecessary, as a running all can just send the XML update to the appropriate WinRT API to have it show up on the tile or toast as needed. Going to WNS would be a very roundabout way to accomplish the same thing. If you'd like your service to trigger push notifications to other devices, then you'll need a service endpoint for that purpose. Windows Azure Mobile Services makes this much simpler; see Alive with Activity, Part 3: Push notifications and Windows Azure Mobile Services on the Windows Developer Blog.

Question: How do I test the different scaled images for my tiles, such as those in my manifest?

Answer: Scaling goes into effect on devices with different pixel densities (dpi), which is a different concern from screen size. A 1920×1200 screen (like my 15.7” laptop screen or my 24” desktop monitor) are 96dpi devices so Windows employs a 100% scaling. If, however, I had the same resolution on a smaller screen, like the 10.6” on a Surface Pro, then Windows will employ 140% scaling, and then use alternate graphics. You can test your scaled images in the Visual Studio simulator or through Blend’s device tab. In the latter, for instance, you’ll see that the different options indicate the scaling %’s in effect:

6-6 (Blend resolutions)

See Guidelines for scaling to screens and Guidelines for scaling to pixel densities for the differences between screen resolution and DPI considerations.  


Question: I've read your book's Chapter 16 [13 in the first edition] with the sample HelloTiles web service to support live tiles. Is there a step-by-step guide to creating a web service in Visual Studio? I'm new to the services scene.

Answer: The main thing is to first understand how the backend in your chosen language gets at the data it needs. In PHP, you might be accessing a MySQL database, which would be very common. In that case, you could try starting at That would show how to extract the data you want, then it’s a question of wrapping that up into the XML payload.

All this really means is using the PHP echo function to output the XML with the values of variables inserted. The samples that these pages show are outputting HTML, but you’d simply be outputting the XML instead. You can then extend the service by allowing URL parameters, for which you’re use parse_url in PHP to get at the individual components (see You can then feed those parameters into your database queries to customize what’s being returned.

Those URL parameters would simply be part of what the client app includes in the URL it gives to Windows for periodic tile updates…Windows will just send a request to that URL. If that’s your PHP page, then your code executes, you process the parameters, run the query, then emit the XML as output (the request response). If it’s properly formatted, you’ll then see the tile update. In ASP.NET you’re pretty much doing the same thing, just in another language, e.g. querying a SQL Server database but again emitting the XML as the “page” that you’re server-side code is generating. You can find many tutorials on, such as

Again, these tutorials as going to show creating a web page response (HTML), but you’ll just be emitting the XML instead. Generally speaking, Visual Studio is better set up for ASP.NET/WebMatrix than it is PHP. WebMatrix was designed to be a closer analog to PHP than the full ASP.NET (where you basically never see the HTML or XML output). Also, Windows Azure Mobile Services will be making it easy to create an endpoint without having to spin up a whole service of your own.  Keep an eye on that.


Question: Can I use a push notification to reset a live tile previously updated with a push notification, other than just waiting for it to expire?

Answer: Not really. There's not a general purpose "reset" with WNS. One thing you can try is to send your real notifications with a particular tag (X-WNS-TAG), then send another one later with the same tag and a very short expiration time. However, there's no guarantee that the update will go through, so it's not foolproof. In the end, it's probably better to come up with some other interesting content as a generic tile update that would serve as your "clear".  

Question: How do I set an expiration time for a push notification?

Answer: Calculate the number of seconds that you want the update to live from the time you post to WNS. Include that value in the X-WNS-TTL header.  

Question: I understand that WNS does guarantee deliver of push notifications. How often will WNS attempt delivery of cached messages when messages have the X-WNS-Cache-Policy set?

Answer: See notifications will be delivered automatically when the device next comes online. They may be dropped by the server after a few days if the device is not seen.

Question: Does WNS support multicasting a single push notification to multiple device endpoints?

Answer: WNS doesn't offer this directly, no. Toolkits built on WNS can offer such capabilities. however.

Question: How do I handle expiration of an OAuth token for push notifications? To be specific says, "An access token is returned in the HTTP response if the cloud service successfully authenticated. This access token can be used in notification requests until it expires." How does one detect the expiration – the response shown in doc doesn’t include expiry or a refresh token. Will the POST to WNS return a 403 or some other code and then I need to reissue request for a new access token? What’s the recommended approach for handling the scenario in code?

Answer: The recommended approach is to store an access token and push notifications using that access token until an error code is returned.  At that point, the app service should reauthenticate with WNS and request a new access token for pushing notifications (again using that token until an error code is returned). The documentation states that WNS uses the 401 error code to indicate that an access token has expired.        

In relation to my series of posts, Alive with Activity, on the Windows 8 Developer Blog (part 1 is there, part 2 will be posted today, and part 3 is in production), I’ve been working some with Windows Azure Mobile Services and am increasingly impressed with what’s being offered here. You owe it to yourself to learn something about them.

As you’ll see in parts 2 and 3 of that devblog post, Mobile Services, which I abbreviate as AMS and which is also referred to as ZUMO (aZUre MObile service), setting up push notifications is really a snap with this technology. That is, if you go through the list of things you have to do to support push notifications, there’s quite a bit on the service-end of things (as part 3 will describe), and these are many of the details that AMS takes care of for you.

The two primary tasks for push notifications are:

  • Sending channel URIs to the service: this step becomes far easier with AMS. Instead of sending HTTP requests that you have to build up yourself, you instead create a database table in the mobile service (through the Windows Azure portal) and simply insert a record into that table with the channel URI and any other key information you need to attach to it. The AMS client library takes care of the HTTP request behind the scenes, and even updates the client-side record with any changes made on the server. Furthermore, AMS can automatically handle authentication through the user’s Microsoft Account or through three other OAuth providers—Facebook, Twitter, or Google—if that you’ve registered your app with one of them. See Get started with authentication in Mobile Services.
  • Sending notification: in the raw, you have to send HTTP requests to the channel URIs used with push notification. With AMS< you can attach scripts (written in the variant of JavaScript known as Node.js) to database operations, and also created scheduled jobs in JavaScript. In these scripts, a simple call to the push.wns object with a channel URI and a payload generates the necessary HTTP request to the channel. It’s also a simple matter to capture push failures and record the response with console.log. Those logs are easily reviewed on the Windows Azure portal.

Now instead of spoiling the fun of my devblog posts where push notifications are concerned, here are other capabilities of AMS that you will want to know about.

  • The ability to authenticate the service with OAuth providers is very cool. Just as you can use OAuth providers to authenticate a user in a Windows Store app (using the Web Authentication Broker), you can also use that same provider on your service back-end. This means that having access to a unique user identity is pretty simple and straightforward, allowing you to manage per-user data in the service.
  • AMS builds on SQL Server databases hosted on Azure. Those databases are just like any other online SQL Server instance and can be accessed in the same way. This means that you can have other services, apps, web sites, etc., all talking to the same database that the Mobile Services part uses. This allows you to use that database as a central gathering point for data that you’d use for things like periodic and push notifications (OK–that’s a spoiler for Part 2…).
  • Whether or not you need push notifications in an app, the client library gives you a very easy way to save records to a database table and have any server-side modifications reflected back in the client. You can, of course, just read, delete, and update those records as well. In other words, the table-management capabilities in AMS can be used by themselves just for data management, which is super-cool. Even more so is the dynamic scheming capability with the database, meaning that you can just add columns (properties) as you need without having to separately manage the database tables.
  • You can easily do paging of data from the database, e.g. having your app only acquire so many records at once.
  • The scheduled jobs feature of mobile services lets you run code on your server whenever, for whatever purpose. You’re just setting up these jobs with little bits of JavaScript, so it’s not like you have to learn everything about server-side programming.
  • AMS works with Windows Store apps, yes, but also Windows Phone, iOS, and basically anything else that can talk to a service. Don’t think of AMS as just a Windows thing.
  • You can use AMS to send emails from the server.
  • AMS also provides mechanisms for managing server-based storage, e.g. for uploading images and other data from an app. You can use the Background Transfer APIs in WinRT to do this directly, but it means writing a service that can deal with those data streams. AMS does that for you, and employs the background transfer APIs on the client side.

And from what I hear, the story will get better in the months ahead when new features are added.

In short, it’s worth spending a few hours just looking through the AMS docs on I think you’ll be pleased at what you find. ANd check back in every few months to see what’s new.

By the way, if you’ve read this and find yourself a little nervous about all this “service” stuff that takes you away from the concerns of client apps, let me say that I really do understand! Learning about HTTP, etc, well, I didn’t want to touch services for a long time, as it can be a very different world than writing apps. However, in the process of writing Chapter 13 of my book, I really didn’t have a choice. Because no one, to my knowledge, had put up a sample service to work with tiles, toasts, and badges (the Windows 8 SDK only has client-side samples), I took the plunge. Having done so, I have to say I’m really enjoying learning about this space, not just with Azure, which is very cool, but boning up more on ASP.NET, refreshing my PHP (in which I’ve worked a little), checking out Node/node.js (for writing servers), learning about the whole world of web APIs (see, and thinking about how to use services creatively in apps.

And now that I’ve been looking into AMS, what’s so very cool about it is that you don’t have to deal with all that HTTP stuff at all!

So don’t be that afraid of it (I’m still a little iffy on OAuth…but that’ll come!). Take it a little at a time, and I’m hoping my devblog posts will help you bridge to that space as well.


Working with tiles, badges, and toast notifications is a wonderful way to have your app surface information to the user when it’s not in the foreground or not running at all. Because of this, however, it can be difficult to debug updates or notifications that aren’t working. If there’s something wrong with the XML or the contents of an update, then it might not display at all, which can be difficult to figure out. So I wanted to offer a number of things you can do or check when you encounter problems.

First, consider something like the following scheduled XML payload for a toast notification:

<toast><visual><binding template=”ToastImageAndText04″>
<image id=”1″ src=”ms-appdata:///local/some_image_created_dynamically.png” />
<text id=”1″>Some text 1</text><text id=”2″>Some text 2</text><text id=”3″>Some text 3</text>

Let say you’ve called the necessary APIs to get this up, but it doesn’t appear at the appropriate time. Why? For one, consult the troubleshooting guide that’s found in the docs. But let me add to that some.

For one thing, the XML could be malformed–Windows will reject any tile, badge, or toast where the elements inside <binding> don’t match the template indicated in binding.template. To compare, run the App tiles and badges sample and go to Scenario 5. This is less of a sample and more of tool that lets you generate tile updates, where you can then see the resulting XML. It’s also worth pointing out that the XML text should always be UTF-8 encoded (contrary to the troubleshooting guide’s statement about UTF-16, which is a doc bug). I’ve also found that Windows is somewhat picky about extra line feeds at the top of the XML.

For scheduled notifications, check to make sure that you’re actually scheduling a time in the future. See the Scheduled notifications sample for reference.

Next, be sure that any image.src property is a valid URI, for one, but also make sure that the target image is 1024×1024 or smaller, and 200KB in size or smaller. Windows will not display larger images. In the example above, the overall toast will still appear, but it will have a blank image if Windows can’t find the image file or if the image is too large. In general, a blank image shows up when there is some problem loading that image.

You can also use the event log. In the event viewer, navigate to Application and Services Logs > Microsoft > Windows > Apps > Microsoft-Windows-TWinUI > Operational tile where tile activity takes place. Note that you need to click on the Details tab to see which app was involved as the General tab doesn’t show that.

Speaking of the event viewer, note also that Application and Services Logs > Microsoft > Windows > PushNotifications-Platform > Operational has additional events about push notifications.

For push notifications in particular, it’s absolutely essential that the package ID in your manifest exactly matches what you have in the Windows Store. Using the Store > Associate App with the Store command in Visual Studio will make sure of this.



I installed the Win8 app called “Logo Quiz” the other day and noticed that the authors used a default splash screen image that simply contained an hourglass:

I found this definitely curious because a splash screen, while serving the same purpose of the hourglass–namely giving the user something to look at while an app is loading–is also an app’s first opportunity for promoting their brand and creating a sense of identity in the mind of the user. So having an app’s splash screen contain nothing but an hourglass works, for sure, but can be made so much better. I certainly hope that Logo Quiz improves upon this in their next version, because they do have a much more interesting tile image to serve as a basis.

At the same time, it’s clear that some of the blame for this misunderstanding lies with Microsoft’s early app templates in Visual Studio, where the default splash screen image from those templates showed a clock face:

This could easily have been interpreted to say that the purpose of the splash screen image is to show an hourglass representation of some sort, but indeed, that’s not the point at all. This is one reason why the current templates now just have a box with a big X through it as if to say “please don’t use this image!” (though some apps still do!).

In the end, always remember that the splash screen image is the first thing a user sees when they tap your app tile, so you want to make it as engaging and inspiring as you can–make the user happy that they tapped your tile! Help them to look forward to spending time in your app! As one example, I offer the splash screen of Pinball Fx2, an app with which I spent far too much time over the Christmas holidays:

I would almost venture to say that a great splash screen image is one that makes your users wish the app would load faster–and then, of course, you’re in great shape to use an extended splash screen….

While I was preparing for my Alive with Activity talk at the //Build 2012 conference last October, I was thinking more deeply about the design of the Windows Start screen, live tiles, and why, exactly, the API for live tiles (as well as toast notifications), limits you to using a predefined ‘template’ for a tile’s XML update payload. Put another way, why didn’t Microsoft just allow apps to create whatever kind of tile updates they want to? Why shouldn’t an app developer have complete control over the appearance of their tiles?

The clearest reason, to me, is that the Start screen is the central piece of shared real estate in the whole system. As such, it really begs for a sense of unity across the whole experience, and works best when there is consistency between the tile updates that are happening for all the apps involved.

With this in mind, I’ve been reflecting on the Start screen experience as it relates to the three ‘qualities’ of energy, known in the Bhagavad-Gita and other Vedic teachings of ancient India as the ‘gunas.’ These qualities are something that one of the best-known modern masters, Paramhansa Yogananda, drew from extensively in his teachings. For example, one of his early writings, Psychological Chart (1925), identified many different psychological qualities as expressing one or more of the gunas.

The three qualities or gunas, as explained in Yogananda’s Autobiography of a Yogi, are tamas (obstruction, inertia, ignorance), rajas (activity), and sattva (elevating or expansive, sometimes written sattwa). These provide a way of understanding the predominant nature of human beings, and is, in fact, at the core of the Living Wisdom School attended by my son (a system that is explained in the book Education for Life, written by J. Donald Walters, himself a direct disciple of Yogananda).

Human psychology aside, my point in this post is to think about the ways that the start screen of an operating system can be designed, and how they related to these qualities.

One design is something we all know very well: a screen full of static icons, perhaps with a pretty picture in the background. Yes, this design has been around for 20 years or so now (can you say Windows 95), and while it works and can look beautiful, it’s actually quite lifeless. In many ways, then, this design can represent some elevating qualities (sattva) but by its static nature—if not its age!—represents inertia (tamas).

Another design would be to give apps a space on a start screen in which they can do anything they want—any kind of text and image content, perhaps video and audio, whatever kinds of animations they might choose, and so on. Certainly this is a step above the static, tamasic kind of experience, but the result is un-unified, undirected, and chaotic. This is rajas at its best, like when you’re busy and active just for the sake of being busy and active. Such activity helps remind you that you’re not dead, but isn’t particularly elevating in the sense that you derive any true joy or happiness from it. Indeed, what lies at the end of this road is exhaustion and a collapse back to the tamasic state. Put another way, if you designed a start screen like this and (hopefully) allowed users to turn off the noise, it’s likely that they’ll turn it off rather quickly, especially if multiple apps wanted to play audio and video simultaneously!

A third design is to allow for some activity, but in such a way that there is that sense of unification, coherency, and beauty without letting things get out of hand. This is both rajas and sattva working together—an activating+elevating experience.

And this is exactly what I think the Windows Start screen, through the tile update templates, achieves. There is activity, certainly (and still something that users can control), but that activity is coordinated such that tile animations and the update cycle happen in a way that’s actually enjoyable to look at, rather than an eyesore.

If you haven’t been on your Start screen for a bit, assuming you’ve been reading this post, hit the Windows key and watch what happens. When you first land on the Start screen, there’s a moment of rest where everything is quiet. Then a number of tiles will update more-or-less together (but a bit in a sequence too), and then everything gets quiet again. After a time, a few tiles will again update or animate, and then a period of rest.

It’s this coordination between the app tiles, combined with the period of quiet and rest, that makes the Start screen alive with activity, but not busy with activity. And as apps draw their tile updates from a choice of available templates, every update has a relationship with the others that also reinforces this sense of unity.

Personally, I think it’s a brilliant solution.

New projects created from Visual Studio templates contain default tile, splash screen, and store logo images that just contain an X in a box. These are designed to be so ugly that you feel utterly compelled to replace them.

Unfortunately, some developers forget to do this. Until recently, these weren’t actually checked by the Store certification process, thus we see some apps in the Windows Store that still contain the default Store logo:

The particular challenge with the Store logo (that’s referenced on the manifest editor’s Packaging tab and not the Application UI tab) is that you never see that graphic in the running app. It appears only in the Store after you’re onboarded the app, which is why we see some of them make it into the Store.

Fortunately, the Store certification process (and a version of the Windows App Certification Kit from November 2012 or later), will fail you if you’re still using the default images.

Save yourself the trouble, then, by making sure to double-check your square tile, wide tile, splash screen, and store logo graphics before uploading to the Store.

While you’re at it, be sure to give your app a more interesting background color than the default gray. Such things are so simple to change and make a huge difference in your Store presence.

This is something we saw with a number of early partners. In the app manifest, in the Application UI section of Visual Studio’s editor, there’s an option called Show name with a variety of options:

By default, this is set to “All logos” meaning that the value in the “Display name” field (also on the Application UI section), or the value in the “Short name” field, if given,  will appear on the lower left of a tile as shown here:

As you can see here, the display name/short name text is redundant with the app name that’s already on the tile. To remove it, select one of the other options in the Show name drop-down.

It’s a good thing to double-check before submitting an app to the Store. Having a name show on a tile when the graphic shows a name too won’t cause the app to fail certification, but it does look a little silly.

When you support live tiles, there are situations where you do want the name or a badge logo to appear on the tile, even though you don’t show the name for the default tile. For these purposes, use the branding attribute in the tile update XML. See Chapter 13 of Programming Windows 8 Apps with HTML, CSS, and JavaScript, in the “Branding” section (page 585) for details.