Currently the only way to reply to user feedback (posted in marketplace) is to put in your own review - which of course is only possible if your xbox live account is located in exact same region (and then other users may get annoyed based on what star rating you've applied to your response).

Although many developers (such as myself) put in direct 'tech support' email functions inside the apps - users unfortunately don't commonly use these.

Many times I see a 'bad review' from a user in another market - which is raised because user has not understood some functionality offered in app - or they have hit a bug common to entire platform (ie. inability to update a trial app on pre-nodo devices, problems with phone freezing or resetting, problems with live tiles disabling themselves due to connection problems, trying to use fm radio without aerial - to name a few of the common ones).

Many of these issues could be resolved quickly and to customer's satisifcation if only there was some way to reply and engage with them. (and hopefully users who recieve this direct engagement will then fix up a bad star rating after they understand problem is not necessarily a fault of the app itself).

At the moment, developers planning to sell apps need to have a US tax ID (ITIN, I think?), which can be awkward to get if you're based outside the US. In the AppHub forums, several developers have said that they've paid for certified copies of passports etc to support their applications to the IRS, but are being rejected. Obviously, I'm not keen on starting this process with no guarantee that it will actually work, and I imagine that it's putting off a lot of prospective developers.

Is it practical to pay non-US developers through a local MS office, so that we don't need to register with the IRS to avoid double taxation?

When app developers submit app updates to marketplace (and the user is prompted to install new updates - and can click through to a description) - it is desirable to sometimes inform users of what has changed in the new release.

Although these 'release notes' can be placed in app description - it isn't great marketing to put them there (and will be confusing and busy for user who has never downloaded the app before).

I think this sort of thing will be increasingly important with new o/s updates like mango where developers will need to be able to say 'fixes issue XXX on mango' or 'adds new feature YYY for mango users' etc etc..

This of course is a common feature on the iPhone app store and works really well.

Another simple way to implement this is to allow a URL to be provided by developer (ie. could even use the support url which we already enter in app hub) - and when clicked ie could be launched at that address.

Currently the App Hub provides a very simplistic reporting tool for tracking paid and trial downloads - with a single report row per Trial/Paid type and country. If you have several apps - this can result in several pages worth of data which has to be manually copied and pasted to Excel etc in order to determine totals (which cannot be automated due to https login). Additionally the parent graphs only show total downloads (with no breakdown of trial vs paid totals). There needs to be a proper 'export' to XLS/CSV function for all sales/trial data - as well as ability to report subtotals and totals on these app hub pages. On top of this - a 'quick fix' would be to allow all rows of data to be output in single page (rather than a paged / 10 rows per page view) - and then at least copy/paste to excel for doing more analysis would be a lot quicker. Another similar improvement would be to display totals/subtotals in a specified currency which accounts for the different converted price points for different marketplaces (as a straight/current currency conversion rate is not used by marketplace).

Currently there is no way to communicate directly with the tester who has failed an app other than to completely resubmit the app and write something in the tester comments field (which in most cases will be forwarded to a completely new tester).

The reality today (from experience with 20 published apps - and many many submissions) - is that testers quite often get it very wrong and fail on rules because they haven't understood the certification requirements correctly (most likely because the testers are not developers and don't understand some of the material).

For example - a couple of very common mistakes has been the certification requirement for location services that requires an 'App Setting' to be available for users to disable location lookups. However if you use Bing Maps - and you want to place a pin on a map - you need to provide a GeoLocation instance - which is located in the System.Device dll (which in turn incorrectly tells tester location services are used). Of course there's no way to 'turn off' anything to do with Bing Maps (so no App Setting could be presented to user or applied) - and I've had apps fail certification simply because tester has not understood this oversight.

Another common mistake is on apps marked for Music/Video hub - and then failing on certification rules which are clearly marked as being 'not applicable if app is a music/video hub app'.

Anyhow - some simple way of saying to the tester 'hey you got this test wrong and hears why' - would save a lot of time and frustration for developers.

The Windows Phone simulator for the existing developer tools has always been easy to use, and capable of running apps not only at full-speed, but in fact faster than what the phone hardware could do (even games that use heavy graphics).

