I think the worst loss is that nothing marks as read anymore. I’m constantly clicking on posts again. It’s so annoying.
Same, had to redo everything.
I also get errors where is like “oops, error! Report it?” And there’s no way to go back other than force quitting the app. lol.
The updates are great. But a ton of issues it seems
Same. I wasn’t paying attention, and just assumed an update would migrate everything, but I found out I wasn’t even sure what Lemmy instance and password I was using (rookie mistake, but App Store updates don’t usually wipe everything). Happy to say after some tense minutes I figured it out, and reported the “bug.”
I know this doesn’t help, but on TestFlight the dev said that he rewrote the app from the ground up to make it better. It’s frustrating to lose everything, but in the end the app is going to be faster, smoother, and have more features. Unfortunately right now, it’s like starting over.
I saw that about the re-write and assumed it was the cause, but it would have been nice to be told about it before it happened…
Yeah, I get it, it’s frustrating, but I’m glad it’s still being developed and not abandoned. I hope it’s a much better app in the long run.
Worse - I reloaded all my info (3 accounts and some filters) and then after a day it crashed. When I reopened the app…all the logins gone again and I had to start from scratch. (IOS 17).
Same. Normally a mobile dev writes database migrations to keep data even after changing the SQL tables to avoid this. 🗿
I also lost all my data.
Could you elaborate on the database migrations part, if you don’t mind?
Would the migration happen when the user opens the updated app for the first time, migrating all the old sql tables to the new schema?
I’m just interested from an operational standpoint.
Yes, the migration happens when the user opens the new version of the app.
Basically you start versioning the database table schemas. If you modify tables, you say “If DB schema is moving from v2 -> v3, update these table columns in the following way…”.
This is what you’re meant to do, rather than dropping all existing tables (and data) when there’s a conflict. It’s tedious dev work but it avoids pissing off users. Using an “ORM” layer for the database can help make this sort of thing easier.
On the other hand, user preferences are probably not stored this way at all, and it’s the fact that a new app project was created from scratch that destroyed the existing user data. In Android, there’s libraries specifically for storing app user preferences that require almost no maintenance.
