Hello,

We have made improvements to the Content Policies and Test Requirements to streamline the submission and Certifcation process.  Please use this thread to provide your feedback or post a question.

Please review the updates found, here, on the home page of the App Hub.

We look forward to seeing your apps in the Windows Phone Marketplace!

Thanks
Jo

The most common requests/frustrations that I've come across boil down to two things: 1) the inability to cancel a submission; and 2) the inability to change things that are perceived as being meta data without going through the entire review and testing process again.

As to the first, if someone discovers an inadvertent bug (or that they uploaded the wrong build, or used the wrong screenshots, etc.) there's no way currently to cancel the process. Instead they have to wait for the app to fail, which can take a little while, wastes the tester's time, and is generally a bit frustrating. Even worse is when the problem is one that won't cause the app to fail (say they forgot to enable the code that displays ads in a free, ad-supported app, or they made some other mistake that is outside of the App. Cert. Reqs.). Then they can wind up with their app going live with some very big problems from the developer's perspective. There should probably be some sort of abuse-prevention mechanism (maybe a submissions per day limit) so that people have an incentive to try their best to get it right the first time. But generally some way to cancel a submission while it's still in the review process (even if it would just stop it from going to the marketplace, e.g. by converting a "release ASAP" submission to a "release only when I say so" submission) would be great.

As to the second, I've read various requests for the ability to do things like change price, switch categories (within the limits of the different criteria that certain types of things have, e.g. photo apps and games have different applicable rules), add or remove screenshots, update the icons, change the description, etc., without needing to go through the entire testing process again. Some of those things probably wouldn't really need any review (changing the price), while some would require some review and others might just not be possible without looking at the app again. But anything that can be done to prevent the need for a full testing of the XAP file where the developer doesn't want to change the XAP file at all but rather just things that are separate from it would be great.

It would be nice to have a process for pre-approval (or rejection) on technical exception requests.  It would save both the developer and the tester's time by being able to have the discussions up front on whether the requested behaviors is acceptable or not.

I realise I'm not contributing a new idea, but Bob Taco Industries has hit the proverbial nail on the head.

It seems that the rules on screenshots aren't enforced very well. I've seen loads of screen shots which: include emulator chrome; are so distorted they must have been taken with the emulator not at 100% and then manually resized; or include the performance counters.

The non-inclusion of performance counters isn't a submission requirement but should be.

There shoudl also be a way to report apps which have been accepted into the marketplace but shouldn't have been. This applies to apps with the above mentioned screenshots but should also be possible for apps with other issues as well. (I've used apps which don't support light theme, or crash after tombstoning and have other errors.) While providing feedback to the creator of the app can and should be done it would also be good to make sure that the marketplace team are aware that such apps are incorrectly being approved. If lots of buggy and low quality apps keep getting into marketplace it affects perception of all apps and the platform as a whole which affects all us developers who are striving to create the best apps possible.

The addition of the test cases is very welcome.  Overall, nothing scary or too different in there.

I know a lot of apps were incorrectly passed early on, and probably have not been updated since, so these violators of several certification requirements are still available on the Marketplace.  On the other hand, a lot of apps were incorrectly failed during that time as well.  Hopefully the testers have improved their knowledge of the certification requirements in the time since the launch, and indeed the fewer reports on this forum about incorrect failures seems to support that.

