Windows Phone app submission "signing failed"

If you ever get a submission report like this (above) it can be quite disconcerting. It's realisitic to think that you may have done something wrong or missed something that caused this.

If you get this it can also be hard to know what to do next. The dev center will provide no more information and there isn't a lot in the forums either.

If this happens to you though, fear not. If you've run the xap through the store test kit and verified capabilities and requirements there could be another reason for this status.

Simply try uploading the XAP again. You may get this if there was a problem (corruption?) during the upload process.

It worked for me :)

I'm speaking at MobDevCon in July - Tickets on sale now

On July 3rd, Naked Element will be hosting Norfolk's first ever Mobile Developer Conference. I'll be there to speak about Windows Phone and application pricing.

Early bird tickets are now on sale from http://mobdevcon2013.eventbrite.co.uk/#.
You can find out more about the conference at http://mobdevcon.com/

Why Windows Phone isn't more popular - the view from the phone shop

I know there are lots of people developing apps for Windows Phone who bemoan it's small marketshare. There are lots of opinions on the success (or lack of-depending on your perspective) and these are often informed based on the perspective of the person talking. That is, developers typically think from a development perspective, etc.

Last week I had the opportunity to talk with a number of people who have a very different perspective to me and a different view of the mobile marketplace. I got to speak with a number of people who work in the operator, and independently owned, stores where a large number of people get their phones. They advise people on what phones people should get and know exactly what people are after when they choose a phone.

When asked about Windows Phone they were generally positive about the platform and spoke highly of the cheaper devices (Lumia 610, 620 & Ascend W1) and have seen some of these sell faster than they can stock them. It's when I talked about apps that things got interesting though.

