Delivering reliable and trustworthy Metro style apps

As we developed the app model for Windows 8 and the new Metro style apps, a key architectural requirement has been to deliver app to customers that can be used with confidence--confidence that apps will be well-behaved with respect to resources, that apps will not interfere with other apps, that apps use system resources with your permission, that apps can be installed an uninstalled with ease, and so on. These attributes require a robust platform and strong set of tools for developers. This is an effort that requires a fresh start and cannot be retrofitted on an existing system. Windows 8 is a fresh start in this regard. This post details some of the work we have done at the platform level to deliver reliable and trustworthy Metro style apps. This post is authored by John Hazen, a program manager on our Developer Experience team. --Steven​

One of our core principles in the development of the Windows 8 Metro style app platform was to ensure that users would have confidence in their apps. This is a mission we’re in together; in this post, I explain our vision for app confidence and reliability and help you build confidence by design into your apps.
Let me start by explaining what we mean by confidence. Picture a customer browsing the Windows Store looking at a Metro style app; we want them to be thinking only about the app and whether or not it is right for them. We want them to assume—in fact be confident—that the app will behave the way they expect and thus will perform well on their system, will use only the data and information they authorize, and will harmoniously co-exist with their other applications.
Our goal with the platform is to help us all build great apps that embody this vision of confidence so that we get confidence by default. To that end we made investments throughout the system. Here’s how we picture it:

​

App Confidence: Windows 8 SDK for Metro style apps, Windows App Certification Kit, App Signatures,
App Container, Ratings and Reviews, Store Onboarding, Frictionless Install, Telemetry Feedback
This post covers these areas and towards the end goes into depth on our app capabilities. First, a quick overview:

• Windows Store – For customers, it starts with the Store, their one-stop-shop for Metro style apps. To get into the Store your app is reviewed for both technical and policy compliance, including security checks. After it’s published to the Store, your app will be rated and reviewed by the community. Together, the onboarding process and community reviews help create an environment in which customers can try apps with confidence.
• App install – Windows 8 handles all the details of deploying apps on your behalf so your customers don’t have to worry that installing, updating, or removing one app will adversely affect other apps.
• SDK – The Windows 8 SDK for Metro style apps provides a well-defined set of APIs that help you build reliable apps that conform to the Store onboarding requirements and provide the best experiences for your customers.
• App container and capabilities – Windows 8 provides a greater degree of separation between apps than was possible with traditional desktop apps, so you can build apps that interact with each other in more predictable ways, giving customers a more consistent experience.

We of course recognize that any onboarding process can be gamed, API sets can be abused, SDK limits cleverly avoided, and that app containers are not impenetrable. But we are confident that the investments we made in this new ecosystem will help you build apps that delight customers. This multi-dimensional approach is the most effective way to build customer confidence and we will improve each dimension over time as we learn from experience. Now let’s talk about confidence.
The Windows Store

Several folks on the team have shared quite a bit on the Windows Store Blog about the overall design and plan for the Store. If you have not had a chance yet, read about the Store, because it plays a central role in helping you connect with your customers. Let’s look at a few ways in which the Store helps build confidence in the app ecosystem.
First, the Store onboarding process establishes a consistent baseline for app quality and reliability. The technical conformance tests, contained in the Windows App Certification Kit, help you know that you meet the expected standards before you submit your app. As you and other devs continue to deliver apps that meet these standards, customers will be excited to discover and try out new apps, creating a stronger app ecosystem for all of us.
The Store also makes it easy for customers to provide ratings and reviews that will help the best apps stand out, enticing even more customers to try out the top rated apps with confidence. In the sample app listing page below, note the highlights not just for ratings and reviews, but also two other important elements of the app listing page. Prior to installing a new app, customers can see what permissions the app has once it is installed (more detail on this later in the blog). After installing an app if the customer has concerns about app content or behavior, they can easily report their concern and we can follow up with you to address any problems identified. Helping customers decide which apps best meet their needs and allowing customers to provide input and feedback is an important way to improve overall confidence in the Windows 8 app ecosystem.

