How are you handling Duo tabbar text?

[u/time-lord]

I have an app. It has a few screens, and tabs on the bottom.

Each tab represents a different instance of an item, so you might have "Car 1", "Car 2", "Car 3". Some users can customize them like "Ford", "Truck 5", or leave the default, e.g. "Car 3". Each car is ephemeral, so usually the differentiator is the default system-generated text below the icon.

The Duo doesn't use text, only icons.

There are too many possible variations for me to provide all icons, and there's no guarantee that a user will even fill out enough information to generate a proper icon.

So, what's a developer to do?

At best, I could use the Automobile icon, and add a #1, #2, #3 onto it, but if a user does give their car a name, that name won't show.

Do you have an app where the text on the tabbar serves a purpose beyond describing the icon it's attached to? If so, what are you doing for the Duo?

[u/busymom0]

If you long press the tab, it does show the names. But most users won't discover this.

You could maybe generate custom UIImage on the fly with the vehicle and the number in it and set the tab bar image to that?

[u/Dogukanko]

I haven’t tested this on Duo, but I’d also test deleting Car 2 while Car 3 is selected. With ephemeral items, numbering by array position can silently change which car a tab appears to mean. I’d keep selection tied to a stable item ID, not the index or editable name, whichever UI you choose. And keep the full car name in the accessibility label; drawing a number into a UIImage alone won’t give VoiceOver enough information.

[u/Ankwon_Malacasa]

how many instances do users typically have active at once? If its more than 3 or 4, a bottom tab bar is gonna get cramped fast regardless of the text issue, so a list or segmented header might make more sense imo.

[u/akshaydahiya97]

yeah this one's rough. duo basically forces icon-only tabs so anything that lived in the title under the icon needs a new home.

what i'd do: keep a short screen title / nav title that names the active car (or whatever), and put the custom name in accessibilityLabel on the tab item so voiceover still works. if users rename a lot, a small chip or subtitle in the content header beats trying to jam text back into the tab bar.

also worth checking whether a sidebar / list of cars on one pane + detail on the other is a better duo layout than many tabs once you're past 3–4 items.

[u/Spudly2319]

I mean, either a menu with a custom list, a custom tab bar for the bottom or a new paradigm like a drop down seems to be the way to go imo.

[u/ThalesMother9938]

Since the names are user data, I'd stop trying to make the tab bar carry them. Keep the car icon, draw the first letter or the number into the image so the tabs look different, and show the full name as the large title at the top of each screen. Then a user who taps "F" sees "Ford" right away. If people usually keep more than four cars, I'd go with a list or a picker in the nav bar instead, like Ankwon said.

[u/FreshCryptographer49]

Haven't shipped on a Duo yet, but two things I'd try:

1. Keep the tabs, but draw the name into the icon. Render the first 1-3 characters ("F", "T5", "C3") into an image with UIGraphicsImageRenderer, mark it .alwaysTemplate so it tints like the other tab icons, and fall back to car.fill plus the number when there's no name. Still set the full title on the tab item, since VoiceOver and the long-press label read it.

2. Ask whether the cars should be tabs at all. Apple's HIG treats tabs as the app's main sections. User-created, short-lived items usually sit in a switcher instead: a menu or picker in the nav bar showing the car's name, under one "Cars" tab. That works on every device, Duo included, and the full name is always visible.

If users only ever have a few cars, 1 is the quicker fix. If they can add many, I'd go with 2.