Thanks for the bug reports! Looks like there's an error in the refresh logic for save--posts should remain in the view when initially unsaved (to avoid losing them forever on accidental unsave), but should disappear when the view is refreshed (which does not appear to be happening).
As far as community blocking goes, that's mostly handled server-side--once you block a community, the app should filter posts from that community out of the currently displayed feed, and relies on the server-side block functionality to keep those posts from appearing in subsequent loads. We load in pages of ~50 posts, so if you block a community from, say, the profile page, it won't update that over on the Feeds tab (yet, we're looking at ways to implement that behavior but it's fairly involved) and so you'll still see those posts in the feed until the next load. In theory, simply refreshing the feed will clear them out because it'll fetch the page fresh from the server.
Highlighting new comments is a good idea! I'll have to take a look at what support there is API-side for it.
We'd like to remember collapse state, though that one's a little trickier technically--collapse state is client-side, so we have to do some caching tricks to make that work. We're reworking our backend modeling for 1.3 to include, among other things, a caching system, so we'll see if we can work that in.
Unfortunately the API doesn't support that and it's infeasible to do client-side, so not for now. They have an issue for it but it's closed as not planned, though they'll reopen it if anybody wants to work on it so hopefully we will be able to offer this feature in the future.
Hmm, that's odd--App Store Connect reports 1.2 as live for all of our testing groups. It might just be a little slow to propagate the build out to all the servers.
As Sjmarf mentioned, we're in bugfix mode for the upcoming 1.2 update. 1.3 is now properly scoped, and will focus on admin and mod tools--we plan to add support for mod actions and build a nice mod tool page to centralize moderation activities.
I'm truly sorry. If there were another way, we'd have taken it, but it's just not feasible for a team as small as ours working in our free time in an ecosystem that evolves as fast as SwiftUI to offer long-term backwards compatibility without seriously compromising the quality of the app.
We have an update coming down the line soon that fixes this--it's taking longer than expected because I've needed to rewrite pretty much all of our post loading code, which has been operating on the same core since early beta and at this point is stretched past its limit. We're hoping to enter TestFlight within the next week.
Thanks for the bug report, and glad to hear you got it resolved! I just got my sopuli account approved so I can debug it properly--it looks like there's a problem adding accounts on 0.19 instances if you're already logged into an instance, which would explain why uninstalling/reinstalling works. Should be fixed in the next build.
Glad to hear the icons are working--I'm going to put that down as an iOS issue and reopen it if it reappears. We'll take a look at compact posts, customization should work in the next build.
We'll look a little deeper into whether that's a feasible toggle--if it can be done without introducing too much technical overhead, I can see the use case justifying the added complexity.
Thanks for the feedback! We're always trying to balance efficient engineering and streamlined design with a rich feature set--which features have you wish were more immediately available? For engineering reasons, the sheet is here to stay, but we can look into extracting key features up to the top level.
We unfortunately can’t make long press the collapse post gesture, since that is already taken by the system context menu behavior. We can, however, add an option to disable tap-to-collapse, since we already have the alternative of swiping very far to the left to collapse a comment implemented.
Swipe actions on expanded posts should be feasible, but I’m not going to promise it until I’ve reviewed our other planned features and verified that there aren’t other uses for that gesture under discussion.
Thanks for the bug reports! Looks like there's an error in the refresh logic for save--posts should remain in the view when initially unsaved (to avoid losing them forever on accidental unsave), but should disappear when the view is refreshed (which does not appear to be happening).
As far as community blocking goes, that's mostly handled server-side--once you block a community, the app should filter posts from that community out of the currently displayed feed, and relies on the server-side block functionality to keep those posts from appearing in subsequent loads. We load in pages of ~50 posts, so if you block a community from, say, the profile page, it won't update that over on the Feeds tab (yet, we're looking at ways to implement that behavior but it's fairly involved) and so you'll still see those posts in the feed until the next load. In theory, simply refreshing the feed will clear them out because it'll fetch the page fresh from the server.