Forum General

Looking for experienced advice regarding the choice of Xam.Forms or not for a specific application

jimuttjimutt SEMember
edited December 2016 in General

We are at the pre-study state for a cross platform Xamarin app which will be used internally within the enterprise. I'm looking for some feedback from more experienced Xamarin developers regarding the most suitable approach for this project. Of course it's to a certain degree a matter of personal preference, but such opinions are valuable as well.

Let's start with some basic information about the project:
For the Xamarin part there'll be mainly one developer (me, who most of the time works will full stack .NET based web development). I've got earlier experience with native Android development (so I now the android ecosystem reasonably well), some Xamarin forms experience as well as very limited experience of native iOS development.

The application to be built will run on Android, Windows 10 (UWP) and iOS. The main functionality of the application can be described as follows:

  • Dynamic form generation from an external source (a form definition will be fetched from a web service). Which means that parts of the UI will need to be generated from code.
  • Image capturing capabilities (no videos, only pictures)
  • Background services (will of course have to be implemented for each platform adaptation) for form submission
  • Local storage of form data for offline capabilities

Regarding the dynamic form generation there will mainly be basic form types like text input, checkboxes etc. Chances are that there will be input types which Xamarin Forms (in its current state) does not have very good support for.

Personally I feel that a Xamarin Forms implementation would perhaps be possible and quite convenient; to avoid the need of platform specific code for form generation. My earlier experience with Xamarin Forms isn't that great though. I have experienced that when you need to use third party libraries or custom renderers for non supported view types etc. it can often feel like a native implementation for the different platforms would have been as quick, with better looking results. As well as quite many of the third party libraries and plugins I've used often have had compatibility issues with certain devices.

Well that's kind of what it's all about. What I'm looking for is some general advice from you guys, perhaps someone have built a similar app with either forms or classic Xamarin and have some thoughts to share. And how you generally decide which way to go when starting a new Xamarin project.

