4 ms·

Now that we are at it, if you have experience / recommendations on developing for multiple mobile platforms please share it here. As far as I understand it, if

Now that we are at it, if you have experience / recommendations on developing for multiple mobile platforms please share it here. 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?

ccvannorman 12y ago
I use Unity3D to develop for multiple platforms and can't recommend it enough -- it is a 3D game engine so it may be too heavy for some applications, but it can do anything you want it to. Everything is written in C#/.net on your end, Unity cross-compiles to other platforms. 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.
- alok-g 12y ago
  How useful is it to develop non-gaming applications (including 2D UIs)? And how much overheads it results in in terms of application performance and size? Thanks.
  - strangecasts 12y ago
    Not very: it fundamentally assumes you're making a game, so it draws 3D scenes and uses a continuous update loop, which taxes the battery on mobile devices. The UI tools are also just finicky enough to make non-game app development a pain. 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.
    - dangero 12y ago
      Have you actually seen a performance comparison when idle? I ask because I have been curious about trying to build a full application inside Unity. Update() on Unity doesn't strike me as being all that different than a normal GUI app's message loop.
- omegavesko 12y ago
  >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.
- rasur 12y ago
  I don't suppose you have done any work with unity and f# have you? I'd be interested to hear any war-stories in that context.
miguelrochefort 12y ago
I have more than a year of experience building applications for Android, iOS and Windows with Xamarin. Overall, I much prefer my experience with Xamarin than the alternatives. Keep in mind that I did have prior experience with C#, .NET, and Visual Studio. 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.
pjmlp 12y ago
I work in enterprise world, as such, my mobile development experience is mostly on side projects, across all the three major platforms. 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.
- discreteevent 12y ago
  Do you think the commercial version of Qt would have covered what you needed? I would also be interested I'd anyone else here is in a position to compare Xamarin and Qt. It's very hard to compare the two from the outside. Thanks.
  - pjmlp 12y ago
    No it would not. 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. [0] http://blog.qt.io/blog/2014/12/10/qt-5-4-released/ http://blog.qt.io/blog/2014/12/10/qt-5-4-released/
  - mwcampbell 12y ago
cornflake 12y ago
I have been developing cross-platform mobile apps for the past five years, initially on Phonegap and for the last three years, on Titanium (Appcelerator). 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.
- mercury_craze 12y ago
  Absolutely check out Genymotion, it blows both the native android and Xamarin emulator out of the water. Xamarin studio sees it as a native device and any issues we've had with it have been minor annoyances rather than major blockers. Deployment time from the IDE is also pretty nippy.
werefox 12y ago
If you're small and a penniless startup, I think creating a native app is also often a wise choice -- all in the spirit of getting something delightful out to the market as quickly and effortlessly as possible. 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-without-losing-a-foot/ http://blog.doublecoconut.com/crossing-the-mobile-platform-w...

ccvannorman 12y ago

I use Unity3D to develop for multiple platforms and can't recommend it enough -- it is a 3D game engine so it may be too heavy for some applications, but it can do anything you want it to. Everything is written in C#/.net on your end, Unity cross-compiles to other platforms. 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.

alok-g 12y ago
How useful is it to develop non-gaming applications (including 2D UIs)? And how much overheads it results in in terms of application performance and size? Thanks.
- strangecasts 12y ago
  Not very: it fundamentally assumes you're making a game, so it draws 3D scenes and uses a continuous update loop, which taxes the battery on mobile devices. The UI tools are also just finicky enough to make non-game app development a pain. 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.
  - dangero 12y ago
    Have you actually seen a performance comparison when idle? I ask because I have been curious about trying to build a full application inside Unity. Update() on Unity doesn't strike me as being all that different than a normal GUI app's message loop.
omegavesko 12y ago
>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.
rasur 12y ago
I don't suppose you have done any work with unity and f# have you? I'd be interested to hear any war-stories in that context.

miguelrochefort 12y ago

I have more than a year of experience building applications for Android, iOS and Windows with Xamarin. Overall, I much prefer my experience with Xamarin than the alternatives. Keep in mind that I did have prior experience with C#, .NET, and Visual Studio. 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.

pjmlp 12y ago

I work in enterprise world, as such, my mobile development experience is mostly on side projects, across all the three major platforms. 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.

discreteevent 12y ago
Do you think the commercial version of Qt would have covered what you needed? I would also be interested I'd anyone else here is in a position to compare Xamarin and Qt. It's very hard to compare the two from the outside. Thanks.
- pjmlp 12y ago
  No it would not. 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. [0] http://blog.qt.io/blog/2014/12/10/qt-5-4-released/ http://blog.qt.io/blog/2014/12/10/qt-5-4-released/
- mwcampbell 12y ago

cornflake 12y ago

I have been developing cross-platform mobile apps for the past five years, initially on Phonegap and for the last three years, on Titanium (Appcelerator). 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.

mercury_craze 12y ago
Absolutely check out Genymotion, it blows both the native android and Xamarin emulator out of the water. Xamarin studio sees it as a native device and any issues we've had with it have been minor annoyances rather than major blockers. Deployment time from the IDE is also pretty nippy.

werefox 12y ago

If you're small and a penniless startup, I think creating a native app is also often a wise choice -- all in the spirit of getting something delightful out to the market as quickly and effortlessly as possible. 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-without-losing-a-foot/ http://blog.doublecoconut.com/crossing-the-mobile-platform-w...