I noticed that under the TCRs ( http://msdn.microsoft.com/en-us/library/hh184840(VS.92).aspx ), that 5.6 - Technical Support Information is still listed as a requirement when it was previously stated that it had been converted to an optional (albeit strongly encouraged) policy here: http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/03/08/an-update-on-windows-phone-marketplace-new-tips-policies-and-regional-access-program.aspx . I'm guessing it was just an oversight in the process of converting the old PDF-based requirements to the new MSDN hosted version.

6.5.2's Requirement Text does not match its Test Steps (the requirement text states that both background music and background music volume must be configurable whereas the test steps state that you should test that the application allows a user to configure the background music or background music volume of an application). The test steps, in my opinion, more closely match the text of 6.5.2 as it appeared in version 1.4 of the policies. The current requirement text would seem to be a modification of the previous 6.5.2 but isn't listed as being updated in the Changelog. While I think developers should be encouraged to provide in-app volume controls, I think a simple on/off should be all that's required and in my reading of 1.4's version of 6.5.2 it was all that was required. Given that certain models do not respect the MediaPlayer API's volume setting (thereby rendering an in-app volume control useless on those models unless and until that is fixed), it's hard for me as a developer to justify spending the time implementing such a control only to know that some users will find that it doesn't work on their phone and may choose to give my app/game a bad review as a result when it isn't my fault.

I think that 6.5.4 as a blanket rule is a mistake unless there's some technical reason for it. Generally apps and games should use MediaPlayer and should be barred from using SoundEffect to try to sidestep the requirement that they respect the user's choice to play their own music/listen to the FM radio. However I know of at least one developer who has submitted an XNA-based app that is a Digitial Audio Workstation/Music Sequencer (which failed and which I suggested he seek a technical exception for). Basically it's something where you can assign predefined sound effect loops to different channels on a mixing board and use the control interface to control the playback thereby creating music. This is impossible to do without SoundEffect since MediaPlayer only allow piece of music to play at once but would fail under 6.5.4's blanket prohibition of the use of SoundEffect to play continuous background music. An app like this is not only a very neat thing to play with, but could actually be used to overlay the existing music someone is playing through the Media Hub or FM radio to provide an audio experience akin to the visual experience of an augmented reality app. That would definitely need a technical exception and would require that the app implement additional safeguards and protections to ensure a good user experience.

One thing that might alleviate the problem I see in 6.5.4 would be to add a blurb mentioning technical exceptions and linking to a description of the steps to apply for one at the top of both the Technical Certification Requirements page and the Additional Requirements for Specific Application Types page. Developers shouldn't come away feeling that they can ignore the requirements and just apply for an exception, but they should know that if they have an innovative idea for providing fun, unique experiences on Windows Phone 7 that do not fit within the stated requirements, that exceptions to the requirements are possible and they should know how to go about that process. I also like the idea an earlier poster had about being able to apply for exceptions in advance of submission. I imagine that some things would depend on the application and implementation, of course. But I imagine that other things might be impossible for one reason or another and that still other things which have already been reviewed and approved in the past might be able to be given conditional approval subject to meeting certain requirements and perhaps a heightened testing process (and perhaps a re-review at that time based on the submission). The latter could even act as a testing ground for things which could ultimately be added in to the App Cert Reqs under the TCRs or the Additional Reqs in a future update to them.

Bob Taco Industries:

6.5.2's Requirement Text does not match its Test Steps (the requirement text states that both background music and background music volume must be configurable whereas the test steps state that you should test that the application allows a user to configure the background music or background music volume of an application).

Nice catch.  The requirement text for 6.5.2 should have "and" changed to "or" so that is consistent with the test steps and with the requirement text for 6.5.1.

4.1.1 has changed the reference from "application icon" to "small mobile app tile" and states the small mobile app tile must be 62x62.  Later on, 4.5 states that the small mobile app tile icon must be 99x99 (for marketplace).  The change in terminology in 4.1.1 may cause confusion because the name "small mobile app tile" is now used in two places but with different required sizes.

The following are unchanged from the October 2010 requirements document.  They are suggestions for improvement.

6.2.1 requirements text and test steps should change "disable" to "disable or enable".  The user may want to enable toast notifications again after disabling them, i.e. the behaviour should be toggle, not just disable.

5.2.1 should mention that SplashScreenImage.jpg only applies to Silverlight apps.  XNA apps can render their own splash screen using the description on this page.

4.2.3 should mention "release configuration", not "retail".  Visual Studio projects supply Debug and Release configurations by default.  There is no Retail configuration.

Would 6.3.3.1 be specifically tested during submission?  That would tie up a device in the test lab exclusively for 5 consecutive days.

In Tech requirement 5.1.3, step 5, it says: "If a progress indicator is displayed, verify that the application provides the user with an option to cancel the operation being performed."

I want to thank everyone for their detailed feedback and interest to improve the Windows Phone 7 TCRs, application submission and certification processes.

Feature Requests. The App Hub feature requests to cancel a submission, a separate workflow for metadata changes or changing the application category are under consideration for future App Hub releases.

Technical Exceptions. Feel free to create a support request via an App Hub e-Form for proactive technical exception review. Just respond to the email from the MS support representative and include the technical exception request. Technical exceptions are reviewed and responded to within a three business day average.

TCR Feedback Details:

4.1.1 - More details are forthcoming for further clarification regarding icon references.
4.2.3 - I'm investing the change to "release configuration" vice "retail".
5.1.3 - The Back Button should suffice as a cancel operation in most cases. I've captured this for clarification.
5.2.1 - I agree that providing further clarification regarding implementation for Silverlight and XNA apps is beneficial.
5.6 - Technical Support Information is not currently enforced per the standing global technical exception. This requirement is captured in the TCRs to allow for possible future enforcement and is also a best practice.
6.2.1 - I'm investigating the suggestion to add "disable or enable".
6.3.3.1 - The test step to test battery consumption over a 5 day period represents a best practice. You can test for a shorter duration and extrapolate the results. I'll review adding this detail for clarification.
6.5.2 - Having an on or off option for in-app volume is a solid suggestion. I've also captured the test step feedback for clarification.
6.5.4 - You're correct that apps should use MediaPlayer in most cases and using SoundEffect is a viable option for XNA-based games. Continuously looping a sound effect to create background music should be avoided, however, a technical exception can be submitted for MS review.

Keep the feedback coming!

Thanks.

- Steve Bell

I'm not sure if this fits as a content policy and I know there has been discussions about this - but what about "Lite" versions of apps?

Actually what ever was updated in my option is making things slower. I submitted an app on the 5th I still haven't heard anything

I have updated each my my apps once.  In each case, I had to re-submit all the information about my product, including resubmitting all the screen shots and icons and descriptions.  I think this is ridiculuous.  It would save my 15 minutes doing an update if I didn't have to re-provide every piece of information on every page.  Please consider making the update feature work like an update instead of an entirely new submission.

digital perfection:

Actually what ever was updated in my option is making things slower. I submitted an app on the 5th I still haven't heard anything

The new Application Certification Requirements come into effect on June 3.

Kraft Software Solutions:

In each case, I had to re-submit all the information about my product, including resubmitting all the screen shots and icons and descriptions.

This is nothing to do with the Application Certification Requirements (which is being discussed here), but is to do with the Application Submission Process.  Microsoft has stated they are working on improving the app update process so that most of the app metadata is retained, but there is no release date for these improvements yet.

Based on my certification experience, the intro section of clause 6.4 is incorrectly worded. The current wording is:

"An application in the Music + Videos Hub provides an integrated music and video experience on the phone as its primary function. When an application calls the MediaHistory or MediaHistoryItem classes, it is considered to be a Music + Videos Hub application and will appear in the Marquee list when installed on the phone. The submission process detects that the application uses these classes and automatically updates the hub type to Music + Videos in the Windows Phone application manifest."

The underlined section would indicate that:
a) The developer can choose whether an application is an "Music & Video hub app".
b) The user excercise his/her choice by calling the MediaHistory API.
c) Only applications that have been submitted so that they use MediaHistory will be tested under 6.4, other media applications will be tested under 6.5