In addition, the new windows phone developer simulator is going to be improved in the next version by running in Hyper-V, and additionally, Windows 8 will be coming with Hyper-V built in (I'm not sure about hyper-v).

So, I think the time is right to turn the existing developer Windows Phone simulator into a "consumer-friendly" version, that allows users of Windows 8 and Windows RT to buy and run Windows Phone apps on their Windows 8/RT PCs. This would benefit users (especially Windows RT users) by opening them up to around 100k apps at launch, and it benefits developers by expanding their potential user market to the millions of Windows 8/RT PCs that will be sold, in addition to the Windows Phone devices that are sold.

If this were done, I think it should be done with the user in mind first, which means it needs to be a good experience all around. But, I think this can be accomplished. Here are my ideas on some potential specifics of how it would work:

- Developers should be able to opt-out. So, for instance if they already have a windows 8 app and want to direct their users to that version fo the app, they would opt-out their phone app.

- Single-touch events would be simulated by the mouse, transparent to the app.

- Developers should be able to specify whether certain hardware is required. For instance, you could specify that your app requires multi-touch hardware, the accelerometer, or the compass. Some of this could be auto-detected by inspecting the assemblies and what APIs they used.

- By default, apps should, unless the developer changes it, default to requiring some basic hardware, like multi-touch. If the app only requires single-touch, they should be able to opt-in to allow the app to run with just a mouse simulating touch events.

- Apps should run scaled to the user's screen, and may require a certain minimum screen size.

- On a stationary screen, the user should be able to easily control whether the "simulator" is in portrait or landscape mode.

- If users are running windows 8/RT on a tablet, then the simulator should respond to the orientation that the user is running in.

- The simulator should also support an on-screen back button that is easy to use, since the back button is not supported in windows 8 tablet hardware.

- The simulator should forward the various system tasks, like launching a URL in IE10, sending an email, or taking a picture, through to the windows 8 equivalent, or if one is not available then one should be created.

The Windows Phone Radio and Windows Phone Blog Microsoft Marketing tools regularly feature new apps and games reviews, as do an increasing number of third party websites. In my experience one of the great frustrations of Windows Phone 7 is discovering from a new review or Blog that a New App is out that I have been waiting for – like Amazon, only to find it is a region restricted release and not available for the Australian Market.

This frustration is exacerbated by the fact that this point is not highlighted up front by anyone. Here’s an example of my experience of excitedly heading off to get a new app once announced for Amazon.com:

I jump into the marketplace on my Focus – hit search. OK not there, maybe it hasn’t synced across to the servers we use for Apps from MS here in AUS. Jump into Zune software, OK not there either….hmmm not looking good. Fine – hit up www.wp7applist.com and look for it – Success! OK use MS TAG or click on link here – Zune opens up and there is the App. Amazon FREE. Awesome. No, wait – DAMN! There is no buy or trial button, just the app description. Region blocked! :(

Hardly ideal.

Perhaps MS could amend the Marketplace submission process for APPS, resulting in a REGION CODE type rating, where either access to, or relevance is attributed to each app and then sortable in the Marketplace or via 3rd party sites like wp7applist.com?

Then each App could have along with description, title, cost etc these extra values:

- Regions Available (eg Asia, Europe, North America, US etc)

- Region Applicable for (eg Global, Australia, etc).

The first allows me to filter UP FRONT what I can and cannot access for my phone. Importantly I want to see what isn’t available for instance in Australia, because I might be a local DEV there looking to make an app with similar functionality here (ie filling the market gap). The second allows me to say – OK I’m in Australia – what Apps have specific functionality applicable to my region/country. It may be a globally available app – even from a US marketplace submission – but it functions in Australia or for Australian content.

This sort of improved categorisation and dice and slice of the marketplace will just become more important as the size of the market (and app crossover/duplication) grows. It may not be a big issue to others, but I for one would also welcome that reduced frustration and annoyance too – by having App reviews showing up front what region restrictions exist for the app they are reviewing…don’t build up my hopes only to crush them like the dream of Zune Pass music in the Australian market!

In any publisher platform, the most important number presented to publishers is their revenue, and it's completely missing from WP Dev dashboard.

There's no way to know how much money you're making until you're paid. All you can see is the amount you were already paid (which for some reason shows up as a big text even though once you got that money you don't really care about that number anymore) and how many paid downloads you have (which doesn't include the price charged for it, so if you ever change the app price, you can no longer figure out your revenue)

If you need an example of what publishers should see when they open the dashboard, check out pubcenter.microsoft.com. Not that the reports over there are much better but at least that most crucial data point is the most clear and visible number on the home page (as it is on any publisher portal).

If you're worried about paid transactions that won't go through, there's a simple solution, call it Estimated Revenue. Add the fine print that the numbers are subject to finalizing purchases or whatever legal wording you need there.