Forum General

Suggestion/Proposal: Xamarin.Forms vs Xamarin.Native ... why not Xamarin.Forms.Native ?

ahmadmadiahmadmadi USMember ✭✭✭
edited June 2017 in General

Xamarin.Forms is a great platform; saves a lot of time when it comes to design, fast growing platform and most important it supports MVVM and Xaml natively, I cannot be greatful enough for having Xaml around.

That is great especially for those who worked before with WPF and However, as many of us know that Xamarin.Forms does not support all features or perhaps there are alot in the native platforms which are not supported a small example is Videos and Maps ,of course there are plugins you could have covering these missing parts but then why do we need to download a 3rd party plugin which many times suffer from bugs and can be abandoned or write a custom renderer yourself with all bindable properties just to make a label with shadow or extra color. And do not let me start talking about compatability with latest native versions of android libraries.

Xamarin forms

Once you are a Xamarin.Forms developer it is hard to go Xamarin.Native as you have to understand how the architecture works of each platform, what is the best practices, the names of the components and so on...

I was thinking that day and wondering how nice it could be if we can write android or/and ios apps natively using our knowledge of Xaml and MVVM and having access to all components that is offered by these platforms including all the properties.
So this is my idea , Xamarin.Forms.Native ... or a better name :tongue: .

When I imagine the architecture of Xamarin.Forms.Native (XFN ) should be something like this..

XFN should use the coming Xaml Standard when it is possible. When it is not possibe, the names of controls in the native platforms can be then easily used.
MVVM helpers should be easily installed on XFN such as Prism. The way navigation works in Xamarin.Forms shuold still be working fine in XFN. This way moving between Xamairn.Forms and XFN as a developer is a peice of cake .

For example, this code below is writtin using XAML Standard to represent standard contols which come out of the box from android or ios , but in this case notice that I am also using a non standard control which is in this case FloatingActionBar. I am not realy sure if i am using it's properties correctly and for sure my selection of colors is not the best :tongue: but I hope you can get my point.

   <StackPanel Orientation="Horizontal" Background="SkyBlue">
      <TextBlock Text="UserName: " />
      <TextBox PlaceholderText="Enter your username" />
      <Button x:Name="MyButton"
       Content="My Button"
       Command="{Binding MyButtonCommand}" />
      <widget.FloatingActionButton x:Name="MyActionButton"
        Source= "drowable/add_white"
         Color ="Red"

XFN should be an Android Class library or iOS class library. This way we can still get the packages intended to be used for Xamarin.Android or Xamarin.iOS. A small example of this is in case we wanted to use VLC library , or if we simply create a binding library from a java based library. In this case we should be still able to see it's properties from Xaml, and extend it to make some of its properties bindable .

       <StackPanel Orientation="Vertical">
        <vlcLib:VideoView MediaSource="{Binding VideoSource}" />
            <Button Content="Forward" Command="{Binding ForwardCommand}" />
            <Button Content="Backword" Command="{Binding BackwordCommand}" />

Xamarin.Forms.Android gets updates when Xamarin.Android gets updates and Xamarin.Forms.iOS gets updates when Xamarin.IOS gets updates.

Since it supports Standard Xaml. Two teams can be assigned for Xamarin.Forms.Android and Xamarin.Forms.iOS development and they will still be to produce products which can be seen by the users as if they are coming from the same team.

Some people might say MVVM Cross , or Native embedding. But to be honest these are workarounds for me . With MVVM Cross (or similar frameworks) there is a lot of boiler plate you need to go through plus you still have use ativity layout approach or MVC approach for android or iOS .
Native Embedding never worked for me , and I am sure that it did not work for most people , I think the fact that it should be done in a shared project is a challenge by itself.


  • Technical wise, Xamarin.Forms and XFN has nothing to do with each other , and totally different projects.
  • Probably the name Xamarin.Forms.Native is a bad idea , it could be called anything else like XamWarrior.iOS and XamWarrior.Droid.
  • When I imagine creating a project of XFN, when you go to your IDE , you will find the option for such projects under Driod app or iOS app .
  • The reason why I relate it to Xamarin.Forms is because how it feels when you work with it. Same experience and expectation when you have Xaml, code behind, ViewModels , IPropertyChangedNotification , e.t.c.
  • How would they do it ? What happens under the hood? This i do not have answer of it right now. But I think there will be a lot of reflection and decompiling to convert Android and iOS UI components to be Xaml-able .
  • This project is targeting developers with Xamarin.Forms experience who will have a hard time adapting and learning the different way of things working in Android or iOS .

