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.
167 comments
Xamarin Native developer here,
I started off by trying to create a Pokemon Go Map app. Although I got off to a quick start, slowly it downed upon me that I started spending too much time finding fixes for Xamarin issues rather that programming. I used macbook as agent and visual studio as IDE. Sometimes the deployment would take 5 minutes! I then had to restart the agent to fix it. As a programmer I am rather a person who runs a code, change a little bit in code, then run it again. If I dont understand things I google it or find the documentation. Thats my way of learning things instead of reading through programming books.
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)
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)
I had exactly the same experience with Xamarin.Droid, even though I'm mainly a C# developer, for android app development, i'll go with Java & intellij Idea.
I use VS2015 a lot for .Net ASP dev, but when I do Xamarin iOS dev I tend to do it in Xamarin Studio on the mac.
Much better experience, fast deploys/builds. I miss Resharper but can live without it.
Much better experience, fast deploys/builds. I miss Resharper but can live without it.
Very recently Microsoft introduced VS for Mac (although I understand it's sort of a preview version).
I don't know about OS X, but I used Xamarin Studio on Windows and it was horrible.
I don't know about OS X, but I used Xamarin Studio on Windows and it was horrible.
That is a rebranded Xamarin Studio, with a slightly updated layout to match VS.
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 ;-).
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 ;-).
Are you saying Visual Studio feels much better on mac? If you've tried it, is there a link to download so that I can try it out myself?
The only selling point for Xamarin for me is Xaramin.Forms, but so far neither this has a good reputation.
As a person who's used XF for the last 2 years in my company, stay away from Xamarin.Forms. I can see some of the appeal for the regular Xamarin.iOS and .Droid but the performance of Xamarin.Forms on Android is absolutely horrible even after optimizing it to an insane amount. Think several seconds render times per page on a Nexus 5X (on a page that takes 200ms if written using Xamarin Android).
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.
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.
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.
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'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.
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).
Can I ask the products you have worked on with Xamarin?
NDA'd, but I'm focused mostly on enterprise mobility
Does your NDA permit you to tell others that you have an NDA?
/s silicon valley reference
/s silicon valley reference
I will see if I can get my contract amended to explicitly permit that ;)
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 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.
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.
[0]: I'm writing about this starting with https://unop.uk/cross-platform-native-mobile-app-development...
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...
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.
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.
"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.
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.
The UI Code(The stuff that uses these apis) should be a thin layer ontop of the core app.
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 would estimate that only 25% of the Xamarin project I manage is cross platform code.
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.
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.
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.
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:
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.
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.
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.
We'll hear about it in a few days.
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.
I can't find anybody that has done significant work with Forms and isn't complaining about it. It's giving the platform a really bad rep.
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.
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 understand this, but how many people read these kind of angry rants on the internet and realise there are more ways to use Xamarin than using Forms?
What you have to deal with;
* 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
* 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
iOS developer with multiple years of experience of burning fingers in cross-platform development here.
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'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.
Thanks for the input. I do feel more and more that cross-Platform is a illusion like you say.
I already know Swift. Do you think Kotlin would a better transition into Android than straight up Java?
I already know Swift. Do you think Kotlin would a better transition into Android than straight up Java?
Kotlin is a breeze compared to Java, and it's conceptually similar to Swift (syntax, null safety, type inference etc). I love Kotlin but it's not with it's own quirks.
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.
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.
I do feel more and more that cross-Platform is a illusion like you say.
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.
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.
How would C++ work for cross-platform development? Would you use a framework like Qt, or write platform-specific frontends?
I second FlyingSnake.
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.
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.
QT is one great option, however I've not used it so far.
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:
http://mobilecpptutorials.com
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:
http://mobilecpptutorials.com
What about React Native?
I've not tried RN, but a team I know tried it for a professional project. They were really dissatisfied with it said it's not suited for medium to heavy applications and found the performance sorely lacking. IIRC they mentioned that the toolchain is also not as great as Android Studio/Xcode. But YMMV.
I've several React Native apps in both appstores. I think while React Native is not suited for all types of apps, there is a sweet spot for certain projects where it really shines. The development speed is really unparalleled, with hot reloading you can see your app changes as soon as you hit 'save' in your editor.
what is the sweet spot? I'm faced with developing a fairly simple thing and it would help to know a little more about learning curve ( I use react ), downsides, etc.
Small to medium sized apps (not games) where you can sacrifice some UI polish to get them delivered quicker and on both platforms. Have a look here https://facebook.github.io/react-native/showcase.html If you know React, learning React Native would be pretty easy, plus you can use many of react libraries like redux, etc.
What problems did you experience with Rx? That's odd. Email is in my profile; can connect you with the core team.
Rx is a fantastic project and I've immense respect for the creators.
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 :-)
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 :-)
Have you, or anyone else here, tried NativeScript? It has its own quirks, but I have been pretty satisfied with it so far. How does it scale in bigger projects?
Xamarin has unfortunately muddled their branding.
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 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
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.
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.
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.
Edit: fixed spelling
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
XAML and MVVM are much nicer to work with then their iOS and Android equivalent. WPF/UWP/Xamarin.Forms are very underrated.
You can do the MVVM pattern on iOS and Android; it's an architecture choice.
Not quite.
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.
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.
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.
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 : )
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 : )
My experience with Xamarin is mostly on the Android side, so that's what I'll mention. Spoiler: mostly positive, with some big caveats.
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.
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 will re-iterate the "Stay the hell away from Xam.Forms" as we've used it at work for almost 1.5 years.
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.
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.
You might want to look into Exponent. They're a YC startup that build a framework on top of React Native. https://getexponent.com/
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/
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/
> you can build apps that are virtually indistinguishable from Swift/Java apps
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.
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.
How would you distinguish between the two if both are running above 60fps, which RN effortlessly can?
> which RN effortlessly can*
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.
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.
React Native is primarily aimed at writing cross-platform UI code. When it comes to performance critical code, or integrating heavily with native UIs (eg the media streaming abilities of Spotify) it's perfectly fine to drop down to native code. RN provides an easy way to bridge between the JS and these native components.
> Facebooks own apps are written in native code, IIRC.
They are written in React Native. See: https://facebook.github.io/react-native/showcase.html
They are written in React Native. See: https://facebook.github.io/react-native/showcase.html
[deleted]
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.
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.
It maps closely to android development? Then how is that a good soln for cross platform Dev?
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.
In theory at least...
In theory at least...
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.
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 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.
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.
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.
> Can they keep up to speed with Google,Apple and MS?
Xamarin is Microsoft now.
Xamarin is Microsoft now.
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).
UWP is going to change that.
They said the same thing about the last 4 APIs as well.
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.
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.
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.
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.
Hey Guys, Xamarin University Instructor here,
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!
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!
I've very recently worked with Xamarin Forms for about 5 full-time months and it was terrible.
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.
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.
Actually they've released Xamarin Forms Previewer - https://developer.xamarin.com/guides/xamarin-forms/xaml/xaml... It's still a bit buggy but does the job in most cases. Also the latest version of Xamarin is way more stable.
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.
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.
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.
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.
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.
FYI don't use x labs. It'd dead. Maintainer has left project and has joined Xamarin to work on improving forms.
The solution is to use Xamarin.Android, Xamarin.IoS
I have read some fairly negative comments in this thread. I have experienced many of the negative aspects myself, and while I don't disagree with them, I would still say that it is worth learning this technology.
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.
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.
My primary question, as an Android developer who can write decent enough Swift when needed and who does not develop on any Windows platforms, is why should I learn Xamarin?
The possible savings of the value of your time? If you can share even a small bit of code between Android and iOS, that is time you save in rewriting Java code to Swift or vice versa.
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.
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.
It depends on what your career objectives are. If you intend to found a start-up you can of course choose your technology stack and ignore Xamarin completely if you wish.
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.
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.
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 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.
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.
[Full Disclosure: I work on the Xamarin team at Microsoft. I’m familiar with the Xamarin tools and want to offer my thoughts and guidance on the original post. Opinions here are my own.]
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.
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.
I think where Xamarin shines is in places where the development stack is already .net. If you are starting green pasture, and don't have .net developers already, then it seems to make very little sense.
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.
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.
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.
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.
> 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.
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.
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.
> 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.
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.
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 been a life long Microsoft developer. So when I started down the mobile app path, I naturally gravitated to Xamarin. Xamarin allows you to build mobile apps in the best development IDE out there. This is true... but it has it's issues. I've created 3 andoid apps with Xamarin (and tried more), but each time i've run in to bugs or oddities that make life suck. I wish it was better, but if I could go back in time, I would have probably chosen a different language/tool. Maybe Unity if I still wanted to stay with the C#/VS IDE.
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.
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.
I have had clients that use Xamarin. This is what I've observed:
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.
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.
I've been using Xamarin since mid-2012 and have developed a couple of niche imaging products on Android and iOS for my employer, plus some internal tools on Android.
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.
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.
I've spent last 3 years working with Xamarin and native iOS and Android apps.
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.
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.
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).
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).
I couldn't get React Native working for Android (on either Mac or Windows) but I've been pretty happy with Xamarin. I've written a simple game in Xamarin.Forms that I will be posting about.
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...
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...
The Xamarin needs to develop easy and customization should be easy.
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.
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.
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?
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?
There also is Delphi with the mobile Addon. https://www.embarcadero.com/products/delphi
I learned Pascal in school many years ago. I honestly did not know that Delphi was still kicking around. Very interesting to see this :)
i'm mostly a web developer with C# and JS. I've tried to learn Swift, Xamarin and React Native multiple times over the last 2 years.
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.
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.
Just one comment to bring up as many folks still don't know, Xamarin is free for many developers along with Visual Studio Community edition, the full info is here in this announcement from March 2016: https://blog.xamarin.com/xamarin-for-all/
Native iOS and Android developer here. I switched to Xamarin a few years ago. As a native developer i was afraid of Xamarin and that i couldn't harness the power that Swift and Java gave me. However it give's you full control over your apps just as Java or Swift does. Everything you do in Java or Swift can be done with Xamarin in C#! Your knowledge isn't lost, the syntax has only changed. Nowadays i absolutely love it! I work with enterprise companies as a consultant using Xamarin, code sharing is approximately around 80% when using a Xamarin and a framework like MvvmCross! In my opinion Xamarin is the feature of building apps. Please ask any questions you have and i be happy to answer.
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.
Such cross platform apps are meaningful only if your product doesn't need great UX. But the question is, if your app doesn't need it, why do you need a native app? It's better sticking to a web-app. Make a web-app and cover all platforms at once.
You can make any sort of UX in Xamarin. Xamarin.Android, Xamarin.IOS are just straight up wrappers to the real api.
[deleted]
Xamarin is only worth it if you already have lots of C# code you need to reuse in mobile apps(our formerly windows-only company had to)
As a day to day user, I quite dislike it. But rewriting our business code was not an option.
As a day to day user, I quite dislike it. But rewriting our business code was not an option.
If you are currently doing Xamarin development or are interested in learning more check out the http://weeklyxamarin.com newsletter.
This is different than your circumstance but back when I was recruiting I helped a Xamarin developer with no professional experience find a gig with a 95K base salary. It's currently niche enough that people are willing to pay top dollar for anyone who can actually work in it. Another Xamarin developer I know consults for 150 an hour. (Although he's probably one of if not the best xamarin guy in Chicago)
95k base is indeed low. Severe undersupply of developers with deep mobile knowledge.
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.
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.
Ruby Motion vs React Native vs Xamarin vs Native (Java/Swift) is a question I have all the time. All look interesting and worth learning
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 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.
This probably isn't cool, popular, or what you want to hear. But for client-side software, use the native GUI library for each platform. Write the core in C or C++. Abracadabra. It's cross platform, no issues, no bloat, no extra fees. With experience it can be fast to develop too.
F# is worth learning that's for sure.
Especially when/if using Xamarin.Forms (and not XAML). It's a very good fit for a functional language. Code equals data.
Isn't Facebook for Android built in React Native? Doesn't seem to be lacking for them. Airbnb and Instagram [1] are also doing alright.
https://facebook.github.io/react-native/showcase.html
https://facebook.github.io/react-native/showcase.html
I think mainly for minor parts.
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.
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.
We use Xamarin Forms a LOT for our internal and public facing apps. I started exploring it almost 2 years back, because native Android development just sucked, and C# has the async/await keywords, which is simply perfect for asynchronous operations in UI.
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.
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.
[deleted]
One downside of Xamarin apps is memory usage. Just launching our app uses >200mb of memory. After doing all we can to avoid memory leaks and excessive usage, we still crash regularly due to running out of memory. (part of this is due to a UIWebView)
How is React lacking for Android?
I've heard performance problems.
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.
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.
According to discord (https://discord.engineering/using-react-native-one-year-late...):
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 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 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 don't think that is the reason, because doesn't redraw work the same on iOS and Android?
Yes if you're looking to be a primarily .Net developer, it's not so widely used outside of the .Net community but in many .Net shops it's become the standard tool for mobile development.
If you already is an iOS dev I think it's easier to just also pick up android instead of Xamarin. Altough, Xamarin seems very nice and so on.
Yes, but only Xamarin, not xamarin forms.
Xamarin for business layer logic, native for the actual app.
I've used in production and experience was good. Xamarin Studio is more than enough for development / debugging. Xamarin is very powerful, but usually people taking the wrong direction with Xamarin and using Xamarin.Forms. As like many other cross platform solutions Xamarin.Forms sucks. If you think making a native iOS application is easy with Swift, it is same with Xamarin too. When i develop applications with xamarin (desktop/mobile) i usually look for java/swift documentations or forums for my problems. This way i don't need separate xamarin community. Because you can write the same code in c# easily. Please check my workflow, for any further questions, twitter: @umurgdk
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.
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.
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.
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?
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.
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.
That's not true anymore, Xamarin is now free for everyone, except larger companies, see https://blog.xamarin.com/xamarin-for-all/
This is 1 year+ old information. Go look at the pricing page for a pleasant surprise.
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.