Handling differences between iOS and Android


#1

I’m writing a mobile app using Meteor and I plan to launch on both iOS and Android. I have it pretty much complete for iOS and I’m starting to edit it for Android.

With so many differences I’m going to have to handle between iOS and Android, would it be easier to have basically 2 separate projects? As I’m looking through the Android version there a quite a few conditions that will have to be set for it specifically, especially in CSS. I realize it would take some duplicate work for the server code and some of the client code, but I’m going to have tons of IF statements and other work arounds if I do them both in the same project.

Does anyone have some advice that has built a production Meteor mobile app before? Would it be easier and better for the app to have 2 projects or to have a lot of conditionals and work arounds?


#2

It’s hard to say, probably depends on the project your working on. I can only say from our experience, we used Framework7 for the UI (which is awesome btw) and just sticked with Material design theme for both Android and iOS, which is also what Google does in their apps (Hangouts is a good example). Doing that we have very few conditionals for handling platform differences (I remember only having to deal with the padding due to status bar on iOS being drawed on top of your content instead of being above it).


#3

Hi @M4v3R, I also think Framework7 is awesome, but haven’t been able to figure out if I can use it for a desktop app as well. Do you have any pointers for that?


#4

Hi @gkrizek: I’d recommend to use one single source code for all usage scencarios, i.e. iOS, Android, and desktop browsers. If you fiddle with different projects, you’d drop a huge benefit of Meteor.

Of course, it somewhat depends on how big you want the differences to be. If you want to implement a completely different user interface (one matching iOS guidelines, one matching Android guidelines and one tailored to the browser), it might make sense to split-up the app on the UI level. But this could also be done by separating the UI part from the rest of the app using packages. Another option in this case is to use a mobile UI framework that automatically adapts its representation to the different environments. Or, you just use an established UI design framework like Material Design on both devices, as was already suggested. I know many apps which are doing it this way. Material Design looks quite nice even on iOS devices, and you could still replace some of the controls (like checkboxes) by iOS-specific widgets.

In my own major app www.guzz.io, I decided to follow a very simple approach. It basically uses the very same code for all target environments, based on good old Bootstrap. To be able to set different styles for certain elements depending on the environment, the app adds classes like “ios”, “android” to the <html> tag on startup, just like modernizr does. So in any of my stylesheets, I can now define selectors like

ios myClass { ...

For instance, I am using this to set a plain style for all buttons on iOS.

I am using this technique also to set classes that differ between “mobile” and “desktop” usage and between native app and mobile browser usage. So in the actual class of the html tag you will find something like mobile nativeapp android.

For handling devices separately on the JavaScript side, I am setting session variables on startup that mimick the same for JavaScript. So I can do the following: if (Session.get('runningOnMobile')) or if (Session.get('runningAsNativeApp')) everywhere. This is in face one of the very rare cases for which I am using session variables, as I otherwise tend to avoid them. These session variables are made available by central Blaze helpers, which allow me to to {{#if runningAsNativeApp}} accordingly.

It turned out that I only need these if statements in very few cases, where there are actual differences on the devices, e.g. in the way they handle the keyboard. The number of these cases would never justify to have separate code for the different device types.

But as I already said: this might be different in your case, depending on how exactly you would like to adjust your app to the specific environment.


#5

Thanks for the advice everyone! Unfortunately, I’m a little too far down the road to start using something like Framework7. I created everything from scratch and it’s done now (on iOS at least). I really like your idea of setting classes to the HTML tag on start up depending on what OS it is. I think I’m going to try that route.

I had an idea of including specific style sheets based on what OS, but it seems like Meteor imports all stylesheets regardless of name or anything. Your answer also seems sort of like the same thing, but with just one stylesheet. I think I’ll give that a try.

Thanks again!


#6

Framework7 is purely mobile framework. In my case I have a totally separate app for the desktop version of the project.


#7

How did you do testing for Android? I’m using Genymotion, but Hot Code Push isn’t working on it. I get this on every change, even CSS changes:

Error: Skipping downloading new version because the Cordova platform version or plugin versions have changed and are potentially incompatible

I get what this error is and why it happens in production. I just don’t get why it is happening on my Android development VM with minor CSS changes.


#8

Personally, I think it’s easier to just show different UI with css depending upon the platform. Two totally separate projects sounds like a lot of work.