I was a huge Meteor aficionado back in 2015. Now it would be amazing if we could quickly repackage our existing web app into a mobile app. I just pitched Meteor for this, and was told that hybrid apps were all the rage around 2012, but then Apple has changed its approval process for hybrid apps. Could someone give me some info on that?
I vaguely recall Apple tightening the screws circa 2015 w/r/t apps that don’t provide any additional functionality over a website. No big deal. Is it just that, or anything else?
Let’s say, a (pretty sophisticated) website + notifications, would Apple be likely to see it as a legitimate app, barring any red flags?
Hi, the short answer is yes. Hybrid apps are as fine as other cross-platform apps.
Long answer.
A Cordova app may be rejected for reasons that a Flutter or React Native app may be rejected. Reasons may be poor implementations of UX or code. Excessive permissions (e.g. continuously run in the background and track user’s location, live video without proper implementation of compression techniques). For instance if you introduce a video player that plays 2k videos over GSM, perhaps your app would be rejected. Recently I heard a Cordova app rejected for looking and feeling as a web app and therefore would not qualify for a mobile app in the store.
In theory, you can have a Cordova app with only (extra) 2 plugins (besides what is included anyway with Meteor), one being an InApp Browser and another plugin for whitelisting urls. In this way you can just pull your web app to start in the InApp Browser and publish it in the store. - This is something that would probably be rejected.
However, if you implement Native UX on the common mobile flows with the respective plugins such as:
Push Notifications
Actionsheets (instead of React notifications or actions components, or modals )
Dialogs (as opposed to React modals for instance)
Splashscree
Statusbar
Vibrations/Sounds,
it is very likely that your app will be published with absolutely no issues.
Thank you for a very informative answer! Another question is, has Meteor’s scalability improved since 2015? I’d love to see some metrics w/r/t concurrent users.
In general, and I know it’s a very lazy question and I ought to RTFM, but I need to pitch a solution soon - I’d love to know what’s new in Meteor since 2015, just a 10,000 feet view.
7 years of Meteor updates can be found in the change log in the Meteor repo.
7 years years of NodeJS update can be found in the Node change log and similarly for MongoDB.
A platform is as good or scalable or performant as the developers behind it.
I’ll give you an example. If you have a social platform with 10-100 million users, regardless of what technology is in use you will need:
Processing - push as much as possible to the user. For instance, do async non blocking normalization of data on the client.
Cache most of your content on the client side, especially user profile, other users profiles, settings etc. I mean permanent storage in browser’s DB.
Use cacheing layers of in-memory DBs for queries (similar to what CDN does for files)
Disconnect idle clients
Make use of Node Events instead of publication/subscription wherever possible. Example: if me and you chat in a window, I will not stay subscribed to new messages in DB but to an event triggered by you sending me a new message.
Run long tasks outside your Node servers
make use of micro-services and micro-frontend.
use local (regional) server providers with high availability and redundancy.
If you plan to put 100.000 concurent users on 100 publications of 1000 documents each … might need a quantum computer with a DB built on Unobtainium processors.
We here use Meteor not because it is more or less scalable but because it is more profitable than pretty much everything else. I can write faster, recycle more code (packages) integrate with … what not, get a Users system in a minute, another minute to add Email, security, CDN storage, one the of the fastest DBs, build for every type of device, monitoring tools with relevant analytics that help me make decisions …
Thank you for excellent architectural guidelines, lots of good thoughts in one place.
I understand that performance often varies more from developer to developer than from platform to platform, and that bad development practices can butcher even the best platform. However, I’d still like some success stories. In 2015, Meteor was my Swiss army knife for pre-MVC startups. Back at the time, it didn’t scale, and I told people that scalability isn’t their top priority at this point in time, time-to-market is. Now I am in a different situation working for a larger company, and scalability is a concern from the get go. So I’d love to see some metrics, some success stories. What’s the maximal known simultaneous users ever achieved under Meteor?
In 2015 everyone here (in the Meteor community) wanted full reactivity. Today, almost nobody needs that reactivity because the UX standards today are built for async. You cannot think of/evaluate/asses Node or Meteor today through the filters of 2015.
In 2015 Meteor was as scalable as everything else … but not many frameworks had any … resemblance of reactivity. Endless reactivity has never been sustainable for any platform.
I always suggest to think “reactivity is not (so/too) scalable” instead of “Meteor is not scalable”, valid for any point in time and any framework since … code writing.
Frankly speaking, I would never use Meteor because I can publish/subscribe to data. Publications is really my very last resort if something cannot be done with a method.
WW2 won by the west was a success story. But 60M people lost their lives. Not sure success stories are of any use…
