Provide a mapping for UIPickerView or at least to a functionally equivalent Windows Phone control

It would be great if Windows Phone supported Adobe Air Apps similar to how the Android/Blackberry Playbook platforms support.

The Blackberry/QNX folks also went one step further and built an Air SDK to allow Adobe Air app developers to plug into native platform methods/properties. If Microsoft also did this, then Air developers could create apps that behaved/looked like other WinPhone apps.

It would be nice if Flash content can be viewed within Windows Phone's Browser.

to employ fully supported flash player, PDF Reader, JRE, flash player embedded in browser (working fine with online flash games like FARMVILLE), Multimedia player with playlist editor, lyric viewer, and online radio facility.

The Mango release does not support Bluetooth's SPP profile, like the iPhone and Android devices do. Looking at the correct API mapping, the namespaces are completely missing.

The Bluetooth SPP (Serial Port Profile) is how we use external devices to communicate with the phone. Some examples:

* High resolution GPS receivers
* Remote controls, such as robotics and servos
* Heartrate monitors and other measurements such as VO2 Max

Develop an estimation Tool that can take the iPhone App code as input and provide the estimate for WP7. This can include items like source code size, effort for developing this app if a beginner/expert works on converting the App, etc. This need not be accurate but that would serve as a guideline for developers/companies that would work on App porting.

CoronaSDK is now a leading standard for Mobile Development and it works with one codebase providing multi-platform builds, currently only iOS and Android, if Microsoft were to partner/work with Ansca Mobile, they could help a lot of developers to create apps for iOS, Android and WP7 devices, that way not only will there be an increased number of apps, but a huge uptake of the WP7 device by developers and users alike.

It would be great if WP can support more APNs. It is interesting for many users, because mobile providers give an unique APN for emails.

Ability to subscripe the PhoneCallIncome Event from a background-service. As EventArgs it would be nice if we can access the Number from the caller.

A lot of successful game developers are using unity, a cross-platform game development environment that allows simultaneous targeting of iOS, Android, Web browsers, PC executables and Mac executables. I have used it for my game, and porting was a breeze. The irony is that they use C# as their scripting language, but they do not support WP7. Given the current size of the WP7 market, unless it is targeted by Unity, it really isn't worth the effort at this time.

If this is to promote interoperability, why not make it work both ways? At the moment it looks like a cynical attempt to ride on Android's/iOS's coattails...

I understand that not many people use or develop apps for windows phones. You want more people to treat your platform seriously. But after visiting the site, it really looks like a sad attempt to beg for table scraps as opposed to a strong drive to establish WP7 as a contender for the no.1 market position. Build a genuine comparison site. Point out the gotchas. Keep it updated and honest. Then we'll talk.

C++/OpenGL is the defacto standard to build mobile games today.

It can be used on iOS, Android, Bada, webOS, and will sooner or later be available on new RIM devices.

iphone users can purchase subscriptions/extra content/Digital books/poker chips/Additional game level from within an application. With WP7 and marketplace there is no such opportunity.

Create converters to convert WP7 apps into iOS and droid.

So you code in C# and VS will give binaries for all 3 platforms. (MS will get revenue for the dev tools which are already better than any other IDE)

This way, developers don't have to go through the mess of iOS cocaine (Cocoa ? or what ever) or Eclipe's brain dead tool set.

Either allow users to edit a mapping entry (like a wiki), or create placeholder pages for every class and method and allow people to comment on how something should be mapped, or point out issues with what is already posted.

NSString (such an obvious thing) is missing. And the other things are not consistent, e.g. it includes both NSArray and NSMutableArray, but only NSDictionary and not NSMutableDictionary, and NSSet and not NSMutableSet, etc.