Mobile feature guidelines

New product features should consider the mobile client at the same level of importance as the web app client. For new features implemented on the server or web app, please consider the mobile client through these lenses:

Are mobile app code changes needed?

A good rule of thumb is that if there are web app repo code changes (outside of the System Console UI), mobile code changes are needed to support the feature.

While not every web app feature needs parity with mobile, this is a discussion to have with the Product Managers and UX team, and a decision to be made in the requirements gathering phase of feature design.

  • If a feature requires mobile code changes, the Mobile team PM (Eric Sethna) should be made aware of the feature before it’s committed to the feature team's quarterly roadmap. Please involve the Mobile team PM in roadmap planning and quarterly OKR planning discussions. The same applies even if the feature team will be doing the mobile implementation themselves, given that the Mobile team will be involved in code reviews, testing, and should provide guidance on the feature implementation.

  • During design and spec development of any feature that will involve mobile code changes, please involve the Mobile PM (Eric Sethna) and Mobile dev lead (Elias Nahum) at all stakeholder checkpoints including requirements gathering, design option exploration, and final design review.

  • Set deliverables taking into account the limitation that a team may not have enough skills to develop features for mobile. Consider the impact if the feature is left out from mobile, document the reasons, and set goals to cover the mobile space. The feature should be released as beta or experimental and any documentation should clearly communicate the impact of not having mobile support as well as when mobile support is expected.

  • If a feature is related to authentication, such as Single Sign-On (SSO), plan to release the feature on Mobile Apps prior to Cloud to avoid users from being blocked from using the Mobile Apps.

Backward compatibility

  • Mobile releases must be backward compatible with at least all server versions back to the oldest supported ESR. An important question to ask during design is: What is the expected behavior on a new server with an old app, or a new app with an old server?

Here's an example:

  • New mobile app with an old server: If the server is running older code and does not support the new feature, we can’t allow users to access the feature from a new mobile app.

  • New server with an old mobile app: Users will not be able access the new features from their mobile device since it’s running older code, but the new server code should not cause regressions to a user's experience on an older mobile app.

    • Example: Users cannot see the “Mark as Unread” option in an older mobile app that does not contain that code, but marking a channel unread on a webapp running v5.20 or later should still mark the channel as unread on mobile, and not cause any mobile app regressions for a user running an old app.

Ideally any new features should be tested on all server versions back to the oldest supported ESR. However, since testing mana is limited, feel free to work with your QA representative to determine the most effective testing approach based on the risks of your feature. At a minimum, new mobile app features should be tested on all supported server ESRs and the latest three server versions.

For new features, consider a minserverversion check that only executes the code if the server connected to the app is newer than xyz. See example to disable or not the position field when editing the profile.

Bonus: Legacy servers (i.e. < v5.0) don't have post metadata, don't rely on it.

Variable network conditions

  • API requests will fail on mobile because network conditions are much more variable than on desktop. As such defaults need to be carefully chosen to avoid failing requests breaking or blocking core user functionality. As an example, if the default for a channel is set to be read-only until a permission API request grants the user permissions, this is likely to result in a poor user experience in bad networks.

When in doubt, the default if an API request fails should not change existing behavior, or a failed API request should either do nothing or notify the user somehow.

Client performance impact

Last updated