Writing Apps Part III: Xamarin for iOS
May 5, 2014
This is the third in a series of articles about writing mobile apps; the first and second using WinJS, and this time iOS using Xamarin. In this article I’m going to talk about where I came from as a developer making some of these decisions, the philosophy of being a programmer in the weird-weird world of mobile devices, and what I want.
First Things First
There’s a lot of invention, learning, energy, community, and opportunity as a web programmer. There are more “traditional” programming roles (desktop, ERP, network), with older more staid languages and platforms, but I’ve never clicked with those. I was on a big project writing a medical records system in WPF a couple years ago. It was interesting, had some great tools, and then when the project was over I was thrilled to be back on the web for the next project. And I don’t think I’m alone: look at github and bitbucket and you’ll see a lot of web-oriented stuff.
Let’s discuss phones, tablets, and the war of the mobile platforms.Today there are three major contenders (arguably two, but I’ll get to that) in the smart phone arena: Google’s Android, Apple’s iOS, and Microsoft’s Windows Phone. Because of market share, a lot of companies aim their development energy at iOS first, with perhaps some plan at standing up an Android version sometime in the future. Windows is sort of a blip on the radar.
Laziness is a Virtue
On the web, getting your web application to look and play nicely on every browser and operating system is a matter of tweaking, but not so for iOS and Android. As a programmer you understand that they will be completely separate entities, with very little re-use of code. Basically, everything is twice the work. And if you want a web version, it’s three times the work. If you count Windows Phone, four.
In an effort to ease the pain and standardize some of this, Xamarin has released a product that lets a programmer write once and deploy to multiple platforms…Sort of. It takes a certain learning curve. More to the point, it takes knowledge of all the platforms, and of Xamarin itself.
As I stated at the outset, I’m not an iOS guy. But I’m writing an iOS app right now using Xamarin. There are some harsh criticisms, but overall it’s a solid product built on a solid idea. But there’s a hidden cost: architecture. In order to take full advantage of Xamarin, you have to know your way around iOS and Android. So to stand up an app in Xamarin you’ve got a double or triple learning curve. All of that is to say, you’re going to pay somewhere.
On the server side (the back-end of the mobile app) things are calm. There are great languages, unit-testing frameworks, best practices, and you only have to write the back-end stuff once. So why do things suck on-device? There’s a really great post by Tim Bray that talks about this in detail.
Good Times Are a Comin’
Bray is smarter than me, so I’m not going to argue with him too much. One thing I do disagree with is where we’re going and why; things aren’t going to stay the same. There are too many smart people in the web world hacking away at the “mobile problem” for it to stay a problem for too much longer.
Bray’s argument is that there are great UI engineers at Google and Apple who are constantly raising the bar on user experience, and that browsers still sort of suck, especially on “memory-starved, CPU-starved, and battery-starved” smart phones. I don’t argue with that. But despite all that, web sites can be done really well, even on a device.
The short version of my opinion is that UX and UI on an iOS or Android app is great in the same way your four-year old kid is great at bowling. I’m great at bowling too when there are bumpers to keep me from falling in. Apple forces app developers to follow their patterns- they put up bumpers on either side. It’s resulted in uniformly high-quality inventory for the app store. So in the app world, deviation from the norm is very difficult- it eliminates a lot of really lousy apps from ever seeing the light of day, but it also keeps some really innovative ones out too.
There isn’t the same cost of entry on the web: lousy websites are published everyday. But brilliant ones are too.
It Can Be Done: We Have the Technology
Microsoft is lurking behind the scenes in this battle, waging the war they’ve won time and again. Sure, reviews say Windows Phone is actually pretty good, but people are still looking at iOS and Android first. MS knows they won’t win the battle on marketing or UX alone. They are playing a different game: tools.
A couple years ago MS announced their own tablet PC, the Surface.
It’s not been a huge success, but it puts MS directly into the consumer market and let them line up their army of programmers behind a product. Apple is driven by image, Google by its ideas, but Microsoft is driven by its products. And they have lined up a stack of products and tools that make them a formidable presence in the tablet world.
See, MS quietly calls the shots for a lot of people who don’t even work at MS. At the end of last year I wrote a tablet app using WinJS (1 and 2). I did it because MS provided a better tool than anyone else. While I have some criticisms of the platform, I think the spirit and idea is right on. Likewise MS .NET web applications are fun. Even writing WPF is rewarding. All of them are engaging because Visual Studio (MS’s programming IDE) is a great tool.
It’s a phenomenal product in the sense that there is brand loyalty. Visual Studio has been around since about 1998. The latest version is really good, and programmers have kept using it. MS uses that loyalty to great effect: when they wanted to get into the enterprise web application market in the early 2000s, they released Visual Studio.NET and got programmers excited about using a familiar tool for a new and powerful purpose. So it’s not a coincidence that MS is pushing a new set of mobile development tools. They want mobile apps, tablet apps, and they have that army of loyal programmers. Provide the tools, and the apps will follow.
The app that I’m writing in Xamarin is moving forward well, but there’s a pattern emerging. Whenever we want to build graphically complicated lists, we display it in a web view and let the browser render it for us. It takes less code, more members of our team have experience with HTML, and gives us access to some really great open source libraries for user interaction. It ends up feeling a lot like the WinJS app I wrote last fall.
We had a long internal discussion about consuming HTML in an app: why bother writing an app if it’s just a web page? In truth, it isn’t, but it’s worth talking about. The app still does a lot of heavy lifting, but using the browser to render stuff is really appealing because that’s what it’s designed to do. And with some good CSS, it does so fluidly and responsively. But at what point does it become a web application in an armor suit?
And now that I think about it, I inherited an application a few years back: the company who wrote it decided that update cycles would kill the project, so everything was delivered in a modified version of Webkit via QT. In short, the user interface on a desktop application was actually a web browser. No one seemed to know it- it just worked.
I Want the New Normal
I want to write once and deploy anywhere. That was the promise of web applications. It hasn’t quite happened yet, especially with the explosion of devices, but I think it will. And I’m looking forward to it. With frameworks like Ruby on Rails or .NET MCV, Bootstrap, and thousands of free libraries, we can stand up non-trivial apps on the web very quickly.
Yes, we can write great web applications that feel like whatever platform they’re supposed to live on. Yes, we can make them fast, beautiful, and useful. And we’re almost there. I want that to be the new normal.
Stay up to date with our email updates!