Certifying and Distributing Windows Store Applications to Earlier (ie Non-Supported) Versions of Windows 10 Mobile

Certifying and Distributing Windows Store Applications to Earlier (ie Non-Supported) Versions of Windows 10 Mobile

In my previous post on Visual Studio 2015 RTM, Universal Windows Platform (UWP) Developer Tools and Debugging on a Windows Phone device I covered modifying the TargetPlatformMinVersion property in the Visual Studio project file in order to deploy your Universal Windows Platform application to a Windows 10 Mobile device. Granted that this post is probably a little too late, since the next build of Windows 10 Mobile is now out (I’m yet to install it), but it is possible to publish your application to the Store so that it can be installed on a non-developer enabled phone.

Now you’d think you’d just be able to create a Store package with the TargetPlatformMinVersion property set to the required value (in this case 10.0.10166.0 to match what I currently have on my device – see the OS Version attribute in the About screenshot below). Unfortunately this is not the case!

If you do attempt to generate a Store package you’ll see an error similar to the following image – “10.0.10166.0” is not a supported value for TargetPlatformMinVersion. Please change it on the Project Property page

Ok, so step one is to revert the change to TargetPlatformMinVersion so that you can at least generate a Store package. From the Project menu in Visual Studio, select Store -> Create App Packages (if this option isn’t enabled, make sure you have you UWP project selected in Solution Explorer). Follow the prompts to do a Store build – this should generate an .appx file you can work with.

What we’re going to do is manually modify the generated package. From the Start menu, select the Developer Command Prompt for VS2015

Change directories to where the .appx file resides. Execute the following command, substituting you .appx filename. This will extract the contents of the .appx file into a sub-folder called “export”

makeappx unpack /nv /p myapplicationpackage.appx /d .export

Open the AppxManifest.xml file using your text editor of choice. Locate the line that looks similar to the following and replace the MinVersion with the version number you want to target (ie 10.0.10166.0)

<TargetDeviceFamily Name=”Windows.Universal” MinVersion=”10.0.10240.0″ MaxVersionTested=”10.0.10240.0″ />

Close and save the updated AppxManifest.xml file. And return to the command prompt and execute the following (again feel free to replace the .appx filename)

makeappx pack /nv /d .export /p myapplicationpackage-updatedversion.appx

And you’re done – submit this package to the Store, and a couple of days later (yes, whilst certification only seems to take a couple of hours, the distribution of UWP apps is very slow at the moment, so expect to wait at least 24hours from when certification is completed) you’ll be able to install your application…… of course, all of this could have been saved if you’d just updated to the latest Windows 10 Mobile build, which I’m about to do now!

Visual Studio 2015 RTM, Universal Windows Platform (UWP) Developer Tools and Debugging on a Windows Phone device

Visual Studio 2015 RTM, Universal Windows Platform (UWP) Developer Tools and Debugging on a Windows Phone device

If you’ve upgraded to Visual Studio 2015 RTM with the associated Universal Windows Platform tools, you may have realised that you can’t deploy apps to a real Windows Phone that’s running the current Windows Insider Preview build for Windows Phone. This is because the version of the SDK, which has a version/minversion of 10.0.10240.0, is higher than what’s currently available for the phone. For application development and testing this means using the emulators that ship with the SDK.

Of course, this isn’t a great story as lots of developers much prefer debugging on a real device. In fact there are scenarios where a real device is the only way to test some scenarios. I came across the following post that provides a temporary, NON-SUPPORTED solution.


The solution rests on manually changing the TargetPlatformMinVersion property in the UWP project file to be the same as what’s running on the phone (in my case 10.0.10166.0). Don’t change the TargetPlatformVersion property – doing this will mean that you won’t be able to open the project in Visual Studio since that version isn’t supported with the SDK.

WARNING: Whilst making this change may mean that you can debug your application on a real device, just be aware that it may through weird errors if you happen to try to access an API that has actually changed between 166 and 240 builds. Your code is still going to be built against the 10.0.10240.0 API set, you’re just lying in the package manifest, claiming that your app will run on a previous version.

As you can imagine this has been designed with future versions in mind. If you open the project properties dialog for the UWP application you’ll see that on the Application tab there is a Targeting section. In the current SDK there is only one option for the target version and min version. Going forward you can imagine that a future SDK will allow for selection of 10.0.10240.0 (the current version) and a future version (where APIs may have evolved).


