feat: add build number to settings screen

[kathaypacific]

Description

As the title. This will be helpful to identify which version of the nightly build you're on.

Test plan

Related issues

n/a

Backwards compatibility

Y

Network scalability

If a new NetworkId and/or Network are added in the future, the changes in this PR will:

• Continue to work without code changes, OR trigger a compilation error (guaranteeing we find it when a new network is added)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.98%. Comparing base (e39b981) to head (0c5e25a).
Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6234   +/-   ##
=======================================
  Coverage   88.98%   88.98%           
=======================================
  Files         737      737           
  Lines       31449    31450    +1     
  Branches     5828     5828           
=======================================
+ Hits        27985    27986    +1     
  Misses       3266     3266           
  Partials      198      198           

Files with missing lines	Coverage Δ
src/navigator/SettingsMenu.tsx	94.89% <100.00%> (+0.05%)	⬆️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e39b981...0c5e25a. Read the comment docs.

[bakoushin]

since it's mostly an engineer-targeted feature, what do you think about adding it under the dev settings (those that appear after many taps on the version)

[kathaypacific]

since it's mostly an engineer-targeted feature, what do you think about adding it under the dev settings (those that appear after many taps on the version)

i agree this information is more for debugging, but i also think it is supplementary information to the app version. i see this pattern of app version (build version) in many apps on my phone so it doesn't seem like it'd cause confusion for users, and giving less reason to activate the debug menu (where you have the dangerous reset app without warning option that you can accidentally tap) seems like a good thing...

[bakoushin]

giving less reason to activate the debug menu

but what are the reasons for the end user to activate the debug menu? I thought it was only for the engineers (who are aware of its existence 😅)

[kathaypacific]

giving less reason to activate the debug menu

but what are the reasons for the end user to activate the debug menu? I thought it was only for the engineers (who are aware of its existence 😅)

this is the context for adding visibility for the build number, i think there are genuine use cases for wanting to know the build number of an app outside of while you're engineering a feature. i suppose you could argue that only engineers have the nightly build, and they should be trusted to toggle the dev menu responsibly (since the debug menu is not enabled by default on any published apps), but this is an extra step that doesn't seem necessary unless there's some harm to exposing this build number alongside the app version? in the event that we accidentally do a public release without bumping the app version, the build number will also become important for debugging

[bakoushin]

i thought it would bloat the UI with seemingly unnecessary information for the end users.
the standard version number is something that users see in the app stores and we could refer to it when communicating about the app.

as for debugging, i noticed that when some debugging/investigation is required, we usually require the end users to send their logs, which include the build number. in the discussion you mentioned, what if the user had the expected build number, but still experiencing the issue? we would ask them then to send the logs, right?

however, within the engineering team, we may want to have a shortcut to quickly reveal the build number without going the full circle with logs.

having that said, I don't want to die on that hill 😃 if it really could help us resolve some issues more quickly, then why not

[kathaypacific]

i thought it would bloat the UI with seemingly unnecessary information for the end users. the standard version number is something that users see in the app stores and we could refer to it when communicating about the app.

as for debugging, i noticed that when some debugging/investigation is required, we usually require the end users to send their logs, which include the build number. in the discussion you mentioned, what if the user had the expected build number, but still experiencing the issue? we would ask them then to send the logs, right?

however, within the engineering team, we may want to have a shortcut to quickly reveal the build number without going the full circle with logs.

having that said, I don't want to die on that hill 😃 if it really could help us resolve some issues more quickly, then why not

I hear the feedback that the build number might just be unnecessary clutter for most users, and I agree that we can usually get this info from support tickets when debugging real user issues. That said, I still feel that having the app version + build number is a more precise way to identify what version of the app someone is using. This is especially helpful for the nightly build, which we rely on heavily to test new features—not just engineers, but also folks like Laura and Denisse. It seems much easier for them to include the build number in issue reports than having to dig into the debug menu (if we agree that generally, exposing the debug menu to non engineers is not desirable), as long as it's not causing too much harm to users to see this information. Given the screen doesn't have a lot of info on it now and the build number is relatively short, I still see it as a worthy tradeoff to have here