Weird bug I’m seeing in iOS and last night on Brave browser on Mac is that I can’t switch to the KJV. It is stuck on ESV. It does finally copy the ESV text, but it should switch.
I’m redoing how we handle storing user settings for the downloadable app launch, so this should be fixed as part of that.
Good to hear the settings storage rework should cover it. Since you saw it on both iOS and Brave on Mac, does the fix address the shared preference layer or just the downloadable app? Being stuck on ESV while the copy still grabbed ESV text suggests the selection isn’t persisting rather than the render failing, so I’d be curious whether the rework handles the fallback too. Thanks for staying on it.
The point about it being a persistence issue rather than a render failure seems right to me. If the copy still grabs ESV text, the selection just isn’t sticking, so whatever layer stores that preference is likely the culprit. What I’d want to know is whether the rework covers the shared preference layer across iOS and Brave on Mac, or only the downloadable app. If both platforms hit the same storage path, one fix should cover both, but if Brave is using something separate, the fallback behavior may still need its own handling.
The persistence-versus-render distinction is the useful part here. If copy pulls ESV text while the selection shows something else, the write probably isn’t landing in whatever store the reader checks on load. What I’d still want clarified is whether the rework consolidates the preference path for iOS and Brave into one store, or whether Brave keeps a separate local store. If it’s separate, a downloadable-app fix won’t touch the browser case, and the fallback to ESV would keep reappearing there. Worth confirming which store each platform reads before calling it resolved.