Creating The Instagram UI In Xamarin.Forms

Xamarin.Forms continues to be dragged down by old viewpoints, that it is unfit for popular, polished, and/or large scale applications. And that it could not possibly compare to a native implementation. Xamarin.Forms apps are native applications, and have the full capabilities of one, the only difference is that you may need to implement CustomRenderers or platform specific code, to achieve things that Xamarin.Forms has not yet, or can not yet implement, in a cross platform manner.

In my attempt to demonstrate this, I am recreating part of the Instagram UI, which at this point, was developed natively for Android and iOS. However I do realize they are soon porting to React Native. Which I suppose, in itself, is proving the point I am trying to make here.

This post, is only here to demonstrate, that some of the worlds most popular apps, can be replicated in Xamarin.Forms. I’m not recreating the entire Instagram UI, and I won’t be dealing with nuances such as rotation and device screen sizes. I also won’t be providing any actual usage, because the Instagram API is private. But, if there is something you deem important to the native UI experience, that you believe can not be easily replicated in Xamarin.Forms, please let me know, and I will be happy to add it.

Note: I realize everything isn’t exactly pixel perfect in the following, but that was due to time restrictions, not lack of capability.

Welcome Screen

On the left we have the real Instagram Android app, on the right we have what I replicated in Xamarin Forms. Nothing out of the ordinary in these screens.

Login Screen

The login screen was a little trickier, because the default Android TextView does not look like that. I added a rounded_corners.xml resource as such.

<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="" > 
    <stroke android:width="1dp" android:color="#e7e7e7" /> 
    <solid android:color="#fafafa" /> 
    <padding android:left="1dp" android:right="1dp" android:top="1dp" /> 
    <corners android:radius="5dp" />

Then, in a custom renderer, applied it to the control, along with the appropriate gravity.

[assembly: ExportRenderer(typeof(Entry), typeof(TextViewCustomRenderer))]
namespace Instagram.Droid.Renderers
    public class TextViewCustomRenderer: EntryRenderer 
        protected override void OnElementChanged(ElementChangedEventArgs<Entry> e) 
            if (Control != null) 
                Control.Background = Android.App.Application.Context.GetDrawable(Resource.Drawable.rounded_corners); 
                Control.Gravity = GravityFlags.CenterVertical; 
                Control.SetPadding(10, 0, 0, 0); } 

On the left is the real Android Instagram app, on the right is my Xamarin Forms replication.

A few color mismatches here, but, once again, nothing that I couldn’t resolve with a little more time. I also made the button default on. This is the color the real app would turn, when you entered an email and password. Something we would do with a trigger in Xamarin Forms.

Main Feed Screen

The main feed was actually surprisingly simple. Here I also show the native iOS version. The only differences between these two, are some icons, which could easily be switched with an OnPlatform.

We have a ListView, some Grids, James Montemagno’s Image Circle Plugin, some images, a few StackLayouts. You could use Xamarin.Forms Animation Framework, or Lottie, to implement some of the animations I didn’t get time to implement. If you can do it on native, you can do it in Xamarin.Forms.

Managing Cross Platform Differences

Of the differences I saw between Android and iOS, there are four ways to manage these, in Xamarin.Forms.

1. Custom Renderers, to modify any control at the native level. Effects could also be used.
2. Native Views / Embedding
3. Platform Specific Code, then use Dependency Injection.
4. OnPlatform

Through these, I can modify any native platform property, access any native platform API, and do it with relative ease.


There was nothing I couldn’t create in Xamarin.Forms, regarding the Instagram UI. It was fairly straight forward. I know that someone is most likely going to pull the, “What about the Performance” card, and despite it not being quite as fast on startup, which the Xamarin.Forms team is working on, the UI uses native elements and performed just as a native app would, once inside the app. The startup performance can also be improved through various techniques. Have a read of Improving Xamarin.Forms Startup Performance to see how to improve your app’s startup time.

