Experiences of writing my first UWP app

I recently wrote an app called Store Insider which tells you the latest version of any Windows store app, and when it was last updated. Through this post, I’ll share my experience of making my first UWP app.

Why?

Well, the simple answer is that the Windows Store s̶u̶c̶k̶s̶ isn’t as good as I want it to be — even after 2 years, the store doesn’t tell you the app’s version number, when the app was last updated, etc. The store in Windows Phone 8.1 did show the versions after all! Yes, there is a contrived way to see the app version by going to “Downloads and Updates” and under the “Recent Activity” head, the versions and last updated dates for the apps you’ve already installed show up.

Versions and last “modified” dates for apps I already own :-(

Well, while that’s better than nothing, I also wanted to see the current version of the app I’m going to install. Is the app in-beta? Is the app being maintained — given the recent state of Microsoft’s attention towards mobile, the default option to that question is to assume “no”, even when the desktop app system is much better by comparison. Thus, given the state of the store (esp. the mobile side), I think a higher level of transparency from MS could build a better trust within the ecosystem.

Another good reason for me to give it a shot was because most of the work for my app was already done! I found this awesome website called WPSnitch which basically had the same functionality as a web app. And getting a look at the whole source code was definitely handy. So I calculated that all my lazy ass had to do was:

1. Rip out the source code from the wpsnitch guy — max time: 1 hour
2. Make a UWP app which implemented the same stuff — max time: 1 day
3. ???
4. Profit!!!

The road to profit

First, the source code for wpsnitch. Though I don’t know much python, it was well-written and straightforward enough to get it through my head in about the time I assumed it’d take. And so, I proceeded to step #2, which was to code the UWP app.

So, I fired up Visual Studio on a sultry Sunday afternoon, and started off with a simple template. Having worked with C# already as an intern in the past, I chose that option to get started. Also, I wanted to see how developing in native XAML/C# felt like.

So, I created a new project with the “Blank App (Universal App in C#)”, and followed the official UWP tutorial.

First UWP app!

To say the least, I was pretty excited with the whole thing about starting off a new app, and created the UI in a breeze and ported over most of the python code to C# (and eliminated the legacy windows store code — more on that later). I was on time to creating the app (3 hours of work). If everything went well, I’d publish the app by 10pm, and by the time I wake up, tens of thousands of people will be using the app! So, I fire up the app to test it out an app URL.

Speed bumps!

Murphy’s law struck on first go! The app crashed in spectacular style due to some error, and it took about an hour to find out that the Windows Store API I was using to fetch the app data was not very consistent in the data it returned. And I also found out that working with APIs in Visual Studio is not as easy as it is with Chrome — there’s no inspect response, retry request, etc. So all I could do was launch the app over and over with logging response objects until I could figure it out. Maybe there are plugins like fiddler which might have helped? I sure as hell didn’t think of that at that time. And thus, tired with all the logging and debugging, I found out that 10pm had come and gone, and I was sitting there burning the midnight tubelight working out basic bugs. So, off I go to bed at 1am, accomplishing nothing.

Week 2

This being a side project, I took it up next Saturday, confident I had figured it all out. I fixed the bug in about 20–30 minutes, and then it seemed like everything was working for any app I checked on the Windows 10 Store. Time to build it and run it on mobile. So I connect my Lumia 950XL via USB, and launch the app there, and after some issues, finally I’m able to run it. The first app I try, Whatsapp, fails. Because it’s not a Windows 10 Store app, but a Windows 8.1 Silverlight app, so the API response would be nothing I was expecting. OBVIOUSLY! After going 4–5 more hours with figuring it all out, I figured it was time to build a production build and use it on my phone. This should be easy.

Building for production

Now, although I’ve not mentioned this before, while developing the app, I was using VS 2015. Then, I was notified by Microsoft that a newer version, VS2017 was available with some nifty performance improvements. “Wow! Nice! I might save some time building stuff” I thought. I updated the IDE to the latest and greatest version so that my productivity improves. Well, I should have done some calculations first. After updating VS to 2017, things went wrong — horribly wrong. I couldn’t even get the project to compile. Not being in-touch with how VS worked for a long time, the misery was compounded by VS throwing weird non-obvious error codes at my face, something which Microsoft apparently excels at:

Your project.json doesn't have a runtimes section. 
You should add '"runtimes": { "win": { } }' to your project.json and 
then re-run NuGet restore. RethinkDb.Driver

Where do I add this project.json? Even after adding the project.json with the recommended suggestion, the app failed to compile. Even after copying the project.json file to every possible directory, sub-directory, and parent-directory, VS didn’t budge. Then, lost and spent, I turned to google, and yup, people were having a lot of this kind of problems. So, I tried most of the suggestions mentioned in the issue in MSBuild’s official repo. And none of them worked. So, I put my head through the wall and gave up for 2 weeks.

Building for production — try 2

After recovering from the aforementioned trauma, I manned up and waded back into the mess that my project had become. Googling some more brought me to the realization that updating the Visual Studio version might have been a mistake. Since I’m writing this blog post after quite some time, I don’t remember exactly what broke, but I all I have got left from that is a small note left in an untitled file which reads:

Move to vs2017 broke some things, such as nuGet 4.0? Project was started in vs2015, but moved to vs2017 (due to expectation of ‘cool stuff’). In the end, had to create a new project, and copy the files over.

So, I guess that was it. Started off a completely new project in VS, spent some time copying the old code and installing dependencies again with nuget, and the project compiled on first go! Things worked well enough on my phone and on the desktop to warrant taking the next step — publishing.

Publishing to the store

To publish the app to the store, VS does a bunch of automated checks and tells you to put app description and images and stuff in your manifest. The steps seem easy enough, and I did complete most of it. To list the app on the store, VS asks me to put the app’s logo in a zillion different sizes — 100x100, 50x50, 100x100_size50, 50x50_size100, and so on… The names were very confusing, but at least VS offered me to upload a vector file and autogenerate the whole batch for me. Good, I thought! But then I find out that it won’t accept SVG, but for some reason, AI! Won’t implementing support for SVG be an easier choice than some proprietary standard? Anyways, so I upload the logo and everything goes fine. But I find that at a particular size, my logo looks like utter shit, so I go ahead and delete the resource. And then, another level of hell broke loose. VS won’t publish the app, and I can’t “re-add” the logo — even after running `git reset HEAD — hard`. I don’t understand why VS is so opaque in these things, and surely there must be a better way to communicate such issues to the new developer than throwing undecipherable errors. Finding such stuff on google didn’t help either, so I had to post a question on SO, which got a few helpful suggestions. But look at this answer! The amount of work involved, and that too, by opening the project file in another editor, just to fix an issue which VS should handle by itself is incomprehensible. Well, it did fix the issue though.

So, finally, I was able to build and submit the app to the Store for review. The submit screen said to expect about 3 days to get listed in the Store. Though like everything else till this point, 3 days came and went, with not a peep from the MS Developer Center. Contacting Support seemed to push things along, and finally, the app got published to the Store.

Overall Experience

1. Fun — yes. I mean it was frustrating with the issues I underlined earlier, but it was also fun. Developing with C# is pretty good and building interfaces in XAML is a pleasant experience. I do web development in ReactJS currently, and have been doing JS development for quite some time, but going to C#/XAML doesn’t feel too alien.
2. VS feels nice, but coming from a web-development background, some things are different and sometimes very painful, such as installing dependencies via nuget — like when things go wrong. Makes you appreciate the work the npm community (and others!) have done to make it so easy.
3. After figuring out how to do it once, cross-device builds are very easy to do. But the figuring out part is not straight forward — visual studio was throwing some weird errors about targets while trying to compile app for ARM (Lumia 950xl). Maybe switching to vs2017 mid-development might have caused those issues too?
4. XBOX and Hololens!

Issues Faced While Releasing

1. Many controls which UWP apps now generally have are not in the default “toolbox”, such as the familiar-but-controversial hamburger menu, etc. You should definitely use the UWP community toolkit for your UIs to kick some ass!
2. While the app built fine in development, when I built for Release, it failed because the .Net Native Compiler did not understand implicit reflection?
   I kept getting a `reflection_insufficientmetadata` error.
   Ref: https://www.google.co.in/uwp+reflection_insufficientmetadata
   Ref: https://docs.microsoft.com/en-us/dotnet/framework/net-native/reflection-and-net-native
   I was using dynamic types while parsing JSON via the Newtonsoft.JSON lib. In the end, I ended up removing the ‘dynamic’ type, and making it static.
3. This might be an isolated problem, but the Microsoft Store certification process was extremely slow. They say they’ll take 3–5 days to get the app on the store, but it took more than 2 weeks for the Manual review process to take place. I hope the process improves in the future.