Meteor-desktop needs to have first-party support

A few thoughts

The local file system is an obvious one, access to peripherals is another.

A third - which is probably more common - is the bundling of a specific browser version. The software I build is B2B - and the users are told repeatedly to use Chrome, and yet some still use Safari. While the idea of the software working fully across all browsers is ideal, it’s not always the case, and the dev time to find and fix all the browser specific quirks is prohibitive and some very odd browser specific bugs come up. Even if coaches are using Chrome, there are some weird things that change between chrome versions which can be extremely hard to debug, some of these are deprecation’s and can be found with care, some of them are pure bugs in the browser. By bundling the application as an electron app, we can tie users into a specific version of Chrome and avoid all these issues.

A fourth is performance reasons, any data intensive app that is used across multiple tabs requires individual connections per tab, with data being sent repeatedly to each tab. While the use of an application specific client side data cache could help with this, it is usecase specific. Bundling the app with electron gives the possibility of a single data connection from the electron side, with each tab/window using that same collection to reduce data transfer and improve performance.

A fifth reason is the UI - there are limits on what you can do with a PWA, namely - no tabs, or split views, unless you encode them into the application itself. I won’t go into all the details of this drawback, but switching from a full browser to PWA doesn’t allow you to have tabs, and split views are ONLY possible within electron, unless you make them visible to web users, which isn’t always desirable (e.g., only enabling Meteor.isCordova, etc). Similarly, if you want modals without electron you are limited to two types, in app modals (stuck within the same window) or full new windows, rendering the entire meteor app a second time (potentially with a specific route). Using electron gives a third option: custom modals designed specifically for your app, these could still be built using blaze/react and thus reuse code from your main application, but would not require the entire JS bundle be evaluated by each modal. I’ve found (only in a controlled test environment so far) that this can make the opening of modals significantly faster, which vastly improves the UI experience.

Lastly, while Microsoft has embraced PWA’s, Apple has not - you cannot submit PWA apps to the app store, which has an (admittedly small) impact on branding.

It’s worth noting that I am a massive proponent of PWA’s I hate having to build iOS apps with cordova just because Apple doesn’t want to support PWAs on iOS. It drives me mad.

1 Like

Our app is probably well qualified as “data intensive” as we do handle DNA data and people have thousands of matches which need to be compared for both copies of the same 23 chromosomes.

But we use MongoDb and AWS to handle that in the cloud so that no matter how slow the users PC or Mac or Linux or device is, he will still get his data in the same time. It just takes longer to maybe display results when we use D3 and use graph networks with the force algorithm but again I wonder why you haven’t considered moving to a web app and utilize the full power of the cloud instead of relying on users desktops (and using multiple tabs).

Like I wrote above (with tongue in cheek) that isn’t a technology of the current era IMO. It’s a relict of the past and when people point to Electron desktop apps like Slack or MS VS Code then I have to point out that they take a huge amount of memory in comparison to their features.

Moving away from your desktop to a web app is obviously a bit investment in time and resources but it will pay off IMO.

But I really can’t see even with the 5 points mentioned above (which are probably all valuable pain points for you) why this should be a first-party support for Meteor when the number of current and potential users will be small (not even talking about the market for such apps).

Forget a hype train.

I have a need to make a desktop app. If you don’t have that need, maybe start your own thread. But please don’t come here telling me that my needs aren’t trendy enough. I’m here to see who else has those needs, and if Meteor sees a value in extending their cross platform builds to desktop, to become a true deploy anywhere solution.


Meteor supports Cordova, Electron is akin to that. PWAs don’t supply nearly the same solution as Electron apps, which have access to a number of desktop APIs that a webapp can’t use.

VSCode, Slack, Skype, Discord, WhatsApp, Atom, they all use Electron. It provides a compelling solution for those who want or need cross-platform desktop applications, and a number of billion dollar companies are using it.

Data intensive has many meanings - doing work on the server side is a viable solution in some cases, not so in ours. Our users often wan’t to look at multiple intersecting sets of the same data (statistics for person X across period Y, then statistics for person X + … across period […, Y, …]) - also, the granularity they need really precludes us from doing much aggregation on the server, all the data really needs to be sent to the client.

Perhaps consider for a moment that I have considered moving to the cloud - and indeed utilise many of the same components you probably do. Mongo, AWS spot instances, lambda, etc. Some things simply require significant data be sent to the client, unless you really want to do all the client side rendering on the server, which has it’s own drawbacks and limitations.

Also, perhaps we’re talking about different things, but my guess is that many people on this forum (the one for a webapp technology…) who want electron are already using a webapp, and in fact want to move in the other direction, for numerous reasons.

Regarding the resource consumption of those apps you point to - ignoring for a moment the scale of the companies you’re talking about: microsoft, spotify and slack all service millions of users - I have not found the resource consumption higher than an equivalent chrome tab running the same software. Of course, if you are comparing electron to a native custom built and optimized app, then of course electron will lose.

All this being said - I don’t necessarily think that Meteor should fully support electron. What I want to see instead is them refactor their build process to allow for electron and cordova support to be added separately, in a customizable way. Recently I tried changing the cordova built to use the modern web bundle rather than legacy, and it was a nightmare, I had to abandon it - what seems like it should be a simple flag is not at all.

