43

Our company will soon start developing few products for mobile platforms, as CTO I was asked to examine the Pro and Cons of the different tools available in order to achieve the best quality / cost effective solution.

We will be aiming primarily at iOS and Android , secondary for Windows-Mobile and BlackBerry.

Candidates:

After conducting some background research, I found the following possible candidates:

  • Native - Simply but laboriously develop for each platform with its native tools and language.

  • HTML5, CSS and JavaScript - Could be a web service running on the device's browser (a website) , or an app which incapsulate such code around WebKit.

  • Rho mobile - Made by Google so it ought to be good - nevertheless based on Ruby (which we are not comfortable with) and does have a complex and rather flimsy dev environment.

  • PhoneGap - It seems easy and mostly based on Javascript - It is open source but lately acquired by adobe - (not a good sign)

  • Appcelerator - Anything from Javascript to PHP and to python, have a nice range of API Access but we heard many stories of rejection (by apple), and incompatibilities when using complex code across different platforms.

  • And more like MoSync, Sencha, Appmobi and Corona (didn't tested them first hand).

Some points of reference:

  • We are not planning on developing games, the applications we are planning to develop are in the realm of business applications & information tools.

  • The applications are not depending on excessive use of the devices API's (but do need some minor basic access)

  • The company already developed for iOS and we have a small team of native iOS developers (Objective-C geeks)

  • We would like to be sure that we can carry on developing our applications in the feature without them getting broken due to new OS or APIs

  • It will be beneficial to ensure before hand that the application will not be rejected due to cross platform code (mostly AppStore)

  • Like any company we would like to be as cost effective as we can - on the other hand we insist on high quality products and top-of-the-line User experience.

There is no better place to ask this question than StackOverflow, I would appreciate any comments from developers with experience on this topic.

Simon East
  • 55,742
  • 17
  • 139
  • 133
Oliver Blint
  • 447
  • 1
  • 4
  • 3
  • 3
    What specifically is your question? "Any comments" doesn't really work with SO's question/answer format. I see that you're new here, so please read the [FAQ](http://stackoverflow.com/faq#dontask): "Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page." – Caleb Jan 14 '12 at 21:59

3 Answers3

61

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.

Peter Knego
  • 79,991
  • 11
  • 123
  • 154
9

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.

Community
  • 1
  • 1
Rob Napier
  • 286,113
  • 34
  • 456
  • 610
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.

Simon East
  • 55,742
  • 17
  • 139
  • 133
  • 4
    I would like to point out Facebook had a LOT if problems with their facebook app because it bet too much on HTML 5, a few weeks they made the change to native suddenly their app is 200% faster and the reviews are much better, Mark Zuckerberg admitted that betting too much on HTML 5 was the issue. Simply put native will always be faster + offer more control for obvious reasons. – Oscar Gomez Sep 19 '12 at 21:34
  • 1
    No, Facebook had problems because they did a horrible job implementing their app. There is a really good discussion at http://news.ycombinator.com/item?id=4507879 . –  Sep 20 '12 at 14:45
  • It was a combination of both, it is true it wasn't all HTML 5, but still native will always be faster than HTML 5, simply because both Apple and Android will not optimize their mobile browsers to close the breach (and even then native would still be faster), they will not do that because they want people to use their app stores. Not to mention it is a lot more mantainable/scalable to use objective-c than HTML5, and the IDE is also a LOT better, it could also be arguably faster to code in objective-c vs HTML 5. The truth is that the single platform concept will always lag behind. – Oscar Gomez Sep 20 '12 at 15:53
  • I forgot to add iOS API is great, HTML 5 API is pretty poor. – Oscar Gomez Sep 20 '12 at 16:02
  • I'm for Native development over js, However the real reason facebook's html 5 app was a disaster(meaning it was very slow) was their implementation not HTML5. http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story – Mike6679 Oct 11 '13 at 16:42