Resizable windows give users more control over how they use your app. New features let you do more with your app’s tile. And updates to search, share, and charms create a more consistent general experience for users.

New or updated in Windows 8.1

Resizable windows

[Get the Application views, Multiple views, and Projection manager samples now.]

Windows 8.1 brings several changes to window size and position. As you develop apps for Windows 8.1, here are the main points to keep in mind:

  • Windows 8.1 does not have fixed-width view states. Users can now resize apps continuously down to a minimum width. (The default minimum width of an app is 500 pixels.) So apps no longer have the snapped and fill view states. Instead, you develop your app to be functional and good looking at any size down to the minimum.

    Note  The snapped view in Windows 8 had a width of 320 pixels. The default minimum width of 500 pixels is larger than the Windows 8 snapped view.
  • If your app works well at smaller sizes and you want to encourage users to keep your app on the screen, you can change the minimum width to 320 pixels.

  • Users can have more than two apps on the screen at the same time. So your app might appear between two other apps and not adjacent to either the left or right edge of the screen.

  • A single app can open more than one window at the same time.

  • An app can launch another app. When this happens, the two apps typically split the screen evenly if there's enough space. But you can change this so that the launched app is wider or narrower than the original app, or so that it even replaces the original app on the screen. To change the default behavior, use the DesiredRemainingView property.

Apps must fill the height of the screen, just like in Windows 8. The minimum height of an app is 768 pixels.

Pixel requirements for narrow minimum size and default minimum size of an app

Design guidelines for resizable windows

When you design an app for Windows 8.1, you have to:

  • Make sure your app layout and controls scale down to the minimum size. In particular, think about how your app's size impacts these controls:

  • Design your app to use the space on a large screen effectively, and with a layout that reflows automatically. Don't leave large empty spaces.

  • If you change the minimum width to 320 pixels, have your app adjust in these ways when its width is narrow (that is, between 320 and 500 pixels wide):

Additional layout samples are available for windows that resize to 320 pixel width and windows that are taller than wide. For more info about using the charms for an app regardless of the app's size, see Charms work on every screen.

Setting the minimum width

If you want to change the minimum width of an app from the default of 500 pixels, you specify the MinWidth attribute of the ApplicationView element in the app manifest.

      <ApplicationView MinWidth=”width320” />

For more info about the app manifest, see App package manifest.

Updates to the ApplicationView class

In Windows 8.1, the Windows.UI.ViewManagement namespace has these new enumerations:

And the ApplicationView class has these new properties:

ApplicationView also has these new methods:

In Windows 8.1, these members are deprecated:

Tile updates

[Get the App tiles and badges and Secondary tiles samples now.]

Windows 8.1 introduces these changes to tiles and the ways you work with them.

New tile sizes

In Windows 8 there were two tile sizes:

  • Square tiles (150×150 pixels at the 1x scaling plateau).
  • Wide tiles (310×150 at the 1x plateau)

In Windows 8.1, there are two additional tile sizes:

  • Small tiles (70×70 at the 1x plateau)
  • Large tiles (310×310 at the 1x plateau)

Because three of the four template types are now square, the tiles that used to be called "square" tiles in Windows 8 (150×150 at the 1x plateau) are now called "medium" tiles. The entire set then is small, medium, wide, and large. Here are examples of all four.

An example of all four tile sizes on the Start screen

A user can fit four small tiles in the place of one medium tile. Small tiles do not support live tile notifications, but they do support badges. A large tile takes the same amount of space as two wide tiles, and supports live tile notifications just like the Windows 8 tile sizes.

New naming conventions for tile templates

With the addition of the new tile sizes, we've updated the Windows 8 naming convention for tile templates. The new convention uses absolute pixel sizes at the 1× scaling plateau. The four tile sizes are mapped to the new names as follows, with many templates in each category:

  • Small = Square70x70
  • Medium = Square150x150
  • Wide = Wide310x150
  • Large = Square310x310

Similarly, the SmallLogo attribute is now called the Square30x30Logo in the app manifest.

