Defining your app’s requirements for a great customer experience

One of the things I really enjoy about developing for Windows Phone is being able to reach a diverse audience across the globe. Windows Phone users access my apps on phones from different manufacturers, all with varying capabilities and price points to meet local needs. While I benefit from the diverse audience, it does take a little planning on my part to create a great user experience and to ensure that my apps comply with the Windows Phone technical certification requirements.

In this post I’ll help you identify the phone features and hardware your app requires, and then provide guidance on how define these needs in Visual Studio.

Capabilities and requirements

Windows Phone uses the app manifest file to identify the software capabilities, hardware required, and memory each app requires to run correctly:

• Software capabilities: indicate that an app accesses the phone identity, camera, maps, media libraries, networking, Near-Field Communication (NFC), push notifications, sensors, wallet, web browser, and other software capabilities. Windows Phone grants access to these capabilities, and customers are informed before purchasing the app which capabilities are used.
• Hardware requirements: indicate phone features that the app must have to function correctly. The operating system uses the list to prevent apps from being installed on phones that don’t meet these requirements.
• Functional capabilities: indicate that your app is requesting more memory at run time, if it is available.

Your app must enable the relevant capabilities and hardware requirements

Make sure your app is not marking capabilities and requirements that it doesn’t need. Users see your app’s capabilities and requirements when they install the app, and may decide not to move forward with installation if they see that your app uses capabilities that they don’t want to enable, or that are not related to the purpose of the app.

In a scenario in which your app can provide value even when some hardware is absent, use API checks to first detect the presence of the hardware, and then to inform users if some features are disabled because of missing hardware.

The following steps explain how you can modify support for different Windows Phone capabilities in your app.

Open your project in Visual Studio, go to the Solution Explorer, and then in the Properties folder, open WMAppManifest.xml. Then, add or remove the capabilities as illustrated here:

Add hardware and functional capabilities to the manifest file

If the hardware or functional capabilities you need are not listed in Visual Studio, you must manually edit the manifest file. To do this, first understand all the capabilities available, and then edit the manifest file in a text editor, such as Notepad, or directly in the code. Right-click the file in Solution Explorer, click Open With, and then edit through Notepad or ‘view code’. You turn these on by adding the correct flag:

Here’s an example of the manifest flag that shows the software, hardware, and functional capabilities:

Capabilities required when using the Microsoft Ad Control

If your app uses the Microsoft Ad Control, be sure to enable the following capabilities:

Additional considerations

In some scenarios, capabilities are added automatically. Here are some examples:

• During debugging, when running the app in the Windows Phone Emulator, the Network Capability is set to ‘on’ by default. You should always test your app on a phone instead of on the emulator if your app uses any of the Windows Phone Software or Hardware capabilities, to ensure you are getting correct test results.
• For Windows Phone 8 projects, it is your responsibility to ensure all the correct Software capabilities are identified and added to the manifest file.
• For Windows Phone 7 projects, the submission process looks for software API calls and, if found, will add the Software capabilities to ensure that the app has the correct permissions to run.
• Third-party libraries could make calls to some APIs, for example, to network or sensor APIs.

Having a variety of phones with different price points creates opportunities to reach out to more users. Take the time to set the correct information and get your app ready to be successful on a variety of Windows Phone devices.

How capabilities are displayed to Windows Phone users

The following table shows examples of how capabilities appear to consumers in the web Store and on the phone:

Using the Store Test Kit (for Windows Phone 7 projects)

If your app targets Windows Phone 7.1, you can use the Store Test Kit to verify the capabilities that are being detected, to confirm they align with what you are expecting. The Windows Phone 8.0 SDK includes the Store Test Kit, and the Windows Phone 7 SDK requires you to install a stand-alone tool to run these tests.

Take the following steps to run the Store Test Kit for Windows Phone 7 project:

• INSTALL AND START THE TEST KIT. Install and run the Store Test Kit. In the latest version of the SDK you can open the Store Test Kit directly from within your project: on the Project menu, click Open Store Test Kit.
• RUN THE AUTOMATED TESTS. The Store Test Kit can detect and add software capabilities based on API calls for Windows Phone OS 7.x managed projects (not on native projects or Windows Phone OS 8.0 managed projects). Note   You probably will need to update the test cases the first time you run the Test Kit, because we update them frequently. You can do this easily from the blue alert bar you might see across the bottom of the Test Kit window.
  
  
  Use the Automated Tests tool to identify the capabilities that your app is using. Verify that these are the capabilities your app actually requires.
  

Windows Phone users appreciate having visibility into my app requirements, so that they can make an informed choice about downloading and purchasing your app. In the end, the user gets an app that performs well on their phone, and you get a better review for your apps. Everyone wins.

I’d like to hear from you. Please let me know your questions about defining capabilities, as well as suggestions for topics you’d like me to cover in future blog posts.