Ever faced with choosing among competing frameworks; needing to make a decision you/your customer won't regret? If those frameworks are for building cross-platform mobile apps and are Xamarin and Ionic, hopefully this article will help.
The background is I had the somewhat rare pleasure of working on these competing frameworks on back-to-back projects recently. Project #1 used Xamarin (and Xamarin Forms more specifically), the C# based framework for building fully native, cross platform apps.
And what if I had to recommend one? I'd probably want to think about a customer's budget, desired end product, and timeline. I'd consider development speed, ramp up time, and maintainability. Basically I'd evaluate based on the following six criteria:
1. Price: Ionic++
The single most obvious framework differentiator is price. Ionic's free price tag may seem like a no brainer. However, as of this writing Xamarin costs roughly $1,000 per developer per year. That prices is quite doable for most companies, especially if there is a compelling enough reason. Two very compelling reasons are:
An organization has only .Net developers; or
An organization's architecture is exclusively .Net
If these bullets apply, then the price is likely justified, and the Xamarin choice obvious. However, should one have a mix of talent and technologies, or no current Microsoft technologies, then free is hard to beat.
It's worth noting that Microsoft's recent acquisition of Xamarin could change this proposition significantly. Should Microsoft include Xamarin in an MSDN subscription, the price would be eliminated as an issue for companies who are current MSDN subscribers.
2. End Product: Xamarin++
Your customers won't be able to pinpoint exactly why they prefer your competitor's fully native app, but you're more likely to lose in the end
Surprise: an HTML-based app, however well styled, will never look, feel, and perform like a native app.
How different is the Ionic look and feel? If you stick to the default controls and don't overly customize, I guarantee your users won't notice. However, faced with a choice your customers won't be able to pinpoint exactly why they prefer your competitor's fully native app, but you're more likely to lose in the end.
We were lucky enough to have a full-time design professional provide assistance on the Ionic project, and several of his (fairly time consuming) suggestions would not have been an issue if we'd gone with Xamarin. Furthermore, the UI always felt a little laggy, even with theoretically GPU accelerated CSS3 transitions.
Simply put if you want the best, fastest, most authentic experience for your users, Xamarin is the clear winner.
3. Development Speed: Ionic++
If you need to get an app out the door yesterday, Ionic is your friend.
Development speed differs between the frameworks in two main aspects. First is the amount of time from writing a line of code to seeing results. For Xamarin, pushing out code to an iOS device required several seconds of compilation plus 10 to 15 seconds of deploy time. Ouch.
By comparison Ionic with a ripple emulator provided zero-compilation, sub-second feedback times. This feature alone significantly increased development speed. Perhaps more importantly the fast feedback cycles actually made coding more fun.
The second development speed difference was in UI debugging. Ripple plus Chrome tools made debugging the UI in Ionic amazingly easy. With Xamarin you have a very limited ability to figure out why an element is rendered exactly where it is at runtime, let alone tweak its attributes. In short Ripple + Chrome Tools makes UI worksignificantly easier in Ionic.
Overall, Ionic was a significantly better development experience. If you need to get an app out the door yesterday, Ionic is your friend.
Visual Studio + ReSharper
You thought Visual Studio and Resharper were just for .Net apps? Wrong, they helped us immensely with things like Bower and NPM package management, code navigation, refactorings, and great static analysis, plus a full-on fantastic debugging experience like you'd expect from a .Net app. Microsoft thoroughly surprised (dare I say delighted) us by providing a fantastic IDE for a historically non-Microsoft tech stack.
5. Unit Testing Experience: ConflictedA good framework needs a great unit testing experience if you're going to bake quality into your app. Unfortunately, as great as Wallaby is, even with Karma, I could not figure out how to breakpoint debug and inspect variables from within a unit test. With Xamarin, on the other hand, unit testing is a first class citizen. It's easy and powerful and with nCrunch, feedback is nearly as fast as with Wallaby.
Why conflicted? Because I love this:
Even with SpecFlow, of which I am a huge fan, .Net fails to offer the same power, flexibility, and expressiveness.
6. Ramp Up Time: Xamarin++
The amount of ramp-up time obviously depends on your background. However, with Xamarin it was just a little easier to fall into the pit of success. Architecturally speaking, we made a wide variety of mistakes in Ionic that made things very messy for us later (notice how I switch to the third person when it's something bad that happened, sneaky, huh?). Those mistakes mostly manifested themselves as poor memory management, although we screwed up our ngCache data structures too resulting in poor performance under load.
Now one might argue it's easy to mess up memory management with any new framework. In Angular, however, upon which Ionic is based, it seems to be especially easy to create leaks. By the time we finished our Minimum Viable Product and realized all of the anti-patterns we'd implemented we had a real mess to recover from.
Conversely, we had only one major memory issue with our Xamarin MVP, and we cleaned it up without issue. Obviously if you have anyone on your team with prior Angular experience that mitigates this concern, but if not and you're choosing Ionic, consider yourself forewarned.
So what if I had to recommend a framework today? Obviously the safe (and correct) answer is: it depends. It depends on the team, the existing architecture, who's maintaining the app, the budget and timeline, and a host of other concerns.
However, just to be provocative I'll avoid the safe answer.
For me: I value quality over speed. Just because you can build something with free tooling (#1), do it faster and have more fun doing it (#3); that's no substitute for building an authentic, top notch, responsive mobile UI (#2) on a clean, refactorable code base (#4) that will be ready for market when it hits first release (#6).
But perhaps time to market is more important for you. Every circumstance is different. Hopefully this has helped shed some light on what decision will be right in your case.
Lee Richardson is a senior software developer at InfernoRed Technologies with a passion for .Net development, open source software, continuous integration, building cross platform mobile apps, and hardware hacking. In his spare time he runs Siren of Shame. He has been consulting in the Washington DC area for over 17 years.