Shared publicly  - 
 
What can't you do in a mobile html5 app you can do in native iOS and Android apps?


A few points I see:
-you can't do really make your app work offline on smartphones/tablets
-you can't post pictures
-it's slower because you have to do more calls = more "waiting for reply"
-adding attachements is more painful
-no push notifications (thanks +David A. Fenton)
-it's got to reload the app each time you relaunch the browser (my experience with gmail on safari/ipad)
-video capture (thanks +Nicolas Roberge)
-Access to contact list

Am I all wrong? What else? thanks
126
84
Brett Freeman's profile photoLoic Le Meur's profile photoDavid Shellabarger's profile photoTom Brander's profile photo
125 comments
 
I assume you are talking G+ specifically?
 
can you not do image posting because the file system is not accessible (iOS). Why couldn't you browse to pictures from Android ... or other systems?
 
No reason for an HTML5 app to not implement local storage, be installable, upload images....
 
The financial times app made on html 5 works offline on the iPad.. 
 
Google is upgrading the web. That is why Chrome OS was delayed. They are adding offline, notifications, hardware acceleration, native code, 3D acceleration, pictures, videos, attachments etc, Google and others working on cutting edge HTML5 are making sure all those features are in our next web browser.
 
+Steve Yelvington no reason, but look, even the Google+ html5 mobile app doesn't let us upload pics
 
localStorage can store up to 5MB. the design pattern is to pre-load everything, assets, templates, etc. when the user first loads the app. wait till you see the html5 apps I am working on for an example - nothing out there atm, outside of demo's, is really pushing the envelope - but the next gen is going to be fantastic
 
html5 is the first true 'write once, run anywhere'.
 
The 16GB Flash storage on a Chromebook is supposed to mostly store offline cached web apps and web app content.
 
There are all kinds of Android specific things you can't do.
-Change the wallpaper
-Completely replace the Home Screen
-Completely replace any app
-Add ringtones
-Access the local file system
-Access the menu button
 
A few things I can think of (some of which are above):

- You can't do overlays on the camera capture screen (guides, buttons, etc.).
- You can't upload files on iOS, so no sharing images
- No push or local notifications

PhoneGap is one alternative (http://phonegap.com/), which provides a JavaScript wrapper to native features that aren't just available in HTML5.
 
if you are asking for seesmic, have one of your devs segregate him/herself for a week and get familiar with all the latest and greatest and produce some prototypes/demos
 
Manifest will allow you to cache almost (if not all) all that you are talking about for off-line use
 
If i remember Android 2.2 was supposed to bring camera access from the browser. In fact they demoed it. Will need to dig up the API

Update: saw the video, its post froyo and experimental
 
you can develop for WebOS = HTML5 + phone sdk... 
 
- No access to the Contacts on your phone or for that matter any other Permission that Android lets you access
 
Need more mature development frameworks -- this stuff is raw, and that's even without considering iOS breakage.
 
+Nik Cubrilovic I'm actually writing a native Android app right now that uses an XML file as the backend instead of a database so that the file can be easily copied between devices.
So it might not be super common but I need access to the local file system.
 
but there is a definite shift happening here, as big if not bigger than AJAX and Web 2.0. it is about single-page apps, css media types, nothing on the server bar a REST API, canvas, the web app being an implementation of its own API, not storing user accounts, microdata, integrated social graph, off-the-shelf web services, and hosting it all on a platform-service provider. exciting times.
 
+Nicolas Roberge If you contacts are in the cloud how to you manage permission to them? FB connect? Should I require a FB account for my app?
 
On SetForMarriage.com, I got around the "no uploading pictures" thing by giving each user an email address on signup that they can email their profile picture to. It's not perfect, but people actually use it. :)
 
notifications are in webkit (chrome etc.) they just haven't been implemented in iOS yet. in chrome they look like that toolbar you get across the top when you install an extension. most of these things will be provided either very soon, or soon - we are in a bit of a parallel platform phase - but it is well worth getting into html5 now. the biggest thing to happen is support for web apps in distribution and defining some form of metadata around an app so they can be distributed in appstores - but that will come (chrome already has its webstore which is essentially that)
 
+Loic Le Meur you just saying that because of Seesmic :)
But seriously, I agree. I find the cloud/web apps very frustrating, they are slow, need a good net connection etc. Maybe I'm old fashioned but I like the code on my machine (be it desktop or mobile) where it can execute whenever I feel like it, not just when I have a good net connection or the server it runs on is online.
 
