Cross Platform Mobile Development – Things learned from building UI used by developers across 170+ countries

Building a Mobile UI Library that is appealing, works across multiple platforms and performs well is not easy. It involves a lot of experimenting and testing. Bringing it to the tool-belt of tens of thousands of developers across the globe is even harder.

We’re going to share a couple of things about how we build and test our controls hoping it is helpful and gives you ideas on how to improve your development approach.

The good news is that the era of IE6 (and 7 (and 8)) is over. We don’t need four images anymore for rounded corners, no more 1px width gradients, no more hacks for min-width, min-height, and I could go on.

The bad news is that instead of testing on ca. 5 browsers running on 3 operating systems, the web is accessible nowadays from everywhere… phones, tablets, smart TVs, cars etc. running dozens of different browsers on different operating systems. So if you target the largest possible range of devices (and we are with Mobiscroll), you are in trouble.

Read on for a glance at how we are doing things here at Mobiscroll.

Our test devices

There is a CSS property for that. But is it supported?

When we decide to implement something, first I want to know where will it work. There are a lot of resources online helping you in it. My favorite is, which summarizes the HTML / CSS /JS API support across different browsers. There is a “known issues and resources” section for every feature.¬† It also has up to date usage statistics, so you can see approximately how much percent of the browsers support it. is a good resource as well.

Testing, testing and some more testing

As I said earlier: testing is difficult. Desktop browsers are not much of a problem and it is very rare that the same browser behaves differently on another op. system. The problem is caused by touch devices. And as they are the primary focus, sometimes they can cause us headaches. It is physically (and financially) impossible to test your product on all possible devices. But in most cases it is also unacceptable to test only on emulators / simulators instead of real handheld devices.

Let’s take a look at the most popular operating systems


The iOS simulator is good for basic testing. Unfortunately the official simulator  is not running on Windows. At this time I did not find any viable solution for running an iOS simulator on Windows (open for suggestions).

So I stick with the physical devices. Currently we test Mobiscroll on iOS5 and 6 (iOS7 will follow shortly), this covers most devices. The tested browsers are stock Safari and Chrome. Chrome for iOS also uses the Safari engine, so different behavior is very rare.


The Android emulator shipped with the SDK is slow as hell. For Mobiscroll testing I use it very rarely, only show / hide can be tested, the scrolling of the wheels is very laggy.

A better solution is the Android x86 project. I use VirtualBox for running different Android versions (2.3, 4.0, 4.2), it runs very smooth so it’s useful for testing.

Of course we test on physical devices as well, the more the better. To cover more Android versions, I rooted a Samsung Galaxy S Plus and I got to a point when I can easily switch between different ROMs (It took some time to figure it out, trying different versions of ClockWorkMod, struggling with bootloops, backups not restoring, etc.). The ultimate resource for working with custom ROMs is the XDA Developers forum. We test on Google Devices (Nexus) and on others as well (Samsung, HTC).

Android brings some other difficulties as well compared to iOS: vendors may add their own proprietary UI modifications on top of Android which sometimes shows differences. What works well on stock Android 2.3’s browser, may not work or may be laggy on the same device with HTC’s Sense UI or Samsung’s TouchWiz UI.

Windows Phone

Windows Phone joined the game with Windows Phone 8, which runs IE10 and finally supports touch events. SDK with emulator is also released. Unfortunately it runs on Windows 8 only. Some claim they managed to run the WP8 emulator on Windows 8 running inside WMvare, but it’s to much of a hassle. So we ‘sacrificed’ a workstation by putting Windows 8 on it, and we were able to test on the WP8 Emulator.

At this time we don’t have any touch devices running Windows 8 or Windows Phone 8, so I don’t have experience with testing. But if Levi is nearby an electronics store, he never misses to run in and open up on a testable WP device.


Blackberry doesn’t have a big market share, so we don’t put too much effort on testing. But from time to time we switch on our BlackBerry Torch 9810 (thanks again to Jim Ing) to ensure that nothing is broken.

Blackberry does supply simulators but last time I tried, I had trouble running it on Windows 7.


Of course the list is not finished here… There are many other operating systems and browsers that may not have relevant market share, but some of them are worth to take a look at. We also test on Amazon Kindle, we have the Firefox OS add-on installed on Firefox, and even tried Tizen, which also provides an SDK with emulator.

Tips & tricks

  • Are there animation glitches and flickering on webkit browsers? Try adding the “-webkit-backface-visibility:hidden;” CSS property on some of the related html elements (sometimes the animated element, sometimes the parent). “-webkit-perspective: 1000;” is also needed sometimes. But be careful! Using it sometimes slows things down, or even brakes the animation. (Taken from here)
  • Animations are sluggish after showing / hiding an element or changing device orientation? Or elements are rendered incorrectly (extra borders, remaining shadow…)? Trigger a DOM redraw (It might slow things down in some cases):
4 = 'run-in';
setTimeout(function () { = '';
}, 0);
  • Sometimes I end up in dead ends. If I fix it in one browser, it’s broken in the other. If I fix it in the second one, it brakes again in the first one. Often the best solution is to come up with a totally different approach. Be creative! Also there is a good chance that it won’t work in a third browser…
  • Never assume that if something works in an older version of a browser, it will also work in a newer version.


As you see, developing cross platform can be a real pain sometimes. It can happen that we develop something in one day and spend the next 2 weeks fine-tuning it to make it work everywhere possible.

Is it going to be better? Sure. But if we want to use the latest technologies I don’t think we can avoid these problems. Since Mobiscroll brings out the most from the mobile browsers, that’s what we do…

Feel free to share your experience and ideas in the comment section below.

Start building better products
Sign up and get posts like this in your inbox. We respect your time and will send you only the good stuff!

Tags: , , , , , ,

  • rak

    really interesting and step by step useful neat and clean guidelines for cross platform mobile app development.

  • laxmi

    I am freelance web designer, web developer in india. I do website design, user interface design, mobile design, responsive web design.

  • Eldad

    Great article , It gave me new ideas and new approaches.

    Can you please elaborate how did you made can easily switch between different ROMs using ClockWorkMod. Did you manage to create an automated tool or process.