Among the many mobile app development challenges (user experience being one of the most important) the platform is one of those that has seen many solutions raising in the recent.
There are a few platforms out there, some are growing (iOS and Android), some are still in the process of seeing sun light (Microsoft) and some are slowly falling to the backyard of the market (Symbian, BB, etc).
When you develop a mobile app you either learn all the platforms you want to support or you try to leverage the frameworks available out there.
There a few promising mobile app portability frameworks, each with their own pros and cons and, obviously, none can really stand the comparison against the true native app, but you must be ready to sacrifice something at the altar of portability.
This approach produces 99% reusable code, meaning the only non reusable parts are the little native bits you might need to plug/customize to get some native features: as an example, if you want to show one of those ad banners using the native ad provider, you need to plug in a little native fragment.
Performance wise these type of frameworks have a limitation directly connected to the native web browser component: faster is the native browser, faster will be your app.
Please note that this type of frameworks usually do not provide any widget by themselves: they just present whatever HTML5 content you tell them to render: while this might be a great benefit it is usually their greater weakness.
In my experience such difference is not so bad to make apps unusable, but you can definitely say it’s not native or not really optimized. Please note: this is not an issue directly related to the portable framework itself, but to the native components these framework use and the UI library the designers adopt.
Another approach to achieve mobile app portability is through a common mapping layer/library: this approach consist of exposing through a uniform library the interface of the native components, as per the well know Adapter design pattern. This is the same approach Java used for their AWK library. The greatest limit of this solution is the framework either exposes the Lowest Common Denominator (abbrv LCD) of the native features or delegates to the end users the problem (AWK used the first approach, which revealed as a failure).
The level of reusability these approach provides is definitely lower than the previous one and can greatly vary depending on a per app basis: their authors state a generic app usually reuse 80% of the codebase, with the remaining 20% customized on a per target OS. These figures are still good considered the 100% non reusable code you get by going completely native, but what is the performance/capability loss? Well, from a capability point of view, the loss is usually not so much if the framework you adopt has taken the approach of exposing the union of all the features available on the OSes it supports. Please consider though there is a time gap between when a features is made available on the native OS and the same feature becomes available within the framework.
There’s no silver bullet here yet: pick your option considering the different pros and cons while the market evolves and new options get explored!