There were 4 key points that I think developers should take note of (even if there is one that they probably can't do anything about themselves.)

1. The number of apps on a platform doesn't matter to people buying phones
700,000, 500,000, 130,000 - they're just big numbers and don't really impact purchasing decisions. I suspected this was the case. They're just a useful metric for journalists to compare platforms. I suspect changes in the rate of new submissions and updates is a more useful metric for platform health but harder to obtain than number of apps in store.

2. Having certain apps on a platform matters
While the total number of apps isn't seen as important, there are certain apps which are seen as essential. These fall into two categories: communication and flavour of the month.
Apps which enable communication between users on different devices (be that text based messaging, voice calls, picture calling or anythign else) need to be on the platform. If a person choosing a phone used a certain app on their old phone and all their friends/contacts use that app too (on other platforms). They won't choose a phone which doesn't have it. It'd mean being unable to communicate with their friends/contacts and isn't that the primary purpose of a phone anyway-communication?
"Flavour of the month" apps are those that everyone is talking about and using right now. Be that a game (usually it's a game) that allows you to throw animals, guess words or draw pictures, if "everyone" you know is talking about and using such an app you risk being left out if you can't get that app too. Coming to a platform 6 months after everyone elase has stopped talking about or even using the app doesn't help.
These may seem trivial issues and you could argue that there are alternatives available, but these are things that affect the phone people choose!

3. Feature parity matters
If an app is on multiple platforms but doesn't have the same features users can feel tricked. Say, for instance, you and your friends use a certain app for group messaging of texts and photos. If you get a new phone and have been told that it supports that app, it'll reflect badly on both the app and the phone if you get home to discover that the app on your phone only supports text messaging and not picture messaging as you'd suddenly be excluded from certain conversations. Not something you or the people using your apps want.
If an app is missing key features it would be better, in some peoples eyes, if it wasn't there at all!

4. Quality matters
While the number of apps doesn't really matter, the quality of the apps that people do choose to use does.
Windows Phone apps are generally perceived as being of a lower quality than apps on other platforms - people you need to raise your game!


What can we, as developers, take from this?
Three things:

• Focus on quality, not just quantity.
• Support multiple platforms. Especially if there's a social aspect to your app.
• Aim for feature parity (especially core features) when moving to multiple platforms

Where to get icons for your app?

So, you need some icons for use in your app.

If you just need icons for the application bar buttons, then start with the ones that come with the SDK. You'll find them at "C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Icons\Dark\" and these are also the ones that Blend can add for you.

If you need more then there are a numberof free resources available:

Metro Studio 2 (By SyncFusion)

It's a downloadable app that comes with 1700 FREE icon templates that can be sized and modified as required. You can see all the icons at http://www.syncfusion.com/downloads/IconPackagePopup/Application

The Noun Project

Loads and loads of icons that you can search online. Download what you want in vector formats. Most are creative commons licensed and/or very cheap to license. (I've never paid more than $1.99 for an icon there.)

Modern UI Icons

A collection of almost 1000 free icons. They're availabel sized for the application bar and in vector formats.

iconmonstr

1300+ icons thast are free to use in personal and commercial projects. They're also helpfully categorized to make it easy to find what you're after.

There are also other sources and you could always make your own or commission an icon if you needed something special.

As an extrs tip, it's usually best, as far as possible, to get all your icons for an app from the same source. This helps make it look like they all belong together. If you have small/subtle differences between icons (e.g. differing line weights or the radius on rounded corners) then some people will spot this and will think it looks bad. Remember, the little details matter.

Microsoft's advice about Panoramas is wrong!

The advice Microsoft's designers will tell you (23:30 into the video) about a page hosting a Panorama control is that the page should not also include the System Tray.

This is wrong!

Let me tell you why.

Consider this scenario:

A person launches your app and upon starting it attempts to load the latest data from a web server or other external source. - Hopefully you'll agree that so far this is a reasonable and common scenario.

After a few seconds no data is displayed and the app still indicates that it is "Loading...". - Again, a common occurrence.

Now what?

Well, the person wonders if the delay is due to not having a connection or maybe they've only got 1 bar on a 2G network. - I hope you still think this is a not unreasonable scenario.

So, having wondered about connectivity, what does our person do?

Well, they swipe down from the top of the screen to reveal the network connectivity indicators that are included in the System Tray.

And it's at this step that we reach the crux of my argument.

If the page includes the System Tray the person will be able to see the state of their connectivity. If they have a connection they'll probably wait a little longer. If not they can, hopefully, do something about it.

But if the page doesn't include the System Tray what can they do?

They can do 1 of two things.

1. They can wait longer, but with the uncertainty of not knowing if the connection is there and if they'll ever get a response (at least until the connection times out.)

2. They can leave the app and check connectivity there.

If 1, you're forcing the person using your app into a situation of uncertainty with your app that can't be a good thing. Uncertainty in what your app will do, or when, is not a feeling you want to instil in people.

If 2, you're forcing people to leave your app when they want to use it. You're also increasing the likelihood that they won't come back. I'd be amazed if you want the people who have downloaded and installed your app to not be using it when they have wanted to.

My advice:

Include the System Tray on any page that has content that comes from a remote source.

Microsoft doesn’t even follow their own advice!

Checking on the WP8.0 device in my pocket I can see that:

While the store, music and video hub, games hub, photos hub and wallet don't include the system tray, the People hub and the Office hub DO include the System Tray

The exception when this isn't true.

My reasoning above is based on a Panorama with dynamic content that is obtained from an external source. Obviously there are apps which use a Panorama control but don't use external content. (I've even written some.) In this scenario there is, potentially, very little value to the including the System Tray and so there may be an argument for not including it.

Yes there is potentially an argument for including a System Tray even if the Panorama uses entirely local content so that it's possible to see things like the clock and battery status. Include it at your discretion in these scenarios.

Disclaimer. Yes the title of this post is quite broad-brush and I'm only talking about a potentially minor issue here. I understand that but small details matter.

tl;dr: DO include the System Tray on Panoramas. Even though Microsoft tell you not to.