Was choosing Meteor for Android & IOS Native Apps a huge MISTAKE?

I build a server + web app chat application similar to WhatsApp on Meteor+Mongodb.

Seems like I did a mistake choosing Meteor.

For Web Client its all fine with the Subscriptions & Reactivity & stuff.

But when it comes to Andoid & IOS Native Applications it seems like MDG has never thought of managing official DDP libraries. Since current 3rd party DDP Native libraries are totally unstable and there are a lot of connection issues & reactivity issues.

So far I have followed these libraries but as you can see that these are 3rd Party libraries & mostly UNMAINTAINED:

So what should I do now. I am totally stuck here. My Web Application is totally Perfect but Native App are totally a mess. No stability at all.

Are there any official support by MDG itself? Or I should never have choose Meteor on the first place?

I think most folks here do Cordova, react native or PWAs.

Have tried something like SimpleDDP with JavaScript? Maybe you have a bridge from native to JS? I’m not sure.

Otherwise you can go Rest route, or try fix those libraries. When you pick open source frameworks and you diverge from the common usage patterns and the community, you should be ready to fork down the road, most of those packages
are maintained by people on their spare time…

However I’m really curious about the connection being unstable and I wonder what is the underlying issue, perhaps some reconnection logic is missing from those libraries.


We face issues like resuming subscription after the Native App is idle or something. Also I dont know if our ideas match on this but Cordova or React Native apps can never beat proper Native Application in both areas Performance & Visuals.
I am expecting something from MDG to build for us.

We do mostly PWAs but we target enterprises so we don’t need fancy animation and the stores. But I understand the need for native performance, for that you can use react native.

MDG is no longer here, a lot of the effort now is done by Open Source community members like me and you, and those libraries were never maintained by MDG to start with, they had enough scope to worry about. With regards to the connection I’m sure there is missing logic for maintaining and/or resuming the connection, I think those libraries forked from one another and never addressed this issue, but that is just a guess, I don’t have first hand experience with them.

If I were in your position, the first thing I would do is compare those libraries connection logic with something working like Meteor client or SimpleDDP and try to figure out what is missing.


Actually I considered Meteor as a Complete solution. Plus as most clients demand Native Apps, I would have personally went for ReactNative but thats not upto my choice. Also time is so crucial for devs like us to study Web libs and develop Mobile DDP libs based on them

Like I said those are open source libraries and they are clearly marked as archived, you’ve to roll up your sleeves and take a closer look at the code.

The reconnection logic for the swift library is here

And for the Android

You can see that the swift library logic is a bit more sophisticated as it try to space out the re-attempts.

SimpleDDP tries to reconnect using a configurable time interval you can see the logic here:

And the Meteor client, the reconnect logic is here

It is similar to the swift library logic however it has a fuzz factor to avoid reconnection storm (i.e. many clients try to connect to the server)

So basically all of them attempt to reconnect several times and then give up. The android library seems the most primitive since it doesn’t seem to have an interval between the attempts, SimpleDDP has a fixed configurable time interval, Swift has exponential and Meteor has some random factor to distribute the reconnection attempts.

I guess what is missing from the Android/Swift library is the listener when the sockets connection opens up again that would trigger the reconnection attempt. In SimpleDDP (the browser) when the socket opens up again, the client will receive an event that triggers the reconnection.

Edit: actually the logic seems to be here for Android at least

It basically reset the attempts and try to connect again, so that seems fine to me. But what SimpleDDP does better is that it has an event dispatching system that the app can handle on disconnect and reconnect, and this would allow you to display messages or refresh the page, I don’t seem to find those events in the Android library, maybe you can confirm. I would put some alerts to detect when those connection/reconnection happen to understand how the app behaves in those scenarios, that is what I did with SimpleDDP.

I hope that helps! I find this area interesting but I don’t use those libraries, I only use SimpleDDP and it works perfectly.


Meteor is what it is, if I may say so. What it is can be read in the documentation and the guide provided on https://meteor.com. You can consider it a “complete solution”, or a collection of resources that you can use however you wish. However, it’s an open source product that comes with no guarantee whatsoever. Following is the actual text of the Meteor license document as published on github:

Meteor’s intended use as a “complete solution” is a classic web application, and also as a mobile app via Cordova builds, respectively.

If I understand you correctly, you plan to use only the server part from the original product, yet you still see what you use as a “complete solution”.

I guess you should have noticed that there is no provision in Meteor to cover your particular use case, as a native Android or Swift DDP package was never part of it.

It’s like getting a car for free, which you take apart, rebuild half of it with something that the original manufacturer did not anticipate or had provisions for, and then when you don’t find manufactured parts for it to make it run the way you intended, you start complaining that it’s breaking down and someone should fix it for you.


@hassansardarlecodeur when you are working with open source software, you have to accept a degree of risk for yourself. You are not paying for a product, you are using free software. I think the support here has been great, and there are ways to fix it. The SimpleDDP package does work well, I would recommend using it.