For what it’s worth I did end up producing a desktop app using Meteor + Electron. It’s listed in the Mac App Store and has received sales. If desktop apps are not a technology of the current era, then the actual people who demonstrate that they are willing to pay for desktop apps would beg to differ. Nothing outlives it’s usefulness. The Mac App Store exists because commerce is happening on it. If it would be of a bygone era then it would go the way of iTunes.

As for the process itself… It wasn’t easy. Went back and forth with different versions of Electron, bundled and un-bundled node and mongo, and sand boxing the app wasn’t entirely trivial, but all no of this can be made easier with better documentation and tooling.


I would also love to be able to publish an Electron-based desktop app for my Meteor app. I’ve already added PWA support with a service worker and everything, but the fact is, many of my users simply want a standalone app so they don’t have to access the app through their browser. PWAs don’t cut it.

I tried meteor-desktop in the past and got it semi-working, and from looking at the repo it looks like folks are still working on it in various forks and branches, though I don’t know how close it is to being brought up to date and working.

@larry, if you have any hints to share about what ended up working for you, I’m sure it would help the effort…

@banjerluke this month they updated the main branch. Prior to this, I have an issue on their github where I detail what ended up working for me.

meteor-desktop works fine if you follow the docs, we’ve been releasing regularly for over a year now. It took a little while to get the full pre-release and release build pipeline in place for Windows, macOS and Linux w/code signing and there were a few gotchas we encountered that were specific to our build and some native c++ libraries we were using but once it’s set up you can just forget about it. They’ve recently updated to Electron 6 (from Electron 2) and decoupled the various internal components for building and packaging, so it’s in the best state it’s ever been now. I’d recommend giving it another shot.


+, this really could be important for the future of meteor. We use meteor-desktop, but there really a bunch of issues like lack of support for last versions. Our fork located here, we resolved a bunch of current issues, but any help is very appreciated

There’s been a good amount of recent development in the main branch, if you have improvements open PRs to get them back in :slightly_smiling_face:

We will do so soon, just haven’t enough. time recently :slight_smile:
When we only started our fork repo was a bit staled, with some open (useful) PRs, without any response from wojtkowiak, so we did a bit of incompatible changes. Looks like we need now to make a branch which we will be able to apply to master when opening PR back to parent repo in order to provide compatibility

We use meteor-desktop as well for the reasons mentioned by others already. It is a concern to be so reliant on a package that’s no longer heavily maintained.

On a side note I notice that Microsoft has released support for React Native on Windows and MacOS. With Meteor now providing first class support for react-native, perhaps this is the way forward long term…

Have you thought about using PWA to deliver the app to the desktop? I know it’s not for every use case, but for some use cases it might be good enough.

I’ve been seeing over & over @alawi’s mention of PWAs and somehow I was not aware of their desktop/chrome integration :exploding_head: I just made the Meteor Forum a PWA (looks so nice as an app, see image below), not just another tab in my browser anymore.

Looks like the PWA desktop might not give you everything that an Electron app does, but wow, I’m impressed. Not sure how I missed this, but I’m even more excited to make my Vue + Meteor app PWA compatible now!

I had realized this for Mobile, but not Desktop… pretty nice & easier alternatives to Cordova and Electron. Although, I do support keeping strong Cordova support & Electron support growing. I do think many mature apps depend on these.

For me the biggest draw to desktop & mobile apps is just the user having an easy icon to click on and recognize when they use the app daily. This is the BIGGEST factor for users returning daily to interact with an app.

For so many years I’ve wondered why this was not easier to do. Feels like 10 yrs ago now, but I remember using this for OSX back in the day, but it was not really a good solution.

It would be great to add PWA details in the Meteor docs. I have noticed Vue’s CLI & Gatsby have clear PWA docs.

Thanks to @jkuester for this Meteor PWA guide, I now finally get why the Meteor core team should prioritize making this more obvious, aka good docs, and maybe an atmosphere package or a skeleton for a PWA app that would configure a package like the Vue CLI does.

@filipenevola hoping you could take a quick look at this :sunglasses:and share with the Meteor core team! :tada:


@omega a great alternative to getting this into core is getting it into the Meteor-Community-Packages org, so that others can help maintain and release it. Others are willing to help keep it up to date as many ppl have businesses relying on this package. Please see this issue

1 Like

So how does the package get there? As much as I understand it’s no longer supported by the original author.

No responses on bugs/issues either. We went along the path due to security and data privacy reasons and are now facing issues as the automatic update doesn’t work and is leaving our customer being stuck with bugs that are long solved (see Cordova force update on stuck clients due hash mismatch)

We’ve been using electron-updater to update our meteor-desktop electron from electron 2 to electron 9 over the course of a couple years and have never had any issues, so it’s not an issue of meteor-desktop.

If the maintainer abandons an open source project then the path forward is fork it into the Meteor-Community-Packages org. It would just need to use a different npm package name like “meteor-desktop-community” or something

1 Like

We’re a two people company and still haven’t launched, so unfortunately we’re not able to maintain this package

Are you guys able to do this or how can we find a volunteer who takes it over?