​

App listing page from the Windows Store
Finally, the Store collects telemetry data that can help you investigate problems your customers see, including the number and types of crashes they suffered. We review this automated telemetry for indications that an app’s behavior is unreliable or inconsistent with the expectations of our customers. Our goal is to make effective use not only of the individual feedback that customers provide on apps through ratings and reviews, but also provide insight into how your app is actually behaving on customers’ machines and give you the opportunity to improve your app based on this data.
In all these ways, the Windows Store is your partner in connecting you with people who want your apps, and helping them have a great experience with your apps.
Apps are just a click away

When you have your customer’s attention on the app listing page, you don’t want anything to get in the way of your customer getting your app. On Windows 8, getting an app is a matter of clicking a single button. Customers no longer have to wade through a series of questions or click button after button. After logging into the Store, when they find something they like, they just click the button, confirm the purchase, and go!
The great news for you is that you don’t have to write a single line of installation code to make this magic happen; it is all provided for you as part of Windows 8. Not only is installation handled, but Windows uses digital signatures to ensure the integrity of your app all the way from the Store to installation and even when the app is loaded and running on your customer’s computer. If Windows detects that the app no longer matches its digital signature, it guides the customer to download a corrected version from the Store.
Because Windows installs each app in a discrete location with separate and private locations for each app’s data and settings, customers don’t have to worry that installing, or removing, one app will interfere with the behavior of other apps or their computer. Customers will be more willing to try more apps than ever before, knowing that installing and removing apps won’t degrade their experience over time (in fact, with Windows 8 contracts, each app you install makes the experience better). You benefit by knowing that there is little another app might do that will damage your customer’s experience of your app.
Having a single, verifiable, and consistent mechanism to install apps not only simplifies your work, it provides an easy and positive experience for your customers, giving them confidence to get even more of your great apps. You can learn more about app deployment in App packages and deployment.
Windows 8 SDK for Metro style apps

The better experience customers have with your apps, the more readily they will try new apps and updates as you release them. The Windows 8 SDK for Metro style apps is a great foundation for you to build apps that customers won’t hesitate to install.
We put a lot of thought into the API set we offer for Metro style apps, not only to simplify the Windows programming environment, but also to provide a well-tested platform on which you could confidently build your apps, knowing they will work well with the Windows 8 Metro style app model.
Resist the temptation to find ways to invoke APIs that are not included in the SDK. This ultimately undermines the expectations that customers have for your app. APIs that are outside the SDK are not guaranteed to work with Metro style apps either in this release or in future releases, so you may find that your app doesn’t function properly for all customers. These APIs may also not function properly in the async environment that is foundational to Metro style app design. Finally these APIs may undermine customer confidence by accessing resources or data that Metro style apps would not normally interact with. For all these reasons, we have provided checks in the Windows App Certification Kit to help you catch places where you might have inadvertently called interfaces not exposed by the SDK.
While it is possible to hide or obfuscate calls to APIs that are not included in the SDK, this is still a violation of customer expectations and Store policy. In the end, we have created this platform to help developers like you to build amazing apps that work well with the system and with other apps and devices to delight customers. Working with the Metro style SDK is fundamental to your realizing that goal.
Working well together and apart

A clean installation process is important to your customers, and the SDK helps you build apps that integrate well with the system. Beyond this, customers expect a high degree of reliability from your app and our platform. We help you achieve your reliability goals by providing a greater degree of separation between Metro style apps than is possible for traditional Windows desktop applications. On Windows 8, each Metro style app runs in the context of a unique app container that helps insulate it and its data from other Metro style apps.
App containers provide a few characteristics that are shared by all Metro style apps. They:

• Provide a dedicated environment for your app, including your own store for data and settings. You have little worry that some other Metro style app will change your app’s data, settings, or behavior.
• Help ensure that your app doesn’t accidently interfere with the reliability of the Windows platform itself, or accidently use your customers’ data or devices in ways they don’t expect.
• Provide a well-defined way to extend the capabilities of your app through declarations you make in the manifest and disclose to your customer in the app listing page.

