Limited functionality of push notifications in iOS (unread mails counter limited to "1")

[jactmp]

I noticed that iOS client has some limitations concerning support for push notifications:
A/ badge is always set to "1"; no information about real number of unread messages in INBOX
B/ notifications (lock screen, badge) are not cleared when there's no unread message in INBOX (etc. by reading all of them in web interface).

I took initial look at source code (I'm Tutanota customer since yesterday) and it seems (I could be wrong of course) like push server is used only (privacy reasons?) to inform iOS client that there's is "content-available" and all further handling is done through direct URLRequest to Tutanota server. Push is received for every knew email in INBOX (no idea about unread->read status change?).

Is there a chance to have unread mail counter (including notification cancellation) available in iOS client. Can I help in any way?

I'm not sure whether it's a bug or just expected behaviour so marked this thread as General.

[charlag]

Hi there,

iOS notifications are indeed quite limited at the moment. We plan multiple improvements (like showing sender and recipient) but we need to do it in a privacy-preserving matter. The counter changes you are describing would require some substantial changes but would likely come together with other improvements.

Regarding content-available it is only used for receiving alarm updates, not for email notifications.

[jactmp]

Thx for feedback. Actually I noticed that pushes are used for alarm updates later.

I know that implementing new features is not trivial and takes a lot of coding and testing, but have one question concerning approach to notifications for now. I know that tutanota is known for its strict approach to privacy reasons. Have you considered approach like (similar to) below:
1/ symmetrical security key (AES, whatever) is agreed between iOS app and server (if not already available)
2/ server sends push notification with withencoded-contentcarrying encoded info, e.g. unread mails counter and Subject, From, To
3/ iOS application decodes that info using agreed key.

In such approach "privacy leak" is limited to the fact that some change in INBOX status happened (seems like acceptable).

I'm not expert (lets say, junior level developer), but know that push notifications are "cheap" and most reliable in iOS (iOS is very strict for background actions and battery saving).

It's more like my curiosity only, but will really enjoy any feedback regarding the topic (quite important for me personally).

thx in advance

[charlag]

Hey,
thank you for the idea. That's roughly what we want to, UNNotificationServiceExtension or similar (guide: https://developer.apple.com/documentation/usernotifications/modifying_content_in_newly_delivered_notifications).

[jactmp]

Yes, exactly this. Looking forward to seeing notification fully implemented some time. 🤞

One more thing. Maybe it's only my personal view but it seems like, functionally, the most important upgrade to existing state would be just cancelling notification should all items in INBOX be already marked as read (e.g. read through other interface). It is (still, personally) the most annoying feature of iOS Mail client that was implemented sometime close to iOS13 release. Before iOS 13 Mail app handled properly both "unread" and "read" events. From then notifications are only updated for new "unread" events (interestingly when new message arrives, "unread" -> "read" change is taken into account for messages for which notification was already sent). All other MUAs that I used on iOS (quite many) handle notifications properly.