As a companion piece to my review of the Phonos app, I thought it would be interesting to check in with Andy and get some background on his experiences whilst developing for Windows Phone. Originally, on the team that built the ill-fated Kin devices he has since been working on Windows Phone 8.0 Apollo. Andy shares his experiences with bringing his app to market. He tells us about hurdles hes overcome with the platform, thoughts on WinRT development and much much more... For these insights you’ll need to keep on reading past the break..
Robert: Andy, please tell us about yourself, how you got into developing for Windows Phone?
Andy: I’m an ex-pat Englishman living in Seattle. I am a developer at Microsoft, and when I started Phonos I was on the Windows Phone team. Whilst I didn’t work on WP7.0 or Mango (7.5) I was one of the first to work on Apollo while everyone else was on the CE-based versions. Being on the team gave me early access to phones and tools, I knew C# but did not know much XAML. I had been on the KIN team before that, and although everything in KIN was done in Silverlight I had never worked on any UI myself so it was mostly a mystery to me.
Robert: Phonos development, it’s just you or is this a team effort?
Andy: It’s just me. I have a few beta testers, but I find I need them less now as the code is pretty stable. I usually target new features at specific testers these days. I usually work on it most weekends, especially if it’s rainy, which often it is here.
Robert: Can you explain why you chose to do a Sonos Controller app?
Andy: I learnt my “Sonos chops” originally on a PC app, built in C# and using a primitive ugly-as-sin WinForms user interface. This allowed me to focus on the UPnP APIs that the Sonos system uses, so I could figure out how to enumerate and play music without having to do the UPnP plumbing (as it is built into Windows). I always knew I wanted to control my Sonos using my phone, so as the 7.0 SDK came together I tried to port the basics of my code, but soon realized that not only was UPnP missing from the phone, but so was the networking code that I needed to write my own UPnP stack.
I learnt the basics of WCF, wrote a UPnP server that ran on the PC and a phone app that communicated with it over Wi-Fi. Until Mango fixed the networking problem, the original version of Phonos required a PC app, that was painful for my customers and me. Every phone is the same, but there are so many different configurations of PCs (and firewalls), writing a Setup app was a chore I never relished. Fortunately, WP7.5 came along and solved the networking problem so then I started writing a UPnP stack for it. Good thing I did as I found some nasty bugs in the network code before it was released. You can follow my technical progress through all this from my blog on MSDN, many of the articles on there were direct results of what I learnt developing Phonos here.
Robert: Do you worry about Sonos releasing an official Windows Phone version?
Andy: I guess at some point Sonos might release an official app, if they do then that will be great for Windows Phone users, as it will have every feature. I don’t have the resources to reverse-engineer then re-implement every single feature the official apps have. I focus my app features on the areas that I think people use the most, like playback control, group editing and music selection.
Robert: Your app is UK £7.99, as far as mobile apps is concerned that is perceived by some as quite a high price, could you explain how you arrived at it? Do you think a lower price might encourage more adoption?
Andy: First off, the Trial mode that WP offers is awesome, it lets folks download and try the app first, before committing their cash. It’s particularly important for the pricier apps like mine. Secondly, there is an unofficial Sonos app for Blackberry I only recently discovered, and it is $19.99, so I guess I am not unique with my thoughts on this.
My app is considered “expensive” by phone standards, and that was an explicit choice. This isn’t in the “fart app” category, it’s not something simple thrown together on the weekend, published, and never updated. Phonos is never going to be a million seller, as it’s restricted to Sonos customers who have Windows Phones.
I was originally going to charge $25, but feedback from a well-heeled Sonos-owning co-worker made me rethink that, so I chose $10. My trial-to-buy ratio is way better than 10%, so even if I made the app $1 and everyone who ever downloaded the trial bought it (unlikely) I’d make less money overall. The software is undergoing continual development, and I like to give proper support to paying customers, so I feel justified in charging a reasonable amount.
Sonos owners by definition have probably spent at least $500 (£400) on their systems, some much more, A $10 app so they can use their phone as a controller seems great value to me. Before the iPhone came along any software for $10 would be considered a bargain, of the things I do not thank Steve Jobs for is reducing the price of what I consider “real software” to a pittance. To be clear this app is not my retirement plan. I worked out that if I did this full-time I would not be making minimum wage with it. However, it is a nice source of beer/coffee money, and the income helps keep me motivated to update it regularly.
Robert: How have you found the development experience on Windows Phone and how was it working with the Sonos system in general?
Andy: Although I worked on the Phone team, I didn’t have anything directly to do with the phone tools, though my greater team did, I think my co-workers did a pretty great job with the tools, as well as with the APIs and the code underneath them. I was less enamored with some of my ex-KIN teammates who worked on the App Hub as it had some real problems in the 7.0 timeframe, but many of the things that originally bugged me have since been fixed. I have only used Microsoft tools for the last 20 or so years, so I cannot really compare them to anything else. I did recently witness someone using Objective C on the iPhone and it looked horrific!
Working with the Sonos gear has been a mixture of fun and frustration, devices expose their APIs via UPnP and most things are straightforward to figure out either simply by looking at the APIs or a little network packet sniffing. However, the Music Service support is all via private APIs and is often encrypted, reverse engineering those is hard work. My proudest moment was probably getting WiMP support working, despite the fact that I can’t even get WiMP (a music service) here in the USA (it is geofenced). I had a keen beta tester who was willing to send me network captures from Sweden to try out random changes until it worked.
I have tried to share my most important technical phone tips on my blog, but I save my more opinionated feedback for the team internally, we have a very active mailing list for employees writing apps. We are fortunate that Microsoft made a special dispensation to allow employees to create, publish and profit from apps without causing legal problems with our employment contracts.
Robert: Any experiences you have had with developing for WP7 that you would like to share, pitfalls, advice to others when going to marketplace?
Andy: I avidly follow the posted reviews of my apps (using “App Reviews” from Ashterix) and that can be a double-edged sword. You will need a tough skin, as some reviews can be seriously harsh. Also, don’t expect the negative reviews to be constructive, few contain actual reasons for low scores. The negative reviews for Phonos since its release did have some common themes (I had real trouble with the volume slider for over a year, for example). I am pleased so say that since the 3.0 release I haven’t had a single bad review. (Famous last words, right?). I also created a Facebook page for my app and that has proven a great way to get involved directly with customers. I use it to announce new versions as well as receive suggestions and feedback in a transparent way. I also lurk in the Sonos forums a lot, to see what features people are asking for in the official apps as well as the never-ending thread for an official WP app.
For others producing non “fart-apps” I encourage you to add analytics to your app so you can see exactly what features your customers are (and are not) using (I use Flurry) and to keep a close eye on the crash data via the App Hub and “LittleWatson”. Also, be sure to make it easy and obvious for customers to contact you via email or Facebook.
Another strong recommendation is to use source control. I use Perforce, which is free for small projects like this and integrates well with Visual Studio. I have only had one failure when submitting to Marketplace (regarding audio control): be sure to re-read the requirements before your first submission attempt to avoid easily correctable hiccups. Before real submission, I highly recommend submitting a beta version, not only does this let others test your app, but it can also detect rare problems in the automatic capability-detection code which otherwise can cause your app to not work at all once signed (background audio playback had this problem).
If I did it all again what would I have done differently? I’d probably get the assistance of someone with good UI/XAML skills and can create icons, my customers have often noted the whole “UI thing” is not really an area of expertise for me and icons take me the longest time to create and look pretty uninspired.
Robert: What are your thoughts on the Microsoft eco system right now?
Andy: I think the Mango eco-system is good, but sorry, I cannot say much about Apollo or future platform improvements I would like to see because I “know too much”. However, I can tell you that most of my desires look like they should be met ;-)
Robert: What are your thoughts on WinRT and Surface?
I do like the look of Surface although I haven’t seen one in the flesh yet (too secret even here) but I’ll have to get the ARM one as soon as I am able to.
Robert: Tell me about your future plans.
Thanks for your time Andy, some great insights!
You can check out the app here.
We may earn a commission for purchases using our links. Learn more.