Hi,
My client have informed me that the app I made for them using Meteor is not working on some mobile browsers, such as Firefox on iphone, ipad and linux (does however work on Firefox on my Mac). Then on my iphone it does work on Safari, but not Opera or Firefox; making it very hard to debug…
App is here: www.skogen.pm (hope that we won’t crash it lol 
)
Any ideas why?? I’m in a forced digital nomad state flying in a couple of days, so not so equipped to debug this unfortunately…
Thanks!
My guess is that your app is using some browser API that is not implemented on all platforms and/or in all browsers, or in some combination thereof.
I do check every single API’s compatibility status on https://developer.mozilla.org/ before using it.
E.g. if you check the browser compatibility section of the API Intl on MDN, you get to see that there are gaps—meaning that you can’t rely on the API being universally implemented.
In such cases you’ll have to protect your app from crashing by either using a polyfill, if available, or wrap the API so that you can fall back to something meaningful.
Another great source for checking browser support is “Can I use”:
“Can I use” provides up-to-date browser support tables for support of front-end web technologies on desktop and mobile web browsers.
The console shows service worker registered. Maybe not every mobile browser supports Service Workers?
I looked around in your app’s code a little for a possible error why it is “not working” sometimes. The only plausible suspect I found so far is the serviceWorker, which is according to MDN still “experimental”, albeit the crashes could only be partially explained with the availability data on caniuse: https://caniuse.com/?search=serviceWorker
The serviceWorker API is only available in Safari on iOS since 11.3 (Mar. 29 2018), so using this API may break the application on devices running with older Safari versions.
As for Opera Mini, serviceWorkers are not supported at all.
Opera for Android: it is not supposed to work until version 59 on Jun 30, 2020, meaning there can be lots of devices out there with an older version.
According to the charts, however, it should work flawlessly with Firefox on all platforms.
On another note, maybe you should consider configuring eslint for your app. I’ve turned this on on my machine for your project, and it seems that there is a massive amount of missing props validation, missing imports and unused variables.
Also in some cases I can’t seem to find the invocation ...ready() in subscriptions on the client prior to fetching the corresponding collections’ content. I didn’t check in all details, I also didn’t debug your application, but this may cause unexpected results.
Last but not least, your app does very little with respect to error handling/logging. It basically just sends error messages to the browser console, where they are immensely useful during development, not so much however in production. Using a remote error logging service would generally be very helpful in finding out what exactly fails in your app.
Thanks a lot for the great review and very valuable points!
Yes, I need to implement all the good things you mentioned, least for my sanity…
Oh yes! It works! It was all due to the service worker. Now it works both firefox and opera touch on ios. I’m yet to confirm the linux case though…
Thanks a lot for the feedback all!
However, it’d be great to find out the best way to make this work as a PWA and not get it to crash on some non-supported browsers…
Actually it’s in my todo list! Do you have any recommendations for a remote logger? I’m even thinking of creating a mongo collection just for the errors and building my own logger there… Bad idea?
All right, that’s great news
I think the solution could be as easy as checking whether Navigator.serviceWorker is defined. If it isn’t, just don’t invoke it. The PWA functionality wouldn’t have worked anyway in those browsers and on the affected platforms.
Please have a look at this lines. All service workers installations should be conditioned by the browser support of service workers:
I don’t have a recommendation for a remote logger. There are very many out there, both as a paid service and free. I have built my own solution as I have my own broad concept of how errors need to be dealt with, which is more than just sending messages and a stacktrace. But it’s definitely much better to have something simple than having nothing at all!
As a side note, stack traces of production code are not so useful when using the Meteor package standard-minifier-js, because the function names, class and method names get minified too. I think the zodern/standard-minifier-js package solves that problem.
Great, thank you very much for your response.
Actually it was as easy as you both suggested. Checking for the serviceWorker within the navigator was sufficient to conditionally register the service worker.
Like:
const swSupported = 'serviceWorker' in navigator;
if (!swSupported) {
return;
}