+Loic Le Meur that is because Quora is more formal with performance pressure - here we feel free to say anything crazy and unedited :)
 
it is a bit like how it is harder to hit publish on a blog post than it is on a tweet
 
+Gerard van Schip your desktop app would need a good net connection as well. Desktop seesmic app or web seesmic app would both suck if the connection speed is lacking
 
There's no opportunity for peer to peer device functionality via HTML5. No mobile payment via NFC, contact exchange or other data sharing.
 
Here what I can tell you about the points you mentioned:
- You can be fully offline if you want it (no server call), it really depends of the app.
- right, you can't post pictures
- Using websocket, it's very very fast
- right
- may be possible sooner than we think
- right, except if your webapp is part of a native app
- right
 
+Mina Almasry It's actually not that HTML5 couldn't handle certain things but rather iOS and Android are not exposing certain functionality to the mobile browser.

Example: You can share a photo or video from your laptop's browser here on Google+ but you can't do it via mobile Safari on your iPhone.
 

@Mina almasary look at dive in HTML 5 as a good starting point. HTML is defined by w3c and then the individual browsers implement the features depending on a variety of factors. There is a site that shows which parts of the HTML 5 specification the popular browsers have implemented. 
 
+Mina Almasry You can use most all.. there are some excellent JS shims when you read the links it will all be revealed html5rocks and html up and running are great resources
 
Most of it is doable in HTML5 actually. LocalStorage, SessionStorage, Browser SQLite, Drag & Drop for attachments, Web Workers + real-time protocols, etc...
 
I don't think you can access the camera at all ( video or pictures )
 
Totally agree with you! In many cases html5 to me sounds so tomorow!
 
Access to OpenGL and similar underlying graphics libraries is not possible with mobile HTML5 (they don't support WebGL AFAIK). And even if they did, the JS interpreter is just not fast enough to get good frame-rates for any complex 3D accelerated interactive application.
 
Build a walled garden and rule the lives of your developers like an angry dictator...
 
Hey now, I would rather have the walled-garden than the malware-fest that is happening on the other side of the wall. Besides, many of the carriers are trying to create their own little walled gardens. Been there, done that, have the crappy RAZR to prove it.
 
+Raj Advani webgl will be available in iOS5 for iads, and the plan is to offer it fully in the iOS after that after the spec is shaken down. it should be fast enough considering webgl api maps to the native opengl api which maps to hardware accelerators. javascript is already very fast in safari with the jit compiler. I don't think we are far away from full 3d games running on both iOS and Android. Carmack talked about porting RAGE to webgl (some guy did a demo port and it ran on desktop chrome very quickly and well). If you can do it natively, the overhead of doing webgl via the browser shouldn't be that great. this is definitely where apps are heading
 
+Mina Almasry what you are looking for is modernizr : http://www.modernizr.com/ . it will detect which html5 features are available and allow you to use 'shims' (eg. modules of javascript that will implement certain html5 features in browser that do not support them using other means). do not sniff the user-agent, but instead use modernizr or your own tests to find out if the browser supports the function(s) you need
 
and here are some webgl demos if anybody is interested in trying them: http://www.khronos.org/webgl/wiki/Demo_Repository

there is also a quake II port in webgl : http://code.google.com/p/quake2-gwt-port/

i was going to port the DOOM engine to js+canvas+webgl for kicks, but it turns out that somebody has already ported the quake 2 engine, which is sick :) not far away from being able to run a half-life like game in a browser on mobile devices, especially with the new snapdragon-like chips in the androids and the tegra's
 
