I think you're misunderstanding jtheory. It's not about whether it's native or not - it's about using each platform's idioms and peculiarities which don't exist in other platforms. There isn't a 1-to-1 mapping between iOS UI elements and Android UI Elements. What do you do then?

The Android Spinner is an example: http://developer.android.com/design/building-blocks/spinners...

There is no alternative in iOS, but if you don't use it in your Android app you are missing out, because people on that platform expect it and know it.

What about Back buttons in iOS? You don't need them in Android. If you are developing a cross-platform UI without using these elements, you are probably compromising the UX of your app.

I am very interested in how those problems are solved. Will try and play around with it.

The application you are building will use each platform's idioms. So the UI layer code will be platform specific and can not be reused. All other business logic code will be reused thought.

This is often a returning topic here on HN where most users probably work in startups and/or companies with consumer facing apps. Those would want every platform to have the look & feel of the platform you're running on. Although... Seems the new version of iOS Skype is WP8 styled and feels a bit alien on iOS while it's not unpleasant at all. So not sure if I agree always. Anyway; if you have apps for internal use or use with partners, it is actually often better for the apps to be 100% identical on all platforms as that will save tons of support calls. That's why a lot of companies just do iOS first, design it for that and will make the Android version exactly identical. To save time there, often HTML5/Cordova is used for that by internal departments / IT, but I know you can make MUCH nicer apps in the same / less time if you use Xamarin (Forms or Metaframe) (or maybe a solution like this) (although I cannot imagine IT would pick JS over .NET or Java, ever).

I think for many apps out the codebase is dominated by UI code, and the business logic part is small and relatively easy to write anyway. From personal experience, sure, I have some classes that abstract away server APIs and some classes for data models. But most time and sweat goes into getting the UI to look good and performant on different devices.

Say, for an app like Timely [1] which I'm a fan of, I would think the data models for timers and alarms are trivial, and the code for all the subtle animations is where all the meat is.

[1] https://play.google.com/store/apps/details?id=ch.bitspin.tim...

This is really the way to go. Customize the UI to the platform make the app as polished as possible, but don't give up cross-platform business logic/unified deployment.

I agree with what you said, but I'm curious about Android Spinners. They look like select drop downs. Why are they called spinners? What makes them unique to Android? iOS of course also supports drop downs, and the UI implementation for a drop down actually looks like a spinner in iOS...