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.
MS stack developer
I think yes, MS invests a lot into the Xamarin platform, so I expect it to become more stable and more developer friendly than it was before. I have a plenty of experience doing cross platform mobile development and I tried several other alternatives, Xamarin was actually the best - easy to start, easy to implement stuff, fast enough on mobiles, has a lot of components, etc.
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.
XAML and MVVM are awesome, but I wouldn't touch Forms with a ten foot pole. I really miss having something like the bindings like they work in WPF in Xcode
I occasionally go on rants when remembering the WPF days and realizing I now spending 30% of my time fixing dumb stuff like NPM breaking, gulp going crazy, or realizing I'm using 6 month outdated tools because the kids found a better one. I felt like I really had a chance to learn WPF.
In my opinion WPF was MVVM done badly, and never fixed. Having to implement complex converters just to map a couple of radiobuttons to an enum was ridiculous. The amount of boilerplate made it look like a joke. As someone said, WPF makes the difficult simple, and the simple - next to impossible.
I think you statement is true when people tried to follow MVVM with a religious zeal. In my experience WPF/MVVM worked far better for people who took a more pragmatic approach to the code behind.
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.
That may be true, but what does it tell you? To me it shows that the implementation is lacking, if people need to sidestep the pattern on a regular basis, and are actually better off by doing so.
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.
If you want to develop cross platform mobile apps your only other option seems to be React Native. I'd like to see a good rundown of the pros and cons of each approach.
There are tons of cross-platform mobile application frameworks ranging from Qt to Unity, Marmalade to probably hundreds of web-based solutions.
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?
Ionic 2 is a very promising hybrid approach. It's still in beta but should be out of it soon (better wait until it's released). The current beta version is quite fast. It has lots of components which are beautiful and has great support for ios, android and windows phone. It's JS (angular2) and html based.
Can you please point to an app built on this? I'm currently looking into hybrid apps and Ionic is probably the best option. It may be fast but not smooth though, e.g when scrolling or pulling a left side menu.
Our app Pacifica, http://thinkpacifica.com, is built on Ionic 1. It is currently showcased on both the Ionic and Cordova websites and we've see a fair amount of success with over a million registered users since launching last year.
We are in favour of Native. We are still in product market fit with our current product (native iOS to native Android online instant porting tool, www.myappconverter.com) but we are making good progress based on customers and user feedback. We are currently working to support auto-layout.
The thing with RN is that, well, either you like javascript or you don't. I don't.
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.
I tried Xamarin once for a macOS application. I migrated a Forms application by extracting all logic that I could from Forms-specific (code behind files) into more generic classes.
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.
We've been working lately with React Native and Exponent (getexponent.com) and we've had an amazing experience. The apps resulting have a great experience and performance. Vue.js and Angular are also making progress towards the Native world. I honestly don't think hybrid apps are going to be a think 2 years from now (of course I could be wrong, this is just an opinion).
I'm currently developing an app integrates Google APIs like SignIn and a google product that i plan to make available on all major platforms (Android,iOS,Windows).
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.
You are right, on the other hand, Microsoft isn't famous for being able to keep up with itself (especially if you look at the number of deprecated ways of creating GUIs).
Depends on which "last 4" you are talking about. UWP's GUI API is essentially the completion of the "Avalon promise" from the Longhorn/pre-Vista era: WPF and Silverlight (aka WPF/E) were both "spin offs" from Avalon in their own ways and WinRT was final push to complete "Avalon" before being rebranded UWP... So from that sense Avalon, WPF, Silverlight, WinRT, UWP are all iterations of the same API plan, all share more similarities among each other than dissimilarities, and all share a base set of transferable skills that learning one of them makes it easier to transfer to a different one. So from that perspective too, the "last 4" APIs they told people to use have all really be just one API that's taken a while to grow, evolve, then re-converge.
Ripple is terrible, but you can use other emulators for Cordova. The Visual Studio Emulators are quite good and I've heard there are ways to set up Cordova debugging in Android Studio as well.
Microsoft just announced the launch of Visual Studio for Mac (based on Xamarin). It's great if you want to C# development. Have you tried Eclipse or Android Studio?
If you're familiar with C# and .NET, it's a no brainer.
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.
When using Xamarin I always get the feeling I'm writing Java code--but in C#. The cross-platform project is a blessing, it's truly amazing to be able to write code once and use it on all platforms (especially if you use Dependency Injection for even more sharing).
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.
> Some of the most used API's are not documented at all, simply having a "To be added" description.
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.
Agreed. I never read the Xamarin documentation, instead I'm looking at objc or Java and then impl as c# instead. The method names, signatures and idioms match almost one for one. When the API doesn't match it's because it makes sense to; Pickup a copy of the dotnet framework design guidelines and you'll see what I mean about the previous statement.
> 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.
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.
Most of my problems often come from constructors. For example, using a custom parametered constructor in an Activity or Fragment seems impossible, so constructor injection is already out of the question. This is valid C#, but will not compile. Hence, I stated that using Xamarin feels like programming Java in C#, which makes me feel like I would actually be happier writing Java code.
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.
I've written a few apps in C++/COM with a UI written in Visual Basic. The VB app was 'button code', with the heavy lifting done in COM. I wonder if this approach would work for Xamarin - write the core logic in C# but leave the UI in Java.
I've used Xamarin for several projects and I greatly regret that decision. Granted, most of my hatred is targeted towards Xamarin Studio and Xamarin.Forms so if you use Visual Studio and build only native UIs then maybe your experience will be better.
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 admit that Microsoft is usually quick to fix those bugs, but it doesn't instill much trust in the system if you're constantly running into issues. Many days I am literally working 50% of the time on my app and 50% working/fighting my way around Xamarins issues.
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.
Forms is not Xamarin. It's a DSL in the form of a NuGet (aka npm/cpan) package developers can use to attempt to ignore the differences between the platforms.
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.
I have used both "native" Xamarin and Forms to build apps. Last year Xamarin had a really bad streak with stability but things have certainly improved.
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.
I am using Xamarin.Android currently for a project, and I really like it.
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 have access to all of the same namespaces that a native app does, and also access to all of the namespaces included in .net Framework Standard.
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.
if the xamarin cross platform sdk maps closely to one mobile platform, how does make it intuitive for iOS developers? Or are the classes aliased for each target platform?
I'm no mobile developer but I guess that being able to share classes and libraries(that are non UI/mobile specific, mostly services and domain/business logic) among all the .NET platforms. So you could use the same libraries for an android,ios, windows phone client, a desktop GUI client, a webserver, a static website.
At flexVDI, we use Xamarin for building our macOS client (Xamarin.Mac), sharing most of the code with the client for Windows, built with Visual Studio. Both of them, link against a shared library which implements core functionality, written in C.
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).
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.
I loved C#, hated Xamarin forms.
It was about a year ago no, but I doubt things have changed that much.
There were just so sooo many bugs.
I have nothing against them and still think .net is amazing, but that was such a worse experience.
I think reactive will win though.
The only performance problems I've seen were created by people who don't understand when React triggers a redraw, thus rerendering a 1MB image on every keyboard keystroke.
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.
This was posted on the 7th June admittedly. Does this still hold true?
I personally haven't experienced any performance problems, even on lower end devices (only the ones where the whole OS is sluggish).
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.
I've used Xamarin for several projects and I greatly regret that decision. Granted, most of my hatred is targeted towards Xamarin Studio and Xamarin.Forms so if you use Visual Studio and build only native UIs then maybe your experience will be better.
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.
Agreed, people seem to think Xamarin == Xamarin Forms, while the real power lies in shared business logic with native UIs, in my opinion.
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.
I've been extremely disappointed in Xamarin. The main issue is that you don't really get code sharing. I would estimate that only 25% of the Xamarin project I manage is cross platform code. The rest is this bizarre merger of native APIs with C#. It's difficult to write because of the lack of examples and documentation. It's also buggy, even with simple things like page views.
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.
Hm, completely different experience here. I've been involved with three rather large Xamarin-Projects in the last year, and we were (team-wide) completely surprised at how much of the code can actually be shared, how our velocity compared to native development and the overall dev experience.
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.
I think it's going to entirely depend on what type of app you have. Much like your parent comment, my experience with building an app was that very little code could actually be shared. In my case we had some fanciful design that would largely have to be custom code for each platform. Thinks like API calls, validation, business logic could be shared but that was negligible compared to the platform specific code.
Yes, and that's always going to be the case with cross platform development. Fancy UI/UX is going to be highly platform dependent, while projects that have more model/controller code are going to be easily shared.
Vs what? Native would be the same? And with native you have different languages. So which cross platform gives you that but with more code sharing? 25% (which is low, we are well over 60% in general) is more than 0% and you can work in F# to boot.
"The rest is this bizarre merger of native APIs with C#. "
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.
I've had completely the opposite experience. Have worked on several medium-to-very large Xamarin projects (4 developers up to 60 developers) and rarely have I seen code sharing drop below 50%, with the sweet spot being around 60%.
2 years ago, Xamarin was buggy as hell. Today, (IMHO) it's quite stable.
Edit: downvoted for sharing my experience? Stay classy, HN.
Don't worry about strange downvotes. Nothing attracts upvotes faster than an initial downvote. Lots of people will upvote an unfairly grey comment that they normally wouldn't have upvoted. So it's quite likely that you'll end up with more upvotes than you otherwise would have.
Can you elaborate on what kind of apps are you developing and where you are getting good reuse? My apps are generally heavy on the UI and moderate data and I'm wondering where the sweet spot is.
I've been doing Xamarin for about 6 months and I get most of me reuse in services. Sure, manipulating the UI is mostly native code but the rest can be reused such as the DB layer, API layer, and anywhere else you have business logic.
Enterprise mobility mostly; moderately heavy on UI (UI standards in the enterprise are rising, particularly for mobile users), but I generally find the bulk of reuse is in workflow, local persistence/offline storage + data synchronization + security/encryption + enterprise infrastructure integration / cloud & "other" services integration (e.g. CMSs, CRMs), etc.
I had no issues two years ago; what was buggy? We wrote very large apps in it without problems (besides the normal crap one has with builds now and then).
It depends. I've been pretty happy with Xamarin for what I'm doing (a game [0]).
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.
I've gotten great levels of code-sharing, but you don't just get it out of the box. You really have to architect for it. See: MvvmCross and ReactiveUI.
You can do all of that with Forms with custom renderers when needed. I like that flow; mock up the app with standard cross platform components and when the basic functionality is in place, add custom renderers to add fancy UI.
I was extremely disappointed in the development experience, but the core technology is extremely helpful, depending on your use-case.
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.
No one is mentioning how expensive Xamarin is and there is no proper free version.
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.
Hi, from Xamarin here - what page are you referring to? Community is free, there are a few extra features that come with VS Enterprise. Those are just nice-to-haves, like other VS enterprise features. You can develop with Xamarin for free.
Yes it is worth learning. It's a skill which is quite in demand especially from established companies for their business applications.
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.
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.
AFAIK, Xamarin Forms was always meant to be simplistic, and not very customisable. They even say it was meant to be called Xamarin Duplo, but trademarks.
That was just an internal working name. Xamarin.Forms has first and foremost been a code patterns library, not a WORA framework (despite how it may be used in practice). It's a unique leaf on the MV* tree. The central insight from it's chief architect was to apply the scenegraph + renderer model from 3D graphics to solve the native cross-platform UI problem. It should be classified something like Model-ViewModel(Scenegraph)-Renderer.
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.
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!
167 comments
[ 5.9 ms ] story [ 253 ms ] threadAlso 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.
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?
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.
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.
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.
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.
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:
I admit that Microsoft is usually quick to fix those bugs, but it doesn't instill much trust in the system if you're constantly running into issues. Many days I am literally working 50% of the time on my app and 50% working/fighting my way around Xamarins issues.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.
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...
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).
https://facebook.github.io/react-native/showcase.html
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.
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.
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.
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.
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.
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.
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.
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!