+Nik Cubrilovic That sounds brilliant, and I really like where WebGL is heading. But last month I messed around with WebGL and while the bindings to OpenGL worked really well, it was the lack of a consistent local storage solution that made me abort porting my rendering engine over. The FileSystem APIs seem to still be in their infancy.

Furthermore, on Android even the Dalvik VM runs too slowly to handle complex CPU-level calculations if you have a lot of objects on screen (unlike Quake, Doom, etc.), so I'm skeptical that JS speed will be good enough -- there was just too much overhead involved with invoking any virtual function. On Android I got around this by using the NDK, which was incredibly fast.
 
+Christian Del Rosso wrote "with html5 you cannot access sensors in the device."

That is too general. The accelerometer and gyroscope are both available in iOS right now. GPS has been available for some time. All qualify as sensors in my mind. :-)
 
W/ HTML5 you loose accessibility layers that are built into the OS/Browser and at the moment aren't being made up for in the current draft of HTML5... think Canvas for one...
 
Thanks all for your comments, I'm still heavily investing in native for now :)
 
Both are good in their own way. Arguably, cross-platform's ROI is much higher.
 
Good point about your app not being promoted in appstores, marketing wise
 
the tipping point for html5 was the Windows 8 demo. now there is nobody standing in its way that could actually slow it down. all the major vendors now have an interest in seeing it work, Microsoft, Google, FB, Apple etc. and that has not happen in tech for a long time.

only adobe lose :)
 
I was going to say Good Point to Nik, but the thing is, Microsoft isn't even a player in the mobile space: they're laggards and their market share continues to dwindle as, internally, the old desktop Windows guard will sabotage anything new and non desktop-Windows (at least that's the way I see it from an external point-of-view).
 
Josh it isn't just mobile, Microsoft are talking about html5 on the desktop with windows8. the idea is that they unify their platforms around html5 - the purpose of the operating system is to simply provide a layer between hardware and html5
 
those dashboard gadgets/widgets in the windows 8 demo were all html5
 
Nik, let's see how this pans out for them. Personally, I think they lost their edge a few years ago, just as they entered the gaming console market. I would bet on Apple, Google and other players.
 
Josh I would agree. MSFT need a major overhaul if they are to survive. you can see that their strategy is completely fragmented. they have windows, mobile, .NET, silverlight, xbox, the cloud and now html5. they previously owned by having a single platform and getting it everywhere - they seem to be just trying everything atm.

more to it with html5, it was a case of if Microsoft got in the way of adoption then it could have hurt the cause. ~50% of web users are on IE, so Microsoft co-opting html5 was important
 
If by HTML5 we are talking about server side applications, then the biggest miss would be the revenue model that App Stores provides, i.e. API access to in-app purchases. There are projects like PhoneGap which allow to package HTML5/JS as apps, and expose APIs. However, the mobile market is currently a fast moving target. If developers rely on third-party libraries, they will miss competitive advantage (i.e. iOS5 Twitter integration, iCloud, etc).

Maybe, in five years mobile OS innovation has stopped and HTML will bring superb user experience, but not now.
 
Mina: «am wondering which platforms are best to invest in». It depends on your needs. Android has a large user base and grows fast, it's a good target for free applications. For paid apps, iOS users spent more money. Windows Phone 7 is just a promise at this moment, very small market share.

C# can be used to target iOS, WP7 and Android, take a look to http://xamarin.com/ (I hate middleware, and ended learning Obj-C for iOS dev).
 
HTML5 does actually provide for working offline on a local database with syncing when you are connected again. However an HTML5 browser with appropriate support is required. None of the browsers provide full HTML5 support yet. Check http://html5test.com for browser support.
 
You could use Appcelerator Titanium as a wrapper around HTML5 content while having access to native hardware (camera, GPS, storage). Your app could run on iOS and Android from a single JavaScript code base. Publish to the app stores, run without a data connection, do camera overlays, access native UI components, lots more.
 
I'm not sure if it's the technical details that will swing usage in either way, it's what's more natural (and fun) to use for the average user. Clearly native apps have an advantage here. HTML5 apps still has their place though.
 
Great thread, lots of good ideas for the web platform team! :)