Under the new naming conventions, all of the existing tile templates have been renamed.

Old nameNew nameExample
TileSquare*TileSquare150x150*TileSquareImage (old name) / TileSquare150x150Image (new name)
TileWidexxxTileWide310x150xxxTileWideImageAndText01 (old name) / TileWide310x150ImageAndText01 (new name)


For compatibility, the older names are still recognized. But use the new names in any new development you do.

Tile-related changes in the app manifest

You declare the default properties of your primary app tile—the sizes it supports, the display name, and the tile color—in the app manifest.

Opting in to new tile sizes

In Windows 8, you opted in to supporting a wide tile for your app by specifying a wide tile asset in the app manifest. In Windows 8.1, you opt in to supporting a large (Square310x310) tile by specifying a large tile asset in the manifest.

Note  Your app can support a large tile only if it also supports a wide tile.

All apps support medium (Square150x150) and small (Square70x70) tiles. Again, you can provide small tile assets in the manifest. If your app does not provide a small tile image, either by doing its own scaling work or by providing a separate asset, Windows 8.1 automatically scales down your medium tile image.

As in Windows 8, we recommend that, for each tile size you support, you supply separate assets for each of the four scaling plateaus (0.8x, 1x, 1.4x, and 1.8x). This ensures that your tiles always appear crisp and without any scaling artifacts. Also, for better accessibility support, you can provide image assets for the high-contrast theme.

Displaying the app name for different tile sizes

In Windows 8, you used the app manifest to specify which tile sizes displayed your app's name. You still do this in Windows 8.1, but there's a new formatfor it. And note that you can't show the app name on the small (Square70x70) tile size.

Declaring a default pinning size

In Windows 8, if an app supported a wide tile, it was pinned to Start as a wide tile; otherwise, it was pinned as a medium tile. In Windows 8.1, you can optionally override this and declare either the medium or wide tile (but not the small or large tile) to be the default pinning size. But don't forget that, in Windows 8.1, your app is not automatically pinned to Start on installation. It appears in the All Apps view, and from there the user must explicitly choose to pin your app to Start.

Changes to the app manifest schema

Now you specify an additional namespace, "http://schemas.microsoft.com/appx/2013/manifest", in your manifest, to include the schema elements that declare the new functionality we've been talking about. The following example shows you some of the new and renamed attributes that you'll see in your manifest. Note the large tile asset included under the DefaultTile element, which also explicitly declares a preferred default size. The app also opts to show its app name on only the medium and wide tiles and not the large tile.


    DisplayName="Your app name" 
    Description="App description" 
            <wb:ShowOn Tile="square150x150Logo"/>
            <wb:ShowOn Tile="wide310x150Logo"/> 
    <wb:SplashScreen Image="Assets\SplashScreen.png"/>

Changes to tile notifications

When you send a tile notification, remember that your app could receive the notification while running on either Windows 8.1 or Windows 8. Because the new names for existing templates are recognized only by Windows 8.1, the schema has added a fallback attribute. By including the fallback attribute, your notification payload can specify a Windows 8.1 template along with a Windows 8 template, in case the notification is received on a Windows 8 system. To use the new template names and the fallback attribute, include the new version attribute, set to a value of 2, in the visual element as shown here.

  <visual version="2">
    <binding template="TileSquare150x150Image" fallback="TileSquareImage" branding="None">
      <image id="1" src="Assets/Images/w6.png"/>
    <binding template="TileWide310x150Image" fallback="TileWideImage" branding="None">
      <image id="1" src="Assets/Images/sq5.png"/>
    <binding template="TileSquare310x310Image" branding="None">
      <image id="1" src="Assets/Images/sq6.png"/>

Note that you can't use the fallback attribute with large tiles because they didn't exist in Windows 8.Windows 8 notifications work just fine on Windows 8.1 without any alteration, but they aren't able to use the large tile size.

Note  Any large (Square310x310) tile template included in your payload must be the last binding listed. A Windows 8 system stops parsing a notification if it finds a binding that it doesn't recognize through either the template or fallback name. So it will always stop when it encounters a 310×310 binding.

