ESS Sync Failing on iOS until force quitting app

I’ve noticed that the iOS app will frequently not have up to date data when I open it. When that occurs I check the sync status under settings and it will say that it has not synced in something like 15 hours despite auto sync being enabled and me having a functioning high speed internet connection.

If I try pulling down on a list to force a sync that way (the most convenient way that doesn’t require me to constantly tap through settings to force a sync) the wheel will spin and never sync. Eventually the wheel will stop and the app will just kind of sit there with a stopped wheel at the top of the list and no sync occurring. If I force quit the app and open it then it immediately auto syncs and my data is up to date.

Obviously having to do that or tap into settings to force a sync every time I need to execute something is a huge pain. I haven’t been able to test all the angles on how to reproduce this (still don’t know if tapping through to settings to force a sync works when this occurs) but I will keep testing as I see it occur and update this post with details.


I’ve been tracking this throughout the day and the iOS app constantly fails to sync unless I force quit the app. If I go into the sync settings and manually force a normal sync it just sits and stalls on the “syncing” dialog and never finishes just like with the progress wheel does when I pull down on a list. So far the only way to reproduce it I’ve found is that it’s always taken more than ~10 minutes in the background before the sync starts to fail, and that it will always fail after ~2 hours in the background.

In the meantime while I wait for a response from a dev, I’ve noticed some other iOS bugs that I’m taking note of to report and they’ve given me some pause about how well iOS is supported for Everdo. Having a fully functional iOS app is crucial for me and I’m getting a little anxiety about whether or not this is really going to be the right platform for me, can any end users reading this speak to the general stability and bug status of the iOS app?

Hello! Sorry you are experiencing this issue. It hasn’t been reported before. I will try to look at it as soon as possible.

Thanks, let me know if you need anything from me to reproduce or isolate it. This is my only iOS device that’s functional at the moment but I have an iPad that I’m almost done repairing so I’ll be able to test it there within a day or two to see if I can reproduce it on the same account.

Update: My iPad is now repaired and I can confirm that this issue appears on it as well. It’s actually a bit worse on the iPad, so far while testing it only seems to successfully sync once when it’s opened after a force quit.

Both devices were setup using the Quick Pair on the desktop app, both consistently sync without any issues immediately after a force quit. I have the desktop app running on macOS and Windows without any sync issues so I’m guessing it’s an iOS/iPadOS client issue.

I ran some packet captures on my network to compare the network traffic during a successful sync and a failed sync from an iOS/iPadOS client. On a successful sync you see all the back and forth you’d expect, but if I force a one-time sync that fails I only see a total of 5 packets transmitted:

  1. client → server: TLS application data
  2. client → server: FIN ACK
  3. server → client: FIN ACK
  4. server → client: TCP ACK
  5. client → server: TCP retransmission

After that the client continues to sit at “Please wait” and never progresses past that while no further traffic is exchanged between the client and the server.

Ok this is working now after deleting the iOS app from both devices, doing a force push with a new encryption key from a desktop app, and re-paring both iOS devices.

I had already tried re-pairing the devices after deleting the app so it seems the force push with the new encryption key had a hand in resolving it. Wasn’t even doing that to try and resolve this, only did it to restore a backup of my db file after an un-related user error issue, just got lucky and seems to have resolved it. I’ll keep an eye on it and report back here if it recurs.

Thank you for you updates. I haven’t been able to reproduce this issue so far, but I’ll keep looking.

Appreciate your diligence, I couldn’t find any other reports of the issue so I’d guess that I was an edge case. Based on my testing so far this other bug that I reported appears to affect all iOS/iPadOS apps so it might warrant review before this sync issue.

Spoke too soon, this issue has begun again on my iOS/iPadOS devices. Very much the same situation, iPadOS will autosync successfully once right after a force quit, iOS will sync up to several times after a force quit but will fail syncing before it reaches it’s 10th sync since a force quit. iOS appears to actually be worse now, before I couldn’t replicate it on command but now if I just run manual syncs several times in a row it will start to fail around the 7th sync. In testing it today it has often started failing immediately after the first successful autosync, just like iPadOS.

I can try the force push with a new encryption key/repair device fix again but I’ll hold off for now in case you need any info from/about the affected devices.

I don’t think changing an encryption key could change anything.

I have performed a code inspection of the relevant modules and modified some sections that could potentially be problematic. However it’s not clear why the bug is so difficult to reproduce.

By the way, have you confirmed the same behavior in different networks, for example your home network, cell, work, etc?

Yeah, I wouldn’t be surprised if the encryption key change had no effect and was just a coincidence, but for now doing that once a week would be slightly more convenient than the constant force quit lol.

Yeap have tested on multiple different networks and same behavior. It definitely is easier to produce now, at least on the iOS device; iPadOS device is the same as before.

If it would help I could always replicate it on my side and provide you with the timestamp and the public IP from a failed sync attempt so you could trace it in the logs. Could even provide you with a packet capture of that failed sync if you’d like.