And yes, as many pointed out, it can take a while for some of the HTML5 standard features to make it to mobile. The pace is picking up though.
 
On Android right now you can't do anything with smooth graphics in html 5, hardware accelerated rendering (compositing) is simply not supported yet.
 
To clarify some points on Titanium & Phonegap:

Titanium is nice, but it's really limited to only iOS and Android, and by all accounts, the Android piece isn't nearly as finished as iOS. It also suffers from the fact that while it's library of 300+ api's is very robust, they are also proprietary. On the other hand, PhoneGap is pure HTML5+CSS+JS for everything except calls to native components. (By way of example, if you want a native UI in Titanium, you write Javascript to call a Titanium specific UI api function, and it gets worse because often times you'll need to make different API calls to accomplish the same task for different platforms. Whereas with PhoneGap you only write the UI one time and it is interpreted by the specific browser on the device. Exactly the same? Nah, because the browsers are different. Pretty damn close? Yep, and a lot easier to maintain.) PhoneGap enables access to native components on iOS, Android, Blackberry, Symbian, WebOS & WP7. While Native will always be faster, and apps created with Phonegap are still a web apps (the app is packaged into a native app code package but spools out to a web view) it is important to note that they are executed locally on device so they tend to perform very well compared to native and much faster than cloud based web apps. To be clear, I'm not hammering Titanium...it's a fine choice for some specific scenarios.

So...if performance is critical and only a single (or small) number of platforms will be supported then native, and possibly Titanium, are the clear choices. For all other scenarios (many platforms, need to generate POC rapidly, etc) the best candidate is Phonegap as it provides the best intersection of performance, platforms supported, native functionality and prominent development platform (HTML5+CSS3+JS).

Probably a tl;dr...but just my 2 cents... ;)
 
Loic, since 2009 appMobi has focused on HTML5 as a unifying technology for mobile development and we have solved many of the issues you raised with HTML5 mobile apps:

>>>you can't do really make your app work offline on smartphones/tablets
We have a cloud-based build service that builds HTML5/JS into native iOS and Android apps. We also have a "web app" browser called MobiUS that makes web apps perform exactly the same as native apps - persistent data, icon on startup screen, no reload on restart.
>>>it's slower because you have to do more calls = more "waiting for reply"
We've speeded up HTML5 canvas rendering for games by 5X with "DirectCanvas" tech - available for both native and web apps.
>>>no push notifications (thanks +David A. Fenton)
Our "PushMobi" cloud service delivers rich HTML5 media (not just text) push to native and web apps
>>>it's got to reload the app each time you relaunch the browser (my experience with gmail on safari/ipad)
again, solved with MobiUS


While the general perception is that web apps are still an "ugly stepdaughter", we think the advantages of open and very mature dev technology (HTML) easily beat the pain of fragmentation. I'm sure you experienced this firsthand in porting Seesmic to iOS, Android and BBY platforms.
 
@Ian: The point isn't that HTML5 needs to catch up, the real point is that you can build apps which have these features using HTML5 as a basis, provided you know how to do it, i.e. which libraries and technologies to use as wrappers and extensions (e.g. PhoneGap, Sencha Touch, Appcelerator, JQuery Mobile) as we do at YashLabs Touch: http://touch.yashlabs.com. The advantage is higher ROI since a single code-base can be reused on all platforms with little or no modifications.
 
Josh, I think you need both. And tools. And a 3rd party ecosystem. And ... :)
 
Web app + Simple Wrapper to support notification, camera file uploads would work. but then if it is too complicated, you might as well make a native app.
 