Specifying tile sizes for the notification queue

In Windows 8, when you enabled the notification queue, it was enabled for both medium and wide tiles. Windows 8.1 adds methods to the TileUpdater class that let you enable the notification queue for specific tile sizes.

New tile sizes and alternate logos in secondary tiles

In Windows 8.1, the flyout that users see when they pin content as a secondary tile allows them to page through and choose from all of the secondary tile's available sizes and looks. The secondary tile can support any tile size that is supported by its app tile. If you don't specify a specific small tile image for the secondary tile, Windows 8.1 scales down the square tile image and uses that.

In addition to the default secondary tile image, you can provide up to three alternate versions for each tile size, for a possible maximum of 12 versions. You can also specify, using the AlternateVisualElements method, an alternate small logo for each of the three tile sizes (square, wide, large) that support logos.

More accurate phonetic-string support for ordering secondary tiles

In certain character-based languages such as Japanese, the sort order in the UI is based on a phonetic spelling of the characters that make up the app's display name. This phonetic spelling is a separate string from the display name. When pinning a secondary tile, users can specify a display name for that tile in the pinning flyout but they cannot specify a phonetic spelling. Windows makes a guess as to the phonetic string, but it's not always right.

Apps sometimes know the right phonetic string, though, because the user has defined it through a custom control that the app provides. In Windows 8.1, an app can then pass that string to Windows through the new SecondaryTile.PhoneticName property. Note that this phonetic name string is tied to the default display name associated with the secondary tile. So if the user changes the display name through the pinning flyout, the system's guess for the phonetic spelling is used instead.

Search updates

[Get the SearchBox control sample now.]

Windows 8.1 introduces a new search-box control to help you provide search results: Windows.UI.Xaml.Controls.SearchBox for apps using XAML and WinJS.UI.SearchBox for apps using JavaScript.

Your apps now can include the search box as an element in your markup. The new control supports full templating and styling.

In Windows 8.1, the app search experience is controlled completely by your apps. The search box integrates with the Search contract to power the experience and enable deep customization, so your apps offer experiences that are crafted to user needs.

The search box supports app-supplied search suggestions and results, app-specific search history, and full support for touch, keyboard, and mouse interactions.

The search box layout looks like this.

The in-app search box control for Windows Store apps

Here are example search results displayed in the search box control.

Example search box results for MSFT.

The search box control supports input method editor (IME) integration.

In-app search control with IME.

Suggestions are updated as the user types each letter with an IME. Suggestions include ideographic Chinese characters based on partial phonetic input. The IME Candidate UI doesn't obscure the search suggestions flyout. The search box supports using keyboard input to navigate the text box, the IME candidate list, and the search suggestions.

Share updates

[Get the Sharing content source and Sharing content target samples now.]

Windows 8.1 brings these changes to the sharing experience and the way you use the Share contract in your apps.

Adding new data formats to DataPackage

In Windows 8.1, source apps for the Share contract can provide multiple ways to get back to the content being shared. Windows 8.1 splits the Uri format into two new data formats in DataPackage and introduces four new strongly-typed properties in DataPackagePropertySet. For DataPackage, the Uri format is deprecated and replaced with the WebLink and ApplicationLink formats.

WebLink is shared when the user has selected nothing, so the source app is sharing an implicit selection of the displayed content. By populating this format, the source app shares the content of the current page as a Uniform Resource Identifier (URI). The shared link references the webpage that the user is viewing, so this format always begins with http or https.

ApplicationLink is also shared when the user has selected nothing, so again the source app is sharing an implicit selection of the displayed content. By populating this format, the source app shares the content of the current page as a URI. The shared URI has a scheme that's handled by the source app. When the source app is activated with this URI protocol, it displays the same content they are currently viewing. This format represents the shared content by providing a way to return to the content by using an app protocol.

