Meteor: [IOS] [1.3] White Screen Of Death For Specific Bundle ID's On Resume

[pmwisdom]

This is kind of a continuation of https://github.com/meteor/meteor/issues/6471. I felt like I needed to re-open as a new issue since this seems to be a bit different from the original.

I'm getting a white screen on resume (app foreground -> lock screen -> wait a few seconds -> unlock screen). It only happens on my production bundle ID, and it only happens if I have a numerical lock screen enabled. This did not happen before 1.3 with UIWebView.

If I build the application with the production bundle ID and change it in xcode before I build the application functions as it should. To re-iterate, if I change the bundle ID to _anything_ else other than my production bundle ID, it works normally.

To make things worse, if I build a _completely_ fresh application and add a mobile config with the offending bundle ID it still does not function correctly. I've even had other developers attempt to use my bundle ID, all with the same results.

I'm currently talking to an apple tech but any information of why this could be happening would be useful from anyone else that might be experiencing this problem. Maybe @martijnwalraven has some input of possible causes.

[martijnwalraven]

Hmmm, this sounds really mysterious! The only thing that comes to mind is that maybe certain features have only been enabled for the production bundle ID, like background activity or push notifications. And these could somehow be causing the issues.

[pmwisdom]

I would have thought that too, but I can create a new fresh meteor project, not touch anything except for add a mobile config, build it for ios, and once I enter the bad bundle ID into xCode, it will start white screening immediately

[martijnwalraven]

Does the bundle ID contain any unusual characters?

[pmwisdom]

Nope, Always characters [a-z] in the form of io.appname.app.

[pmwisdom]

So I got a "final" response from apple regarding this. I sent them a test xcode project, aka a completely fresh meteor project, built for IOS, and they couldn't give me too many details about what was happening.

Some excerpts from the conversation:

"I’ve done some more testing, and have a few more details to share. First off,
the underlying problem is that WebKit is crashing. If you use Xcode to watch
the console log on your device, you can see the crash occur and the log being
written out."

"The best guess I’ve had is that the crash in the main app is corrupting
something in WKWebView stored data, and that damage is persisting even when
the app is deleted."

He goes on to recommend that I reload the web view every time the app is relaunched from BG.

I'm not sure if you'd be willing to run a test project, but I have one set up which clearly shows the issue, although this may be an apple bug, so it might not have anything to do with Meteor.

[martijnwalraven]

Hmmm, this does sound like you've hit a rather obscure bug in WKWebView! If you could share a test project, I can always have a look at it, but I probably won't be able to do much about it.

[pmwisdom]

I've found some others with this issue on my search for resolve!
No need for the repo now, apple has basically said its a bug in the WebView.

Heres an issue along the same lines on the plugin page:
https://github.com/Telerik-Verified-Plugins/WKWebView/issues/41

And here is one on apache:
https://issues.apache.org/jira/browse/CB-9888

In that first thread they actually forked it and have a working "crash detection" that refreshes the web view if they don't see a wkwebview title available.

https://github.com/IjzerenHein/WKWebView

I'm guessing theres no way to pop that fork into my meteor project huh?

[martijnwalraven]

No, the Telerik plugin is an older workaround only needed when Cordova did not have official support for WKWebView. You would have to add the same 'crash detection' to the official plugin.

[pmwisdom]

Sorry, what I meant was, can I swap out the WKWebview plugin in meteor without forking meteor itself?

Kind of like how crosswalk is dealt with on android.

[martijnwalraven]

Yeah, you should be able to fork cordova-plugin-wkwebview-engine and use your version instead of the one Meteor adds by default.

[adamgins]

Hi wondering if any progress. I think I have same issue. Sporadically I get the white screen of death on my production app.

This has only happened since upgrading to 1.3

[erkkimon]

I'm also facing the very same problem.

[adamgins]

Yep I have for it about five or six times in the last week at random times.

[erkkimon]

I was able to snare some whitescreen-related output in my XCode. Please see it if it provides any useful information.

[adamgins]

Could it be the mismatch of your Cordova plugins?

Sent from my iPhone

On 3 Jun 2016, at 8:01 PM, Tom Himanen [email protected] wrote:

I was able to snare some whitescreen-related output in my XCode. Please see it if it provides any useful information.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[erkkimon]

