This post has been written by the TAppEx and CMCO teams, in collaboration with Windows AppConsult
Below are common Desktop Bridge Microsoft Store Policy failures. By familiarizing yourself with these policies and making any necessary changes to your app, you can help ensure that your app gets into the Store in a timely manner. We've also dedicated a section to recommendations and suggested Windows features that may improve the overall experience of your app. While the issues listed in this second section are not Policy failures, addressing them may improve the overall quality of your app on our platform.
Common Microsoft Store Policy failures for Desktop Bridge applications
Privacy policy
If your app accesses, collects or transmits personal information, or if otherwise required by law, you must maintain a privacy policy. For Desktop Bridge applications in particular this includes importing or accessing files using the file explorer. The privacy policy can be set in the Store Listing step of the submission process in the field called Privacy Policy URL . It must include the URL of a page of your website which describes the usage you make of the personal data collected (if any) by your application.
The field where to set the privacy policy URL during the application’s submission on the Dev Center
Privacy Policy links show up in the Product Description Page (PDP), they are required for apps that access, collect or transmit personal information
Security
All of your apps, modules and in-app products must be installed, serviced and updated only through the Store. Do not direct users to update the app via a link to a website or other non-Store update mechanism.
Directing users to app updates outside of the Store is not allowed
Be sure to remove any links to executables. For example, you should not link to an app that is available from the publisher’s website (and not the Store). Linking to the publisher’s other apps in the Store is encouraged!
Links to executables are not allowed
Testing on Windows 10 S
Ensure your Desktop Bridge app supports this special version of Windows 10. Note that on Windows 10 S it may not be possible for users to download external dependencies like Java or Silverlight if they aren’t already embedded in the application. If your app has any dependencies that aren’t embedded, work with your Microsoft point of contact to find out the best way to proceed.
Guidance
- Porting and testing your classic desktop applications on Windows 10 S with the Desktop Bridge https://blogs.msdn.microsoft.com/appconsult/2017/06/15/porting-and-testing-your-classic-deskto...
- Handling Visual C++ dependencies in a Desktop Bridge app in the Fall Creators Update https://blogs.msdn.microsoft.com/appconsult/2017/10/30/handling-visual-c-dependencies-in-a-des...
Embed any necessary dependencies directly inside the package to avoid error messages on launch
Purchase & Trials
You must provide in-app information about the types of add-ons purchases offered and the range of prices. You may not mislead customers about the nature of your in-app promotions and offerings. In addition, your app must make it clear to users that they are initiating a purchase option in the app. It is acceptable to put a free trial of your application in the Store. Trial applications must identify themselves as such in the description. Users must be redirected to the Store if they want to upgrade to the full version. They cannot be directed to a website or asked for an activation code to unlock the full version. Be sure the paid versions of your application are the full versions and are not directing users to the trial version instead. If the pre-conversion version of your application requires a license that can expire, ensure that it won’t for the Store version.
Users cannot be directed to a website or asked for an activation code to unlock the full version. Ensure your package does not require any licenses that can expire.
The same guidance applies to paid add-ons. You must use the Microsoft Store APIs to sell digital items or services that are consumed or used within your app. Your app may enable users to consume previously purchased digital content or services, but must not direct users to a purchase mechanism other than the Microsoft Store APIs.
Guidance
- Enable in-app product purchases for Desktop Bridge converted desktop applications: https://blogs.msdn.microsoft.com/appconsult/2017/09/12/enable-in-app-product-purchases-for-des...
- In-app purchases and trials: https://docs.microsoft.com/en-us/windows/uwp/monetize/in-app-purchases-and-trials
Elevated permissions
Elevated permissions (at runtime or startup) are not permitted in the Store. This includes offering added functionality by use of elevated permissions. The user has the option to launch your application with elevated priviliges, but the set of available features must be the same regardless of the way the application has been launched.
Apps cannot make use of elevated permissions
System requirements
The app must run on devices that are compatible with the software, hardware and screen resolution requirements specified by the application. Hardware requirements for input, memory, processor, graphics and others should be enumerated in the System Requirements field of the Store. If touch is not supported for example, be sure to indicate this in the system requirements on the Store page.
List any hardware requirements (including keyboard and mouse if touch is not supported, memory, processor, graphics) in the System Requirements of the Product Description Page.
Resolution and scaling
Your app must be fully functional and must provide appropriate functionality for each targeted device family. We sometimes see this policy fail on Desktop Bridge apps in relation to resolution and scaling. Depending on the device and native resolution some users may be using a higher display scaling, this is particularly true at resolutions higher than 1920x1080 or on tablets. It is a good idea to view your device at common resolutions and scaling values, particularly scaling values higher than 125%. Issues can range from obvious interface truncation which renders the application unusable to less noticeable inaccessible, very small, or offset buttons and touch targets. Note that only applications that are unusable due to resolution/scaling issues would fail Store Policy.
Guidance
- High-DPI Scaling Improvements for Desktop Applications in the Windows 10 Creators Update https://blogs.windows.com/buildingapps/2017/04/04/high-dpi-scaling-improvements-desktop-applic...
- Testing application on various screen resolutions https://blogs.msdn.microsoft.com/appconsult/2017/08/18/testing-multiple-resolution/
Interface truncation due to scaling issues is acceptable as long as it does not render the application unusable. It is still recommended to address these issues for an ideal user experience.
The appearance of small buttons and text due to scaling issues is acceptable as long as it does not render the application unusable. It is still recommended to address these issues for an ideal user experience.
Application Title
Your app and its associated metadata must accurately and clearly reflect the source, functionality, and features of your app. Be sure that the title of your application in the Store matches the title in the Windows App List. Developer names or package family names can sometimes populate in the App List.
Guidance
- Preparing a Desktop Bridge application for the Store submission https://blogs.msdn.microsoft.com/appconsult/2017/09/25/preparing-a-desktop-bridge-application-...
Be sure that the title of your application in the Store matches the title in the Windows App List
Application Identity
To publish a UWP application on the Store you must be sure that the package identity and publisher set in the manifest match the values that the Dev Center has assigned to your application when you have reserved the name. If for a native UWP app, typically, this isn’t a big issue thanks to the package generation performed by Visual Studio, which includes a wizard to select the right identity from your developer account, it may not be the case for a Desktop Bridge app. It’s likely, in fact, that if you have packaged your application without using Visual Studio but other tools like the Desktop App Converter, the manifest of your package contains a set of test values. In this case, you will be blocked while uploading your package during the submission because the package identity doesn’t match the one assigned by the Dev Center.
To get the right identity you need to go the Dev Center, choose your application and, from the menu, select App management -> App identity. Make sure that the values reported in the page match the information you have in the manifest file.
You can follow the article reported in the Guidance section for a step-by-step tutorial.
Guidance
- Preparing a Desktop Bridge application for the Store submission https://blogs.msdn.microsoft.com/appconsult/2017/09/25/preparing-a-desktop-bridge-application-...
Approval by Microsoft
All Desktop Bridge apps must be specifically approved by Microsoft. If you try to submit a Desktop Bridge application to the Dev Center without being approved you will get the following errors:
Package acceptance validation error: You don't have permissions to specify the following namespaces in the appx manifest file of the package <name of the package>.appx: http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities
Package acceptance validation error: Your developer account doesn’t have permission to submit apps converted with the Desktop Bridge at this time. https://aka.ms/desktopbridgeforwindowsstore
The approval process is per application, not developer, so if you want to submit more than one Desktop Bridge app be sure to work with your point of contact in Microsoft to obtain approval for each app. If you don’t yet have a point of contact, submit your information here: https://developer.microsoft.com/en-us/windows/projects/campaigns/desktop-bridge to request approval.
Other suggested guidance for Desktop Bridge applications
Writing to install directory
If while testing your application it crashes immediately on start-up check the Event Logs for more details both Windows Logs/Application and Applications and Services/Microsoft/Windows/Apps/Microsoft-Windows-TWinUI/Operational. Desktop Bridge Applications are not permitted to write to their install directory, but they can write to any non-system protected folder. If your application is attempting to write logs or configuration files, a simple work-around may be to set your working directory to the AppData folder.
Guidance
- Prepare to package an app (Desktop Bridge) https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare
- Handling data in a converted desktop app with the Desktop Bridge https://blogs.msdn.microsoft.com/appconsult/2017/03/06/handling-data-in-a-converted-desktop-ap...
- Accessing to the files in the installation folder in a Desktop Bridge application https://blogs.msdn.microsoft.com/appconsult/2017/06/23/accessing-to-the-files-in-the-installat...
Unicode and Double-byte characters
Be aware that users may use double-byte/Unicode characters in their Windows username (for example, Chinese or Japanese users). If your application uses the Users folder in Windows to save data you may run into issues, such as crashes or the inability to save.
Guidance
- Unicode and Character Sets: http://www.joelonsoftware.com/articles/Unicode.html
- Unicode in C and C++: http://www.cprogramming.com/tutorial/unicode.html
Users may use double-byte/Unicode characters in their Windows username, which may cause issues if your application uses the Users folder in Windows to save data.
File extensions
Verify that your application functions properly if it uses pre-existing or custom file extensions. The application should appear in the list of applications that the file can be opened with. Your application may support opening files in-app, but outside of the application more work may need to be done. Be on the lookout for blank icons when the application is set as the default program for file types.
Guidance
If your app uses pre-existing or custom file extensions, it should appear in the list of applications that the file can be opened with.
Be on the lookout for blank icons when the application is set as the default program for file types
Empower your application with the Universal Windows Platform
To make your application even more appealing think about implementing UWP feature s such as live tiles, notifications, background music controls, Cortana, IAP, or a true responsive design for various window sizes or resolutions.
- Live tiles and toast notifications - https://docs.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-badges-notifications ...
- Push Notifications - https://docs.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-and-notifications-win...
- Windows Ink - https://docs.microsoft.com/en-us/windows/uwp/input-and-devices/pen-and-stylus-interactions ...
- Background Audio - https://docs.microsoft.com/en-us/windows/uwp/audio-video-camera/background-audio
- Background tasks - https://docs.microsoft.com/en-us/windows/uwp/launch-resume/support-your-app-with-background-ta...
- Create and Consume App Services - https://docs.microsoft.com/en-us/windows/uwp/launch-resume/how-to-create-and-consume-an-app-se...
- Add voice and Cortana interactions - https://docs.microsoft.com/en-us/windows/uwp/input-and-devices/cortana-interactions
- Windows Hello https://docs.microsoft.com/en-us/windows/uwp/security/microsoft-passport