Cross Platform C#
Xamarin.Forms: What Developers Make of It
Developers tell us why they use it and what benefit they derive from the tooling, and Xamarin developer Craig Dunn goes over the decisionmaking process when choosing between Xamarin.Forms, Xamarin.iOS or Xamarin.Android.
I reached out to several developers who were involved with the Xamarin.Forms (XF) beta to get their thoughts on it and also talked with an evangelist for Xamarin, Craig Dunn to get some deeper insight into the development of the product.
Rui Marinho is a developer based in Portugal. Rui is heavily involved in an open source project called Xamarin.Forms Lab project, which is intended to provide additional functionality that can be plugged into Xamarin.Forms. You can check out his Web site at ruimarinho.net to check it out and find additional third-party/open source projects for Xamarin.Forms. Ryan Groom has been developing software for more than 20 years and has authored several books and been extremely active working with Xamarin tools. Jason Awbrey is a Xamarin MVP with nearly 20 years of experience with software development.
What Developers Think
Question: What are your general thoughts on Xamarin.Forms?
Rui: I'm amazed with Xamarin.Forms, being a XAML developer for almost seven years since the early beginnings of WPF. I was very excited to see Xamarin taking this approach to build the UI layer. At the same time what Xamarin is achieving here is empowering users to finally share their UI between multiple platforms without compromising the UI guidelines and performance, and that's pretty cool.
One of the most useful things in XAML is the DataBinding platform and this saves a lot of time in tracking properties and changes. Now it's in Xamarin via XF. Also, you can now separate your UI code from your business/logic code and have a clearer separation of concerns.
Ryan: I really like Xamarin.Forms for creating simple and complex UIs for cross-platform (mobile) apps. I'm currently working on a video catalog app for a local telco, which I'll be building the app for iOS, Android and Windows Phone. The user will scroll through a list of categories and TV shows and pick a video to watch on the handset. The data (menu structure) comes from a JSON feed and is perfect for Xamarin.Forms. Instead of creating a separate UI for each platform I can use one code base to cover all three platforms. I'm very excited about that.
Many mobile apps are done by solo developers or a small team, so Xamarin.Forms lets them focus on their app, not the endless nuisances of each platform UI. I personally find most of my time building an app is doing the UI for each platform and I spend too much time getting the buttons rights for each platform instead of thinking about the app as a whole. I also like how it renders the native look and feel for each platform -- if it didn't do this it would be a non-starter. Remember old Java apps? They looked bad everywhere, Xamarin.Forms embraces the native look and feel. Plus, I'm a Windows Phone fan and glad it supports that as well.
Jason: I think that conceptually this plugs a big hole in Xamarin's platform for people who wanted cross-platform without having to do the platform-specific UI. Native is great, but it will always lock you down to a single platform. If you want cross-platform without having to maintain multiple code bases, or want to reuse any existing code from the Web/desktop world, Xamarin is something you should consider. XF doesn't fundamentally change that argument, but it is another big plus in their favor.
Question: We have seen that native apps (Objective-C, Swift, Java and so on) are very successful. Why should a developer use Xamarin.Forms? When should a developer use Xamarin.Forms?
Rui: The main benefit is that if you have a .NET background or know how to write C# code or F# and want to start building mobile apps, you can start immediately with Xamarin. You won't need to learn a new programming language, and you can reuse all of your .NET skills building mobile apps. At the same time you are saving precious time by reusing your business logic between platforms, and even your UI if you are using Xamarin.Forms. You should use Xamarin.Forms if your main goal is to develop for all three platforms and share some UI between them.
Ryan: That is simple -- time. Mobile developers have to deal with supporting two, sometimes 3, different platforms and many times the UI can be simple across platforms. I find even with small apps, you get one done, task-switch to another, then task-switch back, I find the productivity increases more you can work on a core block of code that is miraculous everywhere.
Jason: The biggest issue I see with XF so far is that it's a very young platform. It's not nearly as feature-rich as it should be, and not necessarily as stable either. I'm sure that will improve over time, but for now if you want to really to exercise the features of each platform you might be better off writing platform-specific UI.
I also think it will be challenging for them to maintain XF over time as iOS8 and Android L continue to introduce new UI elements. I'm sure there will be things introduced that are difficult if not impossible to abstract in a cross-platform manner.
Question: When should a developer not use Xamarin.Forms and instead use Xamarin.iOS and Xamarin.Android?
Rui: There are three main reasons not use Xamarin.Forms. If you want to use the free license it won't work with Xamarin.Forms -- there's a size limit and Xamarin.Forms library exceeds that size. Another reason is if you don't plan to write your app for all platforms; if you are only doing a IOS app, you will be better off not using Xamarin.Forms. The last one is, if you need a very particular UI for each platform or a very complex UI, it's best to build each UI in that particular platform instead of sharing it using Xamarin.Forms.
Ryan: If the UI is complex or if the UI is leveraging the uniqueness of each platform then the developer should not use the Xamarin.Forms. It's better to start out and build the native UI and leverage the uniqueness and power of each platform. For a photo editing app, you will want to leverage the native image processing libraries and UI, like on Windows Phone using the Nokia Image SDK or native image processing and presentation features of each platform. If you do your initial design (good old pencil and paper) and you find the controls/features you want to use do not map to the Xamarin.Forms UI set, then you know the path you need to follow.
Jason: I think XF is ideally suited for prototyping. I think it is also a great choice for production apps, if you are comfortable with the relative "rawness" of the platform, as well as a fairly vanilla UI. If you want a really polished UI that is customized to each platform, or need a truly bug- or hassle-free experience, then writing platform native UI might be a better choice. Or, if you are doing something that is really targeted against a single platform, then the argument for XF is much weaker.
Along with the questions, I asked Rui was asked to share information regarding the Xamarin.Forms Labs project. Here are his thoughts:
"I started the Xamarin.Forms.Labs project with some members of the Xamarin forums community. It's an open source project that is tailored specifically to work with this new product Xamarin.Forms, and it's focused in sharing services and controls that are not yet implemented by Xamarin's team.
"Lot's of developers started building controls and services that weren't yet on the platform, and we wanted to gather all those precious contributions in one place so everyone could share and improve what already existed instead of building their own. This way, one could save time and have a more robust and tested implementation. Since Xamarin gave us the ability to create custom implementations of services and controls, the project has grown in three parts: Services (TextToSpeech, SoundService, CacheService and others), Controls (Calendar, ImageButton, ExtendedCell, HybridWebView, and others) and Plugins for working with DI, Serialization and others.
"The project has great traction because Xamarin.Forms is being widely adopted by many developers. We have around 10 contributors, almost 350 commits and we have NuGet packages with around 600 downloads -- all this in less than two months of Xamarin.Forms being publicly available."
Inside the Mind of Xamarin
No article on Xamarin.Forms would be complete without some discussion with Xamarin, so I talked with Craig Dunn. Craig is a developer evangelist for Xamarin, a certified monkey wrangler, and he was one of my coauthors for our Xamarin.iOS book several years ago.
Question: What are your general thoughts on Xamarin.Forms?
Craig: I'm very excited by the potential for Xamarin.Forms on a number of fronts. First, it gives our customers to ability to reuse code not just for business logic and application code, but the user interface as well. Xamarin.Forms apps can share 100-percent of their code across three platforms: iOS, Android and Windows Phone. It's a feature that customers have asked for and we're happy to be able to deliver what our customers want.
Second, it makes it even easier to get started building cross-platform mobile apps. Xamarin.Forms offers a single set of UI controls and events that work across platforms; what's more the controls and the way they work together will feel very familiar to many developers from other platforms.
Third, Xamarin.Forms supports XAML for defining the user interface, which immediately makes the design process more approachable for millions of developers. Xamarin.Forms also supports data binding and commands as a first-class feature, which means for proponents of the MVVM programming model not only can they share all their code, but it can be written in an easily testable style and using the declarative UI write less code overall. Finally, Xamarin.Forms apps are still Xamarin apps, with native UIs, native performance and ability to reuse existing C# code and libraries as well as bind-in native libraries when required.
Question: We have seen that native apps (ObjectiveC, Swift, Java, etc.) are very successful. Why should a developer use Xamarin.Forms? When should a developer use Xamarin.Forms?
Craig: You're absolutely correct that native apps are successful: They're fast, they have familiar user interface elements that are consistent with the platform and they can take advantage of the all the features of the platform's SDK. Xamarin customers have always built native apps using out platform, so each of those advantages listed is also our strength!
In addition to that, we have always offered the ability to share code across those platforms so you can get to market quicker to a broader range of customers.
Xamarin.Forms further facilitates that objective by adding cross-platform user-interface code with XAML and data binding; rendered natively and with native performance. I encourage all mobile developers to look at Xamarin.Forms and understand the features it offers -- it's very simple to trial and incredibly easy to write your first cross-platform mobile apps.
This is especially true for VSM readers. Xamarin's Business Edition runs inside Visual Studio, enabling iOS, Android, and Windows Phone apps to built with C# in the one IDE. Developers familiar with XAML and MVVM will find themselves at home with our Xamarin.Forms flavor, and be delighted to see the screens rendered natively on all three platforms.
Question: When should a developer not use Xamarin.Forms and instead use Xamarin.iOS and Xamarin.Android?
Craig: I'm not sure there's a clear-cut answer to this question. Xamarin.Forms offers a set of cross-platform UI controls and if your app requirements can be met with those controls, I'd absolutely start building with Xamarin.Forms. If your app needs more controls than we offer, Xamarin.Forms has been designed for extensibility so developers can build custom controls with Xamarin.iOS, Xamarin.Android and also for Windows Phone.
This makes the decision more about how much customization is required before most of your code is iOS-, Android- or Windows Phone-specific. Your Xamarin.Forms code and custom controls can also be used in Xamarin.iOS, Xamarin.Android, and Windows Phone apps, so there's really no harm in starting off with Xamarin.Forms. If your app is based around a platform-specific API or requires significantly different UI layouts on each platform, perhaps that would be a reason to consider separate Xamarin.iOS, Xamarin.Android, and Windows Phone apps.
Question: From the standpoint of the marketplace, what drove Xamarin to build Xamarin.Forms?
Craig: Xamarin.Forms is just another step in our mission to delight developers by empowering them to build amazing cross-platform mobile apps. It was certainly a feature customers had asked for, and once we felt we could do it without compromising the developer or user experience, we set about delivering a great extension to our product. Xamarin firmly believes that native user experiences are key to successful apps, and we wanted to make sure any shared-user-interface-code solution we offered was true to this goal.
Question: How does Xamarin.Forms compare to other cross platform tools that are out in the marketplace, such as PhoneGap, Appcelerator Titanium, and other cross-platform toolsets?
Craig: Xamarin's traditional strengths already compare positively with those tools: native UI, native performance, powerful language features, code sharing and amazing IDE experiences. Xamarin.Forms adds the ability to share a single user-interface definition (whether you code it or use XAML) across platforms as well - something that other platforms have advertised as a feature. I obviously think Xamarin.Forms does it better -- the resulting user interfaces are native, with the usability and performance benefits that come with them.
Question: MvvmCross runs on Xamarins tools for iOS and Android. How does Xamarin.Forms compare to MvvmCross?
Craig: MvvmCross has been a great option for Xamarin customers keen to utilize the MVVM pattern for a long time now. We spent a lot of time on the Xamarin.Forms layout engine and cross-platform user-interface controls, and we made sure that it could support MVVM/databinding/commanding as well. The two are not mutually exclusive -- we're already seeing people in the community posting their experiences using Xamarin.Forms in conjunction with MvvmCross.
Question: What are some interesting things under the covers of Xamarin.Forms that will excite developers?
Craig: The main thing that comes to mind is the extensibility model. The team has spent a lot of time thinking about how to provide the extensive support for a common UI codebase while still allowing customization. The layout engine in particular brings lots of options with relative and fixed layouts that help take advantage of multiple screen sizes, something that has always been a challenge on Android but is likely to become more important on the other platforms as time goes on.
It's also great to see a community growing around Xamarin.Forms and the extensibility points in particular -- there are already a number of open-source projects writing additional controls for Xamarin.Forms, and helping out other developers with solutions and ideas.
Question: What are your future plans for Xamarin.Forms over the next 12-18 months?
Craig: We don't have a roadmap to share. However, we have lots of ideas as do our customers on UserVoice. We definitely want to make it even easier to do platform-specific customizations and we'll always be striving to add features and improve the usability of the APIs.