I work on the Google Maps team and was part of the team that developed http://maps.google.com for mobile web browsers (http://googlemobile.blogspot.com/2011/05/google-maps-on-your-mobile-browser.html). The main challenge we faced (and continue to face) in attempting to surpass or even match the experience of native mobile maps applications was performance, particularly in the areas of startup time, maintaining high and consistent frame rate in animations (e.g. panning, zooming, scrolling, fading), and leveraging device storage to avoid going to the network. To enable mobile web apps to challenge mobile native apps in performance, mobile web browsers will need to:
- Improve JS execution speed (Android browser is much better than iOS browser in this regard, but both need to improve)
- Improve JS garbage collection so it doesn't cause noticeable stutters when running apps
- Support WebGL with high performance
- Support CSS 3D and CSS animations with high performance (iOS browser is good here already, latest Android browser supports CSS 3D and animations but performance is not great compared to iOS)
- Provide developers tools to pinpoint and diagnose performance problems
- Make it possible to install mobile web apps similarly to how mobile native apps can be installed, complete with up-front permission granting, up-front downloading of code and assets, auto-update when new versions become available, and the ability to run the app in a chrome-less browser instance.
- Give mobile web apps access to more local storage so they can cache code, assets, and data across sessions. Today a web app can only store 5MB of uncompressed code and assets (in AppCache) and 5MB of data (in LocalStorage), while native apps have much higher limits. Either these limits need to be raised significantly, or a mechanism provided where users can grant an app higher limits.

The second challenge for mobile web apps compared to mobile native apps is APIs: mobile native apps have access to many more APIs than mobile web apps do today. This thread has already explored this thoroughly so I won't go into it more here. I also feel that performance is really the first and main challenge, though clearly it takes time to design and implement APIs so mobile browser teams should work on improving performance and APIs in parallel.
 
+Evan Parker , totally agree with you! i have recently worked with two clients on two android apps that require the google maps component, performance is def the #1 issue, esp with different Android screen sizes, performance varies.and it is very hard for some of the overlay items to get clicked and retain the same behavior as in a desktop browser.
 
+Evan Parker The one i was referring to was a native android app to communicate with the web app backend. The android app has an activity where google maps are needed and we ended up using webview to load the standard web app within the app. The reason was that there were some functions provided by the Google Maps on browser that is not in the Android API. But on the other hand, the web app's overlayed items were not so responsive when clicking on them and the UI wasn't so pleasant, as expected.
 
+Evan Parker Awesome overview, thanks for sharing. To add to this, I'd say that the performance enhancements on the browser and JavaScript side is a given since all browser vendors are now engaged in a tight evolutionary arms-race to improve both. I like the PhoneGap approach where the API capabilities can be compensated. In addition, I'd say that there are a lot of UI, Client-Server and architectural issues that the Web has already solved a long time ago so it's a good base to build upon. Moreover, not all apps need to be highly performing, so that performance is a non-issue for many apps.
 
+Edison Wang OK, the maps api a separate code base from http://maps.google.com, though it faces similar performance challenges. I recommend posting to the Maps API forum about your experience, or maybe pinging +Thor Mitchell who is on the Maps API team and is often active on the forum (not sure how active he is on Google+ yet though).
 
+Josh Nursing Yup mobile browsers are rapidly improving performance these days, though they have a ways to go to match native apps. And I agree that PhoneGap is a great approach give mobile web apps access to more APIs.
 
One assumption i see in most arguments pro HTML5 is that it is just another version of HTML. But it isn't. It is a radical change from 'regular' HTML. Your average HTML-developer will not become an HTML5-programmer overnight, you have to understand all these API's that enable you to use the native functions from web. It's just not the same thing as HTML4. HTML5 is a client platform, like +Tim Bray said (http://bit.ly/ijQ36u ), and it is not an easy one.

So even if i could do all the things +Loic Le Meur is mentioning above, the question is whether i can find the HTML5-developers to do it for me. I know i can find developers for the other platforms...
 
