New iOS mobile app beta available for testing

“Revoke Access” is under Preferences > Apps (if you have an authenticated app, then you should have an Apps tab).

1 Like

It’s not there. I also don’t have a “Saved Searches” tab, which I see I have here on Meta.
Edit: Deleted and re-installed the app. Everything’s working as expected now.

2 Likes

Here‘s another issue. I got this push notification twice.

1 Like

Cool, glad to see removing/reinstalling app fixes the api key issue.

The double push notification issue in the screenshot is an issue we’ve seen recently, where some PNs (about once every two weeks for me) are sent twice. This is likely because in our PN implementation we retry sending a PN if Apple’s servers don’t return a status code, and that happens sometimes, even for PNs that Apple delivered correctly to the device. Anyhow, it’s not an issue with the current version of the app.

5 Likes

This happens at least twice a week for me.

4 Likes

Since updating to the new app I’ve seen it three maybe four times. I don’t recall it happening at all on the public version.

Do we ship some unique id with PNs that is stable? Then prior to showing the notification we can have the app check if it has seen it before?

1 Like

The way I understand PNs is as system events: the app doesn’t see them at all, it only sees them if you interact with a PN. One small case when the app can suppress PNs is if it is in the foreground, but this is a small use case (we were suppressing PNs while app was in foreground prior to the beta, for example). When the app is in the background or not running at all, the PN is shown to the user by iOS, with zero interaction with our app.

What we can do instead as a start to tackle this issue of duplicate identical PNs, is add more granular logging to our sending API.

3 Likes

Yeah my understanding is that you can send “invisible” PNs to the app that would wake it up, would be a big change to the way we do stuff.

Probably better go down the diagnostics route first, then we can queue extra clean up here maybe for one of the future app releases.

3 Likes

I’m beginning to wonder if what I’ve been experiencing are duplicates at all.

I just received a pair of notifications for the same reply, but the two notifications were different. The respondent had added a line of text above their original message.

Is it possible that we’re not getting duplicates, but instead we’re getting notifications for responses that have been updated?

I can’t rule out that my previous “duplicates” weren’t edits as typically people edit their post to either correct something, or append more text. It’s quite uncommon for the top of the message which gets included in the notification to be edited.

2 Likes

In some cases, they are edits, yes, but I do think that sometimes exact duplicates are sent without edits.

2 Likes

Do edits trigger notifications on the site? Don’t recall seeing a notification for an edit.

Sorry for the delay, I was wondering about that question as well and wanted to look into the relevant code before answering.

Edits to a post by its author do not trigger the same type of notification. So you might get a second notification for a post if it is of a different type, for example, userA replies to you, you get a notification of type “reply”, then userA edits the post and mentions you, then you will get notification 2 of type “mention”. This is the case even if the excerpt of the notification is identical in both notifications, we should probably not trigger a notification in this last case (when excerpt is identical).

4 Likes

Receiving notification for some edits would be more confusing than not getting them at all.

I would prefer edit notification excerpts be prepended with edited:, or suppressed entirely.

1 Like

I totally support adding edited: in front of push notifications for edits. But 100% mixed on if this is a push notification class event. Leaning on no … this is not a push notification event.

3 Likes

I’m curious to know how many users perceive duplicates once edit notifications go away.

1 Like

I’m afraid this doesn’t cut it for me. On one of the Discourses I use, the bar doesn’t come up at all and I struggled to get back to the overview screen until I accidentally found out that swiping down a lot gets me there.

However, even when the bar is coming up, it’s not a natural place for me to look for a home button and I don’t find the downward arrow very intuitive.
I wish there was a way to go back with a swipe.
I’d like to suggest to take a look at the podcast app Castro, which I think does a fabulous job with navigation.

The sheet sitting at the top would probably be too present and unnecessary when you spend a lot of time on one Discourse. But the right swipe, which has some resistance and then haptic feedback as the :information_source: icon lights up, I think would work great if the Discourse app used a :house: icon instead.

This is almost certainly because the site isn’t up to date with tests-passed. The bottom bar was added to core very recently, so if the site isn’t up to date, it won’t be there.

Umm, there is… you stumbled on this, you can swipe down from the title bar to dismiss. It might be a little hidden, but once you figure it out, it’s easy to invoke. Also, horizontal swiping (left/right) triggers back/forward navigation in the webview, I don’t think we should (and I don’t know how we could) add another horizontal gesture to return to the site list.

1 Like

Oh, I hadn’t realized either of those things. I thought swiping right from the homepage of a Discourse would never work, but it does when there is a browsing history.
And even after swiping down to return to the overview I didn’t know that I’d have to hit the title bar. Thanks for clarifying.

What about a more intuitive button in the nav bar? The iOS equivalent would be
https://fontawesome.com/icons/clone?style=regular
turned 180 degrees, but because the app doesn’t use sheets, maybe a bullet list icon?

image

:thinking:

6 Likes