The WebLink and ApplicationLink formats are not exclusive. WebLink links to the content on the web and ApplicationLink links to the content in an app. For example, a news reader app may have content in both forms, with a URI to bring the user back to the article in the app or to bring the user to the same article on a web site. The target app chooses how to handle the URI. For example, the Mail app might use the WebLink format, because the link can be sent to the Internet and consumed from a non-Windows system. But the reader app might use the ApplicationLink format, so it reactivates the source app and brings the user back to the original content.

ContentSourceWebLink is a companion property that you use to attribute the shared content. It's shared when the app provides a web link to the content that's being shared. When the user makes an explicit selection, the WebLink format isn't populated because the value for the WebLink format isn't the same as the user’s selection. Populating this info doesn't mean that the web page is the user's selection; it just means that the content comes from there.

ContentSourceApplicationLink is the second companion property that you use to attribute the shared content. It's shared when the app finds it meaningful for the user to return to the content that's currently displayed in the app. When the user makes a selection, the ApplicationLink format isn't populated because the value for the ApplicationLink format in this case isn't the same as the user's selection. Populating this info doesn't mean that the deep link into the app represents the user's selection; it just means that the content comes from there.

For example, a user is in a reader app looking at an article. The user selects a quotation and shares it to OneNote. To attribute the quotation to the article, the reader app doesn't use the WebLink or ApplicationLink format, because the article isn't equivalent to the quotation being shared. So instead, the app uses the ContentSourceWebLink and ContentSourceApplicationLink properties. OneNote adds the selected text along with the source attribution. Later in OneNote, the user can read the quote and can get back to the reader app or web page to read the surrounding context of the quote.

Improving share responsiveness

In Windows 8.1, your apps that use the Share contract can improve responsiveness by dismissing the share pane programmatically.

Call the new DismissUI method to close the Share pane. Calling DismissUI is similar to the user dismissing the Share pane by tapping outside it. If the share operation takes a long time, the app continues to run. If the operation isn't long-running, it has 10 seconds to run before being terminated.

The target app can't currently move itself off the screen. So when a share operation starts, the app typically shows a progress indicator and has the user wait until the operation is complete (even though no more user interaction is necessary to complete the operation). Although it's actually safe for the user to dismiss the flyout with a light tap, users tend to think that dismissal before the share operation is complete could cause a loss of data, and so they're not inclined to do so. DismissUI lets your app dismiss the flyout automatically.

Package family name

In Windows 8.1, source apps for the Share contract can provide a Package Family Name to target apps, so that target apps can provide a fallback experience when launching the app specified by ApplicationLink.

The Package Family Name is the unique identifier of an app package. When a source app gives this identifier to the target app, the target app can provide a fallback experience by calling the LaunchUriAsync method with the provided ApplicationLink. If the URI’s scheme is not handled, for example, because the user uninstalled the app, or if the URI is roamed to another device that doesn't have the app installed, a dialog box tells the user to look for an app in the Windows Store. The user is taken to the Store by default, but not to the required app. If you include the Package Family Name in the LauncherOptions object that is passed to LaunchUriAsync, the user is prompted about the specific app to install and is taken to that app's listing page in the Store.

Uri format has been deprecated

As was mentioned earlier, Windows 8.1 splits the Uri format into two new data formats in DataPackage and introduces four new, strongly typed properties in DataPackagePropertySet. For DataPackage, the Uri format is deprecated and replaced with the WebLink and ApplicationLink formats. The Uri format remains as an alias for the WebLink format.

Charms work on every screen

In Windows 8, when there were multiple apps on the screen and the user invoked charms, the system displayed charms for whichever app occupied the most screen space. In Windows 8.1, the system displays charms for the last app that the user interacted with, regardless of how many apps are on the screen or whether there are multiple screens. For example, if the user selects the Settings charm, the system displays the Settings flyout for the last app that was used.

Design your app so that it works with the charms regardless of the size of the app. In particular, the width of the Settings flyout must be less than or equal to the current width of your app.

Build apps that integrate with people and events

[Get the Contact manager API, Appointments API, and Handling Contact Actions samples now.]

