When to choose Xamarin.iOS/Xamarin.Android over Xamarin.Forms
I was lucky enough to start developing with Xamarin over 8 years ago at a time when Xamarin.iOS went by the name MonoTouch, Xamarin.Android went by the name Mono for Android and the products were both owned by Novell.
It was a time where you would write code to develop a user interface. Back then the best knowledge on MonoTouch was normally blogs and books by Craig Dunn and Mike Bluestein. Years later I would work with both at Xamarin and like their books and articles, they were great to spend time with.
Fast forward to today. Xamarin.Forms is now the key player in the Xamarin world. Most developers when they hear Xamarin, now think of Xamarin.Forms and that is something I see on a weekly basis when I teach Xamarin; most new developers gravitate to Xamarin.Forms.
And there are very compelling reasons to use Xamarin.Forms. It’s designed for a .NET audience, you learn one framework (Xamarin.Forms) instead of multiple frameworks (Xamarin.iOS, Xamarin.Android, Windows UWP) and Xamarin.Forms has a feel that is natural to existing .NET developers.
But there are situations where Xamarin.Forms may not be right for your project. You might be working on a system that uses a lot of custom controls/displays, that uses lots of native APIs or controls that aren’t as easily accessed in Xamarin.Forms. You also might want the kind of navigational structure that is no available in Forms.
For my apps, the situations where I’ve chosen Xamarin.iOS or Xamarin.Android is where:
- I’ve had to code integration with background capabilities which differ between platforms. For example, downloading a file would use a Service on Android and you would use the File Transfer API on iOS
- I’ve wanted to have extremely rich animations such as using the Physics Engine animations in Xamarin.iOS
- I wanted to use the popover support on an iPad
- I wanted to define my own navigation structures and generally really push the limits to get the exact user experience I want.
But I’m not without knowing my biases too. I remember at the Evolve 2014 conference being asked a question about mocking frameworks. Even then my response was something like “I roll my own because I’m a control freak”. And that’s still true. I want my products to be exactly the way I want them and I’m happy to take a little more time to make that happen.
I take comfort in the line from Alan Cooper’s classic About Face which says:
“However, it is the developer’s job to satisfy users, not vice versa. If the developer thinks of the user as just another input device, it is easy to forget the pecking order in the world of software design”
I think about this statement a lot, and for the consumer based applications that I personally write, I want to take the time and do it well. That’s just me though. I write these apps in my own time.
So, could I have done this project in Xamarin.Forms. Probably, but sometimes like, in this case, I see two options.
Option 1: Write the project in Xamarin.Forms.
Option 2: Write the project using Xamarin.iOS and Xamarin.Android
I want to be clear before I go any further. Sometimes you will choose the wrong option. It happens. We are all humans and we make mistakes.
It happens and any good project manager should be looking to minimize risk by ideally architecting your project with Model-View-ViewModel (MVVM). By using MVVM much of the logic is written within the ViewModels, Models and Services so you can easily swap it out. MVVM is a topic on its own, but it helps keep your application logic separate to your user interface which allows you to add new presentation layers in easier.
Option #1 — Write it in using Xamarin.Forms.
If you are creating an application that is data-centric in nature, go for it. Forms is likely going to be a good fit. Keep in mind if you need to add in native capabilities that are not there you should be aware of how to create renderers, events and embed native controls. It’s doable to create extensions but you are working on the top of another framework to do this.
This is fine on some projects so keep going. But when you get the sense that you are spending so much of your time working with native code writing renderers and effects because all the controls are not doing what you want them to, it may be time to re-assess. Maybe you want to create a navigation structure that doesn’t exist in form and if you do create it, it may not be as easy to manage.
The reality is, for the most part, you will be ok. If not you can move over to Option 2 and use Xamarin.iOS and Xamarin.Android.
Option #2 — Write your app using Xamarin.iOS and Xamarin.Android
Going back to the previous quote by Alan Cooper, this is going to be more work which means more time. Maybe you don’t have that amount of time so Forms would be a better option. But maybe you want tighter control. Maybe you want:
- A custom navigation system or complex user interface
You may want a custom navigation system or complex user interface that does something different. With Xamarin.Forms you are normally limited to mostly StackNavigation, TabbedPage, MasterDetailPage. If you want to create something truly novel you will probably have to do far more work than you want to. For these kinds of systems, I find Xamarin.Native a much easier option to manage imo.
2. Tighter control of animations including physics animations
I love some slick animations in my app. I’m a big fan of Lottie, which is probably the main reason I have an Adobe Creative Suite licence. Lottie works in Xamarin.Forms, Xamarin.iOS and Xamarin.Android.
But sometimes there are other animations that you want to take advantage of, things like some particle physics, some multi-stage animations. All these while possible in Xamarin.Forms may be more effort than what you can do, especially in the animations also involve your core navigation system.
3. Quicker Startup Times, especially on Android
This is a temporary issue imo. A few weeks ago, I loved reading the following tweet:
in particular, with Jason Smith’s response:
So I have it here as an option, but it may not be for long.
4. Better integration with services.
Your Android app may be significantly different in how it works compared to iOS. To download a file, on iOS you would use the File Download API but on Android you would use a Background Service to manage the download. Bluetooth, Location Tracking and other capabilities work in similar ways. I know there are lots of open source libraries that address these but in my experience, they are not typically written to address how to operate when running in the background effectively.
This is really a minor point as you would have to write the same code for Xamarin.Forms or Xamarin.Native. I find that the integration code here is better with Xamarin.Native.
5. Deeper control of User Interfaces
It might also be that you have very different and complex situations where you are supporting Phones/Tablets/TVs/Foldable devices and you need to control this. Using the Storyboard designer in iOS might be one option. For Android, you might have custom layouts for different screen resolutions that need to be considered.
The cost of benefit of going Xamarin.iOS and Xamarin.Android in these situations might be worth it.
Summary:
This post was really about helping you consider what are the choices and what has worked for me.
It might be Xamarin.Forms which is going to be more likely, or it might be Xamarin.iOS/Xamarin.Android. At least now you know what the options and risks are.
Now do the next thing. Write the app. That’s where the magic happens.
Just a note that this article is a part of Xamarin Month: Love and Friendship, an initiative during February to share content about this great tool.