Ask HN: Is Xamarin worth learning?
For context I'm a day to day iOS developer. However I'd like to quickly be able to make cross platform applications, and React Native is apparently lacking for Android.
For me Xamarin Native was slow and rigid. I highly doubt I could make 'innovative' apps with Xamarin. Maybe it is okay for people who want simple things like a "to-do app" or somethign that fetches list of images and displays it.
I wanted more and found no solution for things I needed, so I gave up and started xcode (swift + some objective c).
And let me be clear here, if I had spent same amonut of time on xcode as xamarin I would have been iOS dev master :)
Things just works much better. You can do anything you imagine with Xcode and swift. With Xamarin its more like find whatever library is out there and try to create something by combining these. Too many bugs.
This is no sly dig on Xamarin or Microsoft as I use alot of MS products myself. I have also tried phonegap, react native etc. and Xamarin is the best when it comes to cross platform without a question, but none of these can match true native coding (xcode swift/objc)
Much better experience, fast deploys/builds. I miss Resharper but can live without it.
I don't know about OS X, but I used Xamarin Studio on Windows and it was horrible.
It feels much better on mac I must say, also tried it on Windows but just weird and slow.
I'm quite happy with it, but maybe I'm biased a bit because it sucked big time and they made big improvements to it last year. It's all relative ;-).
They've been denying it's a problem for over a year, and then acknowledged it a few months ago and did nothing about it.
The platform itself also harbors a lot of bizarre and difficult bugs that only cause a couple of crashes each under some very specific conditions that are nearly impossible repro consistently. But there are so many of them that on a given day, 5% of our apps will crash or freeze because of some Garbage Collector bug, a platform bug, or some platform race condition. Just check how many of the bugzilla bugs are still in the NEW state.
The real problem is that I can write a native iOS app in a fraction of the time it took to write a Xamarin app. Swift has improved iOS development speed so much I'm not convinced we need cross platform app engines (excluding games).
As for Android, yeah, native Android sucks. Activities and fragments are the worst idea anyone has ever had and no one agrees on best practices. But even with cross platform high levels of abstraction like Unity3D you still need to understand them. So, my current advice is to suck it up and write it native twice. Pick your favorite OS, start with that, and then port the logic.
I think the code sharing thing really comes down to how you're using Xamarin – if you keep on writing apps the way you're used to from the original platforms, there's not much to gain. On the other hand adopting the patterns and ideas that influence the .NET sphere (DI/IoC, MVVM..), Code Sharing rates (or PCL vs. Native LoC) can be as high as 80/20.
Xamarin Studio certainly has its own shortcomings, but both Microsoft (Visual Studio for Mac) and Jetbrains (Project Rider) are actively improving or developing alternatives, so I think that pain is going to fade over time.
Yep, you will keep hearing this from people complaining of Xamarin. A huge problem indeed, and I'd say enough for it not be worth learning.
That was the thing that struck me the most when following a Xamarin course. I just don't see the added benefits of Xamarin when you are at that level of using (or having knowledge of) native code.
2 years ago, Xamarin was buggy as hell. Today, (IMHO) it's quite stable.
Edit: downvoted for sharing my experience? Stay classy, HN.
/s silicon valley reference
If you are using basic Xamarin then you will end up writing separate UI code for each platform, but you can still share business logic if you architect if well. Xamarin.Forms is different and lets you share the UI too.
Even with Forms, you will always have some platform specific code, but this is normally small. For example, some implementation details when using SQLite.
[0]: I'm writing about this starting with https://unop.uk/cross-platform-native-mobile-app-development...
If your app is just a mobile front-end for a REST API then I wouldn't bother with it: develop two versions of the app with different UI idioms.
If your app does something considerably more complex, Xamarin might also be a good idea. Keeping two drastically different codebases in sync can be a very big task, but I suggest proactively looking at issues people have experienced with it, as well as other differences such as memory management which works very differently to what you're used to as a .NET developer.
However I think a number of responses have strayed from the question, which is "is it worth learning Xamarin". It appears Microsoft bought the technology because it was useful, not to kill it. I don't think the technology will be retired any time soon and can only get better. So long as Microsoft gives this the TLC it needs, it will be a formidable part of any developer's toolkit.. so long as it can get over the really bad reputation it has.
I for one will explore every possible alternative before considering Xamarin again.
However, in my experience, both Xamarin Studio and the build system are buggy as hell. Random or inexplicable build errors, things that break during updates, incompatibilities with official Android support libraries... I find myself doing 'clean project and rebuild' to fix random errors, or switching between alpha, beta and 'stable' channels all the time depending on which one does not have the bugs that I'm running in to.
Xamarin.Forms is simply a disaster. Because it aims to unify the apis for the UIs for various platforms it boils down to only the most common denominator of those platforms. And then makes it worse. Not only is it buggy, it is also very slow and incredibly limited. In our office we're keeping a list of all of Xamarin's silliness we encounter, here is just one of those:
"Clicking a Button changes its text alignment from center to left-aligned; it requires writing a custom Renderer to solve this."
I'd love to hear from someone using Visual Studio if their experience is more positive, but my advise is: please stay away from Xamarin.Forms and Xamarin Studio as much as possible.
It's kinda like swing. Great for throwing together a line of business application and getting xplat ui for free. It's possible to build a performant application with the framework but it abstracts subtle things that come back to hurt you. For example. Forms apps on Android is a single activity, always, period. Fragments are cycled in and out of this activity as navigation occurs. This introduces subtle annoyances related to memory usage as the entire app must be running vs thin slice. It transforms the lifecycle of Android into the UWP or iOS lifecycle.
Again this is Xamarin Forms. It is not Xamarin. It has its place but please don't confuse the product due to poor branding.
Android itself has so much quirks in development in itself that it is sometimes impossible to abstract away. Xamarin just doesn't show this always so you're chasing the wrong ghost from time to time. Android development is simply madness.
I'm not gonna say Forms is perfect, far from it but it serves a purpose. With a little bit of work I could get everything going that needs to be done. As a single dev I can cover both platforms. If you have the resources go native Xamarin.
Xamarin Studio is actually not that bad, only it has become a bit of resource hog last weeks releases and needs the occosional restart. With the power of MS behind that should certainly be improved.
Xamarin.Forms is now open source, but I really hate that the PR's are slow to being reviewed and 1 contributer is outpacing the Xamarin team in his spare time. Clearly something is brewing, they must be working on something new. Or else they should ditch and start something else.
We'll hear about it in a few days.
* Xcode = iOS bugs + UIKit bugs
* Xamarin = iOS bugs + UIKit bugs + different runtime, language, memory model abstractions + .NET bugs + P/Invoke bugs & overheads + GC inter-op bugs & overheads + C# bugs + slow followup of platform updates
* Xamarin Forms = iOS bugs + UIKit bugs + different runtime, language, memory model abstractions + .NET bugs + P/Invoke bugs & overheads + GC inter-op bugs & overheads + C# bugs + slow followup of platform updates + extra UI abstraction layers + lack of fine level controls & features
I've tried Cordova/Ionic, Xamarin, Dropbox Djinni, and native iOS development. C++ is the closest I've got the a performant cross-platform solution, even though it go it's own quirks.
The problem with Xamarin is it'll always play second fiddle to quick moving targets of Android and iOS toolchains. In my case the Reactive Extensions support was utterly broken, and Visual Studio kept crashing on MvvmCross, Android SDK updates would make things hell, and I would waste at least 8 hours a week to fight the toolchain. The promise of cross-platform doesn't deliver much as you're trying to tweak your MVVM solution to Android/iOSs whims and fancies, which leave you with a fragile common logic.
If you want to write a TODO list of simple CRUD app, it might work, but for professional iOS/Android development, Xamarin is not enough. Xamarin doesn't free you from learning ViewController lifecycle etc and platform specific implementation details. So you're stuck on a foreign platform, with extra overload of learning C#/F# along with Android/iOS platform overhead.
My Advice: Learn Swift and Kotlin, and do native development. Cross-Platform is a illusion, and the road is paved with dead and failed projects.
I already know Swift. Do you think Kotlin would a better transition into Android than straight up Java?
I would love to see a true cross-platform solution, but honestly it's a dead end in my experience. I would say C++ comes close, but I wouldn't be surprised if people feel unwelcome due to it's syntax and quirks.
As it has always been, my son. I've been hearing the wonders of cross-platform for going on three decades. Be it Unix->MS-DOS, Java on anything, or iOS->Android, there is always a compromise. Prior, it was usually that the app that didn't look native on any of the platforms. These days it seems the compromise is at dev time. But there's no free lunch. Maybe some day, but probably not within my career.
And that's fine, I now know that when the topic of cross-platform comes up to ask "what are we giving up? What will our new pain points be?" What I don't do anymore is think that this time will be different.
I use Djinni IDL from Dropbox to create common logic in C++ and UI Specific code in iOS/Android. It's not at all beginner friendly and you need lot of patience with the setup.
Cons: complex build setup, and C++.
Pros: Blazing fast native performance, and you can easily write common business logic in c++
Start here is you wish to go that path:
It is easier to use straight C++, using a MVVM approach than Qt.
QML doesn't provide enough support for native UIs, so you end up spending time redoing native widgets on it.
Similarly Qt doesn't provide any bindings for the majority of mobile OS APIs, so you end up writing your own wrappers anyway.
In the end it is a bigger effort than using C++ libraries plus your own integration code.
Additionally in iOS and UWP, you get C++ extensions, Objective-C++ and C++/CX respectively, that make it quite easy to integrate with native APIs. Android is the outlier here with the JNI pain. Still Djinni and SafeJNI help to reduce the pain.
My problem wasn't with Rx but rather the way our project grew crazy huge with lots of inner cross platform components and app specific implementations. Add to it the customized libraries for Android/iOS. I believe VS is one of the best IDEs out there but still it couldn't cope up with it, and it made things tough for us. So thanks for your help, Rx is fine, it's just the situation we were caught in wasn't great :-)
Xamarin Forms is not Xamarin, it is a DSL. You do not need to use it. At its core Xamarin is c# with pinvoke to the underlying native platform implementation. You'll still need that platform knowledge but now you can share the core business logic between platforms.
To get maximum code share you'll need a MVVM framework such as ReactiveUI which is based on the Reactive Extensions and modeled on functional reactive principals check out https://github.com/reactiveui/ReactiveUI/releases/tag/7.0.0 or http://reactiveui.net
Xamarin Forms may be useful for internal super-CRUD LOB apps that really are just a collection of input fields, but as soon as you do anything customer facing, you should be using the standard native UI approach.
Also +1 for ReactiveUI, it completely changed the way I build apps for the better.
Also I would like to recommend to focus more on Xamarin.Forms, it's using more modern approach. XAML (it's a xml-derived language) is actually quite good for writing UI part. Add there some MVVM framework and you'd love it.
Edit: fixed spelling
I always found that WPF/MVVM made the 90% use case really easy, and the 10% use case ridiculously hard. So I usually used MVVM for the 90% case, and the code behind for 10% case. People I know who shared this philosophy with me had a lot more luck with WPF then the zealots.
It also introduces inconsistencies - in similar scenario, one dev will already prefer resorting to code behind, another one won't. Plus, testability gets tricky and messy when some of the behaviour can be verified by testing the viewmodels, some can't, and some is actually split over two layers.
All of this at least partially invalidates the benefits MVVM architecture was supposed to bring about in the first place.
Also note that WPF was sort of neglected: it hardly ever evolved over the years.
Ghanhi, when asked what he thought of Western civilization, famously replied that it might be a good idea. I guess the same could be said for WPF : )
For MVVM (unlike MVP and the like), you need the "glue" that ties viewmodels to views. Rolling it out by hand is far from trivial, not to mention things such as IDE support etc.
The official Data Binding library by Google - in my opinion, the only sane way of attempting MVVM on Android - is fairly new. If I'm not mistaken, they've only recently moved it out of preview stage, and they didn't tout about it much anyway.
In no particular order:
Stay the hell away from Xam.Forms, unless it's improved drastically in the last 6 months. Though I also think the whole idea is misguided.
For Android, go with Xamarin or Kotlin. I would take C# over Kotlin because of the maturity of the language, the tooling around the language, and the ecosystem. Either way, having a powerful modern language will be a godsend.
Concurrency on Android is much easier to deal with in Xamarin than with native. This extends to things like complex orchestration of animations.
You will do backflips trying to get startup-time down. But once your app is in memory performance is basically native-level.
Xamarin gives you some nice framework-level things that native Android doesn't. A good API for sqlite and http. Proper data-binding. MvvmCross and ReactiveUI are light-years ahead of anything that is available in native-land.
Xamarin builds are faster and more reliable than Gradle.
Xamarin introduces its own layer of bugs and glitches. You've added another slice of Swiss cheese to the stack.
Xamarin plugin for Visual Studio is crash/glitch city. Xamarin Studio is tolerable at best. Either way, your tooling will be faster but less feature-rich than Android Studio.
Every time you want to use an existing third party library, you will go through this process: Has anyone done an official binding for it? If yes, use awkward Java syntax in C#. If no, try to find an unofficial binding. If not found, try to bind on your own - 50% chance it just works, 50% chance you fiddle for half the day and then fail. If it's the latter, try to decide if you want to do a code-level port, or abandon your idea. Code-level ports are possible nearly line-by-line, it's slow brainless work.
I just convinced our management to move away from it when I migrated a page from Xamarin.Forms to regular Xamarin.Android. The page render time went from 2,000ms to 400ms.
A quick glance on the now-open source code of Xamarin Forms now shows you why the perf is so sluggish (the whole thing seems like it was hacked together by a college intern as a week-end project).
Xamarin seems to have a marketing team that is far ahead of their development team.
The team is made up of a few React core devs and some ex-FB folks. They actually helped organize the last official React conf. The scope of what can be built using Exponent is expanding rapidly. And you can build apps that are virtually indistinguishable from Swift/Java apps.
If you want an example, I'd encourage you to download the Android version of this app: https://li.st/
That is a very tall claim to make without any citations. All the cross-platform toolkits lag behind native swift/java apps by at least some margin, and the claim that JS indistinguishable from swift/Java is highly questionable.
I respect RN and the engineering behind it, however how can it beat the raw, on-metal performance of Swift/Java? I'm not talking about CRUD/TODO list apps like https://li.st, but performance critical apps like Spotify etc. Facebooks own apps are written in native code, IIRC.
I would love to be proven wrong here, and it would be great if you can provide some sources.
They are written in React Native. See: https://facebook.github.io/react-native/showcase.html
One thing I love is that because it maps so closely to native Android development, you don't need to look specifically for Xamarin.Android tutorials/SO Answers/blog posts etc to learn how to do something.
Most of the time, information targeted towards native Android development will apply to Xamarin.Android also, and you can basically map example Java code to C# because they use the same classes/namespaces.
I'm going to be getting into Xamarin.IOS soon, hopefully the experience is as nice.
You can stay within .net Framework Standard and share that code between your Android/iOS/Windows Phone(lol) app, and reach into the native libraries when you need platform specific functionality.
In theory at least...
In the beginning, i thought about making a hybrid app, because it could save me time on the long run, but starting to developing with Cordova and EmberJS or even Xamarin was frustrating.
My major reason for frustration is the tooling, cordova emulator just sucks (Ripple?) and working with javascript mvc frameworks isn't just for me (too complex IMHO).
Xamarin on VS has some bugs that would only go away if i restarted the IDE in order for things to work. Also, i'm concerning about being dependant to a third party framework.Can they keep up to speed with Google,Apple and MS?
Another valid concern is app size distribution that seems to be considerably higher with cordova and Xamarin.
Since i started on Android, using Android Studio made my life a lot easier and i'm progressing daily and enjoying it, something that was a PITA with other tools.
In my experience i would say that it will be more time consuming (expensive) to develop a single solution for each platform as well as giving support, but the tooling is a lot better, also you can give users a better experience because you end up developing native apps for each platform that can take better advantage of it's ecosystem.
I'll find out in the future if i'm right or wrong.
Xamarin is Microsoft now.
Xamarin is nothing more than a C# wrapper around the native iOS and Android APIs. Everything you're familiar with (UIViewController, UIView, UITextField, UIButton, etc) remains the same. The main benefit (other than using C#) is that all non-UI code can be shared across platforms (iOS, Android, Windows, server, etc).
Xamarin.Forms is built on top of Xamarin and lets you reuse the same code for UI as well (using their own abstraction that's similar to WPF/UWP). I would only recommend this for relatively simple apps as you lose some control over platform specific details.
Obviously I think it's worth it, I learned it well enough to teach others. We have a bunch of free Self Paced Learning modules and videos at Xam University, as well as obviously the paid stuff that pays my salary ;-)
There is a ton of investment and effort from a small team, remember, we've only been with a "big company" a few months, so the improvements come at a blistering start-up pace. If you haven't seen it in a couple years, you should really check back.
If you are going to develop "all platforms" or even just iOS and Android, it is _certainly_ worth a long look. Access to every API you get access to in their native languages and the ability to avoid that language "context switching" pain. Plus, some amount of shared code (varies wildly, 25% - 75% depending on how heavily your app is just about custom UI and animations ).
Because we use the same APIs (except when we have better ones), you can leverage the same documentation and StackOverflow posts when you need to (yes with a little language translation), but you often don't need to because Xamarin has a _lot_ of great documentation as well.
And, as has been mentioned, "Xamarin Forms" does not equal "Xamarin". Although it is a valid choice for developing in Xamarin, it is only one option. Here is a super shallow comparison:
Xamarin Forms: Super fast for super simple UI's and interactions with common elements. It is highly opinionated on what it should do and look like on all platforms. Customization is do-able but starts to increase the complexity of the app quickly to the point where the below would have been a better choice.
"Xamarin" aka "Xamarin.iOS and Xamarin.Android": Use essentially the same development patterns as Native Android and iOS developers and use the same API's (plus .NET library, and many .NET 3rd party libraries). You get code sharing (as noted, amount varies considerably), ability to "think in one language (often including your server, which might also be c#), and access to some additional libraries (because we support both the Native libraries _and_ the .NET ecosystem).
Hope this helps :)
Oh, and a quick plug. Xamarin University is live classes taught by real, very experienced developers who can actually help you learn and understand, so we are, you know, worth asking questions of. Also, we'll be doing a free presentation all day on November 18th as part of Visual Studio Connect, so check us out there and see what you think of Xamarin _and_ Xamarin University!
My main complaints are:
* It's full of bugs
* The build system is unreliable and mysteriously breaks, which generally takes a full day to fix
* Basic functionality such as merging resource dictionaries (which are stylesheets, kinda) is missing
* No graphical UI designer or preview, so every layout change requires a recompile and deploy before you can see it
* Apps feel sluggish and crash at runtime without specific error messages
* It makes VS crash all the time. I'm not a regular VS user so I'm not sure if VS:CE2015 is a POS or if Xamarin is.
However, as others have pointed out, Xamarin Forms is a bit of let down.
In my experience, if you try to create custom designed UI (which is quite common in the native apps), then you find that Xamarin Forms is very limited. To overcome this limitation you need to write something called as a custom renderer for each OS you want to support. So it doesn't really save you much time.
Xamarin has something called as Xamarin Labs project on Github: https://github.com/XLabs/Xamarin-Forms-Labs But it's progress has been very slow.
If you have a business data collection / reporting app, where how things look is not very important, Xamarin can save a lot of time while creating cross-platform apps.
However, I wouldn't recommend Xamarin Forms for B2C apps.
As a practical matter it had to ship with a library of default renderers for common UI elements, but other than the layout system, those all can be replaced by alternative renderers either in part or in whole. But the scenegraph essentially is the data structure that stores your app's business value (think HTML templates + JS). The renderers can too, but those should be reusable across many apps (think CSS/the value prop of Bootstrap). The scenegraph maximizes intra-app UI code sharing and the renderers maximize inter-app UI code sharing.
It's a hard problem space, and there is no magic bullet. Even the Xamarin.Forms team would tell you that. For many use cases, it's great. The bugs are tricky, since UIKit and Android have major thread safety issues and wildly divergent object life cycles (and Android itself is such a moving target, which any experienced Android dev knows, cough Support Libraries cough). Bugs tend to come from the layout engine because that is the heaviest lift. XF eats complexity that you otherwise have to eat on your own. For many small/under resourced teams, that's the difference between "iOS only" and "Android also" support. If you are resourced for two teams, awesome! If not, but have to support both, you face some hard choices. Xamarin.Forms tops a very short list of available options.
All that's to say that some people use Forms to build really native apps because they understand the patterns Forms is built on, and it's limitations. Every framework has a grain. When you cut with it, the results are quick and smooth. When you cut against it, and the results are tough, course, and possibly cracked.
Microsoft's strategy with bringing a phone to market appears to have failed so they're going to have to take the next best thing which is owning the development tools. I expect the outlook for the software to be extremely bright and if you plan to be a professional mobile developer I strongly suggest learning it.
Of course, this does not excuse you from learning how to develop for iOS and Android natively, but it is a great addition to your toolkit as a developer. It's also another box to tick for the recruiter or hiring manager.
I can't tell you where that bar is, but especially if you are a solo developer it can be easy to undervalue your time spent porting your app between platforms.
Beyond that too, even though you don't develop on Windows now, using a cross-platform toolkit at least provides you the option. You might be surprised how many users [1] you can pick up by making a Windows version, and if it is as easy as add a couple more platform specific files to a mostly shared codebase you might get extra users for quite cheap.
[1] Windows phones have dropped to a low percentage, but that low percentage is still countable in millions of devices. Plus, the UWP continues to expand in number of tablet devices and desktops that support it, not to mention Xbox Ones and AR/VR devices.
However if Xamarin takes off in the way I hope it will and becomes a high-quality product under the auspices of Microsoft, I believe it will become a vital skill in the marketplace.
And then, it would be like not knowing React or Angular as a web app engineer. Depending on the company's technology choices, that might not matter, or it might mean you don't get the job.
Then I had a .dll that I could use in my Xamarin project. The Xamarin project was razor thin and I only used C# to connect my XIBs or Storyboard (I forgot what I used, but it was in Interface Builder) to the existing .dll calls and a specific type of hardware scanner.
The hardest part was getting that scanner to work, which would be not so easy for me even in Objective-C. But I basically had to create an Objective-C wrapper wrapped in some kind of C# wrapper. It wasn't easy but it was doable.
The hardest part was getting everything signed correctly, since I was using all kinds of layers you usually wouldn't use in "just software" project.
The overall experience was really good despite that the native editor for macOS wasn't that spectacular. I did the meat of my programming in Visual Studio and Visual Studio is a really great tool. Another part was done in Interface Builder which is a great tool in my opinion.
A friend uses it a lot for a cross-platform app written in Xamarin Forms. The thing with Forms is that unless you keep it simple you will run into Xamarin bugs, iOS specific bugs or Android specific bugs in your layouts and that can be challenging sometimes.
I would say that if you would make the UI in native code or storyboards and it still seems like an attractive idea to use Xamarin, use Xamarin. Don't use Forms.
The answer to whether or not you should learn Xamarin depends largely on what you are trying to accomplish. Let me explain.
If you were to approach me as someone interested in Xamarin, I would start by asking what kinds of apps you are looking to build, how complex they are, and how much you care about UI quality and customization. This is to help decide between Xamarin and other xplat solutions, but also between Xamarin native and Xamarin.Forms, our cross-platform UI toolkit. I’d ask what you hope to gain from a cross-platform approach, so we can optimize for that. I’d ask what parts of your app you are looking to share, and how you plan on architecting your app to allow that.
I’d ask how much experience you have with .NET, and if being able to use C# and/or Visual Studio makes you more productive. I’d ask if you have an existing codebase you want to connect to. Your familiarity with native iOS development is a plus - the particulars of iOS and Android add to the learning curve, but you can’t make good native apps without knowing the basics of the platforms you’re building for.
From these considerations, we would decide if Xamarin is a good fit for you. It would be naive to say that Xamarin is the ideal solution for everyone, but it is a very good solution for many people.
At the end of the day, Xamarin is free, and it takes less time to get a handle on developing with Xamarin than it does to read this thread. I encourage you to try it out and decide for yourself.
With that said, I've made a number of apps in it, and it works well enough, but the more abstractions, the more problems, and you want to do anything outside of simple UI apps, you are likely going to have to learn how the native methods work anyway.
The downside to this is that making a UI seems to even out your gained time--it's extremely messy and even complicated. Code that's valid in C# produces vague underwater bugs in Java code, which makes you keep hacking around until you find a working solution.
Not to mention the docs: some parts of the documentation are completely outdated to the point of not even compiling on an older version of Xamarin. For example, the tutorials on using Google Maps in your Xamarin.Droid application are way out of date, ignoring the fact that the "Google Play Services" component has split off into thirty-or-so components. Some of the most used API's are not documented at all, simply having a "To be added" description.
All in all I find much potential in Xamarin, and I really want to love it, but it's a messy nightmare to use, and it only makes me want to use Java and Swift separately for apps.
I rarely find myself reading the Xamarin documentation, and mostly browse documentation and StackOverflow as if I was coding a native iOS/Android app. This works because the Xamarin wrapper is pretty much identical to native APIs.
Interesting, I had the exact opposite experience, since the Java->C# mappings often reduce much of the boilerplate code that you have to write if you were using Java (e.g C# events, properties, etc..)
I also never came across any bugs in the mappings, but I can't say for sure that there aren't any.
Instead, for this example you could subclass Activity/Fragment and use reflection to find properties on the activity to inject services into.
This is only one of countless annoying Xamarin problems I have encountered in my few months of use, and this one was relatively easy to solve. Vague problems also ensue when forgetting to inherit a class from Java.Lang.Object which leads to vague exception messages like "Specified cast invalid".
Sure, sometimes parts can be made faster in C#, but more often than not I spend day(s) debugging extremely vague bugs related to non-documented mappings.
One nice thing about it is that all the methods/classes are named almost the same thing as native android. If you want to know how to do something, you can find the android solution and just change a few small things.
So my vote would be to not do Xamarin and to choose a different cross platform development environment. Cross platform is the key. If you do choose Xamarin, I would spend some time and do a little bit of training before jumping in. It's not like the ease of building windows applications in VS.
1. If you don't use Xamarin and you don't have a team in-house that uses C#, don't bother. You'll be better off doing native development on iOS and Android platforms.
2. Your app won't be as pretty, and it won't adhere to platform native UI conventions as well if you use Xamarin.
3. Xamarin does a better job of it than most but it will still be lagging in access to the latest features.
4. BUT, if you are doing a vertical market app that wants to be cross-platform AND you have C# coders you can apply to that task, Xamarin is the best choice.
There are a lot of places where choosing Xamarin makes a lot of sense. And the people who created Xamarin are excellent. And now that Xamarin is owned by MS, it won't die because it is hard to make money as a cross-platform startup. But as with every other cross-platform tool for non-game apps I've seen, it isn't the best choice in green-field situations.
Overall I've been very happy. Code re-use hasn't been stellar, but good enough to repay the investment. We have re-use not only between apps, but also between mobile apps, Windows desktop apps, and our application backends. I also feel I'm more productive than if I had so swap between Java/Swift/ObjC/Andorid Studio/Xcode.
Stability has improved a lot in the last year. Paid-for support was pretty good (esp. guys like @jonpryor), but the self-serve forums can be a bit hat-and-miss. I never had any killer bugs (but then I never used Xamarin.Forms...)
Overall: 85% happy with Xamarin.
Xamarin wins if you need something for Enterprise. A lot of entry fields, validation, integrations with SSO, Sharepoint, other rest API. If you use MVVM well, it will lead to ~75% of code reuse between iOS and Android. Even more with XamarinForms. No complex effects, no complex animations, just enterprise.
Native wins if you want to make it more beautiful for end-users and you need to have a lot of customization. For example, customize map, pins and callout views. You will hate everything if you do it in Xamarin. No code reuse here
In general, Xamarin has very great chance to be #1 choise when you choose platform for Enterprise development.
I must say that, having its own quirks and nuisances (specially in Xamarin Studio, which was pretty buggy until version 6.x), it does the job pretty well.
In fact, when we wrote our iOS and Android clients, Xamarin was still pretty immature. But if we had to rewrite them today, it would be one our of first options, right after using the native frameworks (which ensures the best results, but drastically increases the costs).
Purely by coincidence, I have four blog posts on this out this week. The first one (on React Native and Xamarin) is here: https://unop.uk/cross-platform-native-mobile-app-development...
Had huge pain in full screen mode dynamically for all the devices.
Calendar with colors forced me to create a new custom control from 0.
To be stable with the controls if you make a tab control in one version should be the same in other versions also, not reinvent and change the wheel.
Easy and clear documentation. Forums all with lots of no one cares why it works int works on my machine stuff.
To new technology and has to get mature and stable. If you are not in the same versions of Xamarin in mac and windows it just not works properly.
Proper error message. I am getting an error like There were deployment errors. Continue. (Not run in administrative mode the vs 2015, closing the emulator or it was opened by other vs before, or you closed the emulator before finished the deploy) There are lots of errors like "aapt exited with code 1" that means there is some bad character in image or in files like -.... or files starts with number.
Also sometimes out of memory exception when loading images larger then 1mb or in android 4.2 larger than 300kb, even going lover to 100kb having problems in 4.2 android.
Proper editor for Xamarin.Forms is a must have if you want to develop. You can't see the design what you are doing with vs 2015.
Also designer is crashing all the time if i open multiple times and make some adjustments.
What Xamarin and React Native have in common is (partly) using native UI layers for building the interfaces, perhaps you wanted to specifically address frameworks doing that?
With both Xamarin and React Native there was a honeymoon period where everything seemed so easy and great. But at some point I always hit a problem where there was limited documentation, or unsupported features, and that really hurt my productivity and motivation.
The learning curve for Swift/ObjC always seemed much higher, with a lot more upfront investment required before I could make anything resembling a functional app. The iOS layout system in particular was an obstacle, as well as managing the tooling and dev environments.
If I had a free 6 months, I would just learn full native, but keep an eye on React Native. The dev experience in React Native is unparalleled, and it seems easy to drop down to native code (assuming you know it). Also the ability to easily contribute back to the community with NPM and react-native "link", makes me hopeful limitations will quickly be erased.
As a day to day user, I quite dislike it. But rewriting our business code was not an option.
Whilst it's been years since the advent of mobile, most enterprise organisations are doing their first mobile project in 2016/2017. You can thank Gartner for that.
As for $150/hr on contract, I know someone who invoices more than that but you must be on your A game and be ready to teach, teach, teach.
There's nothing too special about Xamarin knowledge. Drop your Apple vs google fanboyisms, learn both platforms, learn MVVM, implement pure MVVM (don't fall back to singleton city).
If you know android/iOS well and are wondering where next to apply your six+ years of mobile development knowledge vs having to compete with comoditization and off shoring - this is it. With your deep knowledge and experience you will smash the existing talent in the market out of the park.
I agree that RN is the most sophisticated of the options but at the same time I would rater write in Ruby than in javascript. There are some other languages that you can pretty well compile to JS (cljs for example), but in the end you're still dealing with javascript.
From my initial research it appears the React Native on Android suffers performance problems. I.e. the Discord app on that showcase is still native Android, whereas their iOS app is React Native.
It has not been an easy road. After 2 years, I'm finally beginning to reap the benefits. The simple problem is this: this is another layer over the existing layers and it's very hard to get it right, especially if the underlying layers suck.
Just because you've learnt Xamarin Forms doesn't mean you can choose not to learn the underlying native platforms. You can skip over most of the details, but something will always come back to bite you, and then you have to go figure it out. Xamarin Forms works on top of Xamarin Android, that works on top of Android SDK and Android Tooling, which works on top of the JDK, which works on top of the OS you're developing on. So many places for something to go wrong, and usually presents itself in the form of a cryptic error at the top. Developing for iOS is considerably easier.
So there's still a fair amount of expertise to develop if you're completely new to mobile development. Take it for what it is -- an abstraction, and as with any abstraction, any concrete manifestation will have its issues, and you must be ready to roll up your sleeves to figure it out. And it does get keep getting better with every subsequent release.
But it does eventually help -- we have to get the complex bit right once, and then it simply works. Don't approach this like you would approach an Android app -- make sure you understand UI design best practices -- especially reactive design and data binding.
We also have .NET stack, so I'm finally in this beautiful world where all my logic is represented as C# Expression Trees on the server side, that gets serialized and pushed down to our Xamarin Forms Apps. Looking forward to WASM adoption, so I can finally get rid of that JavaScript mess.
So if you're writing a one-time app, and you just want to target Android/iOS, and you don't care how you've done it, no it doesn't make too much sense.
But if you're trying to make a long-term bet, in this awful fragmented device-oriented world, (and having to write the same app twice goes against the very nature of your existence), well that's my bet, I will be cautiously optimistic. If you're on .NET, it's a no-brainer -- there are simply too many other benefits to ignore, and philosophically very true.
The architecture itself (Forms, Xamarin.Android, Xamarin.iOS, Custom Renderers, Platform Effects, Bindings to access native libraries) is theoretically flawless (or very close to it), a work of art -- and I'm a sucker for theory, no matter the real world pain.
As long of you are a bit mindeful of the big pitfalls (any bigger framework has some of those), the performance of React-Native is excellent.
Unfortunately Android devices have much
greater variance in performance and tend to trail significantly behind iOS.
We were able to get our app running fairly quickly,
but the performance — specifically on touch events was not at an acceptable level even on higher end devices.
In addition at that early stage there was still a lot missing in the React Native Android feature-set that would
have made getting our prototype to production level more time consuming than our iOS effort.
I don't know what Discord has seen there, so I don't know if that's been resolved. They also state that transitioning to React-Native on Android would have been more time than on iOS , which doesn't mean that any alternative like Xamarin would have been better. It also reads like the team for the respective platforms is around 1 person big and they already have a running version for Android, so the cost of a rewrite and the time to retrain would not have been worth it, which is reasonable. On a greenfield project, different conditions apply.
Recommended workflow: 0. Never ever use Xamarin.Forms other than quick prototyping. If you develop applications with other cross-platform frameworks, you already know all of them sucks and Xamarin.Forms is not an exception.
1. Create PCL / Shared project for your business logic (also your view models if you're using MVVM architecture). Believe me most of your application is platform independent (except the view layer). Your api communication, storage operations all handled here. See 3rd article to how to make storage/network platform independent.
2. Create native projects for each platform (iOS, Android, Windows) implement native views here (use xcode, android studio if you need visual designer). This part should be exactly the same as your swift/java code. For iOS you're just implementing an ApplicationDelegate class and UIViewControllers as same as your swift code. Same for Android part, nothing special to xamarin just implement your activity classes. At this level you have the full power of your native platform with one exception 3rd party native libraries. It's possible to use (yes i used some swift/java libraries for youtube player) them but really hard to integrate to your project, that part has to be improved and better documented.
3. Your shared code base need native features, for example storage implementations are totally different for each platform, or changing views (navigation) will be implemented differently for each platform. Since shared code base shouldn't know anything about native platform. You should abstract these functionalities with interfaces. For example create a storage interface with methods like saving/reading/creating files. Another example might be network communication. Abstract it as an interface on your PCL and implement this interface in your native project with full control of your platform. Your shared code base only knows how to use that interface. And then each of your native projects should implement these interfaces. At this point dependency injection may help to register implementations easily. Actually that part is what makes you share your business logic. Writing idiomatic cocoa navigation code is much better than using any cross platform implementations, you have full control but in the same time your shared code base using them without knowing anything about the platform.
In the free version you app expires after 24 hours AND it has to be below a certain size, I dont remember maybe 2 MB or something.
To make something you have to cough up a lot of money, and the sad part is this information is incredibly hard to find, you only stumble upon it when you download GBs of files.