Thanks for your time!


  • GuyProvostGuyProvost CAMember ✭✭✭

    First of foremost, Xamarin Forms (XF) is an impressive undertaking... Huge one! This is great software! But...

    I would stay away of XF if the app is at least moderately complex. We worked (team of two) on an app that fitted this description with XF, worked for 12 months on it. We made it through! It does work! But to a cost that kills the core principle of XF which is code sharing and the "utopical" write once and run everywhere!

    Conclusion, we did the Android App with XF and we decided to forgo XF to complete the iOS app. We are porting our app using Xamarin.Android and xamarin.iOS with a PCL for shared logic. Yes, theoretically, we will share less code... But not that much if you take into account the work we have to spend in each specifics rendering.

    Our app use a map and it turned out that we add to do to Custom renderers for a lot of things... Hence writing native code (in C#, but still). We wanted a splashscreen, those needs to be done on the native app themselves, we had to check for some platform specific stuff at launch time, those too are platform specific and the list goes on.

    Note that this has a cool side effect if you are just starting mobile dev. It is a nice, smooth learning path for each platform development. You can start developing quickly with a tool set that is not scary (XF itself) and have something running in no time! Then, you face a challenge and learn a bit of info on how that thing works on Android and iOS... then you go on and dev a bit more.... And face another challenge and learn again... Until you know enough about each platform that XF doesn't have any edge any more!

    If your app is a simple, data collection line of business app, XF could fit the bill. But anything more complex I would stay away XF.

    Also, XF brings another layer of abstraction on top of everything, on top of Xamarin itself so to speak. On an already loaded stack (to code in C# for Android and iOS, Xamarin studio and VS abstracts the tool chain of each development platform. You'll face challenges on every update of the core tools AND XF itselfs! Read in the forums about those challenges. Things get realllllly fragile there!

    Also, XF brings a concept of a "Foms App", (with a nice MVVM FX though and real cool XAML) and you code against this abstraction, with it's own lifecycle, which is not Android's nor iOS's. It's kinda like coding for an imaginary device, a Forms device! But in real life, you end up coding on real SDKs, Android and iOS, the reality check is hard cause the XF abstraction isn't complete. In the end, there is an Activity in Android for example, or there are iOS's views with their specifics, contraints, fragments, what have you!... But in order to take advantages that Apple and Google offers to developers, you have to go the native way, XF can't cope!

    And, frankly, I prefer taking time on learning "real" SDKs like Android's one or iOS's one than Forms. My value as a dev is more if I have these SDK under the belt then just XF. This is, in my view, a time well spent!

    Good luck with the app and I hope that other will add their two cents, ideally showing another point of view then mine!

    Happy coding!

  • JWhiteJWhite USMember, Xamarin Team Xamurai

    For the broader benefit of others, when I am working with companies who ask that very same question the advice I always give is to take a couple of your most complicated views and see how much effort it takes to write them in Xamarin.Forms. This gives you a good benchmark of how well Xamarin.Forms fits for your project.

  • jimuttjimutt SEMember

    I apologize for the late reply. Thank you very much for your input @GuyProvost, as well as @JWhite. It will definitely be very useful.

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    I keep telling myself that the next version of Xamarin Forms is going to fix all my problems and it will work just the way I need it to. Sadly that "next version" has not yet arrived.

    Xamarin Forms is a genius idea that suffers from some really "interesting" implementation issues. That it works at all is a hugely impressive achievement.

    In particular, it adds value by creating uniformity across all supported platforms in some key areas of app development:

    • Layout engine
    • Styling system
    • Animations

    The uniformity is at once a blessing and a curse.

    The reality is that all the platforms are different. There's some convergence in UI look and feel, but the underlying implementation means it's always going to be hard to get things to look exactly "natural" for the platform - hence the recent move to Effects and platform-specifics.

    The other reality is that the Xamarin Forms team's goals are different from mine. I'm building apps; they're building a framework. Moreover, their approach to the framework design is reminiscent of Henry Ford's "any colour so long as it's black" mantra. The framework is great if you want to use it exactly as provided. Try to extend it, though, and you rapidly run into many problems. The more egregious of these are caused by the extensive use of internal classes and properties throughout the framework. I see that internal provides a convenient way for a framework developer to share things around within the framework and make them invisible to external users. However I strongly disagree with the Xamarin team on which objects should be internal. It's clear to me that they have never developed an app that required a custom renderer that subclasses one of the provided renderers.

    The biggest problem as reported in bugzilla and the forums is performance. The design of Xamarin Forms (mostly) follows the paradigm that all "native" objects are enclosed in the most generic "view" object for the platform, which the framework calls a "renderer". It doesn't really "render" anything though: it's just a blank container whose size ends up being the size required for the native control, and as such it's mostly redundant. That effectively doubles the number of view-type objects in the view hierarchy, and it's this that causes the biggest performance issues. On iOS the device/OS combination seems capable of handling it, but on Android it's a really big problem. There's a line in the roadmap that indicates Xamarin is developing a tool to collapse redundant views and remove them from the hierarchy, but I think this is a poor solution that just adds more complexity when I would prefer to simplify the whole thing. Plus I just can't get my head around how Xamarin thinks they can cope with the layout requirements while they're messing with the object tree. But they clearly think it's a good idea and that they are smart enough to pull it off. Hats off to them if they succeed.

    Another issue with Xamarin Forms, on which I'm grateful that the latest versions have made good progress, is the dreaded memory leaks. These are especially problematic on Android where Image objects have been extremely reluctant in the past to give up the ghost. However they are much less prevalent than before.

    Then there's the layout engine itself. This is the biggest value-add of the whole package as far as I'm concerned. But there are quite a few "quirks" with it that require lots of experimenting to get it to do what you think you said.

    It's interesting also that Xamarin Forms is very opinionated about some things, but curiously silent about others. For example, it requires the use of the MVVM design paradigm, but doesn't include any form of DI container. Instead it does a (very time-consuming) reflection on all the app's assemblies to gather all the custom renderers and connect them up to their respective View subclasses. A DI container could cut down an app's startup time by quite a lot, at the expense of having to configure things in code instead of via attributes.

    Additionally, the Xamarin Forms development team appears to be quite small (less than 10 people, from what I can tell). In contrast, Peter Steinberger develops PSPDFKit with about 30 developers. The bug list on bugzilla for Xamarin Forms is over 500 items (513 as at 2017-01-05). I don't see how 10 people can even address all those items, much less clear them, in a reasonable time frame.

    So while the promise of Xamarin Forms is development Utopia, the reality is quite different. There are many developers (including myself) successfully creating apps with Xamarin Forms. But don't believe the hype. Even the fact that it's Open Source now isn't particularly helpful in and of itself, since all modifications are by Pull Request and if they don't meet the team's goals they don't get accepted. That said, people in the community (most especially @AdrianKnight) have done massive work in improving the framework, for which we are all very grateful.

    One good alternative to Xamarin Forms is MvvmCross. I started my Xamarin journey using this framework and have been consistently impressed with it. It's not perfect, but it doesn't try and be a DSL in quite the same way as Xamarin Forms. That said, it's big enough that learning it will still be a significant undertaking.

    Other people have had good success for a long time by going fully native (albeit in C#), leveraging the Xamarin .NET ecosystem to put as much platform-independent code as possible into common DLLs and leaving only the platform-specific things in each platform's executables. If you do this for long enough you'll end up with something that looks quite a lot like a quirky version of MvvmCross, so it may well be worth just biting the bullet and learning that. There's a book in progress that should help a lot with this.

    For your particular case, funnily enough, I think Xamarin Forms could end up being a good fit - despite the limitations. The reason is that to make a dynamic forms generator you're going to have to do a lot of work if you do it "natively" on each platform. You'll have to create objects, add them to the view hierarchy, somehow specify at runtime how to lay them out with respect to each other, and somehow bind them to ViewModels that you also create dynamically. That's exactly the kind of job that Xamarin Forms was created to do! You'll need some kind of form factory that parses your form definition and constructs a ContentView and bound ViewModel from it, implementing INotifyPropertyChanged in the ViewModel. But I think this will be a lot easier than making something that works with Android's layout system and iOS's AutoLayout (and whatever WinPhone uses).

    So despite my criticisms of Xamarin Forms my $0.02 would be firmly bet on a Forms solution rather than "native" for this particular case. Xamarin Forms isn't yet at the stage where it's the obvious choice for every app though, and I find myself going through this conversation with myself and colleagues each time we start a new one. Thus far we've built everything with Forms (and have mostly not regretted it), but one or two of them were a really close choice between Forms and MvvmCross. In every case I've needed custom renderers though, and in some those custom renderers consumed all the time we thought we'd saved by using Xamarin Forms.

    Caveat Emptor.

  • JimBennettJimBennett GBXamarin Team, Insider, University, Developer Group Leader ✭✭✭✭

    Not sure what else I can add to the excellent comments by @DavidDancy. Forms does a lot of what you need but has nowhere near as much control as native. You can drop down to native to do things but it is not always easy.

    We use MvvmCross and Forms - you can use them easily together and with the bulk of our app built this way if we ever decided we needed more we could replace the UI layer with platform specific code and it would still work. Forms has meant we are getting an iOS and Android app to market much faster than if we did native but our app is not that complicated. I'd never write Facebook or Google Maps in Forms, but I would write in-house apps using Forms without a second thought, or simpler apps.

    The number of plugins allowing your core code to interact with hardware is constantly growing, and there is a big movement in the community to build toolkits to make your life easier. Forms also has a new guy on board to help run things - he's already laying out roadmaps and helping to define the future goals. Forms is here to stay and is key to Xamarin's roadmap so it will keep getting the love it needs.

    I also heartily agree with the book recommendation! I hear the author is a fantastic chap, talented, helpful, smart, good looking... :p

Sign In or Register to comment.