The article says it all - they chose the wrong language with no community support for the trail they were blazing and that technical debt destroyed their productivity.
I achieved 90+% code share in Xamarin including UI across windows - ios - andriod. 100% buisness logic shared. You can write cross-platform UIs, and swap out to native code on a widget by widget basis. Threading is seemless. Sure it has its own set of issues, but everything is a trade-off. Look at your use case, and define what trade-offs you are happy with.
The drop-box use-case is also an outlier - to achieve high levels of responsiveness, it must integrate with low level platform specific APIs to the point their entire app may be some kind OS specific service. Look at blogs about their desktop apps and you see my point.
If you going to drink cool-aid from companies just because they are dominant in an area, atleast drink the cool-aid of a startup which was created for the purpose of building cross-platform apps.
I took a look at Xamarin recently to see how far it had come, and the tooling is really impressive. They seem to do a great job of keeping up to date with iOS/Android SDK changes, too.
But when trying to find an example of a native-feeling Xamarin-based app for iOS, I was really underwhelmed. I tried to find one that was (a) well-known and (b) third-party (not developed by Xamarin or Microsoft). The 4 contenders were:
- UPS - 1/4 stars - All views of the app are awkward embedded web views. Every page has a full screen modal spinner.
- Outback Steakhouse - 1/4 stars - Not updated for modern iPhones, so the whole app is letterboxed. UI is completely custom, so didn't attempt to feel native. Crashed as soon as it tried to get my location.
- Alaska Airlines - 3/4 stars - Feels native-ish, nice "vanilla" design. Mix of native forms and web views. All UI related to searching flights & buying tickets is a web view. Every tap on the tab bar causes a full screen modal spinner.
- FOX Sports - 4/4 stars - Wow, impressive. Lots of native-feeling views with their own branded styling. The custom widgets feel native.
It was great to find one "hero" app for Xamarin (FOX Sports), but the fact that it's an outlier is a little concerning.
They specifically mentioned when I was interviewing there that the reason their Xamarin apps are so good is because they already know how to make good native iOS apps.
Also, I specifically asked about whether or not they would be using more technologies like Xamarin in the future and they didn't seem too keen on it.
According to them, making a truly native seeming app in Xamarin isn't much less work than making two separate native apps.
Many businesses go with Xamarin because some guy in a management mandates it because he feels it will be a silver bullet that will let them get around having to hire skilled native mobile developers.
The reality is that to do Xamarin well you’ll have to wander outside out Xamarin Forms, and to do that well not only do you need native mobile developers but you need far higher caliber native mobile devs who are able to mentally translate swift/objc and android calls into their C# equivalent, and who have an idea of what’s going on the os when there’s a crash at a level lower than the .NET runtime caused by a native part that’s not apparent in the crappy Xamarin stack trace.
Xamarin really only makes sense if your company has a mountain of existing complicated .NET code with priceless business logic that you absolutely have to reuse.
I used to work for them. Great company, great technical talent. If anyone wants to move to Charlottesville or Durham I encourage you to apply! I live in CVille and I love it.
The Xamarin folks are native platform engineers first. Xamarin teams comprise Android experts and iOS experts who did then went on to learn Xamarin on top.
Thats the same experience with us except instead of Xamarin we used more popular cross platform mobile framework Flutter from google. Given most of business logic is maintained in back-end. Fron-end client be it mobile or web based needs UI and state management with some local data for offline storage. We thought it will be easy to share code across platform and we were so wrong.
Given advances in mobile platform and Native SDK a company like Google, Microsoft or Facebook will not be able to keep up with native SDK and will be one or two generations behind. You can see the result in issues on flutter project. Also given Swift has Python like syntax and ease of use with powerful toolchain and Kotlin with nice syntax with functional programming efforts are not that different working with native SDK.
Obviously this cross platform mobile framework are ok for simple crud apps. But when it comes to building a mobile app using modern vision, audio, keyboard, touch and gesture input along with modern sensors in the platform and provide a consistent UX is a big challenge. Also UI and UX have enough subtle differences across iOS and Android the code written to manage them is also substantial. So its nice to go native SDK route for mobile apps.
I think there is a little bit of bias here. Companies that are prioritize look and feel over cost probably are going native. And companies that prioritize cost over look feel are free are going xamarin.
Xamarin is indeed the closest there is to the holy grail of cross-mobile development. I too had some success with it for a small project at first, but just like the theme of the blog post, the challenge is in the long-term maintenance being cost-effective, not just the initial development. Especially in the face of these adversarial platforms constantly changing things underfoot. For example in Android recently I've been forced to switch to the AndroidX library, and iOS has Dark Mode coming out. Will Xamarin support both of those platform changes cleanly? Maybe, but it's a risk.
I'd be happy to hear if the project you worked on has been cost-effective to maintain in the long term. Then at least someone has seen the mountain top!
there is a difference between Xamarin and Xamarin.Forms, one thing is just C# => ObjC binding / C# => Java binding (C# to AOT native shared libraries and binds it into the native things), which basically SUPPORTS ALL of the native features.
so basically you can either have one application on top of a custom ui framework (xamarin.forms) or you can only share business logic, and write controllers, which feels native in c# or the native language.
i.e. without forms you can build a controller with objc or you can have the implementation in c#, and call into a shared business logic library.
unfortunatly the docs are really really weak when you consider what you really can do with xamarin.
with forms you can build a ui that works on both platforms so basically you have 100% shared code.
It was years ago, but Rdio went the Xamarin route, regretted it, and then did exactly what Dropbox just did and went full native.
The reasons for regretting it were similar: lack of available engineers on the market, incompatibilities between runtimes, and lagging support for platform features (although in the Xamarin case it's not even in your hands to fix it)
Xamarin on paper seems like the holy Grail, but the fact that Microsoft itself chose to use react native instead of its own solution for Skype made it seem like I should not expect long term commitment to xamarin from MS.
I would be careful to attribute framework decision making to careful thought. This is more the regular organizational dysfunctionality. Either:
- The entire organization uses a single framework (and improves on it), which will lead to a bunch of teams grumbling that "We are only using X because of organizational pressure, while Y is much better"
- You leave freedom to the org to pick their technology, and hope/steer people towards certain parts. But you will have to accept some divergence from the norm
I prefer the second org, and luckily I am in such a place where we can use Go while the team next to us is on Scala, and we weigh in-house developed technology against publicly available technology on ROI.
Office also has to make sure that things work on the web given they also support all the Office.com O365 versions of their apps. That's another reason they'd prefer React Native (for React Native Web) to Xamarin.
But the Office team is also a right tool for each job group and has both Xamarin and React Native apps and telling the difference between them is getting tougher to do. You can already integrate React Native components inside a Xamarin app and vice versa because they each can look like native components to each other, and it's not entirely an either/or decision.
I achieved 90+% code share in Xamarin including UI across windows - ios - andriod. 100% buisness logic shared. You can write cross-platform UIs, and swap out to native code on a widget by widget basis. Threading is seemless. Sure it has its own set of issues, but everything is a trade-off. Look at your use case, and define what trade-offs you are happy with.
The drop-box use-case is also an outlier - to achieve high levels of responsiveness, it must integrate with low level platform specific APIs to the point their entire app may be some kind OS specific service. Look at blogs about their desktop apps and you see my point.
If you going to drink cool-aid from companies just because they are dominant in an area, atleast drink the cool-aid of a startup which was created for the purpose of building cross-platform apps.