Most of the problems are solvable with HTML5, although most HTML5 implement don't use them all correctly which is part of the problem.

There is definitely a different "feel" to HTML5 web apps over native, which is think is usually down to responsiveness. Web Apps have a layer of HTML rendering in between themselves and the bare hardware, and as such they will never be as responsive as native Apps.
 
I have yet to delve into HTML5, though it's on my To Do list, for the reason +Eelco Hoekema mentioned. Are there any security issues involved with giving increased access to device resources beyond those of native apps? Can some rogue phishing site take advantage of access to local storage and hardware? It seems more risk would come from the web than native apps traceable to known developers. As developers push the boundaries of performance, is security being considered?
 
+Keith Moon I agree that HTML5 web apps have a different feel today, but if mobile browser performance improves in the areas I list then I bet we can create web apps that feel indistinguishable from native apps.
 
@Kieth Moon "they will never be as responsive as native Apps" - never say never - the apis just have to route down to the hardware when needed - e.g. transform3d on iOs is pretty close to native performance, some WebGl implementations bind almost directly with the GPU - its getting there, won't be long, but ffs someone stick a rocket up the Android guys arses please!
 
You get slightly more HTML5 offline storage in iOS using the Web SQL db (max 50MB), but the limits are smaller and harder to determine on Android.
 
wow I had no idea I would start such a debate, thanks all for your answers!
 
W3C Device API working group which might be of interest: http://www.w3.org/2009/dap/
It includes plans for direct access to contacts, calendars, media capture (cameras, mics), messaging (sms, mms) and many others. Could anyone comment on how active this is?

As many have already said, wrappers such as PhoneGap will fill that void until these API's mature and (slowly!?) get supported by browsers.
 
Luic, just so I could answer your question… we launched today a Native iOS app that delivers thousands of mobile HTML5 apps. It even searches inside them.

So, we used a native app to build the platform, because it couldn’t be done (yet) in HTML5, (we open multiple browsers and swipe and prioritize resources between them).

Then,inside the app, we use HTML5 web apps, because you can LINK to them (rather than install them), you can search them – you can create a new mobile web.
 
@dale Cruse, you can charge for HTML based apps in many ways - micro transaction (see Zynga), subscription (see FT), advertising (most of the Android native app market), are all available to HTML5 apps, in fact, even on the iOS, fremium is already bigger than premium: http://bit.ly/qj8YSp
 
(my post that was posted in a re-share on another thread)

