Recently a colleague of mine at BlueMetal Architects presented to the following trend image:
State of The Environment
I find it funny how these things go in cycles. It is like the cycle of Client/Server –> Desktop –> Distributed. If you think about it the technology of the time dictates the paradigm flavor of the month. Take the switch from web apps to native switch right around the time smartphones started to become more common. Native apps emerged to take full advantage of the hardware they were running on. Along comes HTML5 that starts to take advantage of parts of this functionality. So where does that leave us? Go native? Ride the leading edge of HTML5?
One of the reason native applications became prevalent in mobile applications is because the vendors keep out plugins that enabled rich applications. That left the developer with two choices: a) go native or b) go web. Each of these has advantages and disadvantages. Native allows the developer to utilize the full feature set of the device, but for companies that want to be on all platforms, this requires redevelopment of the app into each native form. If the developer decides to go the web route, they cut down on development time/costs but more than likely they can’t take advantage for all the capabilities the devices have to offer. They also develop an app that doesn’t follow the visual design standards for the device. Windows Phone has Metro, Apple wants their apps to look like iOS apps, and even Google has guidelines for Andriod.
Keeping Developer Costs Low
So how do companies keep their development costs low while creating native apps for all the platforms? They use frameworks that take one language as input and output native applications or HTML5 equivalents. The input languages could be HTML5, Xaml, C#, or others. The problem with approach is that the conversions don’t always take advantage of all the functionality of the devices. Or they can only handle a small subset of tasks (look at ComponentArt Mobile Dashboard Server). The ComponentArt server takes in Xaml and outputs many different formats that works on all different platforms. The problem is that the input is Xaml markup of a ComponentArt dashboard.
Another barrier to conversion frameworks is cost. So you are cutting developer costs but the costs of the different frameworks may wipe out and savings you are getting. The aforementioned ComponentArt Server cost in excess of $10k (at the time of this post). That’s a lot to pay for such limited functionality. When evaluating whether to use one of these frameworks you should keep the cost vs. functionality in mind.
The Best of Both Worlds
Some organizations try to get the best of both worlds by creating hybrid applications. They use native where it makes sense and incorporate HTML components when needed. This allows them to create reusable components that can then be utilized within native applications. This is just one way to get reusability out of common components. There are issues here. Not all platforms handle hosting HTML within native apps the same so there maybe some workarounds that need to be implemented. So how much time/money are you really saving.
Reusability to the Max
Another way to maximize reusability is to encapsulate as much business/data access logic behind web services. Now the native app only has to handle creating a compelling user experience for displaying data. That is where native apps excel. Developers can take advantage of the capabilities/design guidelines of each platform. What’s the catch? Well this approach requires the device to always have a connection and in certain situations a high bandwidth connection (data dependent).
When is Enough, Good Enough
Sometimes you have to ask yourself “When is enough, good enough” for my users. There are situations when a mobile optimized web application is “good enough”. If your applications does not require an accelerometer or fancy touch gestures then go ahead and build that web app. Content delivery applications are another good candidate for the web. These apps usually don’t have heavy interactivity requirements. Besides at the end of the day most users ignore apps on their mobile devices.
At the end of the day there is no right or wrong answer to what app should I build. The situations, time, developer skill set, target audience, and budget are all going to factor into the decision on application type. It is always good to look at the trends leading up to this point in time.
What will the future hold? Which paradigm will drive future development? These are questions that only time will tell. If we don’t learn from the past we are destine to relive it.