Windows 8.1 lets you bring the power of people and events into your app. You can let users of your app look up info about people they know from within your app, and engage with people by integrating communication experiences such as messaging, email, call, video-call, and so on. You can also keep users in your app by letting them quickly view their calendar availability and add events to their preferred calendar.

Use these new APIs to enable your app to view people contact cards and manage events from your app:

  • ShowContactCard method

    Enables apps to query the operating system for a user’s contact and show user’s contact data in a contact card.

  • AppointmentsProvider namespace

    Supports add appointment, replace appointment, and remove appointment requests through activations that an appointments provider interacts with.

  • AppointmentManager class

    Enables apps to interact with the user’s appointments provider to add, replace, and remove events. Also, shows the primary UI for the appointments provider.

  • Activation namespace

    Enables an app to handle the activation parameters for the new appointments provider and contact contracts, supported by Windows.

Speech synthesis

[Get the Speech synthesis sample now.]

Windows 8.1 introduces the Windows.Media.SpeechSynthesis API, which supports speech synthesis—also known as text-to-speech (TTS)— in Windows Store apps.

Use speech synthesis to prompt a user for input, highlight app notifications and message dialogs, provide instructions (such as turn-by-turn navigation), and read content like text or email messages, RSS feeds, books, and search results.

Windows 8.1 includes a number of speech-synthesis engines, known as voices. Each voice has a friendly name, such as Microsoft David (en-US, male), Microsoft Zira (en-US, female), and Microsoft Hazel (en-UK, female), that can be specified in your app and also selected from the Language control panel by a user.

The speech-synthesis capabilities supported by Windows 8.1 enable:

  • Setting the speech synthesizer to a specific gender, voice, and language.

  • Generating speech output from a plain text string using the default characteristics and properties of the current voice.

  • Generating speech output from a string containing Speech Synthesis Markup Language (SSML) to customize voice characteristics, pronunciation, volume, pitch, rate or speed, emphasis, and so on.

  • Reading and writing audio data generated by the speech-synthesis engine to and from a random-access stream.

Generating speech from plain text

This example shows how a Windows Store app uses a SpeechSynthesizer object to create an audio stream and then generate speech based on a plain text string.

