This is a subject of much debate as it seems that some applications have a harder time than others passing certification. A good example of this is the issues that Carbon experienced while trying to pass certification and failed several times. We will give it to Carbon though as they were trying to pass certification with Yalla apps instead of Microsoft. Below is a extremely simplified diagram of the steps that are taken once an application has been submitted for approval.


Below, we have compiled the list of policies and requirements from Microsoft that need to be met before an application can be signed and certified.

Application Policies

  • Your application must be fully functional when acquired from Windows Phone Marketplace (except for additional data as permitted below). Unless you have a pre-existing billing relationship with the user, your application may not require the user to provide payment information, within the application experience, to activate, unlock, or extend usage of the application.
  • Your application may not sell, link to, or otherwise promote mobile voice plans.
  • Your application must not jeopardize the security or functionality of (a) Windows Phone devices or (b) Windows Phone Marketplace.
  • If your application includes or displays advertising, the advertising must comply with the Microsoft Advertising Creative Acceptance Policy Guideand the application must have distinct, substantial and legitimate content and purpose other than the display of advertising.
  • If your application requires the download of a large additional data package (e.g. greater than 50 MB) to enable the application to run as described, the application description must disclose the approximate size of the data package and that additional charges may apply depending on connectivity used to acquire data.
  • If your application enables chat, instant messaging, or other person-to-person communication and allows the user to setup or create his or her account or ID from the mobile device, the application must include a mechanism to verify that the user creating the account or ID is at least 13 years old.
  • The following requirements apply to applications that receive the location of a user’s mobile device:
  • Your application must determine location using the Microsoft Location Service API.
  • The privacy policy of your application must inform users about how location data from the Location Service API is used and disclosed and the controls that users have over the use and sharing of location data. This can be hosted within or directly linked from the application.
  • Your application must provide in-application settings that allow the user to enable and disable your application’s access to and use of location from the Location Service API.
  • If your application publishes or makes available location data obtained from the Location Service API to any other service or other person (including advertising networks), your application must implement a method to obtain opt-in consent. To “implement a method to obtain ‘opt-in’ consent,” the application must:
  • (a) first describe how the location information will be used or shared;
  • (b) obtain the user’s express permission before publishing the location information as described; and
  • (c) provide a mechanism through which the user can later opt out of having the location information published. Your application must periodically remind users or provide a visual indicator that location data is being sent to any other service or person.
  • Your application must not override, circumvent, or suppress any Microsoft toast notification or prompts related to the Location Service API.
  • Your application must not override or circumvent a user’s choice to disable location services on the mobile device.
  • Your application must request location and retain and use location data from the Location Service API only as necessary to deliver the location-aware features your application provides to users.
  • You and your application must adopt measures to protect against unauthorized access to, use or disclosure of location data received from the Location Service API.
  • If your application shares a user’s personal information (including, but not limited to Contacts, Photos, Phone number, SMS, Browsing history or unique device or user IDs combined with user information) with third parties such as other services or individuals, the application must implement a method to obtain “opt-in” consent.
  • To “implement a method to obtain ‘opt-in’ consent,” the application must:
  • provide your privacy policy, which at a minimum must describe how the personal information will be used or shared;
  • obtain the user’s express permission before sharing the information as described; and
  • provide a mechanism through which the user can later opt out of having the information shared.
  • If your application uses the Microsoft Push Notification Service, the application and the use of the Microsoft Push Notification Service must comply with the following requirements:
  • The application must first describe the notifications to be provided and obtain the user’s express permission (opt-in), and must provide a mechanism through which the user can opt out of receiving push notifications. All notifications provided using the Microsoft Push Notification Service must be consistent with the description provided to the user and must comply with all applicable Application Policies Content Policies and Additional Requirements for Specific Application Types.
  • The application and its use of the Microsoft Push Notification Service must not excessively use network capacity or bandwidth of the Microsoft Push Notification Service, or otherwise unduly burden a Windows Phone or other Microsoft device or service with excessive push notifications, as determined by Microsoft in its reasonable discretion, and must not harm or interfere with any Microsoft networks or servers or any third party servers or networks connected to the Microsoft Push Notification Service.
  • The Microsoft Push Notification Service may not be used to send notifications that are mission critical or otherwise could affect matters of life or death, including without limitation critical notifications related to a medical device or condition. MICROSOFT EXPRESSLY DISCLAIMS ANY WARRANTIES THAT THE USE OF THE MICROSOFT PUSH NOTIFICATION SERVICE OR DELIVERY OF MICROSOFT PUSH NOTIFICATION SERVICE NOTIFICATIONS WILL BE UNINTERRUPTED, ERROR FREE, OR OTHERWISE GUARANTEED TO OCCUR ON A REAL-TIME BASIS.
  • Your application must have distinct, substantial and legitimate content and purpose. Your application must provide functionality other than launching a webpage.
  • Your application and its associated metadata must accurately represent its functionality, capabilities and features.


