In iOS build 7012 updating doesn’t seem to run automatically and also whenever running it manually it seems much slower than it used to be. My feeds are on Newsblur and I’m connecting over Mullvad VPN though that has always been the case for me.
It seems the issue is about background updating. If I initiate an update, then switch to another app and several minutes later switch back to NNW the update will not have happened. If I wait on the Feeds screen for the update to finish, it will complete (but seems much slower than it used to be, which is why i started switching away while the updating happens).
i do have the Background App Refresh setting on in the system settings. I tried switching it off and back on, closing and reopening NNW, but that has had no effect.
Further thoughts. Could the reason the updating when NNW is in the background now never or rarely works be directly linked to the fact it is taking much longer than it used to. I understand that background tasks in iOS are limited in time. If the sync takes longer than whatever the limit is in the current iOS version would that fail the sync? If so it would explain why it works when the app is active. If that’s the reason then the issue is some change introduced in v7 that considerably slows down the sync when using Newsblur with NNW (I assume not with other syncing mechanisms otherwise there would have been more reports about this).
I’ve just timed the update (+/- a few seconds as I did it by hand with the Clock app) to have more concrete info than my subjective impression:
- On the iOS app (7024): 1’29”
- On the macOS app (7015): 1’35
Both updating from the same Newsblur account. On macOS, it’s not an issue as it happens in the background. On iOS one needs to refresh and keep the app in the foreground until the refresh is completed or the sync will be abandonned.
Hopefully this can be identified and fixed in v7.1
@panda Just out of interest, how many feeds are you subscribed to?
Not sure how to count them. What I did is that I exported the opml and then in BBedit searched for xmlUrl. That found 679 occurences, which should be the number of feeds.
iOS only has a 30s window for a background refresh, so it makes sense that it is being killed.
@Brent A possible avenue might be to concurrently refreshUnreadStories for more than 100 hashes at a time for NewsBlur?
Thanks for confirming my suspicion that this may have been the root cause.
There are two distinct issues:
- For NNW to be able to sync in the background an update that takes more than 30 seconds - for which you have suggested a possible way forward.
- Why does it take this long to sync with Newsblur in NNW v7. This was not an issue in NNW v6 (so I’ve never timed it).
NNW7 had a significant under-the-hood modernisation that adopted Swift Concurrency. It’s possible that it has introduced some unintended performance problems.
Hopefully with v7.0 soon in the iOS AppStore, after some celebrations, you’ll have more time to look at this and any other performance issues that may be raised.
I’ve added a ticket to the 7.1 milestone:
https://github.com/Ranchero-Software/NetNewsWire/issues/5090
(The 7.1 milestone is focused on syncing.)
1 Like
Seeing the change note ‘Fixed a performance bug with syncing, with sending read status to NewsBlur’, I’ve tried again with the new 7.0.1b1 (Build 7016) and I just got 28’’. So much better and just under 30” which means that with the same performance on iOS it should be close but under the limit breaking the background updating.
1 Like
Thank you so much for having worked on this issue.
28” also on the new iOS build. So background syncing is working again which makes a huge usability difference. Much appreciated.
You may want to consider an early AppStore release with this fix for all NNW users syncing via Newsblur.
Longer term, it is close enough to the current iOS background task limit and from Stuart’s earlier question I gather that how long it takes may be proportional to the number of feeds one subscribed to, that it may be worth investigating whether this operation can be sped up even further as I guess it’s not possible to break the updating task in several to be well below the current iOS 30 secs limit.
We could switch to longer running BGProcessingTask instead of BGAppRefreshTask. They have a longer window to process but I’m not sure if they run as often.
I can’t easily find when or how often BGProcessingTask is scheduled. Maybe a two prong strategy would work best:
- app initiated background processing could use BGProcessingTask as in my view it doesn’t need to happen often (i.e. once an hour or even every few hours seem fine to me).
- user initiated refresh may need to use a different mechanism that is scheduled immediately as one expects that refresh to happen asap even if one temporarily switches away from NNW.
It likely would be helpful to create a TestFlight build with BGProcessingTask so that we can all figure out how that works out in practice, before deciding on a best approach?
Currently, the there doesn’t seem to be background sync initiated by the app. I’ve enabled the badge to check without switching to the app. When i woke up, with the phone charging and idle for many hours, NNW showed no new posts. Going to the app to refresh and immediately switching away from it did initiate a syncing that did work in the background.
Not particularly an issue for me, but not sure that’s the expected behaviour and it may impact your decision re switching API call.
Background sync isn’t initiated by the app. The app can only schedule it, and the iOS overlord decides whether or not to grant it execution time.
1 Like
Sorry to have been unclear by indeed confusing the runes of NNW and iOS. Let me rephrase that:
-
A refresh initiated by the user in NNW works well, now even when switching away from NNW. iOS grants it execution time and the syncing now runs fine in the background. The badge number changes without switching back to NNW.
-
Leaving the phone charging and idle for many hours (while the user sleeps) no syncing happened. When picking the phone in the morning the NNW badge had not been updated. As i understand NNW does schedule background syncing it would mean that in this optimal situation iOS didn’t grant it any execution time which is surprising. Not sure if anything can be dubbed about that.
Also wondering if switching API will affect either of these two cases and, if so, how
Nothing can be done about it. iOS is the ultimate decision maker on whether a background refresh will be executed.
1 Like