// The object for controlling and playing audio.
var audio = new Audio();

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from plain text.
synth.synthesizeTextToStreamAsync("hello World").then(function (markersStream) {

    // Convert the stream to a URL Blob.
    var blob = MSApp.createBlobFromRandomAccessStream(markersStream.ContentType, markersStream);

    // Send the Blob to the audio object.
    audio.src = URL.createObjectURL(blob, { oneTimeOnly: true });

Generating speech output from Speech Synthesis Markup Language (SSML)

The next example shows how a Windows Store app uses a SpeechSynthesizer object to create an audio stream and then generate speech based on an SSML text string.

// The string to speak with SSML customizations.
var Ssml = "<speak version='1.0' " +
    "xmlns='http://www.w3.org/2001/10/synthesis' xml:lang='en-US'>" +
    "Hello <prosody contour='(0%,+80Hz) (10%,+80%) (40%,+80Hz)'>World</prosody> " + 
    "<break time='500ms' />" +
    "Goodbye <prosody rate='slow' contour='(0%,+20Hz) (10%,+30%) (40%,+10Hz)'>World</prosody>" +

// The object for controlling and playing audio.
var audio = new Audio();

// The object for controlling the speech-synthesis engine (voice).
var synth = new Windows.Media.SpeechSynthesis.SpeechSynthesizer();

// Generate the audio stream from SSML.

    // Convert the stream to a URL Blob.
    var blob = MSApp.createBlobFromRandomAccessStream(synthesisStream.ContentType, synthesisStream);

    // Send the Blob to the audio object.
    audio.src = URL.createObjectURL(blob, { oneTimeOnly: true });

Updates to background task management

[Get the Background task sample now.]

Windows 8.1 adds several new features for background tasks:

Quiet hours and background tasks

Quiet hours is a new feature in Windows 8.1 which allows the user to designate specific hours of the day when they don't want to be disturbed with notifications. This feature also stops most of the background activity associated with Windows Store apps, preventing disturbance of the user and potentially extending the connected standby lifetime of the device.

When the system enters quiet hours, background tasks are queued and held until the end of quiet hours. Currently running background tasks will be canceled when the system enters quiet hours.

At the end of quiet hours, background tasks are allowed to start back up. Each background task begins again at a random interval before the system exits quiet hours. This ensures that background tasks don’t all wake up at the same time, which would put an unnecessary load on system resources and remote server resources. The system will not trigger notifications until the designated quiet hours exit time.

There are 2 exceptions allowed to quiet hours by default: incoming phone calls arriving from an app supporting the new lock screen call capability, and alarms set by the user in the default designated alarm app. If the app is a lock screen call capable app, and the IncomingCall setting is set to TRUE, the background task will run and the notification will be delivered. Notifications from alarms set by the user in the default designated alarm app will be delivered during quiet hours.

Quiet hours is enabled by default from Midnight to 6 AM, while allowing incoming calls. Users may change those settings or disable quiet hours on the notifications tab in the apps section of Change PC Settings. Quiet hours is available on all systems.

Cancellation of idle tasks

In addition to background task resource constraints, the Windows background task infrastructure detects idle or hung background tasks. A background task is considered idle or hung if it has not utilized its minimum CPU or network resource quota within a minimum amount of time (which varies depending on the state of the system). If an idle or hung background task is detected, it's sent a cancel notification so that it can stop work and close. If the background task does not stop work and close within 5 seconds the app is considered unresponsive and the system terminates it.

In Windows 8.1, avoid getting your app terminated due to an idle or hung background task: always associate a cancellation handler so that it is cleanly cancelled. See details and code snippets in How to handle idle or hung background tasks.

Work cost hint for background task

Windows 8.1 provides a hint to background tasks about resource availability. When a background task is activated, it can use this hint to decide how much work to do. Three background resource states can be reported: Low, Medium, and High. To learn more see BackgroundWorkCost and BackgroundWorkCostValue.

PowerShell cmdlets for background tasks

Developers can use the new AppBackgroundTask powershell commands, and the new BackgroundTasksManager cmdlet designer module, to retrieve info on running background tasks. This can be very helpful when implementing and debugging background tasks. For more info see the PowerShell cmdlets for background tasks.

Alarm app support on the lock screen

[Get the Alarm notifications sample now.]

In Windows 8.1, one of the lock screen slots is now used for alarm apps. Alarm apps use the AlarmApplicationManager class to request permission from the user to be the system alarm app. If the user grants permission (or if the user places the app in that alarm slot by using the control panel) the app takes the slot and becomes the system alarm app. Alarm notifications fired by the system alarm app are then shown to the user with an accuracy of within one second. Only the app in the alarm slot can fire alarm notifications; alarm notifications fired by other apps are treated as normal notifications.

You schedule alarm notifications by creating toast notifications with the commands element. And you use the audio element to specify the alarm sound, which is played when the notification fires even if the system is muted.

Updates to work-item scheduling

The CoreDispatcher (Windows::UI::Core:CoreDispatcher) API now allows you more control over priorities in work-item scheduling.

In Windows 8.1, work-dispatch priorities are now in this order:

  1. SendMessage (Highest priority)
  2. CoreDispatcherPriority.High
  3. CoreDispatcherPriority.Normal (Includes window messages and Component Object Model (COM) calls)
  4. Any device-input messages
  5. CoreDispatcherPriority.Low
  6. CoreDispatcherPriority.Idle (Lowest priority, used for background tasks)
To change task priorities, use these new members on the CoreDispatcher type:
  • CoreDispatcher::ShouldYield method (2 overloads)—Queries whether the caller should yield if there are items in the task queue of the specified priority or higher.

  • CoreDispatcher::CurrentPriority property—Gets or sets the current priority of task that the CoreDispatcher handled most recently. When an app is processing work of a specific priority and higher-priority work comes in, set this property to bump up the priority of the current task so that ShouldYield gives more accurate results.



© 2015 Microsoft