Content Policies

Licensed Content, Name, Logo & Trademarks

  • Content and application name are original or licensed.
  • Copyrighted content that is used with permission. Use of branded items (logos/trademarks) has been approved by the brand owners.
  • If an application depicts any mobile or wired telephone, handheld PDA, or any other data and voice communicator, it must be either generic or a Windows Phone device.
  • It is the application provider’s responsibility to determine if the application provider has the right to use the chosen name, content, logos, copyright, trademarks, online services & API’s.

clip_image001Illegal or Contemplates Harm

  • Any content that is illegal under applicable local law, obscene, or indecent.
  • Any content that depicts or encourages harm or violence against a person or animal in the real world.

clip_image001[1]Defamatory, Libelous, Slanderous, and Threatening

  • Any content that is defamatory, libelous, slanderous, or threatening.
  • Any content that facilitates or promotes content prohibited by these guidelines.

clip_image001[2]Hate Speech or Discriminatory

  • Any content that advocates discrimination, hatred, or violence based on considerations of race, ethnicity, national origin, language, gender, age, disability, status as a veteran, religion, sexual orientation or expression, or that promotes organizations devoted to that purpose. Such content can include images or text that perpetuates a negative stereotype of a race, gender, sexual preference or religion. We are particularly inclined to act against content where there is evidence that the intent of posting was to harass, threaten, or insult an individual or group on one of these bases.

clip_image001[3]Alcohol, Tobacco, Weapons, and Drugs

  • Any content that facilitates or promotes, whether directly or indirectly, the illegal (under applicable local law) or excessive sale or use of alcohol or tobacco products, drugs, or weapons is not allowed on any section/site, regardless of targeting.

Adult Related Content

  • Sex / Nudity – Images that are sexually suggestive or provocative (e.g. sexually provocative touching, bondage, masturbation); provocative images that reveal nipples, genitals, buttocks, or pubic hair.
  • Content that a reasonable person would consider to be adult or borderline adult content (images, text, or audio).
  • Content that generally falls under the category of pornography.
  • Content that depicts or suggests prostitution.
  • Content depicting sexual fetishes.
  • Content of a sexual nature depicting children or animals.

clip_image001[4]Certain Types of Illegal Activity

  • Any content that facilitates or promotes illegal gambling, illegal adult content and/or pornography, child pornography, bestiality, piracy, illegal online pharmacies, illegal drugs, or criminal or terrorist activities.
    • Applications that enable legal gambling in the applicable jurisdiction where legal gambling is allowed may be permitted, subject to the Application Provider’s acceptance of additional contract terms.
  • Any content that instructs users how to make bombs or weapons, drugs, or solicits involvement in behavior that is violent or illegal under applicable local law.
  • Unauthorized use of another entity’s intellectual property, including but not limited to: software, music, art, and other copyrighted, trademarked or patented materials or trade secrets.
  • Any content that facilitates or promotes underage drinking, consumption of illegal drugs, or socially irresponsible behavior due to alcohol or drug consumption (e.g., drinking and driving).


  • Realistic or gratuitous violence, including depictions of the following:
    • Decapitation, impaling, blood splatter/blood spurting/blood pooling, or gore
    • Exploding body parts
    • Guns/weapons pointed toward user/audience (e.g., “Russian Roulette” games)
    • Strangulation/choking
    • People or creatures on fire
    • Cruelty to animals
    • Audio of humans or animals suffering
  • Involuntary or physically-resisted sexual interactions with violent or illicit overtones
  • Rape, sexual assault
  • Molestation, physical child abuse
  • Requests or instructions to injure or otherwise harm a real-world person or group of people
  • Glorification of crimes against humanity such as genocide and torture

clip_image001[6]Excessive Profanity

  • Any content with the excessive use of profanity or adult language.

Country/Region Specific Requirements

  • People in revealing clothing or sexually suggestive poses
  • Religious references
  • Alcohol references
  • Sexual or bathroom humor
  • Simulated or actual gambling

Group 1: China

Group 2: Malaysia, Indonesia

