(I have put various products in bold. If ANYONE has extensive experience with any of these, I'd be interested in comments on your experiences.)
First, some background:
I was hired to rewrite a RealBasic application. Vastly over-simplified, this is a vector drawing program which supports our cutting device and which must run on Windows and OSX. The previous job holder had decided to use C# and had written some code and did a small test with Xamarin, but hadn't gotten very far and apparently was running into problems, though since he left before I arrived, I'm not clear on what those problems were. I decided to use Qt and having been making good progress doing so.
Yesterday, I was told that the higher-ups have decided that a "lite" version for tablets, especially iPad, was my new priority. I immediately started doing some research and making calls. This is an extension of that. I am looking for real world experiences, not advice based on what someone may have read or Googled. I have narrowed things down to the following choices:
1) Continue with Qt. Pros: native C++, solid, I can do a lot of development on Windows, iOS & Android support are being added. Cons: iOS & Android support are being added and thus feedback on iOS/Android capability, performance, issues, etc. is limited, runtimes are large.
2) Switch back to C# and use Xamarin. Pros: Xamarin has a good reputation. I can do a lot of development on Windows. C# has some nice things about it. Cons: performance questions, look & feel issues, previous developer was having problems. C# has some nasty things about it--I'm quite adept at it, but still dislike the non-determinism, performance issues at critical points and how often I end up P/Invoking. Mono has gotten pretty good, but is still limited.
3) One developer suggested Unity, but it's way overkill for what we need--it's very game oriented--and while it handles some of our display issues, it doesn't help much below that.
4) Go completely native. The developer from #3, who's written games for iOS and Android suggested this. Pros: best speed, look and feel, app can be more fully optimized for the platform. Cons: portability issues may cause huge opportunity costs if sales justify going to Android. Requires me to even more "jack-of-all-trades, master of none."
5) A combination of the above (something the guy from #4 also suggested); writing as much code as possible in a common library with a shim layer (like QtCore) underneath and completely native for UI. This mitigates some of the opportunity costs from 4 at the cost of some speed and optimization. However, it may end up causing more work and end up with more #ifdefs than not.
5a) To simplify some of this, I've found a library called DragonFireSDK, which abstracts out the iOS APIs and lets you develop iOS code on Windows. Has anyone used this?
Again, I'm hoping to get feedback from developers with actual experience writing applications using these tools or alternatives. While I can get a little OCD about these kind of things, my main concern isn't as much picking the right solution but avoiding the wrong one.
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.)
Last Visit: 31-Dec-99 18:00 Last Update: 20-Dec-13 17:11