Application Development Using States and Transitions

Application Development Using States and Transitions

Having worked with each of the different XAML based technologies Microsoft has released (WPF, SL, WP, Win, UWP…), I’ve long been a proponent of the use of visual states. Jerry Nixon discusses using visual states to build Windows 8.1 application. I’ve written articles that talk about using visual states for changing page layout to reflect states within a view model. Let me talk briefly about why I favour visual states and why the visibility property is often misused…. then we’ll get onto discussing using states for building applications.

Developers new to working with XAML discover that they can hide/show items on the page by data binding a Boolean property on the view model (this assumes they’re using mvvm/data binding) with the visibility property on an element. This of course requires a Boolean to visibility converter. It works nicely and assuming the developer has implemented INotifyPropertyChanged and is raising the PropertyChanged event correctly, the elements on the page will hide/show as required.

Whilst there isn’t anything wrong with this approach, it makes it difficult to design the layout in Blend. In order to hide/show elements, you have to modify the design time data (assuming you’ve bothered to create design time data). The alternative is to use visual states to describe how the page looks for each state. Blend for Visual Studio includes a States window which allows for one or more states to be invoked, making it easy to create, view and edit visual states, at design time!

Ok, time to move on an talk more about using states as a foundation for application development. Unfortunately we can’t jump there yet as we need to first look at different levels of how an application hangs together. Rather than get into a discussion on the similarities and differences between application platforms, let’s just look at the Windows platform (this should apply to Windows Phone, Windows 8.x and Windows 10):

– An application typically has a frame, within which it navigates between pages

– A page can be made up of any number of visual state groups, and can have a single visual state selected at any time from each visual state group. Animations can be run as part of transitioning between states.

– Controls (including Usercontrols) can contain their own visual states that determine how they look under various conditions (pressed, checked, selected etc).

What’s interesting about this is that the navigation between pages is actually the odd one out. Most application developers devote a large portion of the application development process to ensuring the navigation between pages is correct. They spend very little time working through the visual states of pages (often hacking away at hiding/showing elements on the screen). So, what happens if we make the assumption that each one of these scenarios can be expressed as a series of states?

As a starting point, we’d need a definition of a state. In the past, to keep the states of a view model separated from the visual states on a page I typically create an enumeration which has values that have the same names as the visual states. The view model then keeps track of which state is currently selected. Changing the current state raised a StateChanged event, which is handled by the page where it invokes the GoToState method on the VisualStateManager. My basic definition of a state will be an extension of this where the IStateDefinition is based on an enumeration type (well, at least a struct):

public interface IStateDefinition<TState> where TState : struct
    TState State { get; }

with a simple implementation:

public class BaseStateDefinition<TState> : IStateDefinition<TState>
    where TState : struct
    public TState State { get; set; }

And we can then define an interface for an entity which maintains current state, allows for a change in state and raise an event when the state changes:

public interface IStateManager<TState> : INotifyPropertyChanged
    where TState : struct
    event EventHandler<StateEventArgs<TState>> StateChanged;

    TState CurrentState { get; }

    IDictionary<TState, IStateDefinition<TState>> States { get; }

    Task<bool> ChangeTo(TState newState, bool useTransition = true);

The first instinct would be for the view model to implement this interface, but this won’t work since the view model would have to implement the interface for each state group that it needs to track. This means we need an implementation of this interface that tracks current state for each state group:

public class BaseStateManager<TState> :
    NotifyBase, IStateManager<TState>
    where TState : struct
    public event EventHandler<StateEventArgs<TState>> StateChanged;

    public TState CurrentState { get; private set; }

    public IDictionary<TState, IStateDefinition<TState>> States { get; set; }

    public async Task<bool> ChangeTo(TState newState, bool useTransitions = true)
        var current = CurrentState;
        if (current.Equals(newState)) return true;

        CurrentState = newState;

            StateChanged?.Invoke(this, new StateEventArgs<TState>(newState, useTransitions));
        catch (Exception ex)
            // Ignore any errors caused by the event being raised, as
            // the state change has still occurred
        return true;

We’ll use this as the basis from which we can track states at an application, page and control level.