How to deal with Implementing an iOS optimized UI design on Android with Xamarin Forms?

When it comes to Cross-Platform mobile development, it is very crucial to have Screen Design concepts that are compatible for all the targeting platforms (Android/iOS/WinPhone), or at least to have separate Screen Designs for targeting platforms, when you’re using a platform such as Xamarin Forms (allowing you to develop apps with Native Look and Feels).


What if you are out of luck in such requirements? What if as the developer you’re only given the Design Screens that only optimizes for one specific mobile platform?

and worst…

You’re expected implement the same design for both Android and iOS regardless of the design’s optimization?

my story…

Let me put it this way,

the project I’m currently working is a Cross-Platform Mobile Application building on top of Xamarin Forms. I am given a bunch of Design Screens that are optimized for iOS UI patterns, and my seniors wants me to implement the same UI Design for Android as well, regardless of the Android UI patterns.

So despite Xamarin Forms gives Native Look and Feels I am asked to implement the same design that are optimized for iOS into Android regardless of Android UX patterns.

Oh well.. look at that, so mostly to go against the Android UI Design best practices, just implement the iOS optimized design straightaway. (Well my UX Lead seems to be an iOS geek) 😛

Well this would have been better if we were developing on a Hybrid framework which uses HTML5 so that we could simply throw the same rendered result for both Android and iOS, but since its Xamarin Forms, which allows you to use Native Looks and Feels after compilation, it’s going to be a mess!

…gotta suck it up!

As the developer, I have no choice but to get this done somehow, even though the hell breaks loose! because it’s my JOB! 😛

Well for the User’s perspective, getting rid of the Android looks and feel, will surely disturb the User Experience on Android.


So as the developer, here are some challenges I faced…

Difference between iOS Designs VS Android Designs!


When you take a iOS Mobile App design, its mostly a static UI design, which uses mostly pixel perfect and screen coordination perfect values for placing the components on the Screen. This is because for iOS devices almost all their devices uses a pre-defined common Screen-Size-Resolution or as in Screen Height-Width Ratio.


but when it comes to Android devices, there’s a massive sea of fragmented Screen Sizes, and according to researches it only keeps on growing, therefor for Android Mobile App Designs are compiled with non-static flexible UI Design, which has room to stretch and shrink accordingly as much as possible without disrupting the User Experience.

Dealing with the Android sea of Device…

Just to give you a head start take a look at the following illustration which shows the different Android screen sizes that are available in the market by 2016! :O


So you have to deal with the completely unexpected screen-sizes and resolutions, when you try to implement an iOS optimized UI Design for Android. Because of the pure difference I mentioned earlier, how could you take a static pixel-perfect, component coordinates fixed design and adopt it and make it flexible for the massive sea of device fragmentation of Android? 😦

…but not giving up!

So as the job role of a Developer we are suppose to solve problems and accept whatever the challenge throws at us, even the hell breaks loose!

So this is how I resolved it with Xamarin Forms!

So how did I do it?

So let’s go through one by one!

1. RelativeLayout for ze rescue…

Yes that’s right, Xamarin Forms provides several types of Layout types for the ease of Developer and luckily they also provide a Layout called Relative Layout. And yes it does exactly from what it’s name shows.


RelativeLayout is used to position and size views relative to properties of the layout or sibling views.

Unlike StackLayout and GridLayouts which most developers use in Xamarin Forms, for the ease of use, RelativeLayout allows you to place its Children Relatively to each other or for the parent view.

Therefore when dealing with different screen sizes of Android we could push the UI to render itself Relatively to given parameters while maintaining the expected UI design as much as possible.

Take a look at the below example from Xamarin docs:


As you can see, using this Layout we could implement and render the same Design across all mobile platforms. Hence we are placing all the components on the screen, RELATIVE to each other.

2. Always use Constraint type as RelativetoParent!

RelativeLayout provdes three types of Constraint type to place your Components inside the layout, that are

  • RelativeToParent: Set the value relatively to the ParentView
  • RelativeToView: Set the value relatively to another View in the same parent Layout
  • Constant: Set the value as a Constant value

So out of these three types, I would recommend always sticking to the RelativeToParent type, which allows you to have more compatibility towards Android screen sizes, because we are relying on the Parent View which takes up the whole screen Heigh/Width/X or Y properties. So its always better to take relative values accordingly to the Parent instead of another View in the same Parent Layout, which may or may not be behaving as we expect, but as of Parent view, we are sure of its layout.

3. Use XConstraints and YConstraints

Now you must remember how I was crying out loud about having to implement a pixel-perfect screen coordinates fixed design on Android. 😛

So we are going to implement the exact same concept but RELATIVELY!

So with RelativeLayout we can set the X Y locations of a component Relatively to the parent or another view, which helps you place the component on the screen without any worries since those values will get set relatively at the run time. Yep no more worries about those coordinates for Android! 😉

4. Do not use StackLayout or GridLayout inside RelativeLayout!

That’s correct do not use them inside the RelativeLayout and place your child components inside them. Which will lead to the same issue we tried to solve at he beginning, because those Child elements will adopt themselves accordingly to the Stack or Grid Layouts, not for the RelativeLayout. So if you can try to place your child components inside RelativeLayout directly by setting the X/Y/Width/ and Height constraints.

5. Avoid Constants and use Factor…

Yes, with Factor you can get the best suited value according to the ratio of the Relative property, whether its X, Y, Width or even Height! 🙂

And please, stop using Constants, unless you really wants to, because then you will be completely killing the purpose of using the RelativeLayout, hence we need to achieve fluid flexibility to render the iOS optimized design on Android with Xamarin Forms! 😉

6. Also you could use Absolute Layout!

This also does something similar but a little bit differently which could also be used in our situation.

AbsoluteLayout positions and sizes child elements proportional to its own size and position or by absolute values.

So there’s something to keep in mind as well. 😉

Something to keep in mind…

Usage of RelativeLayout is going to be very costly during the run time, takes a lot of processing power to render the UI due to its Relative behaviour of the measurements, meanwhile Jason Smith also recommends avoid using RelativeLayout and instead stick to StackLayouts and GridLayouts.

But unfortunately in order to deal with this kind of scenarios, you have to compromise something , not to mention disrupting the native User Experience of the app.


So that’s how deal with my situation when I was given a iOS Optimized mobile design to be implemented on Android with Xamarin Forms! 😀

Very well then, if anyone else has gotten into this situation, I hope this post has helped you in some way! 🙂



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s