The mobile development debate

It's clear now. You're doing mobile, everybody doing mobile.


Whether it's an apple device, an android powered smart-phone, or someone else (is there anybody out there?), we're all moved to the new jargon. Click's and dblClick's are dead. Our new friends are the entire Tap family, along with swipe and pinch.
This rapidly-growing trend, must change somehow the way we think. In many aspects, we're yet to realize what is the full meaning of mobile development to us.
In the following read, I would like to try sharing some of my thoughts regarding the million smart-phones question:


Will it be native frameworks? Mobile-Web (or hybrid)?


For those who are not familiar with the subject, I will try to sum it up shortly:

1. We have a small number of very big fish who are doing mobile OS's: Apple (iOS), Google (Android), RIM (Blackberry OS), Microsoft (the almighty  Windows Phone), Symbian and WebOS from HP.
2. Each of them provides some SDK that allow you to write apps. These App will fit just fine on a device that runs this big-fish's code, but it will not work on some-other-big-fish's device
3. These apps are being called Native apps (make sense; isn't it?)
4. The native App can speak with almost any other neighbour-component on the underlaying device (phone, Camera, location services, contacts)
5. The mobile-machines also run one special app that called browser, this browser can always understand HTML, JavaScript, and CSS
6. HTML5 is big. Very big. Is it the next big thing? No it isn't next. It's already here.
7. Now, the 1+1 here is that the same html code can run inside any device, with a little help from a browser, which is already there.

Native Frameworks


The native frameworks introduce top notch technology. 
In the Apple Campus as well as in Googleplex a huge effort is being consistently put into iOS and Android, respectively. The best engineering teams in the world are working only to make it easier for the rest of us. The formula is simple: the easier it will be for developers to develop Apps with your framework, the more Apps you'll have in your App store/market/whatever.
Check out the Apple iOS dev-center, 99 bucks, and you're in developer's heaven. If we speak about revenue model, Apple will eat 3 pieces of your cake, you will get 7. If you sell enough, that's enough to make you happy.
Other than that, Native Apps are born to be quick. A web-app is running inside a browser that is running inside an OS. An App is running inside an OS. Generally speaking, the second approach will be faster.
As a Native App, as I already mentioned above, you'll enjoy natural API's for other components. If you'd like to add some photography functionality to your app, for example, you'll just need to copy n' paste some snippets.



Mobile Web


"The Mobile Web refers to the use of Internet-connected applications, or browser-based access to the Internet from a mobile device." (wiki).
I prefer the second definition. I find it useless to mention not-connected applications, there is not much we're doing offline today. So, we are actually debating here about client technology.
So why go HTML'ish?
I can count many reasons:

• JavaScript is usually one of the 5 most popular languages. A tremendous number of developers out there already feel at home with JavaScript, HTML and CSS.
• You only need to write your App once. (a web expert might argue saying that different browsers have also compatibility issues; He'll be right. But hey: it will still cost less then writing it all over again)
• No revenue model splits. You can eat the whole cake.
• HTML5 introduces some very nice features that will make you feel almost native (Geo-location and location services, Web-sockets, offline modes etc.)
• You can update/ fix you're code without popping-up and asking the user to update.
• You have excellent frameworks to support you. I love Sencha Touch so much, so I don't want to mention no one else here.

My two cents


We're definitely going more and more web. 
On the other hand - If it's looks like a browser, it's probably a browser. On our civilization browsers have security restriction, and always will have. No one will ever want to give a web site the potential capability of reading his contact list, or start reading data from his file system.


So it'll probably be both:
Web sites, that are pure HTML, CSS and JS, running inside a web container which is wrapped-up and deployed as a native app.
Take a look at PhoneGap for example. They're already doing it today.
We'll probably have to wait and see.


If you don't think about the future, you cannot have one. (John Galsworthy)