What do you cut when your app has more features than the navigation can hold?
On the web this argument stays theoretical, because there's always another menu. On a phone the limit is physical. The tab bar holds about five things, and everything past five sits behind a More list that almost nobody opens.
I build mobile apps, and I've shipped features that were used steadily right up until the day they moved into that list. Usage didn't decline, it stopped. What I still can't tell is whether that says something about the feature or only about the navigation, and the two point to opposite decisions: cut it, or promote something else to make room for it.
When you're past the limit, how do you decide what stays visible?
The tie-breakers I've used, none of which feel rigorous:
Frequency over importance. A thing used weekly beats a thing that matters more but is used twice.
Whether the feature is the reason someone downloaded the app at all. That one keeps a slot even on low usage.
Whether it can live inside another screen instead of owning one, which is usually the honest answer and always more work.
Whether it can be triggered from outside the app entirely, a share sheet or a widget, in which case a tab was the wrong home for it.
I'd love to hear what you use, and whether anyone has moved a feature into the More list and watched it survive.
Replies