As far as I know Meteor 1.3. should take care of Cordova-related version conflicts by not downloading mismatched version of software from the server to the client. So could this white screen of death be caused by Meteor failing to handle new, mismatching versions appropriately?

[erkkimon]

@pmwisdom: Did you fork cordova-plugin-wkwebview-engine, and was it a good workaround. If yes, I'm in desperate need of your fork. ;)

@martijnwalraven: Any clue, will this be fixed in next Meteor release officially, if there's a fix/workaround available?

[pmwisdom]

@erkkimon I never got around to it, but the proposed crash detection would be simple to integrate into Meteor's WKWebView. Take a look here : https://github.com/Telerik-Verified-Plugins/WKWebView/blob/master/src/ios/MyMainViewController.m#L145. I think you could actually improve upon that by possibly using a meta tag instead of title, which may change.

@adamgins I've been able to reproduce this with an essentially empty project freshly created via meteor create so it shouldn't have anything to do with plugin mismatch.

[adamgins]

@pmwisdom
hi folks, wondering if there is any workaround... my users are getting angry

[pmwisdom]

@adamgins The aforementioned fix that was proposed in that telerik plugin is the only solution for now until something official gets pushed. It doesn't seem like it will take any kind of priority unless many other people report the problem.

[adamgins]

@pmwisdom thanks... sorry if dumb question but does not seem like an easy way we can leverage that fix without forking the whole of Meteor, right? (ie as Telerik is off old code, if I am understand @martijnwalraven 's comment).

@martijnwalraven surely other folk must be getting this?

[martijnwalraven]

Note that this is not a Meteor-specific issue. Meteor does not include its own WKWebView plugin, so this would have to be fixed downstream, in Cordova. I would advise you to open an issue on the Cordova JIRA with as much information about the problem as possible, including your communication with Apple support.

[martijnwalraven]

This is the plugin that would need to be forked if you wanted to incorporate the Telerik workaround people have mentioned.

[tomitbe]

same issue: app stucks often on resume (without closing the app really before), sometimes I have a white screen, sometimes the app is not responding for 20-30 seconds and then suddenly works again... (it always works fine when I close the app and re-open it)
wondering if there is any workaround... my users are getting angry

[axelauvinen]

There seems to be a fix from apache to the underlying component. When is this implemented to Meteor?

[martijnwalraven]

@axelauvinen: That looks like good news! As soon as the Cordova team releases a new version of cordova-plugin-wkwebview-engine we'll be able to update our dependency.

In the meantime, you should be able to install the updated plugin from Git (not tested):

meteor add cordova:cordova-plugin-wkwebview-engine@https://github.com/apache/cordova-plugin-wkwebview-engine.git#815ed0741b9ae30b343d6429bd8ff2ad37ec5790

[erkkimon]

Niceness!

[Wade-BuildOtto]

I have added the recover plugin, Thank you this helps recover some of the times I still get a stalled splash screen which might be something else.

It sucks as I am using Geofences which don't trigger if the app is crashed out.

I am surprised that apple would release with such a bug in their process.

Again thanks for the fix.

[adamgins]

@martijnwalraven just checking, was this updated in a recent Meteor build? If not, can you please confirm exact steps - eg do I need to remove the. Add or is it effectively just setting the version number on the workaround plugin?

Also wondering if others have seen success with this approach?

Thanks all. Hopefully this workaround will fix it for me.

Update: I have added it and my app seems to work but how do I tell that it's working?

I see this in meteor list

[Wade-BuildOtto]

This issue has basically killed 9 months of work. Its great that the app can recover when it's crashed on re-open, but that doesn't help external components like Geofence from triggering code, the only thing I can think to do is to scale all the way back 1.2.1

[pmwisdom]

I'm just going to put this here, as it may, or may not help some people. Ionic just released their version of wkwebview if anyone wants to try that. I haven't done any research into whether or not it will fix anything, but it may be worth a shot!

https://github.com/driftyco/cordova-plugin-wkwebview-engine

[Wade-BuildOtto]

I find that it doesn't always recover, I have to force close it and restart the app, which is a poor user experience. I am hoping someone on one of these companies to attempting to fix the issues. [Apple, Cordova, Meteor] someone help.

[adamgins]

The fix above by Martin has fixed this issue for me. Sorry on phone and can't reference that comment here

[tamino-martinius]

Same issue as @Wade-BuildOtto - the fix reduces the white screens a lot, but it still happens.
Any chance to use meteor 1.3+ with UIWebView?

[lpender]

Is there perhaps a workaround by careful choice of build id?

[Wade-BuildOtto]

anyone know if WkWebview got fixed with IOS 10 I haven't been able to test yet

[Endtry]

Hello all,

I am experiencing similar issue with Angular2 Meteor project I have developed. The app works great on development but when deploy to TestFlight, a white screen appear at random time. I have been investigating this issue for weeks now and I have yet to find a viable solution. The cordova-plugin-wkwebview-engine seems to do the trick (reloads the app on resume I'm seeing) but it does not work for my particular implementation of Meteor. I am using Meteor to build an offline/online hybrid app and reloading the app will cause loss data while offline. Is there a viable workaround for this bug yet? Thanks everyone.

[anymos]

Hi everyone, stupid question but how to find the cordova-plugin-wkwebview-engine version that meteor is using ?

[stevenhornung]

I have been experiencing the same "white screen of death" issue for several weeks now in my pre-production app. I was getting the white screen on occasional resumes but mainly on app updates and just about every time on first app installs. I'd install the app and it would be a blank white screen. I'd then close the app out and re-open and it would be fixed.

I tried the cordova-plugin-wkwebview-engine plugin but that did not solve my problem. I ended up adding a fairly hacky solution where in my main layout file where I defined the head tag, I added a script tag that checked for a Session variable flag that was set in Meteor.startup, if it wasn't defined after so many seconds, I'd reload the app myself (and show/hide the splash screen so it wasn't apparent to the user). This worked OK but wasn't ideal.

Well, I've solved my problem (which may not apply directly to other's issues but I kept coming back to this GitHub issue for solutions). If you use meteor_settings, make sure you add the --mobile-settings argument to your meteor build command. This gives the initial settings for the app although the server settings are still used once connected (to my understanding). I think the problem was that I was attempting to use a public setting before the server connection had been established so there was no Meteor.settings properties and was throwing a silent error on initial install and causing the white screen issue.

I hope this helps someone else. I've spent several days coming back to this problem over the past month so it was nice to find a real solution that wasn't an ugly hack.

[anymos]

Hi there, in case it s useful for someone

To get the actual version, find you meteor version, then head to github to the release page (https://github.com/meteor/meteor/releases/tag/release%2FMETEOR%401.3.5.1)

Then in packages/webapp/package.js, you can find the part :

Cordova.depends({
'cordova-plugin-whitelist': '1.2.1',
'cordova-plugin-wkwebview-engine': '1.0.2',
'cordova-plugin-meteor-webapp': '1.3.0'
});

[anymos]

@martijnwalraven, I might be wrong, but it seems like the version included in the meteor webapp package at the moment, is 1.0.2, and It's sounds like the latests version of cordova-plugin-wkwebview-engine (1.0.3) is including the workaround presented by @Wade-BuildOtto

Would you mind to update the webapp meteor package dependency to include this latest version, as you were proposing it before ?

That way, we could make sure that this workaround is really fixing the white screen of death, as more people will use it inside meteor ?

Thank you in advance

On my side I have copy this package into my app to test it, I will psot here my finding, hopefully it should solve the white screen of death issue

[adamgins]

@martijnwalraven I am trying to create a working build of my project with Meteor 1.4.1.1 do I still need meteor add cordova:cordova-plugin-wkwebview-engine@https://github.com/apache/cordova-plugin-wkwebview-engine.git#815ed0741b9ae30b343d6429bd8ff2ad37ec5790 or is the issue fixed in 1.4?

[martijnwalraven]

The default cordova-plugin-wkwebview-engine version has not been updated in 1.4 (although it may be for 1.4.2). The latest version of the plugin is 1.1.0, so you should be able to install it with meteor add cordova:[email protected].

[adamgins]

Thanks Martin

Sent from my iPhone

On 3 Oct. 2016, at 9:31 pm, Martijn Walraven [email protected] wrote:

The default cordova-plugin-wkwebview-engine version has not been updated in 1.4 (although it may be for 1.4.2). The latest version of the plugin is 1.1.0, so you should be able to install it with meteor add cordova:[email protected].

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[adamgins]

@martijnwalraven since updating to release/[email protected] I have seen the "white screen"/crash/hang appear again.

It's sporadic and hard to replicate.

Any ideas pls?

[adamgins]

Hi I have seen this again a couple of times recently.

Any one else?

@martijnwalraven wondering if others are experiencing this?

I still have [email protected] as my plugin

Should I reinstall meteor add cordova:cordova-plugin-wkwebview-engine@https://github.com/apache/cordova-plugin-wkwebview-engine.git#815ed0741b9ae30b343d6429bd8ff2ad37ec5790 ?

[Endtry]

Hello,

Has anyone find a solution for this bug yet? I still have issues with my app crashing at random due to memory issue. The cordova-plugin-wkwebview-engine (cordova-plugin-wkwebview-engine@https://github.com/apache/cordova-plugin-wkwebview-engine/tarball/81e889854a5ca8b7bd620f91e945998a280305c3x
) appear to work as the app appear to be more responsive and faster than without the plugin. However, this issue with the app crashing at random instance is unacceptable for my client. I am working with angular2 with meteor 1.4.2 and meteor-ios 1.4.x. I read that it may help if I use https://github.com/Telerik-Verified-Plugins but it only work with meteor-ios version < 1.4.

Help is appreciated. Thanks!

[anymos]

Unfortunatly the issue is still there under meteor 1.4.2.3, so the fix provided by [email protected] is not working.

Due to the difficulty to reproduce the bug to investigate it s a pity but the only solution I found is to desactivate wkwebview and use the previous webvieux in ios.

Is some one can confirm that it is not linked to meteor and that we should probably try to involve cordova team on this ?

[Endtry]

@anymos when you say, "use the previous webview" do you mean the UIWebView? I am having issues with the new WKWebView like you and to this point, I am without a fix for the white screen of death.

This is what I found:

This plugin (https://github.com/Telerik-Verified-Plugins) only works for Cordova-iOS 3.9.2 and below. So to use this plugin, I would need to revert back to older version of Meteor, Cordova-iOS and Node?

The "official" version of the WKWebView (https://github.com/apache/cordova-plugin-wkwebview-engine) works with Cordova-iOS > 3.9.2 but I see that it is not stable because I am getting the white screen of death due to memory issues while using the app. This is the output in XCode when the app crash:

WK: Unable to acquire assertion for process 0

[INFO] GCDWebServer stopped

Does anyone know which Cordova version and Meteor version I need for Meteor to generate a Cordova-iOS build using v3.9.2? I am currently on Cordova 6.4.0, Meteor 1.4.2.3 and Cordova-iOS version 4.2.1.

Anyone having any luck with this or should we revert back to the UIWevView (which is extremely slow)?

[grundmanise]

Any update on this issue? I also get a blank screen / other times - infinite splash screen after my app was some time in the background...

[abernix]

The early-December release notes for [email protected] (the Cordova WkWebView plugin) indicate that [CB-11997] webView should reload when a crash occurs was fixed. This is identified as "Add crash recovery for iOS 8" and the issue directly refers to a "white screen" error being fixed.

For those experiencing this problem, please try using the 1.1.1 version by adding it to your Meteor project using the following command:

meteor add cordova:[email protected]

[grundmanise]

@abernix thanks, I've tried to add [email protected] but still having the same issues... white (blank) screen or infinite splash screen after my app was some time in the background.

[Textras]

This bug just to clarify, I don't think has anything to do with Meteor. It appears to be because the WKwebview runs as a separate process. We've switched back and forth between UIWebview and WKWebview many times. The flash on app resume is only experienced with WK. We had serious mem leak issues with WKWebView so we switched back and UI had fixed a tremendous amount of issues, BUT once the mem leak issues were repaired there was no reason to stick with UIWebview. However, this issue is certainly a result of the separate WK process.

A great quote example from pmwisdom, that sums it up nicely.

So the reason behind this bug is pretty simple, WKWebView runs on its OWN separate process, while UI Webview runs on the same process as your application, so if the OS tries to kill the webview, it doesn't actually kill your application just the webview portion, resulting in the white screen. At least, this is my understanding.

[anymos]

Agreed nothing too much related to meter except maybe for the version and still there are workaround.

I found a super quick way to switch back to the previous UIVIEW

App.setPreference('CordovaWebViewEngine', 'CDVUIWebViewEngine');

in case it can be usefull

[Wade-BuildOtto]

how ever if you are using something that calls back to the app, like
geofence once the call returns to the app it is dead and is unable to
process the request, so any features that work like this are broken.

On Sun, Jan 8, 2017 at 10:38 PM, Raphael [e-mail] wrote:

Agreed nothing too much related to meter except maybe for the version and
still there are workaround.

I found a super quick way to switch back to the previous UIVIEW

App.setPreference('CordovaWebViewEngine', 'CDVUIWebViewEngine');

in case it can be usefull

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/meteor/meteor/issues/7018#issuecomment-271214048, or mute
the thread
https://github.com/notifications/unsubscribe-auth/APG2r4JDiI-BDMbq4r4m7ix_89okC9Tiks5rQcfSgaJpZM4IaoZz
.

[Endtry]

@Textras Can you share what you did to resolve the memory leak?
@anymos Switching back to UIWebView works but is extremely slow on meteor/angular2. I have an app with many input text and typing is very slow to say the least. Is there a way use UIWebView and fix the performance issues?

[tamino-martinius]

@anymos thanks for your idea - will try this for our App.

Is there an way to use WKWebView without running it in an separate process?

Updating WKWebView as mentioned above reduced the problem a lot for us, but we are still getting support calls based on this Problem.

[Textras]

@Endtry I wish it was that simple. Your mem leaks would be specific to your application, as ours were to us.

The issues are based on all manner of things, and our fixes likely won't help you at all. Have you tried looking into your garbage collection process in the timeline? Also doing some profiling and breaking it down with heap analysis is a good way to target specific trouble points. Def if you are using a single page application you will probably find that slow typing clears up when you clean the mem. Create a func to quickly dump in store mem and see if the typing clears up. If it helps build around that.

[Textras]

@Wade-BuildOtto great point

[macrozone]

Still occures with cordova:[email protected] on ios 10.

Anything we can do to recover from these crashes? @stevenhornung can you share some code of your workaround?

[macrozone]

It seems to me that when this problem happens, the local server that meteor starts on the cordova device has been killed as well. I managed to have this on a development build and used safari to check whats going on on the webivew. These are my findings:

• body is empty, but javascript code is still there (e.g. Meteor). I can change a route with FlowRouter.go("/") and body gets remounted
• loading files from public directory does no longer work (which are served by the local server). They fail with: Failed to load resource: the server responded with a status of 403 (Forbidden)
• Doing a "soft-reload" from safari (cmd r), reloads nothing, it fails with "Failed to load resource: the server responded with a status of 403 (Forbidden)"
• killing the app and restarting it is the only way to recover from this.

Is there any way to further debug this? It's a crucial Problem that we have on two apps and customer is very unsatisfied by this.

[abernix]

@macrozone I'm certainly curious if this is in any way related to https://github.com/meteor/cordova-plugin-meteor-webapp/issues/24? Any chance of you investigating?

[macrozone]

@abernix good catch. I will try to see if I can investigate in this.

there is one fact that might be related to this: we use this plugin: https://github.com/transistorsoft/cordova-background-geolocation-lt

this can track the locations of the user and emits events on new location. This works even if the app is in the background, because you get some time to process this event.

Having said that, I did not observe these crashes while tracking (while the plugin is active), but when tracking has stopped and was in the background for some time.

[abernix]

@macrozone If you can accurately reproduce the problem, you could try applying the fix in https://github.com/meteor/cordova-plugin-meteor-webapp/pull/25. You can fork it, apply the fix and use your own version of the package by using something similar to the suggestion in this comment above.

[macrozone]

@abernix awesome! will try that.

[awwx]

@macrozone I'm certainly curious if this is in any way related to meteor/cordova-plugin-meteor-webapp#24? Any chance of you investigating?

I'd be surprised if these were related. (Though I could be wrong). The symptom of meteor/cordova-plugin-meteor-webapp#24 is that if you start an iOS app in the background, you'll get the Meteor startup screen logo but the app will hang at that point because it's unable to load its assets (because the local web server is deliberately turned off when the app is in the background). Nothing to do with a 403 Forbidden error, you don't get a white screen of death (the webview is running fine, it simply doesn't have a server to connect to), and it's not random.

[grundmanise]

@macrozone , @awwx I was also using meteor/cordova-plugin-meteor-webapp#25 with https://github.com/transistorsoft/cordova-background-geolocation-lt : it helped me with the launching of the background geolocation tracking when the app was completely killed, but the white screen issue still happens when the app hangs for some time in the bg (not killed).

Reference: https://github.com/meteor/meteor/issues/8324

[macrozone]

@grundmanise, @awwx

thx for your info, that is disapointing to hear.

Anything else we can try out?

[macrozone]

@abernix I applied the suggested patch and did not had crashes yet, but after some resumes, the local server does not respond anymore, so assets can't be loaded anymore. So i now have this issue: https://github.com/meteor/meteor/issues/8324

Edit: crashes still happen sometimes

[Wade-BuildOtto]

A year on, and this is still an issue, my app never loads on the first go and occasionally doesn't recover on reload, I always have to crash it out to load up. its just disappointing that mobile development just doesn't get the love I wish it would.

[stevenhornung]

@macrozone the rescue code that I used as a hacky-fix workaround for my issue (which, again, was solved correctly - see my comment above) involved setting a session variable in the client at Meteor startup indicating the app had come alive. I then had some script code in my index.html file's head section that setup a hard-coded timeout function that would do a hard reload of the app if that session variable was not set. A hard reload was what my app needed to start up correctly after first install. Please note that I highly advise against using this code. It embodies all that is "hacky solution" haha. The rescue code looked a little like:

<script type="text/javascript">   
  // Rescue code in the event of app failure to start   
  if (navigator.splashscreen != null) {   
    navigator.splashscreen.show();    
  }   
  setTimeout(function() {   
    var appStarted;   
    appStarted = Session.get('global.started');   
    if (appStarted) {   
      if (navigator.splashscreen != null) {   
        navigator.splashscreen.hide();    
      }   
    } else {    
      window.location.reload();   
    }   
    return    
  }, 6000);   
</script>

The head section was the only place that I was able to run arbitrary code in the event of an app startup failure. The 6s timeout came from the launch-screen package which uses a hard-coded 6s when hiding the splash screen if the body hasn't been rendered yet.

Basically, if the app opens correctly, all this does is show the splash screen (which should already be shown) then ensures it is hidden after 6s (which, again, should already have happened when the body is rendered). If the app fails to open correctly, however, this code will reload the app after 6s.

In my case, at the time, the app showed the white screen of death after initial install. When I closed out the app and re-opened it, the app displayed fine. It also displayed correctly every other time it was opened. The above code helped my app display correctly after first install at a time when my app needed to be demoed to some important clients - forcing the user to restart the app isn't a great first impression ;)

Again, I highly recommend that you continue to work to find the real root cause of your issue. This code is hacky and doesn't work that well and should never find its way into real code but posting since someone requested.

From what I've found, if you're getting a white screen when you open the app, it's likely that some dependency is being invoked that is not at the client (yet). Perhaps create a new blank app and start adding pieces of your current app to it until it breaks - tedious but sounds like you're running out of options. Mine was a silly issue - my Cordova build required simply passing --mobile-settings to the meteor build command. Good luck!

[rsylvian]

Any news on this? Huge issue on my app ... 😭

[macrozone]

@stevenhornung : ok I see, that seems not to be an appropriate workaround. I also found out, that reloading the webview does not fix the problem in my case, so window.location.reload(); is not a solution.

@abernix: Would there be any support from mdg on this case? If so I would like to provide a minimal reproduction with that specific plugin. I have two customers suffering from this issue and I really can't solve it myself.

@MyBoon: can you describe your problem more presicly? do you use any cordova-plugin?

[mikkelsjolin]

I have the same issue in my app - It showed up after I implemented "cordova-background-geolocation-lt" by Transistorsoft, which is booting my app in the background.

[rsylvian]

@macrozone:

For me, the issue appears once you put the app in background for a long period of time (will say at least 30+ minutes) and want to go back on it. I either get the White Screen Of Death or just the splash screen forever.

My cordova plugins are:

[email protected]
[email protected]
[email protected]
cordova-plugin-ios-no-export-compliance@https://github.com/dvolland/cordova-plugin-ios-no-export-compliance.git#f34d45839e7fcd3bd1556f09ff808b6c684c301c
[email protected]
[email protected]

Like @mikkelsjolin, I also have installed background location using this plugin.

[macrozone]

So it seems to be related to the local webserver and plugins that start or reactivate the app in the background.

applying the fix https://github.com/meteor/cordova-plugin-meteor-webapp/pull/25

helps launching the app in the background, but it also leaves the app in a state where local assets cannot be loaded anymore. White screen of death still happen after the app has been some time in the background idle.

It's a mess and it's really threatening our projects. At this point I can no longer recommend to use meteor for cordova apps. It's just not stable.

I'll try to create a reproduction today, an empty app with a geolocation plugin installed. Without the help from mdg, this issue is impossible to fix. We need someone that knows the cordova integration well.

Edit: we are also willing to pay a bounty to get this fixed.

[Wade-BuildOtto]

I have talked to Meteor team member, the unfortunately don't do consulting or paid work to fix a specific OSS problem, We willing pay for someone to fix or create a plugin.

I am thinking we're if the web server became unresponsive to try and reload on upon reloading the app, it might take an extra second but at least it might recover.

I have been watching this issue for more than a year. It definitely seems to be something around geofences / Location services. This seems to have a limited effect to only those projects using this service, which why it seems to not be a widespread issue.

We'll add to the pool of the bounty if someone can fix this issue.

[Wade-BuildOtto]

Just thinking about it, the MDG geolocation plugin and google-maps plugin I don't think are the issue, I was using the cowbell/cordova-plugin-geofence but when I updated Xcode and the project need to move to Swift 3.0 I had to remove the plugin until I could get it updated.

It worked fine for months until I reintroduced the plugin updated to swift 3.

Feels like it might be something around the call between the plugin pushing the call to the web server is maybe stalling it out.

on top of this, for IOS i skipped using the geo transaction all together because of this issue an move to calling an API directly from Swift, which it now works great for IOS.

just some more thoughts out their.

[stevenhornung]

@macrozone you are correct, not an appropriate workaround at all :) but it put a bandaid on my issue for a week or so until I figured out the root cause of the issue.

@Wade-BuildOtto I'm using the geolocation plugin and am not experiencing this issue. Specifically, I'm using [email protected]

I did have an issue with iOS builds, XCode and the app loading correctly for a brief period after a certain Meteor upgrade (I do not remember the version that caused this). The issue was resolved by installing the webapp cordova plugin, I believe. Specifically [email protected].

Are you using the --mobile-settings option when running meteor build to obtain your iOS build? Do you have any errors in the client (inspecting app via Safari dev tools)? My next guess at this point (since i'm using similar cordova plugins and not having this issue) is an undefined/unavailable variable being used on the client at client startup that causes the app to not start up correctly and give the white screen of death. Likely a race condition if it does not happen every time. This would be similar to my issue with not including --mobile-settings during build which caused a client setting to not be available on initial app open which, in turn, caused the white screen of death until the app was restarted (hence my hack above).

I'd love to try to help more if I can. I've had similar issues that caused me many headaches before figuring out. Is your project public that I could take a look at and try running to repro?

Best of luck figuring this thing out! Frustrating, I know, but a fix does exist.

[Wade-BuildOtto]

I am using mdg:geolocation but I think I might switch to the cordova plugin geolocation and try that, I will add in the mobile-settings though I don't have any that affect the app, I am just using it for galaxy's settings.

I will give this a try and see if it changes anything.

[macrozone]

@Wade-BuildOtto et.al: I created a new issue that should focus on problems related to geofencing events, because i think the initial issue here is not related to that:

https://github.com/meteor/meteor/issues/8763

Please help reproducing the crash by checking out the test-app

[Wade-BuildOtto]

I am calling this solved with https://github.com/meteor/cordova-plugin-meteor-webapp/pull/30

cordova-plugin-meteor-webapp@https://github.com/panter/cordova-plugin-meteor-webapp.git#7bb095ce393d17f662cc6bb596ce91acf743d17a

This has recovered that app every time, no issues same day, 1 day, and 2 days of termination the app opened every time,

[hwillson]

As mentioned in https://github.com/meteor/meteor/issues/7018#issuecomment-307888516, this issue should now be resolved. Thanks!

[macrozone]

@hwillson my pull request hasn't been merged yet, so its not resolved actually ;-)

[hwillson]

Oops, sorry @macrozone - I looked at the wrong PR. Re-opening - thanks!

[macrozone]

@hwillson @benjamn @abernix

https://github.com/meteor/cordova-plugin-meteor-webapp/ is still faulty (breaks when app is called in the background, and other problems)

I used my pr (https://github.com/meteor/cordova-plugin-meteor-webapp/pull/30) which worked properly for a while now. Unfortunatly, it has stopped to work with 1.6.1, because the manifest url has been changed...

It's time now to fix https://github.com/meteor/cordova-plugin-meteor-webapp/. It's not ok that meteor highlights the cordova integration as a feature, while having such big problems.

I don't want to rant, but i pushed for the prs in https://github.com/meteor/cordova-plugin-meteor-webapp/ for a while now, but nothing happend and this is really frustrating.

I will no check whether @KoenLav 's pr here https://github.com/meteor/cordova-plugin-meteor-webapp/pull/42 works with 1.6.1 and try to verify whether if it solves these problems described here.

I would love if you would attach the 1.6.1 label to this Issue here and that we can finally get this right here.

[hwillson]

Definitely frustrating @macrozone! We've been discussing Meteor's Cordova support a fair bit lately, and will have an approach nailed down to address these issues shortly. Your comments (and PR work) are definitely appreciated!

[KoenLav]

@hwillson good to hear!

Any idea of when soon is going to be?

We are considering migrating to React Native and are also making use of Meteor Desktop for the desktop version of our application. Any public debate on what MDG is currently considering would be appreciated.

While HTML5 might be filling the gaps at a rather quick pace, there is still need for native support for various functionalities (maybe it would be nice to outline the reasons for using Cordova over a HTML5 webapp somewhere).

[hwillson]

I don't have concrete timelines, but this issue thread (and outstanding Cordova issues as a whole) were discussed in a meeting with MDG today. Everyone agrees Meteor's current Cordova support needs some TLC, and that the cordova-plugin-meteor-webapp plugin needs to be fixed.

React Native is great, and could be an awesome direction for Meteor's mobile story to head in, but there are still some pretty significant issues that have to be dealt with first. See https://github.com/meteor/meteor/issues/8615 for a good breakdown of those issues.

[KoenLav]

We created a PoC with React Native where Meteor is simply loaded in a webview and the webview communicates with the native portion of the code.

If there is serious interest in developing towards this possibility I could dedicate some time towards creating a solution like this?

All it would require is a proper bridge between webview and native code, in my opinion, or am I missing something?

[macrozone]

@hwillson thx for your answer and good to see some awareness!

We have currently some apps with meteor / cordova, but newer apps tend to be in react-native, some with meteor backends (graphql), some without. Having meteor as backend even for a native app is cool, because you can easily extend your backend with some admin-"frontend", which is great in projects that start small and need to grow and adapt fast.

I think building a react-native app with the meteor build tool is not _that_ important, because create-react-native-app (with and without expo) do a good job and give a similar near-to-zero configuration development experience as meteor does.

While some argue that you should not do isomorphic apps (web + mobile + backend in same codebase), i still see some benefits and meteor could shine once more in that. E.g. there is a project that ports react-native back to web and also style-components have some experimental primitives that work both in web and in react-native.

But of course meteor is not react-only, so web/html and therefore cordova will still be a thing this year, so i am looking forward to hear more about that, alltough i would not do projects with cordova anymore that have main focus on native apps.

[alanning]

Just to follow up on this thread, was this issue resolved with @macrozone's work and can be closed or is it still outstanding?

[macrozone]

@alanning https://github.com/meteor/cordova-plugin-meteor-webapp version 1.6 includes all the changes and i did not observe these problems anymore (but i could not do a deep testing yet).

I would suggest to close it and open a new one if i would encounter a similar issue

[iwoj]

I can confirm that I'm getting the occasional white screen of death in Meteor 1.7.0.3 with cordova-plugin-meteor-webapp 1.6.0. This is a critical bug in my opinion. I'll have to port my application to React Native if it doesn't get resolved.

[macrozone]

@iwoj do you have something that awakes your app in the background like background geolocation / geofencing or so and does it happen on IOS? if no, [email protected] won't fix your issue anway.

can you reproduce it on debug? did you attach safari to inspect your app?

[iwoj]

I haven't been able to repro the errors in a few days. I'll post details if it starts happening again.

[macrozone]

it might be better to open up a new issue and providing some more context on it

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[filipenevola]

closing because it seems like nobody is able to reproduce anymore.