Having this degree of separation makes it far easier to write apps that are reliable and respectful of the user. At the same time, we all want apps that interact well with one another. Windows 8 provides several mechanisms for Metro style apps to work with each other and with the platform to provide these satisfying experiences, including:

• App contracts, which are the glue that binds Metro style apps together and to the system UI.
• The FilePicker, which allows your app to interact with data the user selects.
• App capability declarations, which allow your app to programmatically interact with devices and data, when appropriate for your functionality.

These are all well-defined ways for your app to engage more deeply with other apps and the system. The app container exists to help you deliver on your customer’s expectations of reliability and respectful use of their system and data. The constraints of the app container are designed to help realize customers’ expectations for consistent and intuitive app behaviors, and using techniques that allow your app to run code outside of an app container is a violation of user trust and Store policy.
In our discussions with developers during this preview period, we have seen apps that have misunderstood or accidently misused some of these mechanisms, so let’s go into more detail about the app capabilities in particular.
App capability declarations

The app container can be extended in a variety of ways using capability declarations, each of which is designed to enable certain scenarios. Therefore, we recommend that you use them only under certain conditions. These capabilities fall into 4 primary buckets:

• Data libraries: By default, apps have no access to the customer’s data libraries, like the Music library, or the Documents library. We recommend that you use the FilePicker to interact with these libraries, but in some rare cases it is necessary for your app to be able to directly read and manage data in these locations.
• Device access: By default, apps can’t use devices that most users consider sensitive for their privacy, including the webcam, microphone, and location. When apps need these devices, they must both declare their intent, and get consent from the user.
• Network access: By default, apps have no access to the customer’s networks. Because most apps interact with the Internet, we enabled this particular capability in all the Visual Studio templates for Metro style apps. If your app needs more than just simple Internet access, you can read about your options below.
• User identity: These capabilities provide direct access to a particular customer’s corporate logon info, or to certificates associated with their identity. These capabilities, although rarely needed, are necessary for certain enterprise apps, and you might need to use them in scenarios like banking transactions in which a smartcard might be required for authorization.

Declaring a capability in any of these categories is as simple as checking it off in the Visual Studio manifest designer. But add capabilities only if they are critical to realizing a scenario for an app. During the Consumer Preview, we saw several apps submitted to the Store that declared every capability or a capability that was not essential for the app. So, while the list of possible capabilities is relatively short, it is worth reviewing in more detail each of these capabilities and how to use them.

​

Visual Studio's manifest designer
Data libraries

These capabilities grant your app access to user data that wasn’t necessarily created in your app. Users expect apps to be respectful of access to their private data. One way to honor the trust users place in your app is by declaring only the minimum access necessary for your app. In most cases you can avoid using these capabilities entirely by using the FilePicker, through which the user can browse files anywhere on their hard drive or network. For example, use the FilePicker to provide a File open experience, or to add Save as to your app in order to give your user the opportunity to save content from your app into their library locations or to removable storage.
Manifest declaration
What it provides
musicLibrary
Provides the capability to add, change, or delete files in the Music Library for the local PC and HomeGroup PCs.
videoLibrary
Provides the capability to add, change, or delete files in the Videos Library for the local PC and HomeGroup PCs.
pictureLibrary
Provides the capability to add, change, or delete files in the Pictures Library for the local PC and HomeGroup PCs.
documentsLibrary
Provides the capability to add, change, or delete files in the Documents Library for the local PC. The app can only access file types in the Documents Library that are defined using the File Type Associations declaration. The app can't access Document Libraries on HomeGroup PCs.
removableStorage
Provides the capability to add, change, or delete files on removable storage devices. The app can only access file types on removable storage that are defined in the manifest using the File Type Associations declaration. The app can't access removable storage on HomeGroup PCs.
During the Consumer Preview, we saw app submissions that declared these capabilities when they really didn’t need to. For example, apps declared documentsLibrary for a variety of reasons including:

