Native, Web or Hybrid?
We're looking for more discussion on what people are interested in and why. If you have experience with any of these mobile application types or strong feelings about where you are going with them (like JLHS did in the very first visitor post in this forum) please reply. The feedback could help us re-prioritize content in future deliverables.
This topic has been locked.
9 replies Latest Post - 2013-02-23T17:46:24Z by SystemAdmin
Pinned topic Comments Requested: What kind of mobile apps are you building?
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-02-23T17:46:24Z at 2013-02-23T17:46:24Z by SystemAdmin
Suyesh@IBM 270002MY044 Posts
PeterCranstone 270004U0G61 PostACCEPTED ANSWER
Re: Comments Requested: What kind of mobile apps are you building?2011-11-28T18:42:21Z in response to SystemAdminWe're building two mobile browsers for Android and iPhone. Both allow you to access Native Device API's (you can control privacy) and you can use that data with all current web services. We're also integrating the ability to measure HTTP performance from inside the browser along with real time Carrier and Geo-Location information. Finally we're including support for Selenium automation testing.
Re: Comments Requested: What kind of mobile apps are you building?2011-12-10T07:26:28Z in response to SystemAdminAs I mentioned before, native is still the best choice today in mobile development. I won't say it will always be the best choice, but at least at this moment it is. If you downloaded the samples and run on your Android phone, you'll find that the performance of those samples are really poor. That's the inherited shortage for hybrid apps that they must have a heavy framework running underneath them. When the UI is static, they can look like a good pretender to native apps, but when things starts to move, that's a completely different story. What make things worse is that this is just a very simple demo level app, and its performance is like this. I can't imagine how will it look like when it is used to build a real world complicated business app.
I know that many people are familiar with web technologies and only few people are familiar with native mobile development, so it's natural to try to stay within comfort zone and try to use web technologies to develop for mobile. However, if you really want to win in this market, you can't have your eye and ear shut and bet everything on web technologies only. I am not saying that it will not success, but with the huge resource IBM has in hand, why can't you do web, hybrid and native triple play? Why do you have to act like an oracle to predict that web will win out in the future, ignore the truth that native still dominates today, and bet everything on one side? You don't need to choose side. You can easily do them all. You have to accept the truth that you NEED to do native and start building skills and solutions around native.
KurtP 270001F0XE1 PostACCEPTED ANSWER
Re: Comments Requested: What kind of mobile apps are you building?2011-12-15T19:05:16Z in response to SystemAdminThe native vs web app discussion should slowly fade away. Although there are some advantages to both approaches, the JS/HTML5/CSS3 stack is progressing so quickly that it will soon be difficult for the end user to distinguish between a web app and a native app. My understanding is that part of the Apple app store already uses both in their app. The rendering engines such as WebKit and Trident used in the dominate smartphone market segments are moving aggressively to add the support so developers can move more aggressively than if they are targeting web browsers in general. Performance concerns are being addressed and even Adobe has thrown in the towel going forward with Flash on mobile now that HTML5 has video, audio, and canvas tags widely supported. I think a bigger concern for the IBM Mobile Technology Preview's focus on the so called "hybrid approach" could be that now both PhoneGap (Adobe) and Appcelerator (Red Hat) have significant investors involved. These recent investments may make IBM think twice about putting all their chips in the currently available "hybrid" basket. Moreover, although many tout an advantage in a huge developer base for the JS/HTML/CSS stack there is a disparate level of competence here as can be quickly determined by viewing source on many web sites. The Enterprise market that IBM targets requires a highly professional approach to developing web apps, such that the barrier to entry ends up being only somewhat lower than native app development (Xcode and the Android SDK, not to mention version control, mobile device management, etc. are still concerns). My personal preference has been shifting to native wrappers around web apps. A very different approach uses model driven engineering to code generate based on a mobile domain specific language (e.g. canappi.com). We have demonstrated the ability to model once and generate everywhere for iOS and Android (with HTML5 in alpha) accessing web and data services from the cloud, but this approach brings a different set of issues (not the least of which is a very skeptical developer community). I would add that even for the enterprise market it might make sense to have a basic mobile optimized web site, if only to enable managers and non-technical employees have an easy way to download the enterprise mobile app.
Re: Comments Requested: What kind of mobile apps are you building?2011-12-16T17:25:08Z in response to KurtPNative is here to stay, and will remain dominate for long time. You can't develop 2D/3D games with web in foreseeable future, and more than 50% apps on mobile are games. That means native will still be the top one choice for many mobile developers, and it's hard to overcome this mind share. While web technologies are improving, don't forget that native on mobile is also improving. More and more device specific capabilities are being added, and web technologies can't make use of them. Native also integrates better with the system, while web technologies always make users feel "not right" on certain aspects because they don't integrate with the system well and don't follow the convention on each systems.
I also doubt the "write once run anywhere" promise of web technologies on mobile. The browsers are all different on different platforms, and I really doubt you can move the hybrid application from one platform to another without modifying anything. The debug for mobile web/hybrid applications is also notoriously difficult. All these combined together, it doesn't necessarily save you too much time if you are only developing native apps for iOS and Android, and that's very likely to happen since all other mobile OS doesn't really matter today.
I think the mobile app dev will work like this: For apps that are highly important, requires best UI, good performance, latest native hardware capabilities, then you use native to build them. For those mass production apps where quality isn't too important, you use web or hybrid to build them. For those between these two types, you mix native and web technologies together. That means you use native to do the navigation and business logic part, and use WebView to do the information displaying part. Not the hybrid we are seeing today, where native only acts as a shell and all things are in the WebView. By doing this you have native to work on the performance critical part, and can use native to call all hardware capabilities, while reducing the effort of build apps for heterogeneous platform to a reasonable extent.
firstname.lastname@example.org 270000E5612 PostsACCEPTED ANSWER
Re: Comments Requested: What kind of mobile apps are you building?2012-01-25T10:45:23Z in response to SystemAdminWe have just done an hybrid app (Android+IOS), currently available on the markets for free (search for "MAXXI").
We used Appcelerator Titanium as platform abstraction.
Our experience is that "write once run everywhere, save time" is a lie.
Resource consumption is a disaster (HelloWorld is 4 MB!), there are a lot of bugs, inconsistencies, unimplemented things.
Public support is a joke; when you have a problem and search on the forums, your best luck is to find someone with the same problem, anyway no solution.
It easily happens that you have to plug native code to get some extra functionality, so you are back to using native building tools (X-code, AndroidSDK) with the addition to have to fight between what the framework would like to do (auto generate the manifest and the project file) and what you need to customize in the native building system.
We finally got everything to work successfully, but it took a lot of engineering (out of memory when loading 50 48x32 jpegs, <1kB each???!!!).
I will definitely propose to go native on our next project.
We had one case when the customer said "you are proposing hybrid, but we have done a native prototype ourselves...", so basically implying we were not competent enough for native.
Finally, I will certainly prefer to grow my skills on Android than on a fashion-of-the-week hybrid framework, which could be dead in six months.
Re: Comments Requested: What kind of mobile apps are you building?2012-01-27T19:09:03Z in response to email@example.comThis thread is definitely collecting strong opinions. Thank you for sharing that much of the actual experience, Roberto.
It seems you were not able to achieve "write once" on this project, much less "write once, run everywhere, save time". I'm curious if you learned things about the project specification that would lead you to believe that a hybrid/cross-platform solution really wasn't suitable to begin with, or if you just had a bad experience with one particular platform?
It would be good if we could capture a few of your experiences in a little more detail. Is there anything else you can share about the specific technical pain points and the things that forced you to augment this solution with native coding?
firstname.lastname@example.org 270000E5612 PostsACCEPTED ANSWER
Re: Comments Requested: What kind of mobile apps are you building?2012-02-01T10:44:40Z in response to SystemAdminJeff, my (strong, indeed) words were caused by my disappointing experience with basing my project on Titanium; actually the customer is very happy with the result, but we were hoping to have easier life during development.
The multiplatform (iOS, Android) requirement was present since the first moment and that immediately pushed the project to an hybrid approach. While GUI stuff and remote service calls were readily available in the hybrid environment, we had a couple of advanced features which were only achievable in native. The first one was camera-based QR-code decoding: for this feature we had to include an external library in the project (actually, two different similar libraries, for iOS and Android). The second one was listing wifi networks: this required writing native code for Android and was not attempted for iOS (it seems like the required native API is marked as internal-use). Native modules complicate the handling of the projects files, because you do not have a clear picture of what is being generated by what: you have a "refresh or overwrite" dilemma. We needed to link additional frameworks in our app on iOS and the coexistence of the Titanium IDE and X-code was particularly difficult to handle.
There were other cases where we had to "go beyond" the abstraction: for example the only way to impose portrait-mode on Android is to modify the manifest. Titanium also decided that we needed phone capability and that made the app not installable on phoneless tablets, another case for manual manifest editing.
Maybe these advanced features had to be better evaluated at the start, and recognized as unsuitable to a hybrid approach.
Then there were many bugs or limitations or strange behaviour.
An hello world is 4 MB (enormous for a phone) and runtime out of memory issues were frequent: I will never know why loading 50 48x32 jpegs (each one less than 1kB) should cause an out of memory error on Android. All socket connections are asynchronous. The layout rules for widgets have 'auto' size, which sometimes means wrap-content and sometimes means fill-parent; not specifying an 'auto' width will work on Android but crash on iOS.
Finally the Titanium support (public forums) was not really helpful as it is populated by developers with your same problem and without a solution. There is also paid support for Titanium, which we did not try.
I don't know how much of the pain was caused by a project too advanced for hybrid coding and how much is simply a bad experience with Titanium, which faced us with many issues and generally appeared to be more mature on iOS than on Android.
I suppose both elements have a relevant weight.
My posts are about a project which is not directly related to the topic of this forum, so, while not totally off-topic, they should just be used as a first hand experience on my "first steps" in the general hybrid mobile coding, which is certainly generating a lot of interest because it promises a lot.
Re: Comments Requested: What kind of mobile apps are you building?2013-02-23T17:46:24Z in response to SystemAdminWe have a pipeline of B2B apps that should interest IBM's MobileFirst initiative.
iTendr is alreday in the App Store it's OpenTable for the LinkedIn taking telephone tag and frustration out of booking larger reservations and private dining rooms for executives.
Next is Shuffle that connects executive assistants with both brink n' mortar and online stationary stores for rapid response and best price possible for office supplies.
For Les Clefs d'Or the worldwide guild of high end hotel concierge we're building a referral service for enterprise; in NYC but need to rent a boat in Jamacia or get a translator in Jakarta no problem our army of locally 'DialedIn' hotel concierge can getter done!
For further details of our robust pipeline of B2B mobile first apps please contact me at email@example.com