Select a language to translate this page!
Powered by Microsoft® Translator
Today we published an updated version of the Windows Phone 7 Application Certification Requirements. As always you can find them on the AppHub (http://create.msdn.com). Here’s a direct link to the PDF file. The WP7 App Certification Requirements lay out all the policies developers are required to follow in their WP7 apps & games.
It is our ambition to make the certification process as clear, transparent, and efficient as possible for developers. We are always closely monitoring end-user feedback and listening to the developer community and these changes are a direct result of what we’ve heard.
Below is a summary of the changes in this version (published October 2010, version 1.4):
4.1.1. List of Package Requirements
Changed the maximum size from 400 to 225 MB. Step b. Added a clarification that the application title displayed on the phone must be the same as the title entered in Step 2 of the submission process to Windows Phone Marketplace.
Step e. Changed start experience to app list. Removed the statement “The application is optional for games.” Added a requirement that games must use the application tile image in place of the application icon.
Step f. Added a column in the table about where the application icon and tile image shows up on the phone. And added screenshots of the start experience and app list.
4.3. Phone Capabilities Detection.
Added information about the Windows Phone Capability Detection Tool.
4.5. Windows Phone Marketplace Iconography
Changed the icon descriptions in the table to match the UI in Step 3 of the application submission process. Added a column to the table describing where artwork is used.
4.6. Application Screenshot
Revised this requirement to describe that screenshots must not include any emulator chrome.
5.2.5. Memory Consumption
Revised the first paragraph and added a note about DeviceExtendedProperties and ApplicationMemoryUsage.
5.2.6. Trial Applications.
The trial APIs behave differently for apps/games downloaded from the marketplace than when installed on a developer registered phone. Added a new requirement to not call these APIs in a tight loop.
6.3. Applications Running under a Locked Screen
Updated section with a description of the advantages and challenges of running an application under a locked screen. Separated guidance for audio and/or video applications, and all other applications. Added requirements for minimum battery life and idle behavior while the application is running under a locked screen. Removed the requirement 6.3.1 Configurable Functionality (you no longer have to ask users to opt in to allowing the app to run under lock as long as you meet the battery life requirements above).
6.4.1. Music + Videos Hub Application
Updated text to 'video and/or music media playback'.
6.4.2. Music + Videos Hub Application
Revised this requirement to add a second implementation option.
6.4.6. Music + Videos Hub Application
Added a section to the requirement that states that hub tiles should not contain album art unless the album plays when the hub tile is pressed.
6.5. Applications that Play Media
Updated the first paragraph to better describe the kinds of applications or games that must meet this requirement.
6.7. Photo Sharing Applications
This is a new requirement
Applications currently in the marketplace affected by these changes will be required to adhere to these changes next time they are submitted as an update.
Go grab the doc, read it, and please continue to provide us feedback.
I have a question regarding running under the lock screen and the battery life: The new requirements are not good then the application functionality is gps tracking. This is energy intensive I know but if this is the application feature and the user want's this I can't do anything about the energy consumption.
As a minimum running time I would suggest the worst case: Using of the internet connection, gps and playing music. This gets the minimum which every application must reach (and can). Everything else spoils down the possibilities for us developers and would restrict the plattform more then it have to be.
Absolutely what Rafle said! The whole point of forcing an application running under a locked screen is for some type of data collecting purpose. The audio requirement is fine. It sounds like ralfe is doing something with GPS, just like I am, that we must be able to capture updates while the screen is OFF.
For example, I mountain bike for 6 to 11 hours at a time, logging my GPS the entire time. This works fine on my Android (I don't have a Windows Phone) running under what WP7 would consider "High Accuracy" (sats only, no A-GPS), and I have 70% of battery life remaining when I return home.
The new requirement s in section 6.3.1 that all timers must stop when a screen locks completely defeats the whole point of someone running an application in the foreground, for 10 hours at a time.
This effectly kills all 4 applications I was developing! Talk about a roadblock...
Now, I can return to the events-driven model of allowing updates to be logged whenever the GPS unit updates its position for some of my apps. But I am now affraid that:
A) the operating system will put the GPS into a StandBy mode when the screen is locked, again killing the whole point of my applications to log the gps. I cannot test this as I do not have a WIndows Phone, unfortunantly.
B) Under 6.3.1, what is considered "non-critical" processing? Would serializing and storing a gps location to the IsolatedStorage be considered "non-critical"? If so, again, that defeats the whole purpose guys of someone selectively running an application in the foreground, being told to "lock" the screen if they want it to continuously log, etc.
If a user purposely selects an application to run, even with a warning that certain settings will drain the battery faster (which my application CLEARLY states when setting certain things, such as setting the MovementThreshold to 0 instead of 20 - and I state logging more often may drain battery more as well!), they SHOULD be allowed to do it. That requires a repeat: "Put it onto the user to decide if they want to drain the battery in 5 or 6 hours, do not restrict us developers."
Not to sound like a dictator, but what the guidelines SHOULD say is:
"If an application does not meet these minimal battery requirements, the user must be prompted to accept the battery-draining settings during the first time" - or something alike.
Having the hard blocks is a killer for us developers that actually want to make the phone useful. The iPhone doesn't even have that type of restriction (and they have now posted their approval guidelines now as well). I was very excited to jump into the mobile relm for the first time. This pretty much kills any ability for my applications ro run on the WP7.
Please consider adding the blurb above.
How the data is collected (timer based or event based) is unimportant (it's only an implementation detail) and shouldn't be regulated by Microsoft. It's MY decision what makes more sense in my application scenario. The one-fit-all-solution doesn't exist and please don't try to find it. Besides if you only allow one specific implementation what doesn't fit my needs the app development gets more difficult, time and cost consuming. That shouldn't be the prefered way.
Then reading section 6.3.2: If I didn't play any audio my app must remain in idle state. To archive this my app must do nothing. So why do you allow running under lock screen if my app isn't allow to do anything usefull? Asking for the user allowance did made more sense for me.
To wrap it up: Leave space in the guidelines and rules to allow innovative apps can be build otherwise I see developers leaving WP7.
An other aspect crosses my minds: Then you telling us how long the battey live should be please specify how the timings are measured. This can (und will) make a huge difference! Setup multiple accountts with syncing and different connections on (3G, Wi-Fi and/or Bluetooth) with accumulator capacities out there (1230 mAh on HTCs vs. 1500 mAh on the others) will lead to one hour difference in standby time - at least. If this isn't clear for anybody then it comes to vertification it will get messy because apps failing the test and the discussion between you and us begins. This leads to frustration etc... you get the idea, right?
@Ralfe: I started a thread on their forums with exactly those points (and more).
If you have anything else to share, please do so. We can't be the only two effected by these changes...
Absolutey concur. What a ludicrous idea. If i want to drain my app by downlooading that kind of app then i should be able to. this is my decision as an app purchaser. I am well aware what i am doing as a user. If i need GPS tracking until my phone dies with no battery, then i should be able to pay for this. Who comes up with these ideas? the windows phone guidelines are becoming prohibitive to the point of stilfing all innovation. Its not funny.
2.6 If your application enables chat, instant massaging, 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.
Colud you explain what i must doing when i receive an age information? Lock my application for this user? If it's a client of social network, it's mean that user can't use my app,althow he(she) have account to this service?