To write a native app or web app is a very important decision at the start of any mobile project. There's place for both. Native has some benefits that web app doesn't and vice verse.
But then there are the hybrid app frameworks. The idea of a hybrid app is to bring the strong points of each approach into one app. Probably the best known hybrid app frameworks are the PhoneGap and the Titanium Appcelerator. Both of these frameworks promise multi-platform in essence web apps packaged into a native app package although Appcelerator takes the packaging a step further by compiling some controls to platform native components.
Suzanne Alexandra wrote an interesting article about the hybrid frameworks over at MOTODEV: Mobile Today: Native, Web, or Hybrid?
Quote from the article:
I think this is the key issue. I've been following the PhoneGap and Appcelerator for some time now and my skepticism of the approach is just grown stronger. At this point my recommendation would be to stay away from these frameworks. The obvious fact is that the hybrid approach does not bring the best features of mobile web apps and native apps but instead the worst. This approach simply does not work.
PhoneGap
Let's take a look at PhoneGap. They have provided a helpful app showcase page. If we take a look at the apps listed there at the time of this writing there are seven apps from which only one is available on Android and iOS. The only multi-platform app they have chosen as a featured app is currently rated with 3.3 stars on Android market. The app developer has even chosen to use iPhone screenshot as app screenshots on the Google Play Store...
The iPhone screenshots don't tell much how the app works on Android. This is what you will see if you launch the app on a Galaxy Nexus. Note that this app is not selected by me but it is a featured app by PhoneGap.
Appcelerator
Appcelerator is not doing much better. They also have an app showcase page. Unfortunately they don't give direct links to Google Play (even though they're using the android market graphics) and not all apps that are listed as available for Android can be found from the Play Store. I was able to find one app that is claimed to be available on multiple platforms. I'm afraid that the app isn't doing well either. It currently has 2.5 star rating. But they at least are using Android screenshots.
.png)
A user review from the market:
Multi-platform apps do not exist!
In short, targeting multiple platforms with one app does not work. If you don't want to or don't have the budget to target the platforms with native apps build a web app! User experience on mobile is too important to be ignored. Same app on multiple platforms will feel wrong on all of them.
In my opinion use of these frameworks can be justified as long as they're not used a multi-platform frameworks. I suspect that it is possible to build apps using them that feel right on one platform. And as they use web technologies as their programming languages it can sometimes be easier to find developers for using them than native app developers. In these cases pick a platform you write the app for!
Reason why multi-platform approach is doomed
What causes the bad user experience in these apps? What is wrong with them?
Here's a simple list of things that are likely to cause problems:
I'm open to be educated
But maybe I'm wrong.. I have been trying to find apps that would prove me wrong for some time already. I just haven't managed to find any that are even close. If you know an example of any good multi-platform apps that run on Android and iOS please leave a comment! I'm happy to reconsider my position if given proof that I'm wrong. Until that I will maintain my position.
NOTE: It looks like blogger's comment engine has problems with this post and comments don't appear correctly. If that happens to you you can always post to the follow up post at: http://www.androiduipatterns.com/2012/04/multi-platform-frameworks-followup.html
But then there are the hybrid app frameworks. The idea of a hybrid app is to bring the strong points of each approach into one app. Probably the best known hybrid app frameworks are the PhoneGap and the Titanium Appcelerator. Both of these frameworks promise multi-platform in essence web apps packaged into a native app package although Appcelerator takes the packaging a step further by compiling some controls to platform native components.
Suzanne Alexandra wrote an interesting article about the hybrid frameworks over at MOTODEV: Mobile Today: Native, Web, or Hybrid?
Quote from the article:
You will see differences between cross-platform apps and native Android apps, especially in user experience. For example, you might notice menus at screen bottom, no list selection highlight, and tiny buttons, especially on high-resolution Android devices.
So being cross-platform might mean that you get another platform’s look and feel on Android. Whether time to market and cross-platform benefits outweigh user experience polish -- we’ll leave that choice up to you.
I think this is the key issue. I've been following the PhoneGap and Appcelerator for some time now and my skepticism of the approach is just grown stronger. At this point my recommendation would be to stay away from these frameworks. The obvious fact is that the hybrid approach does not bring the best features of mobile web apps and native apps but instead the worst. This approach simply does not work.
PhoneGap
Let's take a look at PhoneGap. They have provided a helpful app showcase page. If we take a look at the apps listed there at the time of this writing there are seven apps from which only one is available on Android and iOS. The only multi-platform app they have chosen as a featured app is currently rated with 3.3 stars on Android market. The app developer has even chosen to use iPhone screenshot as app screenshots on the Google Play Store...
The iPhone screenshots don't tell much how the app works on Android. This is what you will see if you launch the app on a Galaxy Nexus. Note that this app is not selected by me but it is a featured app by PhoneGap.
Appcelerator
Appcelerator is not doing much better. They also have an app showcase page. Unfortunately they don't give direct links to Google Play (even though they're using the android market graphics) and not all apps that are listed as available for Android can be found from the Play Store. I was able to find one app that is claimed to be available on multiple platforms. I'm afraid that the app isn't doing well either. It currently has 2.5 star rating. But they at least are using Android screenshots.
.png)
A user review from the market:
Multi-platform apps do not exist!
In short, targeting multiple platforms with one app does not work. If you don't want to or don't have the budget to target the platforms with native apps build a web app! User experience on mobile is too important to be ignored. Same app on multiple platforms will feel wrong on all of them.
In my opinion use of these frameworks can be justified as long as they're not used a multi-platform frameworks. I suspect that it is possible to build apps using them that feel right on one platform. And as they use web technologies as their programming languages it can sometimes be easier to find developers for using them than native app developers. In these cases pick a platform you write the app for!
Reason why multi-platform approach is doomed
What causes the bad user experience in these apps? What is wrong with them?
Here's a simple list of things that are likely to cause problems:
- Wrong UI patterns (not using action bar etc).
- Menu system does not work.
- Gestures work differently.
- Native components often work incorrectly.
- No correct graphics for multiple pixel densities.
- No integration to Android platform (intent system).
- No correct layout scaling.
- No alternative large display layouts.
I'm open to be educated
But maybe I'm wrong.. I have been trying to find apps that would prove me wrong for some time already. I just haven't managed to find any that are even close. If you know an example of any good multi-platform apps that run on Android and iOS please leave a comment! I'm happy to reconsider my position if given proof that I'm wrong. Until that I will maintain my position.
NOTE: It looks like blogger's comment engine has problems with this post and comments don't appear correctly. If that happens to you you can always post to the follow up post at: http://www.androiduipatterns.com/2012/04/multi-platform-frameworks-followup.html
"If you don't want to or don't have the budget to target the platforms with native apps build a web app!" -- PhoneGap *is* a Web app, just with greater potential OS integration and packaged in a deployable fashion (e.g., APK). PhoneGap apps, therefore, should succeed or fail at UX at about the same rate as Web apps.
ReplyDeleteWith respect to your bulleted list, for PhoneGap, most of those could be corrected via plugins (existing or potential). Others are simply a question of Web design. For example, your own blog fails at the last two bullets -- it does not matter how I resize this browser window, Blogger's Web design ignores it and renders everything in this narrow column. It is certainly possible to create a fluid design that accommodates different sizes, just as it is possible to have Web artwork for different densities. Not every Web developer does it, whether that is a Web developer creating blogging platforms or somebody using Web technologies to create a mobile app (as a Web app or as a PhoneGap app).
Hey Mark!
DeleteYes. A PhoneGap app is a web app technically but in practice it isn't. It is installed and maintained through Android Market... I mean play. From users' point of view it is an Android app. I don't think that what's underneath matters or allows any excuses for wrong feel and functionality. To users a PhoneGap app simply feels wrong.
Now, if you put the same app to web and distribute it as a web app (ie. a URL) the situation is different. Firstly, the web app benefits from all browser functionality like pinch-to-zoom, bookmarking, URL sharing etc. But perhaps even more importantly users see it as a web page. They know how to interact with web pages and they know what to expect. To me this is what makes the difference and why I think PhoneGap apps are doomed to fail.
I couldn't agree more to EVERYTHING you wrote in this article! I spend a lot of time advocating multi-platform frameworks are bad for all platforms. Besides the fact, it completely waste the user experience, it also reduces app possibilities. Indeed, if you want an app to work on all platforms with the same set of functionalities you will probably end up with using basic APIs. Bye bye widgets, Services, Renderscript, etc...
ReplyDeleteThe thing is that the only common framework for mobile app is HTML5/Javascript. The history of coputing could have been different but this is the reality.
ReplyDeleteIn the ideal world you have infinite time and infinite resource to code your app tailored for each platform with the native toolkit, making use of their particular UX paradigm. Great. But in a less than ideal world, you're a single developer and cannot manage 3 different codebases.
That's why I'm strongly considering HTML5 frameworks at the moment to bring my native Android app to other platforms like iOS, Windows Mobile and maybe one day, Windows 8 Metro.
The greatest concern with mobile HTML frameworks is performance and UX oddities making your app look alien.
I think I can live with alien UX but performance can be a big concern for particular app. Making smooth scrolling lists in HTML5 seems very difficult for example.
As for UX, it seems that most HTML5 mobile framework mimic iOS UX more or less making apps super alien on Android.
While researching this topic, I've found an interesting framework called GwtMobile leveraging GWT, using an agnostic UX theme. At least it is not a copy of iOS widgets.
There's one real world app using it rated 4.1: https://play.google.com/store/apps/details?id=com.TouchOnMobile.FantasyPredictor
It also exist on iOS. It is an OK app although scrolling feedback is slower and different in feel than regular Android list scrolling. On Android, performance is way better when running under Chrome which is ICS only and for which the html engine is not available for embedding in apps.
In my opinion the gap between native and HTML5 app will narrow in the coming month and years, that why it can be a good idea for developers to start investigating now, unless you want to write the same app over and over for different platforms.
To conclude, HTML5 apps brings multiplatform support at the expense of deep platform integration. For now.
Hey B0b,
DeleteNote that I'm not against HTML5 web apps at any level. I think web apps are probably overtake native apps at some point (probably not very soon though). It is exactly as you said and HTML5 is a good way to bring apps on multiple platform.
My argument is against hybrid frameworks that take these HTML5 apps and make them look to users as native apps. In my opinion a much better alternative is to keep web apps in the web and in the browser. Users know how to deal with web apps and don't expect them feel like Android.
Sure you can keep them as web app running in a web browser but then as a developer you have the problem of discoverability and monetarization of your apps, both solved by the Android Market (err...Google Play whatever).
DeleteLast year I wrote a little App with PhoneGap and Sencha Touch, because I thought its a good idea to have 1 sourcebase for Android, iOS, Bada, Windows Phone 7 and so on. But its seems only Android and iOS are relevant for the next years, so the advantages for cross platform development disappear.
ReplyDeleteFrom my experience, if you want to make an app that look & feels native, its a lot of work with phonegap, if not impossible. So new projects I will start with native platform sdks only.
Here are some screenshots from the phonegap app. iOS vs. Android
https://plus.google.com/u/0/116245368163019908111/posts/FBmrf6qJPXR
Disclosure: I work for Appcelerator
ReplyDeleteRather than give my own color and bias on your assessment, let's just stick to facts as they pertain to the list of shortcomings you wrote. Perhaps when you see the true, deep level of integration Titanium has with Android, you may soften your stance a little on it. Bear in mind that all I mention is part of the core of Titanium, no plugins necessary unless otherwise stated.
- Wrong UI patterns (not using action bar etc).
The UI components used in Titanium are actual native Android components. All the standard UI patterns apply without any additional effort. For example, Titanium has a TabGroup component. On iPhone, this TabGroup represents its tabs with the default iOS color scheme and position at the bottom of the screen. On Android, the same code will represent tabs at the top of the screen, using the color scheme of the underlying Android OS. This is just one example. As stated, you are using native UI components with Titanium and they will look, feel, perform, and behave as native.
If there are particular UI components you feel are missing, you can always implement them via Titanium native modules: https://wiki.appcelerator.org/display/guides/Android+Module+Development+Guide
- Menu system does not work.
Sure it does: http://developer.appcelerator.com/apidoc/mobile/latest/Titanium.Android.Menu-object
- Gestures work differently.
I use them in the same fashion I did with native Android development. Titanium has just about every standard Android gesture implemented, with more in coming releases.
- Native components often work incorrectly.
The native components used by Titanium are the same components used in native Android development. Undeniably, bugs do exist in Titanium in their abstraction of these components, but these don't represent a fundamental limitation of Titanium. They represent the growing maturity of Titanium as an open source project, especially as the list of bugs as they relate to functionality and parity have decreased over time.
- No correct graphics for multiple pixel densities.
Sure it does: https://wiki.appcelerator.org/display/guides/Using+density-specific+resources+on+Android
- No integration to Android platform (intent system).
Sure it does: http://developer.appcelerator.com/apidoc/mobile/latest/Titanium.Android.Intent-object
https://wiki.appcelerator.org/display/guides/Android+Intent+Cookbook
https://wiki.appcelerator.org/display/guides/Android+Intent+Filters
https://wiki.appcelerator.org/display/guides/Android+Intents
- No correct layout scaling.
There's a number of ways to scale layouts for android in Titanium. You can use the above mentioned density-specific resources, you can design UI based on the dimensions of the Android device, and you can even specify a 'dp' suffix on the dimensions of your UI components to use density independent pixels.
- No alternative large display layouts.
See above.
Hey Tony,
DeleteThank you for posting this informative comment!
I know that PhoneGap and Appcelerator use different approach in the "wrapping" process. Some of my bullet points are true for PhoneGap and not for Appcelerator.
How do you use libraries like ActionBarSherlock in Appelerator projects? The user experience requirements for Android have been getting much stricter in the last year. I don't think that moving tabs to the right place is good enough.
I see the only reason to go for appcelerator be that the developer team knows web tech but doesn't know Android programming. Having to build appcelerator modules instead of using ready libraries is not saving time.
By far the biggest selling point of Appcelerator is its multi-platform capabilities. But what happens if I take all these Android specific features like intents and try to use the app on iOS? I think that use of Appcelerator is only going to replace use of Android SDK and iOS SDK by building one app on each platforms.
I'm sorry to be so skeptical of the Appcelerator framework. I just would really like to see examples of good apps that run on both iOS and Android. I can't seem to find any.
Check out getglue and triplingo
Delete"I don't think that moving tabs to the right place is good enough."
DeleteI don't think you're fully understanding how Titanium works. We're not moving the tabs. We're not styling them, we're not even creating them. We're just creating an API that tells the underlying native platform how to do it. So when Android design principles and UI components change, Titanium changes with no effort, just as it would if you did native Android development. Same goes for our other supported platforms.
"But what happens if I take all these Android specific features like intents and try to use the app on iOS?"
That's exactly what a lot of our cross-platform examples, like the ones in my last reply, already do. Titanium provides multiple ways to organize your project in such a way to leverage platform specific features while still delivering to multiple platforms from a single codebase. These methods are as broad as allowing you to use specific source files based on the underlying platform, or as granular as branching code logic based on that platform. It's your choice. But you can easily deliver a truly native experience on multiple platforms with one project.
If you have any specific concerns or you'd even like me to run you through exactly how we do what we do, I'd be happy to email, skype, hangout, screencast, whatever. Just shoot me a message at tlukasavage at appcelerator dot com and we'll set something up.
Hey Tony,
DeleteThank you for the info. I really cannot claim that I have done enough with appcelerator to say that I understand it. My concern is purely a design challenge. I'm yet to see one app made with appcelerator that is even close to the design standards I would set to any professional project I work on. While I'm fully aware that me not having encountered any well designed Android projects implemented with appcelerator does not prove that it is impossible to do I think that examples like Zipcar speak really badly about the framework if they are used as good examples.
If creating great Android user experience is possible with appcelerator all it takes to change my mind is to see one. The instance I see an app that matches the criteria I will retract my statement about this kind of frameworks not working.
I'm also not looking for some master piece of design like TED, Tasks or Pocket. I'd be happy with an app that uses Android UI patterns correctly and follows the design guidelines. I'm very happy to be proven wrong and open to evidence but so far every example of good apps are either apps that used to be written with appcelerator but have now been reimplemented with the Android SDK or apps that are so far bellow the standards that they really are not proving anything.
I'm really sorry if I sound mean or like a hater. I can promise you that it is not my intention.
I guess my only concern with your rationale here is that a very large percentage of native built Android apps that use the native tools don't even follow the design guidelines. And in that respect I can assure that there's nothing about Titanium that precludes you from delivering an appropriately designed Android experience. Android just doesn't shove it down the throats of its devs like Apple does, so often the guidelines are ignored.
DeleteSo what do you define as a "well designed Android app"? Are we basically just talking about this? http://developer.android.com/design/index.html
And if so, again, this is all doable. I will be outright and say that we need to implement the ActionBar, that's one thing I may do myself if its not already underway by the platform team.
Do you follow what I'm saying though, in that it's not a fundamental shortcoming of Titanium? It's just shortcuts taken by developers in many cases. And this is not unique to Titanium developers. I mean, your blog is called "Android UI Design Patterns". That is your wheelhouse and what you find most important. Undoubtedly you've found among native developers as well those who don't hold the topic in as high a regard as they should.
Sorry for taking this long to reply Tony!
DeleteI do understand what you mean but I'm just skeptical of the statement. I know that many (probably most) Android apps built with the SDK are not following the guidelines and are pretty bad. But the difference is that there are good apps too. That proves to me that it is possible to build good apps with it. On the other hand I'm yet to see a single good app built with Titanium. Maybe you guys could build one demo app proving your point?
The reason why I'm so skeptical of the approach is the promise of multi-platform apps. I just don't see how it could work even in theory without having to write two apps, one for Android and one for iOS. There's of course the idea of sharing all the model and controller code and simply replacing the view but is that really the case? Does it work in practice? Again, I'm looking for examples that should exist if that were the case.
And you're of course right that I'm writing about user experience and I have fairly narrow view in this blog. If you take a look at the follow up post (linked at the end of the article) you can find opposing views. Especially the Mark Murphy's post brings up good points. But to me user experience is the most important quality factor and I don't think there are any good reasons to sacrifice it.
Heh, sure, titanium uses some native widgets. It's still pretty impossible to do anything close to the native ui experience with titanium.
DeleteTitanium has support for native UI. Unless you want to use anything other than the subset they've chosen. Use the declarative xml for building your UI? I wish!
It's got support for intents... unless you want to pass say... integers to an intent, yup, that's still broken today. You can use native buttons... unless you want to for instance have a button that's just an icon and not text.
You can use native tabs... unless you want to style them (yes, I did finally figure out the trick of actually overriding the appcelerator theme by inserting my own xml in the post-build but really that's a hack and neither documented nor supported.
Any appcelerator employee can feel free to question my statements here in order to try to save face and I can reply with links to the Jira-tickets showing "unresolved" and won't fix.
There's a lot of promises and hype but when you ask about unclosed bugs that are a year old you still get a lot of "yeah we're working on that" and not much else.
Oh and when they say you can always build your own modules they sort of fail to mention that there's basically no documentation. The new docs are 10x better than the old ones but still a joke.
Dashboard? Not on android.
ActionBar? *cough* working on that *cough*
I really wish that I could like Titanium but having to spend my days working around the crap they serve me every day I can't wait to get a chance to do some real native android development.
Interesting. I did not realize that Titanium allows you to use Android intents.
ReplyDeleteI looked at three apps from Google Play on an Android smartphone (Motorola ATRIX with 2.3.6) --
* GetGlue (100,000+ downloads, 4.5)
* WunderList (500,000+ downloads, 4)
* TreksWS (500+ downloads, 5 - but city-specific)
To me, they look reasonably good. I can use them easily. I clearly recognize the iOS influence, but the only thing that really bothers me is tiny buttons that I can't quite tap.
But from Tony's comment, sounds like this can be fixed.
I'd love to see an article or post on how to make a Titanium app really look like native Android, using Tony's solutions to Juhani's points.
Anyone?
Wunderlist has been rewritten as a native app, so they are no longer using Appcelerator.
Deletehttp://www.6wunderkinder.com/blog/2011/09/05/wunderlist-for-android-rebuilt-relaunched-and-really-awesome/
and a more biased link here: http://www.tryexcept.com/articles/2011/09/12/wunderlist-for-android-is-going-native-drops-appcelerator-titanium-mobile.html
GetGlue started as a Appcelerator app but they too rewrote the app as native.
DeleteI'm sensing a trend...
Hey there Suzanne,
DeleteBut wouldn't fixing these points just make the apps Android apps with a lot of platform specific code? They would no longer be multi-platform.
Juhani,
DeleteExactly. And as a user, I don't mind the other-platform conventions, if they're simple and instinctive to use. I also saw this a few months ago when user testing an app that I designed. Android tablet users told me emphatically they wanted certain UI patterns from another platform. Those patterns were natural and intuitive to them.
Your thoughts?
Hello everyone,
ReplyDeleteI am the CEO of Phunware (www.phunware.com) and I am happy to chime in on this issue with some very real world and practical thoughts over the past 3 years of running our business.
These thoughts are by no means random and are completely based on the empirical data that we've been able to put together across tens of millions of app downloads consuming billions of minutes of app usage in more than 100 countries and 10 languages worldwide. They are also based on building hundreds of apps for the largest and most important brands in the world at transaction scale, including CBS, NBC, ESPN, Univision, Discovery, Turner, HomeAway, NASCAR, NHRA, Sony, AMD, YouSendIt, Samsung, Freescale, McDonald's, The Grove, FUNimation, OWN, E! and the NFL amongst many others.
The punchline of our very real world experience is that all of these write-once-run-everywhere mobile app frameworks such as Appcelerator, Titanium, Adobe AIR, Phone Gap and the like simply DO NOT WORK. At all. Sure, they can work in marginal use cases for the overly simplistic or the feature weak engagements, but if you are trying to build real mobile experiences that challenge the processing power, memory and resolution capabilities of the best mobile devices and OS's on the planet, then they simply SNAP. They break. They crash. They simply can't keep up with the demands of the real world for large brands and large audiences and communities when engaging with vibrant content at transactional scale.
Our Phunware Labs team has tried to build out apps using all of these systems as a means to see what they could and could not do in the real world. To date we have launched exactly *nothing* that we have ever built in these experiments. Not only is the non-native UI/UX and look/feel underlying the apps fundamentally miserable, but also the associated maturity, stability and capability of the platforms simply can't handle anything demanding in a normal feature set.
Part 1 of 2 (continued below)
Hey Alan,
DeleteThank you for brining your experience in the discussion! It is always great to hear real world experiences. The part 2 you mention seems to be missing. I really hope that blogger's commenting mechanism hasn't lost it..
Hey Alan,
DeleteI tried to reach you through email for permission to post your answers as a separate post to the blog (but I wasn't sure if email I used was correct). There is clearly some issues with the blog commenting engine as the second part of your answer doesn't show up. I do get a notification email of your post but it doesn't show up. I thin your post is very insightful and would deserve more attention. I just don't want to post it without your permission.
Cheers, Juhani
juhani.lehtimaki@iki.fi
Appselerator actually has a good example:
ReplyDeleteGetGlue
https://play.google.com/store/apps/details?id=com.adaptiveblue.GetGlue
vs
http://itunes.apple.com/us/app/getglue/id377615302?mt=8
Latest version of GetGlue on Android is no-longer build by Appcelerator. It's a native Android app.
DeleteSpot on with this write-up, I truly think this website needs much more consideration. I’ll probably be again to read much more, thanks for that info.
ReplyDeleteI agree, cross-platform development falls short of delivering production quality polished apps on ALL platforms.
ReplyDeleteThe end-result is sort of jack-of-all-trades-master-of-none app.
I have had the opportunity to do it last year and ended up building both phonegap as well as appcelerator app for different platforms, even then the UI experience leaves much to be desired.
They are also maintenance sore-points with Titanium & phonegap releasing newer API versions almost every month with less than great backward compatibility.
Even though both apps were accepted by stores, I will definitely consider native as an option next time around especially for Android.
Hello,
ReplyDeleteI think it's very relative. In Appcelerator case, you can do native applications, using native UI elements. If the developer follows the platform guidelines, the application will probably stay equal (sometimes better) than an application developed using Java or Objective-C.
I'm working in a cross-platform open source project that uses Titanium Appcelerator, and I'm using the MVC design pattern to develop to application. So, my Android UI and my iOS UI is complete different, but the Model and the Controller is the same.
My conclusion is: it depends. If developer follows the Android and iOS guidelines, the application will be awesome. ;-)
PS: PhoneGap and Titanium Appcelerator are complete different, so you can't compare this frameworks. See this post: http://kevinwhinnery.com/post/22764624253/comparing-titanium-and-phonegap
Hey Rafael,
DeleteI believe it is possible but even the Appcelerator folks were unable to point out even a single good cross platform app made with their framework (I haven't even seen a single good Android app made by it). I'm still very happy to be convinced otherwise but I do require some evidence of it. If you have an app that is good please let me know! I'd very much like to take a look.
And yes, I know that phonegap is fully different but the marketing promise is same in their speech as well. I remain unconvinced by any of the so called cross platform tools for now. That's why I don't see much difference between them.
We just released our Ti-based app a couple of weeks ago. It's a regional entertainment guide for the Raleigh, NC area:
ReplyDeletehttps://play.google.com/store/apps/details?id=com.cbcnewmedia.oaa
http://itunes.apple.com/us/app/wral-out-about/id546058259?mt=8
There was a *massive* learning curve with Titanium, but in the end, we built this with about 10 man-weeks of time (and that counts the server-side work that went into it, as well as the one-time learning curve). It's hard to imagine building an app like this in two native toolkits in that time frame.
If I had to build something similar today, I think I could shave off about 3 man-weeks based on all the tricky problems we ran into.
Now I admit that this app doesn't use a lot of flashy UI conventions -- it's pretty much right up the middle of the road. But I would say that nearly all informational apps follow the same basic pattern.
This comment has been removed by the author.
ReplyDeleteHi to All,
ReplyDeletei am getting confusion with this long discussion of experts.i need to develop a online document signing application for both iOS and Android so tell me which approach i need to follow?
You should first pick the platform you want to target first and build the app with that platform tools and design for that platform. Once that is done you can build it to the other. Unfortunately there is not much you can share between the apps if you want to reach into a good solution.
DeleteHi Dear Juhani,
ReplyDeletei have a application which i was targeted for both iOS and Android.the main goal is the application should be same look and feel in both platforms with good performance and Rich UI.
Hey Srinivas,
DeleteThat is the absolutely worst thing you can do. Android and iOS are very different platforms and users expect apps to work differently. Consistency in a platform is much more important than consistency withing one app in multiple platforms (users use other apps from same platform all the time an very rarely use another platform). The platforms have different UI guidelines and different components. Trying to make the app look same on both platforms is likely to cause your users to reject it on both.
Unfortunately it is not possible to get the same UI / code on both platforms successfully. There is not a single example out there where it works (other than games). By trying to do it you will most likely waste your time and have to restart the project from scratch again.
Maybe the cross-platforming part of the story could be left up to ipad application development enthusiasts, who seem to have a better chance at scoring at it when compared to these two groups.
ReplyDeleteI get a feeling that no matter what evidence is presented here in favour of webview wrappers, the author has his opinion and will stand by it till the end. Fair enough.
ReplyDeleteI would like to ask the author if he has built any apps with PhoneGap. I think all your negative points relate to how much attention to detail the developer has. A rushed for time, lazy developer will most certainly churn out a sub-standard app.
Also a point I would like to make, that seems to be lost here, is that there is a trend, especially on iOS, to move away from the native look and feel. There are thousands and thousands of apps now that look the same on both Android and iOS. Look at Evernote for example. Just beacause I am on iOS doesn't mean I have to use their widget toolkit, nor use a bottom "nav" bar. Look at some of the pro audio apps. All full screen without traditional top and bottom bars. Some weather apps also do the same, going even further and having their own unique configuration panels as well.
The native elements do not have to be used to create a professional looking and pofessional functioning app. I, for one, am extremely pleased that apps dont all look the same then we would end up with a PC UI on a smaller platform. We want apps and we want them to look good. Look at 360 News, as another example -a brilliant app. If I cropped the screenshot from Android and iOs and shuffled them around, would an average app buying user know the difference, or really care?
Having said that, I believe in the PhoneGap approach. There is a substantial amount of native code with a javascript bridge for interface elements. We've included a bar code scanner and it works phenomenally well.
We are currently working on 4 apps. 1 is about to go out of beta. We used jqMobi on PhoneGap. Admittedly we were about to throw in the towel after first choosing JQuery Mobile, but as a last effort decided to give jqMobi a try. I must say we are extremely pleased with the results. There is no scroll lag, no UI glitches. In house stress testing has gone very well indeed. The icons are vectors for different screen resolutions, we use ajax server calls with timeout and network sensing.
Also, how can a user's poor user rating point fingers at hybrid? That's not a clever argument as there are plenty low rated native apps. It's all about the concept and the developer skills. Bottom line.
It is pretty ridiculous claim that I will stand by a conclusion no matter what even though I've very clearly stated that all I need to be convinced otherwise is a single example. Only one, that proves that it is possible to create good apps with these frameworks. Personally, I don't believe that it is possible to create even decent apps with PhoneGap. Every single app built with that framework is ridiculously bad and frankly embarrassing to any company choosing to publish apps with that framework demonstrating their complete lack of understanding of the business.
DeleteOther frameworks are a bit different. I've still not seen a Titanium app that is good but I have some level of hoe that at some point it would be possible. I also had an interesting discussion on G+ some time ago about Xamarin. It seems to be decent cross-platform framework as some of the apps are actually OK.
I think these frameworks are moving forwards but they're still lacking behind. I've also talked to multiple people talking about their efforts for trying to utilise these frameworks in their business and in the end having to abandon them as it hasn't been possible to get the last 10% of the app done.
Pointing fingers at bad rated hybrid apps is justified as it is very clear in many cases that the bad result is due to the bad user experience directly derived from the way the framework makes the apps feel.
If you believe that you have created a great app that is great with a framework like this I'd definitely love to see it. I don't put any weight on anybody's words telling that it is possible if there's not a single example of it. On the other hand a single example wille fully destroy my argument and I'd be more than happy to retract it. I've publicly said many times that given the evidence I'll do it. If your app is great just send me a link and I'll write a post about it telling everyone that I've been wrong.