- HTML5 webapps can work offline using localStorage, it's just that nobody's really using it yet (Here's a good early example optimized for iPad http://everytimezone.com/)
- Correct, iOS doesn't allow access to the device's file system. Other systems do, and support for file access is provided by hybrid solutions like PhoneGap http://www.phonegap.com/
- It CAN be slower, considering native apps get most of their content downloaded as soon as you download the app (ever download a 40MB+ app? Annoying, right?). However, many apps are essentially webviews (Yelp, Facebook, Google+, etc) and need to retrieve the information online anyways. Any sluggishness is most likely associated with poor coding: http://twitter.com/#!/brianleroux/status/83062819997757440
- Adding attachments is more painful for the same reasons as point #2. PhoneGap aims to solve those issues.
- Correct, no push notifications. BUT here's something to consider. Apps don't open links. So anytime you open a link in twitter, email, text message or other format, it opens the browser, not a native app. So an HTML5 push notification can be sent via email (think of "John Doe just posted on your wall, reply here") and that email gets "pushed" to your phone. Bonus: that gives you a nice paper-trail/bookmark/sharable record of that notification.
- Correct, the app gets reloaded on browser relaunch. But you can add sites/web-apps to your homescreen to emulate native app experience, and now in iOS5 run them in fullscreen just like a native app (i.e. no URL bar, browser chrome).

Here's a couple more legit qualms with web apps:
- No access to certain device APIs yet (camera, contacts, NFC, media, etc)
- Sluggish scrolling effects (especially in Android) in browser can be inferior to native scrolling effects (which are hardware-accelerated by default)
- Graphically-intense apps (especially games) don't have the same fidelity as native apps

Some non-points:
- "Findability" in an app store. Your app is buried regardless. Search engines, social media, buzz can spread a web app far and wide
- "Native VERSUS Web". It's a bullshit argument. There's certain things that native apps do better than web sites (or web apps), and other things that the web does much better. A smart strategy utilizes both to maximize mobile's potential.
 
here's how we do it: use native code for only-natively-accessible APIs, use HTML5 for UI and other logic that you want to use cross-platform - put it all together in an app and you end up having a 50% native / 50% cross-platform compatible product that's simplet to update and maintain than several purely native products. over time and with increased HTML5 support on all platforms this will become more 40/60, 20/80 or even 10/90 in favor of HTML5.
 
In short its still very difficult to compete with another similar app which has chosen to go native
 
I guess html5 apps are good enough for something and not good enough (yet?) for something else, like everything. What I am interested in is, how to monetize html5 apps? (besides subscriptions and ads). Perhaps a native paid iOS or Android app as a wrapper for a web app?
 
Currently I am working at a big Social Network company, and we are moving from native apps to HTML5 phonegap apps. I mainly work on the Android app.

The biggest problem is indeed app startup. The native apps are instantly there, the phonegap app needs some time to initialize. We already did a lot of HTML5 performance improvments like html5 manifest caching, caching trough local storage, optimizing all resources (minifying, spriting, etc etc). But even with a hot cache the app startup is still too slow... heck we needed a SplashScreen..

Also the user experience, like clicking buttons, going to different screens etc is completely different since we cannot make use of the Android Activities API anymore.

The main advantage is that we can develop for a lot more platforms at the same time... but this comes with a big cost i think.. will users eat it? Time will tell... I have my doubts.
 
It vastly depends on your audience and purpose.

The web app has no actual access (as of now) to the device's hardware, and most of the current browsers are either too slow, or forget to implement correctly, or even at all, ( Oh why hello there microsoft! ) some great features, such as webworkers, webgl etc.

There are kinds of apps that cannot be implemented in a web environment and other kind of apps that would benefit from it.
 
I have huge doubts too +Tjerk Wolterink we had a prototype at one point, and facing the same issues, we gave up.
 
just saying I keep coming back to this thread all the time as reference, thanks so much all
 
+Tjerk Wolterink I am interested in why you chose phonegap over appcelerators titanium stuff? Any pros vs cons?
 
Hi Loic,

Why not just use the passive view design pattern and split the controller into a shared javascript version, and an environment specific version (objective-c, java, or javascript)? Essentially the design of apache callback (phonegap) but allowing for code reuse in your web app as well?

This design solves all the problems you stated while allowing 60%+ of the code to be reused across all three platforms.

David
 
The number of browser quirks and webkit/webview variation puts a damper on an otherwise preferred development approach. I agree with the above approach, use just the parts you need in native, and use the "good parts" of JS/HTML5/CSS3 for the x-platform work. In practice, it does not mean that you reduce your development team or test cycle. It just means you probably don't need to field an expert per platform. That is a big cost savings. Rather, you need someone with some solid x-platform skills to pull together the native layer, and integrate it intelligently with the x-platform portion. You gain some good efficiency if you work with a designer who is familiar with mobile (and mobile device testing) who can give you live HTML wireframes to use. And don't discount the effect this has on the customer being able to do early concept testing in a development cycle to make sure they are on board with what you are delivering. There's such a broad set of features coming into HTML5 that the lead developer needs to cover a lot of breadth and have time to work out what works and what does not on the target devices before committing to certain APIs. And of course, testing overhead remains about the same to qualify on various platforms and devices, but there is some benefit to having a shared component, as your testers get familiar with how it is supposed to behave (and often does not) on each platform. My 2 pesos.
Add a comment...