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.