Unexpected refresh behavior makes app cumbersome to use (iPhone)
The behavior:
On iPhone, the app randomly refreshes the current map when returning to it from a background or locked phone state. After a brief blank / white screen, the map view refreshes, zooming out to show its full geographic bounds, and loading the default layers previously selected on the desktop site (under Details / Sharing > "Update this map's default display to use the currently selected set of layers.")
Variation on the behavior:
Just like above, except sometimes the app doesn't refresh the map but instead loses the map view altogether and just shows the user data (tracks, points, etc) atop a blank map. This is only resolved by swiping out of the app (manual refresh).
The concern:
Through this unexpected refreshing and zooming out and re-loading of the default layers, the map's last view and any modified layer configuration are lost. This makes it cumbersome and time-consuming for the user to return to what they were doing in the app previously.
The preferred behavior:
The app should withstand periods of backgrounding without the aberrant refresh behavior. Particularly when in airplane mode in the backcountry, there is no benefit to refreshing the map (as if to re-sync with the desktop site). The user should not lose their last map view or need to activate GPS in the app in order to approximate that view. The user should not have to re-adjust the layer configuration or remember what it was, particularly when using multiple layers at different opacities. (There should be a way to set the default layer view within the app itself, albeit this is a side note relative to the issue at hand.)
In short, the app should behave like any number of apps on the market and let the user essentially pick up again where they last left off.
Field notes:
The above issues don't necessarily manifest on a map containing very limited amounts of data. For example, if the map only contains a short track or a few waypoints then it may reliably exhibit the preferred behavior. But once the map expands to show multiple features and/or a larger aerial extent of data, then the aberrant behavior occurs. The aberrant behavior occurs randomly and not every time the app is opened after backgrounding or phone locking, with a greater likelihood of occurrence the longer the span of time since last using the app.
Phone, software and settings:
iPhone SE (2020), iOS 18.5
Location: "While Using the App" (most lenient option) (Precise Location: ON)
Background app refresh: ON
Airplane Mode ON
All Caltopo selected (and default) map layers previously cached / downloaded
Caltopo maps affected: potentially all, possibly dependent on size or aerial extent of map user data
Comments
14 comments
Further investigation reveals, well, not a whole lot. Turning off iPhone's Background App Refresh for the Caltopo app doesn't help (nor apparently change much of anything in terms of app behavior). It's an erratic issue but one that has happened to me using different versions of the app on different iPhones over the course of years now (not weeks or months, so this bug is pretty well baked in).
Again. it seems to occur most often with a map that contains a certain minimum threshold of data. It might also occur more often soon after the user has edited the map in the app in some way (created new waypoints, added photos, etc.) Likewise if the user has moved (eg walked) a certain distance from the last location where the app was used. Likewise if a certain amount of time has passed since the app was last used (let's say at least 5 or 10 minutes typically).
Ok, but here's a possible clue: the problem of spontaneous map screen refresh never, repeat NEVER happens while the user is actively recording a track in the app. Seems while the app is busy performing this task it somehow recognizes the folly in "wigging out." So there's one method, rather inelegant, to force the app to behave correctly.
And for the app developers and debuggers, here's another potential rabbit hole to head down. There are essentially four potential behaviors each time the app is opened on an already loaded map, none of which are under the user's control:
1) The app immediately displays the last map view. This is most common when returning to the app very soon after last use.
2) A white / blank (or Caltopo-branded) load screen is initially seen, followed by the last map view. (More common after a longer pause between uses.)
3) The last map view is displayed just briefly, followed by the white loading screen, then either:
A) the last map view once more, or
B) the complete map refresh showing the full, zoomed out map bounds and resetting of the default layers.
Outcome 3B is the problem at hand that makes the app cumbersome rather than a joy to use.
I've had this same behaviour, I downloaded mapbuilder topo, global imagery, map builder overlay, and cell coverage over two map tiles. I don't have any ways or nodes saved (I'm trying the app out, it doesn't handle the waypoints I need but I figured perhaps it'd be useful for the high resolution slope angle + higher resolution satellite). Just keeping the app open in the background for a while causes it to glitch out requiring it to be closed and opened again.
My conclusion is that caltopo isn't well optimized on either layers or user data. :(
I was on a 10 day trip and this basically happened every time I had the app in the background for more than 15-30 minutes. I just got in the habit of closing caltopo anytime I used it. Luckily I'm not really using it for anything at this point aside from high angle SAS as I try and figure out how to make it performant with a large amount of waypoints.
One single square of mapbuilder topo downloaded, along with cell coverage with no user data, that's about as small of a use case as you can get. iPhone 16 Pro on iOS 18.5.
I can't upload videos here, but two example videos of screen capture. Some very odd things happening with tiling:
https://drive.proton.me/urls/ME6CWWDV0C#ysuraJsZLC1E
https://drive.proton.me/urls/ETPRP9Y29C#jThTdNrf3nkD
I've had this same issue, also on an iPhone SE 2020. This issue is very annoying, and it can be a bit nerve-wracking seeing your map disappear into a blank screen when you are in the backcountry and really relying on your maps, even if you can manually refresh your app and they return. Not only this, but often when I am showing friends the Caltopo app, this issue pops up and leaves people with the impression that Caltopo is "janky" compared to a more polished option like Gaia or Caltopo. Which is to say, its slowing down my progress in converting everyone I know to Caltopo! Would love to see this fixed.
I have the same or similar problems on iPhone 16 Pro (and previously iPhone SE). Quite often when opening my phone to Caltopo the map does not show (white screen) with just user drawn routes or a very low resolution map displays with strange dots and other artifacts obscuring the view. This seems to have gotten worse and more frequent over the last year or so.
I love Caltopo and recommend it to friends and family, but this behavior is a real distraction and makes it harder and harder to justify using or recommending Caltopo to others.
I've found that a majority of the time the blank screen issue happens when out of airplane mode and with a weak signal. Even with nothing but previously downloaded layers selected it seems like the app checks online before referencing the cache (rather than displaying cached maps and then checking quietly for any updates).
The blank screen IN airplane mode feels like a fundamentally different issue, and is what I'm describing in the original posts along with the other aberrant behavior related to map display refresh and selected layers reset.
Hi all -
First, thanks for the level of detail in these bug reports - it really helps us. I think there are a few distinct issues being reported here that share a common visual thread.
* The brief white screen + reload is what happens if the mapping library we are using crashes, which is normally due to running out of memory. This would match with it not happening on maps with small amounts of data. While we don't have much control over how much memory the map viewer is using, we've been chipping away at memory usage elsewhere - a few months ago we made a change that uses less memory when syncing and loading very large maps, and with our latest release we were also able to reduce the amount of memory used when syncing photo waypoints.
* When phone operating systems run short on resources, they limit what backgrounded apps can do. When recording a track and requesting frequent GPS updates, the phone tries to keep the app alive. Brett, I'd guess this is why you don't notice the refresh issue when recording a track.
* In poor-but-existent cell reception, it's common for tile requests to take a very long time before either failing or succeeding. Even if you've downloaded tiles for offline use, depending on the zoom level you're at, the map's bounds, etc, the app may still try to fetch higher-resolution before falling back to what has been downloaded. This can cause a blank screen to appear on load (Carl I recognize that your screenshots show you are in airplane mode, where in theory this shouldn't happen).
* There is a known bug in the mapping library we use that can cause the same map tile to appear over and over. It happens infrequently, and as a result it's been a long and frustrating road trying to get it fixed. Normally it doesn't manifest itself in quite the same way as shown on Carl's videos, but it might still be related.
Earlier this week, we finished rolling out version 1.21 of our app. This version contains a change that we hope might address the repeated-map-tile issue, but because of difficulties reproducing the problem, we haven't been able to verify for sure whether it does. It also includes a new "offline mode" toggle in the layer menu, which will force the app to only use local tiles, and clear the cache and reload all tiles when toggled.
If you can update to 1.21, toggle offline mode on and off when tile rendering problems occur, and keep us informed of which of these issues still persist, that would be helpful.
Sorry you have to deal with this - the issues have been really hard for us to reproduce on a dev phone in an office environment, which complicates resolving them.
A few times on my last trip I left caltopo open accidentally and it didn't glitch out when returning to it, but for the most part I was always closing it after opening it. That was some progress as previous ~4 weeks of use in the backcountry had 100% failure after being open a short while, but not definitive.
Reproducing seems like it'd be straightforward - put the phone in airplane mode and don't close the app. You might need to move enough for the blue location dot to cause the map to jump a bit, otherwise just wait 15 minutes.
Many thanks, Matt Jacobs, for looking into these issues and for the greater context. I've long appreciated the way Caltopo operates as a company, and it's thoughtful and personable replies from the top like this that really hit the point home.
I had a chance to try the Offline mode feature in the backcountry on an existing map that previously had demonstrated the errant map refresh issue described in the original post on this thread. I kept the map in Offline mode throughout the trip. Initially I kept the app either active or backgrounded between uses, and had no issues until - perhaps just coincidentally - I added to the map by making a waypoint, after which the app on its next use did refresh the map to full geographic bounds and preset layers. It repeated this behavior on the next use as well. After this, I opted to swipe out of the app after each use, and this approach then continued to work flawlessly the rest of the trip. When returning to the app, the map would either show last displayed bounds or (less often) jump to current location, and this also held true after turning the phone off / on overnight. Selected layers also remained unaffected.
Recognizing that the Offline mode feature is not specifically aimed at solving the above bug, nevertheless it seems to help, and in conjunction with swiping out of the app between uses, might just be the interim fix we're after.
New version seems like it might last a bit longer before freaking out, but most of time after a while the map is just a black screen now.
Still have to open / close the app repeatedly for it to be useful.
https://drive.proton.me/urls/EJDBQQZ32M#XGt8MPNpRsjq - still doing the weird tiling, but less extreme
https://drive.proton.me/urls/C0G037ASA8#VGQxrLj7UHeO - got this the rest of the time
No progress on this for months, and caltopo choking on large datasets in a single map is apparently working as designed as a ticket on that was marked as being fixed/completed.
I want to like caltopo, but in their words it’s an app for people that like planning their trips as much as taking them and I’m more interested in actually using it in the field.
Someday I guess.
Carl can you send us a link to the large map that is causing the issue to help@caltopo.com?
I’ve gotten rid of them because they were unusable. One was a ~3k waypoint import, another was a bit over a thousand I made to share info with someone from CDFW. This maps with others results on Reddit and my past experiences with Caltopo.
GPX imports were valid XML and didn’t contain any extensions. I even went through and edited all the symbol contents to match ones that are in caltopo, left the values blank, removed entirely etc. Just make a map with a thousand GPX waypoints, it’ll take seconds to redraw when moving etc. Gaia & Goatmaps both handle large datasets - I suppose Caltopo is more SAR focused and you only look at a single trip at a time, but my backpacks will often overlap multiple past trips and I might want to edit old waypoints so even rendering out mapsheets to have in the background of old trips isn’t great.
I had a ticket on this subject around 3 years ago, and another ticket on it recently that was closed as fixed. The fact that Caltopo cannot handle large datasets is a commonly known fact. Caltopo's stance always seems to be that it must be a specific issue with a particular map I've made, but I've tried with multiple datasets, some I've worked on sanitizing and sizing down.
https://www.reddit.com/r/CalTopo/comments/1kfjmar/comment/mqs2esi/
"I personally have found Caltopo to be awfully inefficient when handling 20000 markers. It's a scenario we sometimes have from our maritime search jet delivering is track details in an unreasonably detailed way."
"Resampling is the only way forward if you want to get that performance back. We had a plane sampling at 100m intervals which was excessive so that was easy to downsample, but for walk tracks it's harder to find a balance."
https://www.reddit.com/r/CalTopo/comments/1kfjmar/comment/mqt8662/
"I don’t have nearly as many waypoints or tracks as you do and I have trouble loading things. For example I have one folder with 18 routes and 61 waypoints and it takes a few seconds to load. 10s of thousands would lock my shit up lol."
Suggested workarounds have included duplicating a master map, then manually deleting everything off it I don't want on a trip, then switching between it and a new map for the trip that I then add back into it which sounds tedious. Making a mapsheet means I cannot interact with previous markers. Categorizing my waypoints into hundreds of folders and then selectively loading certain folders for trips was another suggestion.
These are all very high friction fixes.
Caltopo maps seem designed mostly to be throw away single use maps made to plan for a trip and then never reused, but there's value is having marked camps, safe stream crossings, notes on off-trail routes etc available for future use.
Please sign in to leave a comment.