Join 'em, if you can't beat 'em - making HTML based apps
If you are into making apps, as a developer or as a company/agency that contracts developers to get apps made, then you might have definitely come across options. The options to um... cheat, cheat as in not create a native app. Native apps dictate the need to have multiple source codes, one for each platform and are seldom cross platform.
There are plenty of options to create apps for the mobile devices. The differentiating factors range in terms of price, language used, platforms supported to the technologies used. While each has its benefits, each has its limitations too.
Native Apps
These are the apps that you can make using Objective-C and xCode for iOS and Java with Eclipse for the Android. While you get access to practically every aspect of the device, the end results on each platform look different and have varying functionalities dependent on the hardware. This is what was used commonly to create apps and also forms the barrier to entry. This is good for large development teams where they can afford to have a team of dozen or more iOS devs and a similar number for every other platform that they might support.OpenGL Apps / Framework based apps
This is the intermediate option, this generates native apps but the engine that displays the app is build on OpenGL and is rendered for every frame. This was made common with frameworks like CoronaSDK, Gideros Studio, Moai, etc and these can offer their own development language (in the case of the three mentioned above, it was Lua) and avoid using Objective-C. The advantage of using this is the source base is a single source and is run against the framework engine, so with minor alterations, the same code base can be used to generate iOS and Android apps. This is more useful for smaller organisations and Indie setups that would rather spend time on the game than develop their own engine. These are mostly cross-platform between iOS and Android as the stubs for other platforms are not as yet developed. Microsoft has been the culprit largely for not having this for their Windows Phone range as they initially insisted on not supporting C++ compiled apps and forced the use of DirectX and XNA instead of OpenGL.Hybrid Apps - Web Apps
This is the third type of apps, these are basically websites wrapped into a webview (literally) so the entire logic and code is the website/webpage and it is rendered as if it was rendered onto the internet browser of your mobile. Users dislike entering the URL (www.domain.com) to go to the app, there is the Bookmark trick where you can bookmark a site onto the springboard of the iOS devices. This on the other hand wraps the website and can offer some access to the hardware of the device which is otherwise unavailable via the browser window. This is mainly used with frameworks like Sencha Touch, PhoneGap, etc. The advantage of this method is since it is run in a browser window, it can run on more platforms than any, including Blackberry and Windows Phone and the desktop using the same code base. These are good for basic stock apps, like timetables and schedules for apps that will not last for more than a week, mainly aimed at conferences or simple business cards to prove to others that even you have an app.So what's wrong
Well there is nothing wrong with using either of the technologies, developers (and purists) that love coe and would like to have access to literally every bit and byte that is on the device would like to use the native approach of the 1st type of apps discussed. The designers and developers that want to concentrate on uniformity, quick turn around, etc focus on the second type of apps. The web designers and web developers that made it during the PHP and DHTML times can come back with wrapping their apps with the third approach.What is really wrong with this picture (without being a purist) is that the market is being skewed or distorted. The development time and cost of a native app employing the first method can be quite expensive but be most rewarding as it can feature most of the functionalities of the device. The second method provides uniformity in the UI (look and feel), could be limited in features (unless the framework developers add those features or provide plug-ins, if supported). The costs and the timelines on these are smaller in comparison to the native method 1 above. The last which is actually the concern is diluting the line between developers and web developers and placing the two in the same bracket and threby skewing the market in terms of costs chargable to a client. This could be a concern that might be present in a very small population and the type of apps that can be created using this third methodology are quite limited in comparison to the first two. This also offers the DIY option, where white label apps are offered to users which they can create themselves using a browser from the comfort of their own homes for as low as $40/month.
The real danger
The issue with this is that even the end user feels that they can create an app. Technically what is generated is a native app as it is the binary that is up-loadable to the relevant market/store and can be purchased by other users for a fee or free.So, what's the issue - you might ask. The issue is that these apps are as mentioned HTML/webpages wrapped inside of a webview and these are stored on the servers of the company offering these and when you think about it, $40/month means that you can stop this at any point of time or are held hostage. All this if the company lasts the time, if it buckles, your app would cease to exist. This is fine for those that want to create a quick yellow pages type listing, place a picture, a map with the address and a page blowing your own trumpet (though maps, etc are charged extra). From an app perspective, this is doing nothing. They even allow links to sections on your web page (so updates are easy). In discussions with a couple of clients, I have heard them mention apps for under $500. My advice - Throw peanuts and attract monkeys.
The cost of an app varies from project to project depending on the time to solve the issues, add the features, the number of screens (most clients understand it this way only). The costs can vary if you are getting it developed in the western countries or outsourcing it to the countries with a cheaper standard of living index in the Balkans, East Europe or Asia for example. Even then it would be difficult to beat the $40 pricing for a stock app to be developed and uploaded to the store/stores.
In contrast, a Native app (using method #1) was created in 2009 way before the iPad1 was released for that matter even before the iPhone 3GS was released, the same binary is still working on the latest version of iOS, iOS7. That's 5 years of an app. The app could be upgraded to add more features, etc but since there is no future backing, the app exists in a as-is state and still works. Apps that were created using method #2 in 2010/2011 (prior to the new iPad - Retina iPad) broke on the new iPad. The developers that were using OpenGL did not know how things would get rendered on the new larger contexts and the apps did not work as expected. All of those required a recompile and then they worked. This however broke backwards compatibility, the framework manufacturers removed ARM6 support (not that with the latest build of xCode, one can build for ARM6 or is advised to). Changing the UI is not without recompiling and submitting a new app binary and waiting for the store to approve of the app, where as with the 3rd methodology, you can change the colours, font, UI etc like you do with a website, because it is a website inside the app.
Comments
Post a Comment