You may look at corona-sdk[^]. I have not used it in over a year but is a great concept. Write everything in Lua and it gets compiled for most any mobile platform. Just make sure you can do what you need it too before buying it. (I ran into a few gotchas, mostly with device specific functions like GPS)
CoronaSDK looks intriguing. I'm a little concerned that it uses a scripting language. One of the reasons I was hired is that our desktop app was using something similar and doesn't scale well. However, were I doing game development, this would be at, or near, the top of my list!
Our company has decided to go native, but I'm not sure I agree. Yes, we use RESTful services, and yes, we're sharing simple JSON data packages from the back end, so the UI is very much able to be platform specific. So now I'm building a native Android prototype. Yes, as a C# developer Java is an easier transition, but the native stack is unique. I've had to learn about saving login information/session states when rotating screens, the uniqueness of binding to a ListAdapter, and the caveats that are the platform. It's fun, but I keep thinking that it's a blank slate the day they ask for my prototype for iOS. Yes, the business logic is in the back end, but the UI isn't light, small or a trivial task, let alone if you know you'll build and maintain at least two stacks. (We will need to support Surface tablets too, so we know we'll need three UI teams eventually.)
BUT - weigh a couple of things - can you/your company afford to have an iOS team and an Android team building the same UI for a given product? Yes, users prefer native Android controls/look and feel, as do Apple users, but if you can't afford both teams, then having a cross platform product that you can sell to either consumer is more valuable (to me) than native.
Also weigh how much of your consumption will depend upon the features on the device; if you're not interested in geolocation, snapping photos, or maybe don't have a need to get to native services, cross platform is a stronger option. In our case, we're very device centric now, using the camera, the GPS, the accelerometers, etc. In theory you can get there with PhoneGap, but it's a weight that must be measured.
Finally, consider your audience and your application suite. My company has a large suite of products and product lines. Each app we release for the new mobile work (because we're a bit playing catch-up) has to be a quality, top notch, well-performing product. We can afford to dribble out a product within a suite at a time, one that lends itself to mobility, and learn as we go. If you're a smaller shop with less applications, it's all about delivering the best product to the largest number of your customers.
I awoke in a fever,
The bedclothes were all soaked in sweat.
She said, "You've been having a nightmare.
And it's not over yet" - Roger Waters
Since I posted my original comment, I've eliminated Xamarin for several reasons and am zeroing in on Qt and DragonFireSDK.
(As an FYI, to check the viability of going back to C#, I ported a section of completed code from Qt. To my surprise, it ran twice as fast as the C++ version. I scratched my head and then realized that I'd been writing files using an ACID type algorithm to prevent data loss/corruption if power was lost. However, in the specific case I was testing, I didn't really need to be doing this since I'd changed how I was enforcing data integrity [it became an all or nothing thing at a higher level.] I made the change and the C++ version ran 4 times faster than the C# version, which is what I expected.)
Personally I found Codename One to be a better match for my needs than QT or Xamarin. QT has some nice capabilities and I would agree with you that I would pick it over Xamarin.
This varies a lot with what you are trying to accomplish though e.g. I would not use Codename One for a game just like I wouldn't use Unity for an app that isn't a game...
When comparing Codename One to QT there are several big advantages e.g. you don't need a Mac for iOS development, but surprisingly native integration is better... E.g one of our apps needed Google Maps support and we were sure we'd need to go native with QT or fully native. Turns out QT doesn't support native Google Maps (or didn't at the time) and Codename One had "ready made" integration that worked on iOS & Android. To be fair the Codename One integration had some issues but we got it to work eventually.
Let me add a bit to this.
GPS Coordinates are actually Latitude/Longitude Coordinates - in use looooong before GPS satellites (or any man-made satellite) ever existed.
Latitude/Longitude (Lat/Lon) is a spherical coordinate system.
UTM is spherical surface projection to a 2D flat surface.
However, the Earth is not a perfect sphere. There are different models of the earth that each have varying accuracy in different regions of the Earth. And these models have also improved over time.
The "Vincenty" formulas are used to go back and forth between the spherical model (Lat/Lon) and the flat model (Northing/Easting/Zone).
The "Vincenty" formula are generalized to allow the use of different "ellipsoidial" models of the Earth using a "data set"of which WGS85 is the most common in use today, at least in the USA.
The iPhone GPS chip provides location in Lat/Lon. A particular mapping program will locate a position on its maps based on the UTM data set the maps were created with.
For example, Google uses WGS84 as did the old Microsoft Teraserver. I would expect that all map services located in the USA use WGS84. However, there are some map services with data that originates from older printed maps that used NAD27.