Some thoughts after (almost) a year of real Xamarin use
1–10 of 113 posts
Re: Some thoughts after (almost) a year of real Xamarin use
#2Having been building a decent size app (tens of thousands of lines) in Xamarin this really reflects our experience. One particular point is that the memory management is fairly complex under the covers with bridged objects and multiple memory management mechanisms working in parallel, this occasionally rears its head.
Another important point is they do provide a single automation test framework that targets both platforms.
If I was starting the app again I'd be very conflicted whether to use Xamarin vs native, though ReactNative looks very interesting too and doesn't have the complexity of running the full .net stack.
Re: Some thoughts after (almost) a year of real Xamarin use
#3Now 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?
Re: Some thoughts after (almost) a year of real Xamarin use
#4Most people don't realize how convenient it is to build and maintain your entire codebase (iOS, Android, Windows Phone, Windows 8, web client, web server) all in one place (Visual Studio), mostly using C# and Typescript. Just have a Windows VM on your Mac. It truly is the best of both worlds.
Re: Some thoughts after (almost) a year of real Xamarin use
#5Having been building a decent size app (tens of thousands of lines) in Xamarin this really reflects our experience. One particular point is that the memory management is fairly complex under the covers with bridged objects and multiple memory management mechanisms working in parallel, this occasionally rears its head. Another important point is they do provide a single automation test framework that targets both plat…
I wonder if RubyMotion is much better when it comes to memory management. According to the website, RubyMotion objects are platform native objects (ObjC objects for iOS/Mac, java objects for Android), so each platform's native memory management scheme applies, rather than having two GC's or GC plus reference counting.
I'd probably use RubyMotion for an upcoming project at work if it had a port to WinRT for Windows universal apps.
Re: Some thoughts after (almost) a year of real Xamarin use
#6Great article, we have a similar story but only used Xamarin for 1 iOS app. If I had option to go back I would not chose Xa marin, we would have used native. Main reason being that we now need to add 3 SDKs to our app and none of them are supported in Xamarin, it seems it will be cheaper and more predictable to rewrite to native than implementing SDKs. Porting libraries to Xamarin is possible in theory but in practice major effort and hard to do without access to library code.
Re: Some thoughts after (almost) a year of real Xamarin use
#7Now 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?
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.
Re: Some thoughts after (almost) a year of real Xamarin use
#8Now 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?
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.
Re: Some thoughts after (almost) a year of real Xamarin use
#9Great article, we have a similar story but only used Xamarin for 1 iOS app. If I had option to go back I would not chose Xa marin, we would have used native. Main reason being that we now need to add 3 SDKs to our app and none of them are supported in Xamarin, it seems it will be cheaper and more predictable to rewrite to native than implementing SDKs. Porting libraries to Xamarin is possible in theory but in practic…
I think this is the key to making a great cross-platform solution. Pretty much any mobile app that's not a toy relies on native 3rd party sdks, be it ad providers or fancy Ui compinents. Whatever platform first solves the issue of making integration of pods on iOs or AARs on Android a smooth process, will win.
I don't see any options that come close to solving this. Xamarin is not native to either iOS or Android. RoboVM (the one i work on) can cheat, as we only need to solve it for iOS, Android comes for free. React Native has no clear path for accessing 3rd party libs at all yet. Whatever they can come up with will be further complicated by the fact that the JS engine is single threaded.
Re: Some thoughts after (almost) a year of real Xamarin use
#10Having been building a decent size app (tens of thousands of lines) in Xamarin this really reflects our experience. One particular point is that the memory management is fairly complex under the covers with bridged objects and multiple memory management mechanisms working in parallel, this occasionally rears its head. Another important point is they do provide a single automation test framework that targets both plat…
I wonder if RubyMotion is much better when it comes to memory management. According to the website, RubyMotion objects are platform native objects (ObjC objects for iOS/Mac, java objects for Android), so each platform's native memory management scheme applies, rather than having two GC's or GC plus reference counting. I'd probably use RubyMotion for an upcoming project at work if it had a port to WinRT for Windows un…
Judging by the docs [1], RubyMotion does indeed not seem to use a GC on iOS but instead relies on ref counting, reusing auto-release pools. That means cyclic refs are an issue. You have to explicitely use weak references throughout your code.
They are not on Android, where RubyMotion uses the Dalivk/ART GC.
So, your cross-platform Ruby code has to deal with two different types of memory management systems. I'm not sure this qualifies as a better option to what Xamarin provides.
[1] http://www.rubymotion.com/developers/guides/manuals/cocoa/ru...