• Storing app-specific settings in the documents library. The private store is designed to provide this function. You can learn more about app settings and storage here.
• Store a user-generated file. This is more properly accomplished using the FilePicker to allow the user to save the file to any location, including the documents library.
• Sharing a document with another app. The Sharing contract is designed for this purpose.

If your app is designed to be the primary handler on the system for a given file type, for example a Fax Viewer that needs to handle all .TIFF files in the user’s documents library, then declare this capability.
Device access

Many devices, like orientation sensors and accelerometers, are available to any app. But most customers consider certain devices more sensitive than others, given that they are strongly associated with user privacy. There are a lot of great apps you can build on these devices. For example, if you have a casual game that allows shared gameplay, using proximity is a great way to establish a connection between devices.
Because these devices are closely coupled to user privacy, Windows 8 ensures that if you declare the capability, the customer will be prompted to approve this access the first time your app tries to access the particular device. For example, if your app offers mapping, you likely want to access the customer’s geolocation data. The first time your app tries to get this info, the customer sees a prompt to approve your app’s access. This approval sticks until the customer decides to explicitly remove the access through Settings at a later time. Because the customer can decline your app’s access to these devices, even if you have added the capability to the manifest, design your app to handle the lack of access gracefully. For example, if the customer has denied your app access to the built in GPS, you could simply prompt the user to select their location from a map.
Manifest declaration
What it provides
location
Provides access to the current location, which is obtained from dedicated hardware like a GPS sensor in the PC or derived from available network information.
webcam
Provides access to the webcam's video feed, which allows the app to capture snapshots and movies from connected webcams.
microphone
Provides access to the microphone's audio feed, which allows the app to record audio from connected microphones.
proximity
Provides the capability to connect to devices in close proximity to the PC via near field proximity radio. Near field proximity may be used to send files or communicate with an app on a nearby device.
Network access

Most apps need an Internet connection, so the Visual Studio templates for Metro style apps include the internetClient capability by default. If your app doesn’t need to communicate over the Internet, you should remove this capability. The internetClientServer capability is generally used in peer-to-peer (P2P) scenarios like gaming or VOIP, but unless your app must open a port in the firewall, don’t use this capability. Use the privateNetworkClientServer capability when your app needs to communicate over private networks, for example between devices within a home, or over a corporate network connection.
Manifest declaration
What it provides
internetClient
Provides outbound access to the Internet and networks in public places like airports and coffee shops. Most apps that require Internet should use this capability.
internetClientServer
Provides inbound and outbound access to the Internet and the networks in Public places like airports and coffee shops. This capability is a superset of internetClient. The internetClient capability doesn't need to be enabled if this capability is also enabled.
privateNetworkClientServer
Provides inbound and outbound access to Intranet networks that have an authenticated domain controller, or that the user has designated as either home or work networks.
User identity

Most developers don’t need these capabilities. Use of these capabilities will be highly restricted and subject to additional onboarding policy and review. But there are cases where such capabilities are necessary and appropriate, for example some banks require two-factor authentication and need to allow customers to provide a smartcard that carries a digital certificate that confirms their identity. Other apps that are designed primarily for enterprise customers rather than consumers might need access to corporate resources that cannot be accesses without domain credentials.
Manifest declaration
What it provides
enterpriseAuthentication
Provides the capability to connect to enterprise intranet resources that require domain credentials.
sharedUserCertificates
Provides the capability to access software and hardware certificates, such as smart card certificates, for validating a user's identity. When related APIs are invoked at runtime, the user must take action (insert card, select certificate, etc.). This capability is not necessary if your app includes a private certificate via a Certificates declaration.
Building confidence
Customers want to safely enjoy Windows 8 and the apps you build. The Metro style app experience is designed to make it easy for you to build apps that everyone can try and buy with confidence. This sets up a constructive cycle where people love and buy lots of apps that then generates opportunities for developers to create and deliver even more great Metro style apps.
As I noted at the beginning, we’re in this together; we are confident that the collective investments we made in this new ecosystem will help you build apps that people will be delighted with, and we look forward to partnering with you in delivering amazing new experiences to our joint customers.
--John Hazen


Continue reading...