Is Meteor Production-Ready for Mobile Apps?

I have a production app to build on a constrained timeline, expecting 100,000 users within 60 days of release. The Meteor homepage promises “A great experience both on the web and as a phone or tablet app,” but so far I haven’t found anyone who’s built a mobile meteor app serving 1,000+ users.

I want to hear from developers who have deployed successful mobile apps built on Meteor about how they produced a usable mobile UI.

I want to be clear about what I’m not asking:

  • I’m not asking about dead projects like famo.us
  • I cannot afford to use beta software like Meteoric.
  • I’m not looking for projects to contribute to. (Done that, but this is not the time.)
  • I’m not asking for promising avenues. I can Google as well as you can.

I want to hear from people who successfully deployed and maintain a production Meteor Mobile app (please name the app), as so far I hear crickets everywhere I’ve asked this.

Thank you!

-D

3 Likes

I’ve deployed a prod. mobile app on Meteor. It’s not 100k in 2 months heavy but has 5 figure users and at peak ~2.5k users across 2 hours (more info here if interested: https://www.meteor.com/case-studies/blonk ).

When I wrote it almost 2 years ago Ionic wasn’t out yet so I wrote all of my own CSS from scratch. This was 10x more performant than any lib out there at the time. However now if I had to do it again I would look into ReApp using only their UI packages. This is using React so that might be a deal breaker.

Avoiding box shadows helps quite a bit as well as using CSS animations over transitions. Blonk Doesn’t have a lot of animation outside of the swiping so I was lucky there.

Cordova will never be as fluid and nice as native or React-Native but its strength is that you can deploy one app to both android & iOS. (also currently you can’t use the Meteor client in React-Native)…

Some other thoughts

Android will be the most painful. You will curse and slam things on the floor trying to get Cordova to work as it should. Sometimes it just won’t do things as the [Cordova] docs say they should. Crosswalk can help with this significantly.

The keyboard and the viewport will be a close second. Unless Cordova has fixed this recently it still sucks compared to native or even React-Native. Simple thing scrolling the view up when the keyboard comes up is challenging… or handling a form that has to scroll up with each input.

You have to watch your publication payload so you don’t flood the device. Some devices don’t have a lot of memory and if you’re not careful you can over-publish fields and soak up memory.

IMHO one codebase for many targets is a fallacy and at best a mediocre experience. You’ll have a lot of if/else blocks to handle other devices. To do it right you’ll have to have different styles and different layouts (drawer vs overlay, different animations, etc…).

This article is mostly outdated but might be slightly helpful: https://www.discovermeteor.com/blog/blonk-building-tinder-for-jobs-with-meteor-for-mobile/

Hope this helps!

2 Likes

we’re having the same issue, can you let us know, what solution you’re using for android. It will be very helpful. Thanks.

I forget the exact implementation but I think it adds extra padding to the bottom of the page container when you focus on any input. This essentially raises and lowers the scroll view. This can be setup cleanly in a switch statement using the input name as the condition.

You’ll also want to measure the keyboard since the height can differ (pretty sure the keyboard plugin does that for you)

I cannot offer a finished app yet, but would like to share some experiences, as I am developing a Meteor-based mobile app since ca. 1.5 months now. To put it short: IMHO the Cordova integration is one of the weaker parts of the Meteor ecosystem at the moment, and I wouln’t consider it as being “ready for prime-time” yet.

Don’t get me wrong: having a tight integration of Cordova with Meteor is a great thing, and in principle, it works. But you will still be facing a lot of glitches in its current state. For instance, it can happen that a Meteor hot code push breaks the whole app beyond restoration (I mean: restoration without a re-install). The Meteor team is aware of this and already working on a solution, but for the time being, this is a huge drawback (not only in production scenarios, but also during development). There’s also quite a lot of minor issues I am struggling with (e.g. my Android app is not showing custom fonts when it has been started from scratch; but after a hot code push it does).

The only reason why I am still sticking to this architecture is that I definitely need iOS and Android support, and as a single developer I cannot afford to develop both versions in parallel (using native technololgy). So at the moment, I am at least developing parts of the iOS app in native Swift, but for Android, I am relying on pure Cordova.

Maybe a good integration of Meteor with React native would be the solution for the future, but React native does not support Android at the moment. I also heard about NativeScript, but I am not aware of an integration with Meteor so far. And I cannot change my frameworks every week or so :smile:

EDIT: The Android fonts problem was my own fault. Today I found out that my font path contained two slashes in succession. iOS was tolerant with this, but Android wasn’t. So I apologize for blaming Meteor here :-/

3 Likes