Please provide some consistency in the certification process. I submitted a game for publishing on Monday. It went through the entire process in about 2 hours. The game wasn't set to be published until Friday at Midnight.

Over the course of the week, some fixes were made to the game's code and was resubmitted for publication on Thursday around 10am.

It's been sitting in "Certification in Progress" now for 2 days. If it doesn't go through, I'm going to miss my published release date.

If you can't give a reasonable estimation on release times, maybe let us put multiple releases in the queue. That way, if the second one gets certified on time, it can take precedence over the previous version.

From my recent experiences it seems that an app submission can pass certification with no problems, but then a subsequent submission that only makes a very minor code change such as bug fix can fail certification. I accept that this will probably happen in general because full checks cannot be applied every time and different testers may pick up on different things.

However, it concerns me that one day I will run into the following hypothetical scenario:
I release a major app update which passes certification fine. I then notice a critical bug in the app which I need to fix as soon as possible. I release the bug-fixed version to the store, but it spends 3 days in certification and then fails certification. I then have to work out why it failed and make the necessary updates or etc and resubmit it for certification which could take another 3 days. That means it's taken me a week to deliver a critical bug fix, which could lose a lot of customers etc. Note that I have already experienced less serious versions of this scenario.

Therefore I would like to propose the ability to mark an app submission for an already-published app as a bug fix, which would either skip or fast-track manual certification (automatic certification using the Certification Kit would still be done). I realise this could be open to abuse, but perhaps there are some rules you could produce which a submission would have to obey in order to qualify - for example the app manifest should be unchanged except for the version number.

Thanks for considering this idea.

Please, give us the possibility to delete add-ons (with, without subscriptions etc) right in the Web GUI of the partner center.

Right now, if you want to delete an addon in the partner center (which you have created there), you have to:

Read and follow all the required manuals to delete an add-on with azure ad integration.

Create an account, wired app to it, get token, app-secret, tenantId etc.

Entered the needed ID also in the partner-center's section "product collections" and "adminstrator agreement".

Search desperatly for a complete c# uwp exambple how to connect and proceed with a follow up request.

Try to delete the addon finally via c# and deleteasync requests
Getting meaningless errors, because the above is so error prone and no complete example for uwp exists.

Windows Store Policy for Adult Content:

11.7 Adult Content

Your app must not contain or display content that a reasonable person would consider pornographic or sexually explicit.

Pornographic and sexually explicit needs to be well defined. Microsoft support working for Report App are taking down apps which have partial, but no ******* nudity. Partial nudity is not pornographic nor sexually explicit. Game of Thrones is on the Windows Store and contains full frontal nudity and graphic *** scenes, so it is quite ridiculous when apps are removed that have partial nudity or body parts blurred out or covered.

Furthermore, Age Ratings in Dev Center Dashboard can be set per app according to the ****** content in the app. If the app fills out this information there it should not be taken down unless it has pornographic or sexually explicit material, which is not well defined in store policies.

I have a disk imaging (which I have already converted) application that writes bytes directly to disk (USB and SD cards). It requires admin rights to get a lock on the disk. The app gets rejected during submission to the store as some features are disabled as admin privileges are required. It would be good if we could submit utility tools to the store as there is no way to perform these tasks without admin. Maybe warn the user when downloading the app or more stringent verification process for these apps but don't block them completely as you're hurting both devs and users. And a user will just go elsewhere to get the app and end up downloading from shady app from the web causing them to get viruses as you won't allow elevated apps in the store. So in a round about way you're actually raising the chances of users getting viruses by blocking these apps as they just get them from the web instead.

Could you add the link for the feedback hub to the store's app review form? I believe that the 'app review' and 'report for developers' should be divided.
Because - a lot of user post a bug report to the app review on the Microsoft Store.
But, In fact, most of these posts should be handled with feedback hub. By using feedback hub, we - app developers - can contact with the users to get know the detail and track the defects.
Is it possible to add the note to the review form as following?
"If you have a trouble for using this app or want to send a report to the app developer, please consider to post it to the feedback hub, instead of review. Here is a link --> [link] "

There is no category specifically related to science apps; I think having such a category would provide a more refined ability to find such an app in the Store. The closest category (the one I'm using) is Education. Here are a couple of examples: I can envision a mobile app that is a "Tree Finder" that provides the ability to identify a tree genus/species by selecting from an imagery collection, or an Astronomical app that provides ephemeris data (position of sun, moon, planets, etc), in a graphical format. My particular application locates earthquakes on a map and allows the user to receive additional detail.

Once a flight group is selected for a package Flight Submission it cannot be changed.

Allowing it to change would help greatly in our release process. Currently to perform our final Staging test we submit a package flight and add a group that targets our internal testers. This works well.

Once we complete internal testing many time we want to open up the distribution to a larger group. The group on the submitted flight cannot be changed without submitting a new flight which may require a rebuild since the same version cannot be submitted and waiting for another certification many time it is not just a couple hours and can be over night.

If we could change the group with out a resubmission this would allow us to transition from internal test to an external beta very easily. Even better if multiple groups are allowed we could just add the external group and remove it as we like and still keep the internal group linked. Less group management in the latter option of using multiple groups.