Application Submission Requirements

Installation Package Validation

The maximum size of the XAP package file is 225 MB.

The XAP package must contain the following:

· A valid Windows Phone application manifest file, named WMAppManifest.xml. For more information, see the Application Manifest File for Windows Phonetopic.

· The <Title> element in the WMAppManifest.xml file must contain the application title. The <Title> element must not be empty. The Application titleentered in Step 2 of the submission process to Windows Phone Marketplace and the title displayed on the phone must be the same.

For more information about setting the application and tile titles, see How to: Set the Initial Properties for the Application Tile for Windows Phone.

· A valid .NET application manifest file, named AppManifest.xml.

· The assembly files as specified in the AppManifest.xml file.

· The small mobile app tile that you want displayed on the phone app list. Games must use the large mobile app tile in place of the small mobile app tile. The small mobile app tile must be a 62 x 62 pixel PNG file.

· The large mobile app tile that you want displayed when the user pins the application to the quick launch area on the phone Start experience. The large mobile app tile must be a 173 x 173 pixel PNG file.

When you submit the XAP file to Windows Phone Marketplace, the file is decompressed, validated, and repackaged.

Repackaging involves the following steps:

· The Windows Phone application manifest is provisioned with a product identifier for each application.

· The security capabilities are rediscovered and listed in the manifest.

· The phone experience Hub type is set in the Windows Phone manifest (e.g. Music + Videos Hub).

· The Digital Rights Management header file is created and named WMAppPRHeader.xml.

· The original contents of the package, the updated Windows Phone application manifest, and the Digital Rights Management header file are compressed into a new XAP package.

Application Code Validation

· You must develop your application using the documented APIs that are supported on the Windows Phone Application Platform for the OS version that your application is targeting. For more information, see the Class Library Reference for Windows Phonetopic.

· For more information on new and changed APIs for Windows Phone OS 7.1, and information on application compatibility for the two Windows Phone OS versions, see the Windows Phone OS Application Compatibilitysection.

· The application must not invoke native code via PInvoke or COM interoperability. If it does, it will fail the certification process.

· The application must be compiled using retail configuration instead of debug. The application must not contain debugging symbols or output.

· The application must not redistribute the Windows Phone assemblies. However, you can re-distribute panorama, pivot, and map assemblies.

· The application must not call any APIs in the Microsoft.Xna.Framework.Game assembly or the Microsoft.Xna.Framework.Graphics assembly when using any methods from the System.Windows.Controlsnamespace.

Language Validation

· An application must be localized in at least one of the supported application languages for Windows Phone Marketplace.

o A Windows Phone application will fail this requirement if a Neutral Language is not set. For more information on how to localize your application and how to set a Neutral Language, see How to: Build a Localized Application for Windows Phone.

Windows Phone Marketplace Iconography

For each application, you must submit one icon to represent your application in the Windows Phone Marketplace catalog. This icon must match closely the icon provided in the XAP package. Users see this icon when browsing the application catalog on the phone before making a purchase.


Do not use transparent PNG image files for the following phone application icons.

· A small mobile app tile icon (required), used in the phone Windows Phone Marketplace, 99 x 99 pixels in size.

· A large mobile app tile icon (optional), used in the phone Windows Phone Marketplace, 173 x 173 pixels in size.

· A large PC app tile icon (required), used in the phone Windows Phone Marketplace, 200 x 200 pixels in size.

· Background art (optional), used in the Background panorama, 1000 x 800 pixels in size.

Application Screenshot

For each application, you must provide at least one or up to a maximum of eight screenshots. Users see these screenshots in the details page of the catalog before they make a purchase.

Screenshots must only contain application graphics, and must not include any emulator chrome, frame rate counters or debug information. You may not graphically enhance your screenshots, except for the addition of informative overlays designated and pre-approved by Microsoft. For more information about these overlays, see this blog post.


Do not use transparent PNG image files for application screenshots.

For more information, see How to: Create Screenshots for Windows Phone Marketplace.

The Details page screenshot must be a 480 x 800 pixel PNG file.

Application Tile Image

The large and small mobile app tile images must be representative of the application.

Technical Certification Requirements

Application Reliability

· The application must run on any Windows Phone device, regardless of model, screen size, keyboard hardware, and manufacturer.

· The application must handle exceptions raised by the .NET Framework and not close unexpectedly. During the certification process, the application is monitored for unexpected closure. An application that closes unexpectedly fails certification. The application must continue to run and remain responsive to user input after the exception is handled.