That was my suggestion. What do you think ? do you think it is a good idea ? or maybe does not add any value ?


  • JohnOkoroaforJohnOkoroafor USMember ✭✭
    It is actually in Xamarin.Forms 3.0 time line to allow you to embed xaml in platform specific code for your UI. So yeah, it's on its way.
  • ahmadmadiahmadmadi USMember ✭✭✭

    @JohnOkoroafor I do not think they are the same thing , what is coming in Xamarin.Forms (according to my understanding) is that if you have done something already with Xamarin.Forms , you can reuse it native android project.

    But you still do not have access to the native controls from the Xaml code. For example , you cannot have a flaotingactionButton in your xaml code. Same case with videoview .

  • NashZhouNashZhou USMember ✭✭✭

    So what I'm assuming you want is something like this...
    You want an iOS app with a button and you add that button with XAML

    <UIButton Text="Click Me"/>

    I think it's a neat idea though I don't know how long it'll take to make. Plus what we have now, Xamarin Forms, could still use some work. Xamarin Forms still isn't that great for performance as I get apps that take up more memory on the phone (Android) and the splash screen seems to lag compared to native apps.

  • ahmadmadiahmadmadi USMember ✭✭✭

    @NashZhou Exactly this is what I had in mind , however in this case maybe it would be with Standard Xaml which is in this case would be but for sure would do also . So maybe an alies can be created for it :smile:
    The selling point of Xamarin.Forms is that it is UI Cross Platform framework, and that strength point in my opinion is their weakness point . As since they have to have 1:1 mapping between iOS and Android , that means if there is something that is not supported in any of them (let's say 3D push , or again FloatingActionButton) then it will simply not be supported.

    With my suggestion, anything you can do in native you can do it here , and when the native gets updated with new controls you get an update here about it too .

  • evminevmin USMember

    As I remember from Xamarin University class you CAN embed native android control in Xamarin.Forms container and us it in PCL project. But it will be available in Android only. The same for iOS. So you can import different platform specific control from Android and iOS for the same purpose and work with them using platform check code.

  • ahmadmadiahmadmadi USMember ✭✭✭

    @evmin I believe you mean Native Embedding . That is the closest thing to my suggestion but it is way far from it .

    By default Native Embedding does not support PCL , it has to be in a shared project , and no support for Xaml. I have seen some people are trying to have it working in Xaml but no luck . Not for me at least .

    I wish that they have continued on that track and allow the access to native components but I do not know if they have it in their plans anyway .

  • ShimmyWeitzhandlerShimmyWeitzhandler USMember ✭✭✭
    edited June 2017

    I'd rather want the opposite, I want XF to have another namespace, something like Xamarin.Forms.NonNative, and introduce all the missing controls that aren't natively supported in all platforms, for example:

    • CheckBox
    • RadioButton/RadioButtonGroup
    • AutoComplete
    • ImageButton
    • DateTimePicker
    • MultiPicker

    These could be fairly easy to implement if you took the time to create all these controls + custom renderers times the number of platforms you want to support. Now that's ridiculous, it's time for a platform like XF to support at least the above minimal controls.
    I've proposed that in the past, but the communy's response was "search GitHub", now that's stupid because there is no official support and no guidelines or even testing of the controls in the desert.
    At least if Xamarin would create an official repo of community controls administrated by some of its officials.
    I was reading this post and my heart was broken acknowledging that nobody cares about this issue. For me, development speed isn't less important than runtime speed. Creating custom controls + tests + maintenance for these elementary controls is a silly overkill.

    Vote here if you agree.

  • AdamPAdamP AUUniversity ✭✭✭✭✭

    @ahmadmadi - FYI, Native embedding does support XAML and PCL, with a few caveats:

  • ahmadmadiahmadmadi USMember ✭✭✭
    @AdamP thanks for your comment and actually this is the closest thing to what i would like to see.
    In fact, i just read my comment on your post about it .
    However, i do not know why they have stopped working on it and at this stage , with no intellisense or code behind or probably no previewer support , this feature is not really practical to use .

    My suggestion is to move this feature down to native level so it references all the native libraries naturally.

    Do you think this is hard to make by the Xamarin team and their resources? I Do not think so.
Sign In or Register to comment.