Mobile development - Native VS Cross Platform VS JavaScript [closed]

Answer 1

There are 500k+ apps on the app markets and competition is fierce. It is paramount to have great UX and graphics.

Cross-platform tools are NOT on par with native development. If they were, we would all be using them. But we are not. With a reason - you do NOT have full control. And full-control is necessary to have great looking apps.

If your app is not a consumer app, but an enterprise app, which use is dictated by some internal department, then you might get by with so-so design, because the value of such app is in it's functionality.

But, if you are serious about mobile apps market - then the only way is to go native. And you need an UX guy and a designer (who knows mobile development) on team full time. You will spend upwards of 50% of time on looks. The project that I'm part of now is spending 80%+ of time on looks (graphics, animations, UX, usability testing).

A suggestion: spend a reasonable amount of time (= days) using you competitors apps. Also spend time with top 50 apps on each market. You will get a feeling how high the bar is. Then check apps made with cross-platform tools (you can find links on their sites) and compare.

Answer 2

I work at AppMobi and I'll just make a few comments.

1. You're app shouldn't be rejected for being cross platform using a native webview. We haven't had Apple use that on any AppMobi submitted apps.

2. Rhombile isn't "Made by google". In fact, it's not even the part of Motorola that Google bought, it's their business division. They are pushing towards HTML5/Javascript but currently Ruby.

3. Appcelerator started out supporting a webview, then backtracked. They just raised a ton of money to go back to the webview suppport.

As to people saying "No" to the cross platform apps. Facebook and some other major companies are moving towards HTML5 based apps for mobile.

Answer 3

While I'm in complete agreement with @Peter Knego, I'd add a few minor points for teams looking to support several platforms:

• As Peter notes, UX is huge, and cross-platform UX is least-common-denominator UX. It's hard enough to get this stuff to be everything it needs to be without tying a hand behind your back. Really fantastic web apps are judged on their ability to come close to a native experience, not the other way around.

• There are many parts of a product that aren't UX. It's worth considering carefully what kind of reuse you can get there. For instance, I've often advised teams who have SQL databases already working on Android not to try to use Core Data on iPhone. There's no reason to reinvent your object and data models.

• This is not a blanket suggestion that you write your core in C++. If you have an extensive, existing C++ core, I've made suggestions before about how to reuse it. But I don't generally recommend it for new code. It's better to use the best OS-level features of the platform in most cases.

• Designing network protocols that work well on all platforms is pretty easy and should be pursued. Your best bet here in almost every case is REST and JSON. Keep it simple, especially for iPhone which hates things like SOAP and parsing complex XML.

• Some complicated layout problems are easier in HTML+CSS than with native controls. This is particularly true if you have complex multi-column tables (especially things you'd need colspan and rowspan for). I've had fairly good luck embedding individual UIWebView pieces in otherwise native apps, even when portability is not a consideration at all. There can be some worthwhile reuse here. Just remember that you don't want to waste a lot of effort and performance trying to make your HTML browser-neutral. On iPhone, use WebKit extensions anywhere they make your app better for the user.

One of the most important lessons in this, though, is that there isn't a single "right" way to make an app that is appropriate for all platforms. iPhone apps should act like iPhone apps. Android apps should act like Android apps.

Highly cross-platform approaches are a cheap way to get "something" if you don't really care what "something" is. They're a very expensive way to get something great.