Based on my testing experience this does not seem to be the case. Based on my test experience, applications are tested according to 6.4.1 to find out if the application is deemed (by the tester) to be an app with music and video experience as it's primary function". If the tester then decides that the app is a "MUsic and Video app", using MediaHistory is required, not optional as the intro to 6.4 would indicate.

I also read clause 6.4.1 the other way from how it seems to be used, to me 6.4.1 language suggests that the application should be tested for "enough" video and music functionality to qualify for the Music & Video hub, now to opposite seems to be true, the application is tested for "too much video and music functionality" to be left outside the hub.

As a result, applications get rejected for NOT using MediaHistory and therefore for NOT integrating with the Music and Video hub. This seems to be contradictory to the clause from 6.4 quoted above.

If the interpretation excercised by the testers is correct, then the wording should read:
"If an application provides an integrated music and video experience on the phone as its primary function, the application must be in the Music + Videos Hub The application must use the MediaHistory or MediaHistoryItem classes and it must appear in the Marquee list when installed on the phone."
 
If this interpretation is correct, the clause 6.4 also needs to be updated with a definition of when an application is deemed to provide "an integrated music and video experience". Now clause 6.4.1 gives no clues as to why or why not an application is a "video and music app".

Suggest that MS make an appropriate clarification in the text or provides updated instructions to certification testing to follow the current wording.

br, Håkan

Completely agree with Bob Taco Industries's comment on 6.5.2: the in-app volume control does not work on some hardware models which would render satisfying the software requirement on providing a volume control impossible. The end result, as also noted, may be bad reviews by users that may find the volume control not working on their device.