Most times you can work out how to fix things yourself with open source code, or someone may be able to help you. Access to the source code is a major plus for that. Your decision to use Meteor was probably a good one - just look on this as a road bump. Once you are over it, the reasons for choosing Meteor in the first place will appear more valid :slight_smile:


I respect Meteor community a lot…
I am using Meteor with Angular js since launch…
Build many dashboards & web application…
Learned alot, specially the community helped me with lots of issues & stuff.
Thanks for that & always will be…
As per my assumption…
When Meteor was launched no body cared about hybrid applications that much as they do now.
Native applications were the top priority those days.
So my point is MDG never thought of supporting Native applications officially at that time.
Ok i know devs should manage and work by themselves if they get stuck.
But everywhere it is not the case…
Devs mostly doesn’t get much time to manage those things.
My genuine point here which seems kind of funny in my head…
Its been many years Meteor has launched…
No body ever worked with Native Mobile Applications?
Or even if they did, they never faced issues like i did?
Seems bit confusing.
I mean community that older and experienced…
When some new devs gets to know that there is a Mature Meteor community launched many years ago, and they want to build apps quicker…
Trust me it will be a bit unfair for them to get stuck where they have to fix DDP libraries when the deadlines are on their heads.
I totally support Meteor, I will always be using and preferring Meteor for web applications & hybrid solutions like React & Ionic.
But I personally won’t recommend Meteor for Native Mobile Applications.
Thats all i have to say for now.
And thanks a lot Meteor community for the support :slight_smile:

@hassansardarlecodeur I understand that it is sometimes frustrating developing native frontends for Meteor. We’re kind of in the same boat, using a Unity client. We ended up using an existing DDP library and gradually adjusting it to our needs.

That library was rather “dumb”, for instance it did not care for connection break-ups, which caused us a lot of headaches, as WebSockets tend to break if the app is put into the background. If you’re used to the magic Meteor provides on the web, you get pretty spoiled. But you only learn it the hard way if the magic isn’t there anymore.

However, it turned out that the DDP protocol is so simple, that it was actually not that hard to understand and adapt things to our requirements. If I were you, I would go that route, fork one of the existing libs and extend them. Maybe you can even contribute back to these projects using PRs?

Having said this, I can still understand your expectation that stuff like that should be available out-of-the-box. But unfortunately, the mobile part of Meteor was always a bit neglected. At least, things have gotten better since Tiny took over.


Yeah I think I under where @hassansardarlecodeur is coming from, he expecting that Meteor [quote=“waldgeist, post:10, topic:54390”]
If I were you, I would go that route, fork one of the existing libs and extend them. Maybe you can even contribute back to these projects using PRs?

Yeah I don’t think those projects are too far off for being fixed to have reliable connections, I think they need an even dispatching systems and more testing, both of their code bases are very well written and documented.

Hi, I am an author of dart_meteor package. If you interested in create a mobile app with Flutter + Meteor. Please check my post on Medium. https://link.medium.com/mFjh4frlabb

1 Like

I tried the most minimal set up with Svelte but had no luck:

@alawi You have shared the codes for reconnecting WebSocket and connect meteor, however I would like to highlight the “Non-Resuming Previous Connection Issue” in DDP.

As mentioned in this link we need to send the previous connection ID to the next connection request to make use of previously subscribed data. But unfortunately, this is not working with my scenario which is tested carefully with the following test case.

Test Case:
I have a collection named “myTestCollection” and there are only 10 records (documents) we inserted against this collection. Now I subscribe to this collection for 0.2sec and disconnect the socket forcefully. It could give me 2 or 3 records in this duration and I have the previously connected session_id with me after disconnection which is known as _lastSessionId for ddp.

Now if I connect my WebSocket again, and give ddp the following request:

{"msg": "connect ", "session": "ERoZSR3R3f8zBQ6Ry", "version": "pre1","support":["pre1"]}

I would like to fetch my remaining 7 or 8 records and ddp should automatically subscribe to my previous collections since I am passing my _lastSessionId in the meteor connection request.


I am the author of MeteorDDP library which is written in purely Swift without any bridging with WebView or javascript. I have fixed this issue by re-subscribing all previously active subscriptions but want to get the optimal solution for the Mobile library.

@hassansardarlecodeur thanks for highlighting this issue here. I am sure, Meteor folks will help me to make it better for native mobile operating systems.

How is that issue handled in the origin Meteor client?

Also some clients don’t even have event system or reconnect logic thus it is leaving the the developer in the dark.

Yes nobody has handled this issue specifically. Libraries like SimpleDDP are only sharing the _lastSessionId on connection request but no one guarantee about resuming the previously subscribed collections.

@alawi can you once confirm the test case in any library how that behaves? It would be great if Meteor guys consider this as feedback and mark any clue of the user what he has subscribed and how much data he got from some collection.