o When handling exceptions, an application should provide a user-friendly error message. You may present a message that is relevant to the context of the application.

· If an application performs an operation that causes the device to appear to be unresponsive for more than three seconds, such as downloading data over a network connection, the application must display a visual progress or busy indicator.

clip_image001[36]Performance and Resource Management

· The application must render the first screen within 5 seconds after launch.

The application may provide a splash screen image in a file called SplashScreenImage.jpg in the root of the XAP package while the application is still trying to load.

· Within 20 seconds after launch, the application must be responsive to user input.

· A Windows Phone application is closed and terminated by the OS when the user navigates away from the application. When an application is started after being closed, its launch time must meet the requirements in Section 5.2.1 – Launch Time.

· A Windows Phone application is deactivated when the user presses the Start button or if the device timeout causes the lock screen to engage. A Windows Phone application is also deactivated with it invokes a Launcher or Chooser API.

· A Windows Phone OS 7.0 application is tombstoned (terminated) when it is deactivated. A Windows Phone OS 7.1 application becomes Dormant when it is deactivated but can be terminated by the system when resource use policy causes it to tombstone.

· When activated after termination, the application must meet the requirements in Section 5.2.1 – Launch Time.

· For more information and best practices, see Execution Model Overview for Windows Phone.

· To maintain a consistent user experience, the Back button must only be used for backwards navigation in the application. The following four requirements relate to use of the Back button.

· Pressing the Back button must return the application to the previous page or return to any previous page within the back stack.

· Pressing the Back button from the first screen of an application must close the application.

· If the current page displays a context menu or a dialog, the pressing of the Back button must close the menu or dialog and return the user to the screen where the context menu or dialog box was opened.

· For games, when the Back button is pressed during gameplay, the game can choose to present a pause context menu or dialog or navigate the user to the prior menu screen. Pressing the Back button again while in a paused context menu or dialog closes the menu or dialog.

· An application must not exceed 90 MB of RAM usage, except on devices that have more than 256 MB of memory.

· You can use the following classes to query the amount of memory that is available on the device and modify the application behavior at runtime to take advantage of additional memory:

o In Windows Phone OS 7.0, use the DeviceExtendedPropertiesclass.

o In Windows Phone OS 7.1, use the DeviceStatusclass.

· The DeviceTotalMemory value indicates the physical RAM size in bytes. This value is less than the actual amount of device memory. For an application to pass certification, Microsoft recommends that the value returned byApplicationPeakMemoryUsage is less than 90 MB when DeviceTotalMemoryis less than or equal to 256 MB.

· An application must not invoke either of the Trial APIs in a tight loop. For example, a game application must not invoke either of the Trial APIs while in a game loop. The API should be called infrequently and the value returned should be cached. For information about best practices for creating trial applications, see Creating Trial Applications for Windows Phone.

Phone Functionality

· The application must not delay or prevent the user from initiating a phone call, answering an incoming phone call, or ending a phone call.

· The application must not delay or prevent the user from sending or receiving SMS or MMS messages.

· The application must not stop responding or close unexpectedly when there is an incoming phone call, SMS message, or MMS message.


· The application must be free of viruses, malware, and any malicious software.

· Windows Phone implements multiple sandbox mechanisms to help protect the integrity of the device and the applications running on the device. The Common Language Runtime (CLR) on Windows Phone relies on the type-safe execution of application code to help enforce security and isolation mechanisms.

· An application must implement type-safe MSIL code to pass certification. For more information about C# unsafe code, see Unsafe Code and Pointers (C# Programming Guide).

· The Windows Phone Application Platform does not allow an application to run security critical code. An application that invokes security critical code will fail certification.

o For more information about the .NET Security model, see Security Changes in the .NET Framework 4.

Content Validation

· The product description and UI text of your application must be localized to each language the application supports.

· Application content, such as text and visual elements, must be visible and legible regardless of the phone theme. For example, if the phone theme changes from black background to white background, the text and visual elements of your application must be visible or legible.

Technical Support Information

· An application must include the application name, version information, and technical support contact information that are easily discoverable.

These incorporate the entire design of your application all the way through the testing process done by Microsoft. We found that this information was available but not so much that it quells the questions of why did my application not pass certification. We on occasion have forgotten to not make some icons a solid color and left them transparent, leading to an unapproved application. We hope that this information being brought to the forefront will help developers coast through the development process. We also thank Microsoft for providing the text above and in more detail to its developers. Until the next news update, Happy Hacking!

Share This