Building Native User Interfaces is the Right Way To Build Cross Platform Style Apps
I hear a few developers getting down on Xamarin because they are required to:
- Create different projects for the various mobile platforms that they want to target.
- Learn the particulars of a given platform, or as I term them, the “isms.”
Interestingly,
these are not negatives to going with a Xamarin style cross platform
solution; these are most definitely positives in their style of
solution. Wait, how can this be? Developers have been training to
think that sharing as much code as possible (including the UI) is a good
thing. In this blog post, I’ll try to explain the issues of cross
platform development, what users want (yes, I do tend to do crazy things
like talk to users), the problems in cross platform development, and
finally why presenting the user with a native solution is just plain
better than a mobile web based solution.
What Users Want
Users
want solutions to their problems. It is pretty simple. Solve a user
problem, don’t create more problems, help the business cut costs, be a
net positive in an organization, add value. These are fairly simple
items. Unfortunately, a number of developers don’t quite understand
this. Many developers just want to write code, “But Wally, I just want
to write code. It is why I got into this job.” Or, you may be a part
of some IT group where you are seen as a cost center. Whatever your
position within the organization, getting out and talking to users has
resulted in my finding the following items:
- Users want applications that look just like all of the other applications on their platform. Giving a user an application that looks like a Windows application while running on the Mac can result in some interesting feedback.
- Users want applications that act just like all of their other applications on their platform.
Basically,
this means that an application must call platform specific APIs and
must do so fairly close to the application logic. By doing this, the
application will look, smell, and taste just like every other
application on a platform. An iOS application will look like iOS. An
Android application will look like Android.
History’s Lessons
I’ve
done a little bit with cross platform tools in the past. Early on in
my career when I worked at The Cola-Cola Company, there was some
involvement with:
- PowerBuilder for the Mac.
- Visual C++ for the Mac. While this never shipped, it existed to the point of us getting an NDA. It may have only existed to create FUD.
After
talking to users and working through some options, this is where I
learned how important it is for apps to look like the other apps that
users use.
A few years later, Java came on the scene. Unfortunately, Java ran into several issues:
- Java
apps didn’t look like other apps on a given platform. Swing came out
later on and it provides a much more platform specific look/feel to it.
- Early on, Java wasn't very fast, let's just be honest about it.
- Java had small incompatibility issues between platforms. Its promise of “Write Once Run Anywhere” had become “Write Once Debug Everywhere.”
- There was no guarantee that the Java framework was on a device. Expecting a user to install the framework was no realistic.
Not
long after Java, Microsoft .NET came on the scene. Unfortunately
Microsoft .NET never took over outside of the Windows space. Its cross
platform capabilities never really came about.
Now, I am sure
that there is someone jumping up and down widely waving their arms and
screaming “HTML5, HTML5 will save us.” Ultimately, HTML was designed
for the display of documents and content to users. Back in the mid
1990s, the reason why HTML took off was due to:
- Deploying most custom apps within a business was a nightmare. Deploying apps to a web browser was much easier. No dll hell, no installation programs to run, life was much better. Imaging trying to do this outside of a company without a support staff?
- Early web sites were much more about marketing. Very few public web sites back then were about applications. It took a few years for web sites to take on more of an application feel to them and now many have an app feel to them.
While there have been many attempts to give an HTML file device like capabilities, these capabilities always seem to be lacking in something. Mobile web apps with HTML5 are no different. There is always something that they can't do. For example, I’m working with some folks that are trying their hardest to get out of phonegap due to limitations of the platform. Now, I’m not going into the specifics on that, merely that there are issues and these aren’t the only folks with them.
Just so that we're clear on things, HTML web apps work out really well in a lot of situations. I've written a lot of them. I'm a Microsoft ASP.NET MVP (well at least for a little while longer). I continue to work on several. They just aren't the go to platform for mobile.
Developer Productivity
One of the big
arguments I hear regarding using a single set of source files to build
an application, is that this is more efficient for developers. I agree,
this is absolutely true. Unfortunately, user productivity is 10-100x
more valuable than developer productivity. Increasing user productivity
by a small percent multiplied by the number of users results in a
greater increase in productivity.
But, But, But HTML5……
While
I will argue the point about user productivity increases dwarfing
developer productivity, I’m not going to be unrealistic regarding what
is happening in the marketplace. There are some places where having a
single set of course files is valuable. These typically are:
- The client only has a few shillings to pay for a solution. The cost of an HTML5 mobile web solution is lower, let’s be honest about it. You can get your neighbor’s kid to do the work. This has a tendency to drive down the price. I’m just sayin’.
- If your IT department is considered to be a cost center. Build something, deploy it to a bunch of platforms, later, rinse, repeat.
PhoneGap Will Save Us
Sorry
folks, but PhoneGap isn’t the be all and end all. PhoneGap is a
container that embeds HTML, JS, and CSS content. It allows access to
device APIs in a cross platform way. Unfortunately, you get access to
content via a web view, so you are limited to what can be provided in
the web view.
I almost went down the PhoneGap route back in 2009, until I read the first announcement of MonoTouch (now Xamarin.iOS).
But I do Java, ObjectiveC, or something else
Ok,
great. There are tools for Java that allow you to write for iOS.
Unfortunately, that won’t help you with WP. The same is true with
ObjectiveC.
Why Xamarin
When Xamarin.iOS was first announced, I knew that was where I needed to be. It provides:
- Access to the native APIs directly from an application via the bindings contained in the various namespaces in Xamarin’s products. If your application isn’t calling native APIs, your application will most likely have small things that are out of place in some way. This immediately solved the problem that I had 20 years ago.
- Access to the .NET framework that I already know. I don’t have to go learn ObjectiveC, Java, Xcode, Eclipse, or Android Studio. I can use Visual Studio to develop apps for multiple platforms. I don’t have to go learn a new IDE.
- Sharing non-device specific code between iOS, Android, WP, and other .NET platforms.
- Learning the UI specifics and platform-isms allows you to build an application that integrates with the platform better than a shared application.
I have heard the chimes at midnight. I have gone through the cross platform battles in the past. The bottom line is that you have to create platform specific versions of your app. I think that Xamarin is the right place for me. I’ve learned my lesson. I’m calling native APIs with my language of choice, C#.
If you are interested in a discussion regarding Xamarin vs. Vendor
Directed solutions, I suggest this discussion in the Xamarin forms: http://forums.xamarin.com/discussion/comment/36834