Recently being on a Native Xamarin development team, being their UI Automation Tester, I am now even more convinced that Xamarin.Forms is the way to go for all cross platform development. Native development suffers from numerous amounts of duplicated effort in the UI, duplication of bug fixes, and even if I spelt out the names to use for each control; different ways to layout the UI, misspellings and forgetting to name elements correctly, continued to surface.

If the UI on each platform is VASTLY different, then yes, a native approach will be suited. But saying you want a more POLISHED app, use native, that’s just wrong. Instagram isn’t vastly different between platforms, neither are most apps that appear on numerous platforms, why would they be? You can create a Xamarin.Forms app to be just as native and intuitive on any platform.

If you want to have a look at the XAML, go to my GitHub Repo Instagram, for the code.



  1. Malte Goetz

    I do not think that a lot of people are still questioning whether Xamarin.Forms allows you to do everything a native app is capable of. I think the question is if Xamarin.Forms is a good choice for apps with extremely customized UIs/UI elements or if I am faster using axml on Android and a storyboard on iOS with the regular Xamarin approach.

    When UI complexity hits a certain range the regular approach is faster because of the overhead that is needed through Forms with all the Renderers and OnPlatform tags. This also decreases maintainability, makes it much more difficult to find bugs. But it is getting better with every Forms version. Have to say that as well.

    1. Adam Pedley

      This is actually the opinion that I seem to be up against. A highly customized/polished UI generally isn’t quicker to develop in both platforms.

      What is a highly customized UI, that can’t mostly be done in Xamarin.Forms? Many people keep saying this, yet I still haven’t seen any example to support this claim. I agree that 2 vastly different UI’s should be built separately, but I don’t see cross platform apps that are vastly different.

      Regarding the maintainability factor, being on large Native and Forms teams, maintainability of 2 (or more) UI’s is more onerous than maintaining Xamarin.Forms with custom renderers and OnPlatform tags. Forms is much easier in maintainability, even in scale, and it follows through into easier UI Testing as well.

      1. Ben Reierson

        This is a good example, and I agree that most apps aren’t vastly different between platforms these days. In the earlier days of Android and iOS, there was a lot more volatility in design guidelines and UI experimentation. We used to see wildly divergent designs, but this has settled down as we’ve all kind of agreed on some standard approaches, and the OS’s have mostly converged. It also helps that windows phone isn’t really a thing anymore. 🙂

  2. Ahmad ElMadi

    Hello there, What a great work! I am interested to see how did you implement the horizontal listview 😀 can you share this part ? or can you share your code in general ?

    1. Adam Pedley

      There currently isn’t a standard way to support horizontal scrolling for a listview.

      I would just use a StackLayout with Horizontal Orientation. You could write your own custom control to make it bindable with a data template.

      For other options, you can just search online, there are 3rd party controls, or many other work arounds.

  3. Dave

    I tried making this same point to some people at a clients the other day. Unfortunately the guy in charge of the web designers has a lot of sway and is stating that progressive web apps are the only way forward…and that “even google” are scrapping native apps. Apparently what we do with xamarin is “old school”…

    1. Adam Pedley

      I don’t know what he is reading, but Google aren’t scrapping native apps. Google’s now starting to push Instant Apps, but they are still native apps, but with support for quick loading of only relevant parts.

      I don’t think we can get across to everyone. 🙂 WebAssembly might be something to watch though.

      1. Dave

        Don’t I know it – bought a Google WIFI Mesh and it comes with a great app.
        Honestly, I think it is some sort of power grab. I called him out on a few points but it was de-railing my workshop from “what can we do for the business” to “what tech is best”…

        WebAssembly will be very interesting.

        BTW, Great article!

      2. Luiz Marques

        Google pushed progressive web apps pretty hard on their last couple of conferences.
        That is probably what they heard.

        Obviously they are not scrapping native apps, that would be absurd.