The trial feature should be built-in with automatic enforcement, user prompting, disabling, etc, just as it is in the Windows Store.

In the Windows store, I can choose trial mode for my app, and then pick the number of days I want the trial to last. From there, everything is taken care of for me. If the user uninstalls during a trial, it tracks this fact and prevents them from starting a new trial later.

Contrast this with the Windows Phone world, where the developer indicates trial mode in the store, but has to manually track the number of days since install, whether the user has purchased, etc. If the user uninstalls and installs again later, the developer has no idea. Adding trial-mode in Windows Phone feels like implement-and-pray.

I absolutely love the Windows Store implementation. With the two stores combining, can we bring built-in trial mode support to Windows Phone?

When developing apps it is often useful to leverage existing Launchers and Choosers as Tasks to access certain data or perform an operation. Currently this is only exposed for system-level data and operations.

It would be ideal to allow apps to expose certain bits of data or functionality to other apps to provide a complementary experience in terms of reuse of information or performing similar tasks.

Imagine shopping apps being able to share a set of data such as a wish list or news apps being able to share a list of news feeds. Imagine having an installed app do what it does best for another app, such as perform a series of complex calculations or gather weather data. It would be the responsibility of the app to decide what it exposes for data or functionality.

Security is a concern and in this case that means access to data or performing undesired operations. This can first be alleviated as with other security screening by prompting the user to allow an app to access another app's tasking features. Additionally, the app itself is responsible for what it exposes; and it would not be able to chain access to any other area - only data in its isolated storage space for functions that are allowed as tasks. Lastly, app submission testing would ensure that the app "plays nicely" in what it offers.

Consider the following...

class MyAppChooser : Chooser
{
public Choose()
{
// give list of saved music or list of sites from news feeds
}
}

class MyAppLauncher : Launcher
{
public Launch()
{
// kick off app function such as PlayMusic() or ShowFeed()
}
}

The current developer ecosystem for WindowsPhone apps is focused on individual developers or corporate developer accounts that typically distribute apps to the masses via the Marketplace.

Internal use of apps is defined as a "beta test" and requires a list of Live IDs designated to allow a certain set of users to download and use the app. This is very limited and also time consuming. Ideally, a company may wish to dedicate a group of Live IDs as testers to be used each time. Allowing for tester groups or "profiles" would allow for efficient test setup in the Marketplace, especially for multiple products, by allowing a group to be assigned to the app as it is entered in the Marketplace as a beta.

Additionally, it would be great to have additional support for Enterprise developers that target a specific set of clients as opposed to the public masses of the Marketplace.

First, an Enterprise Developer account could be established with a cost of, say $499, which is high enough to deter hobbyists or smaller companies from enrolling, while at the same time providing additional benefits to larger "enterprise-level" corporations.

For this cost, a company would receive two unlocked WindowsPhone devices that could be traded or upgraded. This allows a team to use these devices for testing, as opposed to having to put company apps on their personal devices or hand their devices over for demonstrations.

The Enterprise account would also allow for distribution of apps at the organizational level - either in-house or to clients. The Targeted Distribution approach doesn't seem to satisfy the need to sell or distribute from a company to clients. Ideally, a mini storefront or splash page for the company and product would help draw in clients. It could also allow for a specific download key if purchases were made outside of the app Marketplace.

Together, this level of support would cater to a market that would like to leverage the Marketplace in a unique way while having the tools and capabilities to develop apps without requirements of personal accounts or devices.