As far as I understand it, if you are big and have the resources, your best bet is still to develop separate native apps for each platform.
Right?
As far as "recommendations on developing for multiple mobile platforms", I'd be happy to answer slightly more specific questions.
> As far as I understand it, if you are big and have the resources, your best bet is still to develop separate native apps for each platform.
If you have different teams for each platform, it makes sense to go native and duplicate the effort. As soon as you want to share code or resources (including employees) between more than one platform, Xamarin starts making sense. If you have a small mobile development team (1-2 people), you'll probably need to either pick a single platform, or go with Xamarin. If you plan to have a Windows app, Xamarin makes sense. If the business is already using Microsoft technologies (Windows, .NET, C#, Visual Studio, TFS, or even Typescript), then Xamarin makes a lot of sense.
However, Xamarin is not a silver bullet. It does comes with some trade-offs (in addition to those mentionned in the article).
- You still need a Mac (either as your main machine, or on the network).
- Compile time is a bit slower.
- You don't get access to the latest Android SDK on day one (you do with iOS, though).
- You can't use any existing iOS/Android libraries out of the box. Someone (which could be you) need to manually "bind" the Java/Objective-C library interface to C# first.
- Application startup time might be a bit longer on iOS.
Did a project at work with Cordova, it works, but it is only usable for CRUD type of applications.
As for hobby projects, a few multimedia ones with SDL, which was ok since nothing more was being used besides OpenGL and touch input.
Tried to use Qt/C++, only to discover it kind of works, but even with all these years of talking about mobile support, Qt is pretty raw. Lots of native API wrapping is required or only available in the commercial version.
Xamarin is quite appealing, and even with the usual HN complaints about their prices, they are actually not much different from other commercial solutions for the mobile market.
Personally, I am using C++ for portable logic, together with the native UIs in Java, C#, C++/CX. However due to the pain it is to use the NDK, specially now that Google dropped the ball, I am thinking about focusing on just one platform.
If I would be doing this at work, maybe Xamarin would be the solution to go.
Xamarin provides a managed runtime environment (Mono) and a way to call native iOS and Android APIs from that environment. Xamarin Forms builds on top of those things to provide a cross-platform UI toolkit that uses the native controls on each platform.
Qt is a cross-platform GUI toolkit that draws its own controls using each platform's low-level graphics facilities. As such, the controls in a Qt-based application aren't fully native to each platform. Qt tries to mimic the native controls, but the emulation isn't completely faithful. A particular problem is accessibility for users with disabilities, e.g. blind users who need to use a screen reader. Last time I checked (several months ago), Qt didn't implement the accessibility APIs for iOS or Android at all.
Because of the non-native nature of Qt, I would strongly recommend avoiding it in favor of something like Xamarin or RubyMotion.
On my case, I wanted to make use of the native file pickers, which only became available in Qt 5.4 via QML (not C++)[0] for Android, with iOS and WP8 support still coming.
Granted, on Android's case the pickers are only available as of version 4.4, but they are available and it is also possible to use intents for lower versions and vender specific pickers.
On my specific case, I came to the conclusion that writing my own JNI layer would be less trouble than debugging Qt. However note that for me this is just hobby development, whenever I feel like coding for it.
Compared to Xamarin, The Qt Company seems to still be searching on what platform integration to sell to companies and how.
If I was starting from scratch today, I'd take a good look at Titanium, React, Xamarin and Ruby Motion (in that order). In general, I think cross platform will save you time and money if you do it properly.
Titanium has been a timesaver for me. My current backend (stocklight.com) is written in Rails. For iOS and Android clients, Titanium gives me about 90% code reuse on the front-end.
ie. It allows you to implement cross platform GUI's using the same view code and you just make platform specific adjustments (eg. Action Bar versus NavigationWindow) where neccessary.
There's no way I would have had time to develop both backend and android/iOS by myself if I had to write everything natively.
Having a single model/controller layer with Titanium has been good also but I recently made the effort to upgrade this part of the project to use Alloy and that has felt very Rails-ish which has been a big improvement.
This week, Appcelerator have announced their new pricing structure ($39 per month) and are pushing a new service called Arrow for managing your back end. Personally, I don't think i'll be using Arrow (Rails seems like a better choice) but it will be great to get LiveView 'instant updates' with their new SDK.
Also, re. speeding up Android development, you should definitely check out Genymotion.
Unfortunately, the built-in IDE for Unity is MonoDevelop, which has all the problems Xamarin does, You don't have to use Mono though, you can use any editor.
In fact, Visual Studio has first-class support for Unity now, since MS bought the company that made UnityVS and released it as a free VS extension.
I really don't think I could recommend using Unity for a non-game app, though, at least in most cases. It would be a subpar experience for both the developer and the user.
In addition, it does have a little size overhead - the smallest possible build on iOS (a blank screen) is 12 MB with all the optimizations on, and double that if you need to invoke System functions or libraries that need them.
Update() on Unity doesn't strike me as being all that different than a normal GUI app's message loop.
That said, when all the work is done and the critical bugs are squashed, and a cross-platform app works as intended, it's a thing of beauty -- and especially wonderful when it comes time to roll out new features every week.
As a side note, it's very game-focused, but we've put together a matrix with all of the pros and cons of using various cross-platform frameworks. Maybe helpful: http://blog.doublecoconut.com/crossing-the-mobile-platform-w...