I’m in the progress of implementing background uploading on iOS. It’s not ready yet, but hopefully soon.
Background support on iOS is very limited/complicated and it’s tricky to get right. It’s very important that uploading is reliable, so I’m looking for testers in our community to help with testing before I release it to everyone.
We will be using TestFlight for testing. You can sign up using this link:
If the link is not working, please PM me what email you want to use.
It seems that Apple changed the link behaviour, so the link will not work until I have an actual build uploaded ready to be tested, which I don’t at the moment. Before the change, you could sign up at any time, with a build or not.
I can add you manually in the meantime though, just PM which email you want me to send the invitation to!
I uploaded a test build on Friday! This also means that the link above works for signup too
This build includes the first version of background uploading. There are a few things worth noting before you begin.
This is a beta release and it’s possible that you can lose your uploads. We don’t expect this to happen though from our own testing, but we are not 100% sure it can’t happen.
Uploading with the app in the foreground works as before.
Uploading with the app in the foreground is faster than background uploading.
Uploading with the app in the background is handled by the system and we don’t control when the uploading will happen. If the phone has wifi and is connected to power, the uploading should start pretty soon after you minimize the app or lock your phone.
When you put the app in the background, the current file that is being uploaded will start from the beginning. So if you start the upload and progress is at 50% for a sequence, and you put the app in the background, and then bring the app to the foreground again, the progress could be less than before. This is expected and is due to limitations of iOS background uploading.
If you kill the app by sliding up in the task manager, you will also kill all uploads and you have to start uploads again manually.
Looking for feedback:
Does it work as you would expect?
Is number 5 above confusing? Would you prefer to have a bit slower uploads when the app is in the foreground and didn’t restart when you put the app in the background? Or do you prefer to have the possibility for faster uploads when needed?
Would you appreciate a push notification when your background uploads have completed? I would make this a setting in that case so you can disable it.
Thanks Anders, tested it briefly today. Do you prefer feedback here or through testflight emails?
Does work for me, on a small test upload. I did momentarily get an “Upload failed” popup when restoring to foreground, but it disappeared instantly, and there are images processing, so I assume it worked.
Given it’s explained, I don’t see an issue, and would prefer to have faster uploads in foreground. I guess impact of this could be minimised if upload chunks were smaller, but not sure if this is technically feasible. One way to set expectations is to have eg a textbox on the upload screen/during intro sequence, explaining this.
Absolutely yes, as well as maybe some sort of initial notification on successful background upload start (although not sure if you’ll run into the limitations of the push service).
Thanks for testing 4004, and thanks for the feedback! Feedback here is fine if you want to share in public, if not, email etc works too ofc. I think it’s great to have it public so others can chime in.
Yeah that is the current expected behaviour. Technically it did “fail”, but it is by design so I guess not really a failure. I will see if I can hide it in a future update.
I think we will settle for having a slightly simplified version with one small change. That is that if you switch back to foreground from background it will NOT switch “mode” again. In short: foreground = fast, switch to background = a bit slower, switch back for foreground again = still a bit slower. The implementation is complex and I prefer stability and reliability for a first release.
Gotcha regarding notifications. As long as it is an option I don’t see anyone getting upset over this. I don’t fully understand what you mean with “some sort of initial notification on successful background upload” though, can you expand on that? Do you mean for automatic uploading, i.e. when you don’t start the upload manually? That is something I will add next, after adding a function for “do not capture in these restricted areas”, like your house etc.
I will hopefully send out a new build shortly. The current one has bugs with big uploads and they get stuck. I will also add some more information in the UI during upload, and I will probably add the “upload done” notification too.
I forgot automatic uploads were an option, never had that use case. For the notification, I meant a sort of reminder notification, eg if the app is in background (or backgrounded) and an upload is taking place, a notification like “An upload is running in the background. Return to the app to monitor progress” appears. I think iOS also offered an option to make this notification persistent whilst the upload is running.
Might also be useful to have some alert notification in case the app is killed whilst in background
Ah ok, I understand. I’ll add a notification when the app is uploading and minimized Can remove later if it’s not useful. Great idea about when the app is being terminated to inform the user that uploads has stopped. I’ll make all notifications without sound to start with.
I couldn’t find a way to make notifications persistent on iOS. An idea for the future that I have is to create a widget that monitors uploads and processing progress. We will also get server-side push notifications next year, so the user can be informed when the images have been processed and are visible on the map.
Just tested the new version, works great!
The “Uploading has finished” notification seems to only have the title (as opposed to the starting notification, which has “Background uploading” as the title and then the text of the notif), but not bothering me.
Couldn’t get the app to terminate through iOS’s own task handling (ie by squeezing RAM available), I guess once the session starts it might be given priority by iOS. Terminating the app manually in the task switcher did not produce the Upload terminate notification for me.
Server-side notifications sounds great - would be useful not only for the mobile uploads
You are correct that the “Uploading has finished” notification does not have a body. I couldn’t think of anything useful at the time. I will add something before release.
“Terminating the app manually in the task switcher did not produce the Upload terminate notification for me.”
When the app is terminated by the user, there is just a short window to do things. For me it works 50% of the time. I did some experiments and adding a 1 s delay seems much more reliable.
I wonder if it can be a bit confusing. When you terminate the app this way, you will get two notifications:
one that says the upload will continue in the background
one that says that upload has stopped
Not sure how to work around that, unless I add more delay to he upload stopped notification. Or removing the first notification.
One could argue that user-triggered termination doesnt need a notification, given that the user supposedly knows they are stopping the app. Maybe a popup on the next startup “The app has been closed from the app switcher when a background upload was in progress” etc, but I wouldn’t need it
Perhaps. However, not even our product manager understood that “swiping up” also meant killing the uploading, and some people tend to open the task manager and killing all apps on a regular basis without thinking too much about it. We’ll see which notifications we keep in the end.
On the feedback items:
2. Definitely faster uploads in foreground. Imagine travels, where one might get faster internet access only occasionally.
3. Yes, an optional notification on that would be great.
Yes, user education on iOS is really poor in this respect, somewhere around iOS 8 people were somehow persuaded clearing the task switcher is a good thing. It’s terrible and causes a few issues for background tasks.
Had a difficult to trace issue the other day, when Mapillary was crashing shortly after starting a new sequence (crash report sent). Up to that point I had about 15 of them. Not had this since.
Also not sure if this is beta specific or just the iOS (wide) camera stack, but a lot (if not most) of my handheld images are very blurry. Not just when turning but also simply walking in a straight line. Will need to test if this is the same with wide cam disabled