Don’t Be Lazy

I received an email from our local Java User’s Group (AJUG, the Atlanta Java User’s Group) which was a continuation of a thread which requested help on resources/tutorials for development on mobile platforms, specifically iOS and Android. My previous post was my response which included iOS resources that I found extremely useful during the last few years of my iOS development career. The lastest response from another AJUG member in the thread had suggested to look into Sencha Touch or Appcelerator (I’ll throw PhoneGap into the mix too). So, I’m going to chime in (like everyone else with an opinion and please remember this is my opinion) with my experience with the whole “Native” or “Cross-platform” approach.

First off, I am going to address all the wonderful experts who dedicate a large portion of their development time to JavaScript. I am not attacking you or your craft. You are awesome at what you do. You’ve worked wonders hacking at an environment (HTML/DOM) that was never intended for what you’ve been able to do with it. That being said, I have only experienced that JavaScript environments are just not a great fit on the mobile platforms (yet). Please read “Why mobile web apps are slow” if you want to read into detail about this. It’s a great resource which explains some of the pain points of the JS environment on constrained devices.

That being said and out of the way…

My response to the suggestion of using these cross-platform/web frameworks APIs is as follows:

“Don’t be lazy.”

Sencha Touch, PhoneGap, Appcelerator or any of those “cross-platform” libraries are just excuses for cutting corners that shouldn’t be cut. Don’t be lazy. Learn the languages. Learn the APIs. You will only make yourself more competent, experienced, well-rounded and knowledgeable in the long run: that’s a huge bonus! Just as everything in computer science is a tradeoff the tradeoffs here are huge. I’ve seen by first hand experience a lot of time and money wasted by using these toolsets. I’ve seen user’s cringe at the way an application responds. I’ve seen product owners, sales persons, and engineers drop their heads in disappointment when receiving feedback regarding the deliverables (I know this is anecdotal, I’m just speaking from my experience).

The reason is that most of the time all you end up with is a slow HTML based application which does not perform, look, animate or behave anywhere as well a native application does on these devices.

“Don’t make your users suffer for you.”

If you are going to deploy something to the world all I have to say is “Don’t make your users suffer for you.” Software development is a complex task. Design is a skill. Orchestrating a great UX is a complicated and difficult job. We are expected to take this task on for our customers and solve it. It’s not right to deliver something to tens, thousands or millions of people that is substandard just so we can save a little time for a few developers. The user is the most important part of our development efforts. Do them a favor and do the best you can do and not limit it to what has been provided for you.

“You’ve already done 80% of the work”

Once you have actually developed an application in one platform you’ve already done 80% of the work to port it to another. The hard part is flushing out the requirements, defining the services, designing the interface and all that not-so-fun stuff. If you have an app in iOS and you want to port it to Android it’s simpler than you think. You aren’t spending any of your time on anything but coding. I have someone porting one of my iOS applications to Android as we speak. This developer had never done any Android development (although, a very talented Java developer) and they are enjoying the time porting. What took myself (I wrote the iOS application) and an 1-2 Java developers (backend services guys) about 14 months of concurrent development to complete is taking the Android port about 3 months. I’d also like to mention the mobile developers (myself and the other developer) had never used an Android based device before this porting effort. Anyway, back to the point… So, lets say ~3 man years to get the front and backend done for this product. We are only adding only ~3 months for an Android port. Meanwhile, the iOS version has been on the store during this development. Since I used storyboards on this project the developer could easily see the outline of the entire workflow of my application. The developer could read the SQL and predicate queries that were located in the application’s source code. They could reuse all the digital assets (images and audio) that were included in the original application. They could talk to me about how I did something. The idea is that this ground work was all done for the client. It’s really not that big of a deal to port! The developer porting can focus all their time on making the port a great native application which looks correct, acts in a manner a user expects and can be as efficient as possible without affecting the other application(s) that are already done.

Don’t forget the same problem occurs in the cross-platform APIs that has always plagued web development: different browsers|devices = different capabilities. Fixing something for one device or platform might break another or just make it awful. It’s just not worth it. If you fix a UI bug for one use case for a platform, QA has to test across each platform. What ends up happening is you end up developing for the least common denominator which is just a loss for your users (and yourself if you want to show off those skills).

“If you’re the target user, then do whatever you want.”

If this is an “internal enterprise application” (not commercial) I think differently (and I don’t mean the Apple way). If you’re the target user, then do whatever you want. It might be easier as the expectations of the business and users aren’t as high. This is the 5% of the time I would consider writing a non-native application. Sometimes we need to hack out a quick application that is purely functional and not necessarily done in regards to the aesthetics.

“Those who cannot remember the past are condemned to repeat it.” (link)

Another note… Since this is a Java list I thought a prime example of trying develop to far away from the platform is Java on the desktop. Over the last 15 years developers have been and are primarily the only users that use this (Swing) as desktop applications. Even the Eclipse foundation hated java components and created SWT to get by this issue. Java has always given a suboptimal client-side (AWT then Swing) user experience that has annoyed the users since the very beginning and it never recovered. Perhaps if Netscape had finished the Java version of their browser I’d be telling a different tale. A lot of mobile devices are limited in memory, CPU, and (what everybody seems to forget) battery! We as Java devs are so use to just saying “add more ram”, “oh add another CPU”. We can’t think this way in the mobile/battery-powered world. When I speak of mobile, I speak of anything running with a battery. I don’t limit this to smart phones and tablets. You have to be as efficient as you can (we should do that for desktops too, why not be green?) when taking someone’s precious power. So, by getting your application to finally squeak by with performance because you are now only using 80% of the CPU, you still aren’t doing the user any favors. Be nice and as efficient as possible.

Anyway, those are just my thoughts. I’ll probably modify this post a few times before I am done. I have other thoughts:

  • Loss of developer control using cross compiler technologies
  • Debugging is much nicer and robust in the native toolsets
  • Licensing adds another huge cost or confusion in many circumstances
  • Refactoring tools in Java, .NET and Objective-C are far superior to JavaScript’s tooling availability.
  • Drastic API changes in Javascript are very difficult to move forward and just require a rewrite anyway. Android and iOS have been awesome at forward compatibility. Take a look a Sencha’s track record for drastically changing their APIs/framework (a writeup of moving from Ext 3 to 4 see “Upgrade Transition”)

TL;DR – 95% of the time I will write native applications.


This entry was posted in Random Thoughts, Software. Bookmark the permalink.