Root view as tabbed swiftui view

[TAKeanice]

This is a working preview of the tabbed root view, mostly generated by Claude with my guidance. I have not completely reviewed the code yet, but all basic functionality works, which I can say from basic UI testing.

[timbms]

Looks very nice and good to me.
I got many compiler warnings on the first compile. Strange
I am not a full screen user. I assume @digitaldan will have some feedback.

[TAKeanice]

@timbms the compiler warnings could stem from the version requirement which I pumped up to iOS26 for now (will implement some backward compatibility later).
Another source could be the added package dependencies in the Core package, XCode was very resilient in not recognizing them for a couple of times I tried to compile.

[digitaldan]

So i'm not in favor of this approach for a couple of reason. First is that in my very long experience with openHAB, users primarily use sitemaps or the main UI, they don't frequently flip back and forth between the two. Our app does not offer other frequently used features either that a user would often navigate to. So having a permanent menu, taking of space to just show 4 things that once the app is setup, are not actually used much does not seem like a good design choice to me. The other thing is that while we don't typically coordinate too much of our look and feel with the android app, mostly in menus and extra features, this would be a departure from how a primary view of our mainui or sitemaps work from them, having a permanent menu floating above the user's primary content.

I think the floating menu work @timbms is doing is great and really modernizes the look and feel, so my vote is to keep developing that strategy and not pursue a menu bar.

[TAKeanice]

This was based on a discussion I opened some time ago, where it sounded to me like the decision was to go with a tabbar.

I don't think UI consistency between Android and iOS is very important, otherwise we would do much better using a cross-platform approach. Feature consistency would be nice though.

Using a tabbar is what has been recommended by Apple for years, and with iOS26, it neither has to take up the whole bottom nor do we have to show all tabs at once. That part is configurable in the settings. So every user can decide on what they like to use. On iPad, the tabbar can appear as side menu instead, to be out of the way. I dislike having two sidebars though, one in the home view and one for the application frame, that has always been confusing and inconsistent to me. There has been the added issue that the right side menu has been reachable by a swipe gesture, but that was not obvious at all and there were many situations without a visual navigation option (neither back nor to open the side menu). The tabbar, which is always accessible, improves on that by the well known tap-to-return feature, where a second tab on the selected tab brings the user back to the first page.

[TAKeanice]

I can imagine a tweak on the current tab bar approach though:
We could allow the users to configure tabs for individual Sitemaps, tiles or MainUI paths, resulting in a very customizable experience tailored to exactly how users want the app to work.

For iPad, I need to play around a little before I can envision the best solution (I think sidebarAdaptable is very neat).

[timbms]

I clearly favor the tabbed view over my proposal. To me, it simply feels like the more natural and future-proof direction.

The screen space argument is understandable, but with the display sizes of modern iPhones, I don’t see it as a decisive constraint anymore.

Cross-platform alignment between Android and iOS is not a goal I would prioritize. I believe each app should lean into the native interaction patterns of its platform.

We’ve already seen how the SideMenu “hamburger” approach felt somewhat odd on iOS. I’d prefer we fully embrace the native conventions.

[DigiH]

If I may …

I find this even worse and more distracting than the previously mentioned and settings disableable search field - just out of curiosity, how would the search field be also displayed along with these other tab items?

But as it currently stands:
Home - I never use MainUI., Why should a constantly visible Home tab be there to distract me when it is completely useless for me? I would assume the same applies to other users preferring sitemaps.
Sitemaps - I have one sitemap for the iOS app or for viewing in a desktop web browser, and one sitemap for the Apple Watch. Again, why should there be a constantly visible Sitemap tab, when I never need it to switch between multiple stumps. Also again, I think most sitemap users have little need to constantly switch between sitemaps. And why should users mainly using MainUI be distracted by a useless Sitemap tab?
Tiles - apart from having tried the available two options once in the past I never use any of these options and therefore find a quick access tab at the bottom more distracting than helpful.
Settings - obviously needed, but does it have to be on top of the sitemap? What was wrong with how it is currently accessible?

I do understand the temptation to implement new UI elements, but they should only really be used if the tabs actually include frequently functionality - GitHub Mobile is a good example for this.

Introducing such a tab bar, just because one can and because it looks cool, but populating it with rarely or never used functions, is the wrong way to go in my eyes.

Just my very personal 2 cents worth.

[TAKeanice]

Hi @DigiH ,

the tabs you mentioned are configurable, even in the current draft state of this PR.
A search bar as right side button next to the tab bar has become standard functionality in apps (see GitHub mobile), but has not been implemented yet, thanks for the suggestion.
The "new" UI element is not for the novelties sake but replaces the side menu's poor UX, so there is nothing really new about it, just a different placement which makes the app clearer and more aligned with iOS interface conventions.

I really like discussing this approach, and I am very open for ideas and changes although I will of course argue for my rationale, but please take a look at the considerations that have already been made, the suggestions in other posts, and maybe actually install and try the solution first, to contribute constructive progress to the topic.

[TAKeanice]

@timbms thank you for the input, very relieved to read someone liking the approach :) I will still try and make the tabbar contract when scrolling though, because I think this will be convincing for users that only use one of the tabs (e.g. Home or one particular Sitemap) 99% of the time.

@digitaldan and @DigiH what do you think about the minimizing tabbar improvement and about the suggestion to make the tabbar even more configurable, allowing tabs for individual sitemaps, tiles or MainUi paths?

[digitaldan]

I'm really sorry, but i do not like having the tab bar visible by default or at all. Our app is simply a viewer for a user's sitemap or main ui, thats where the user customizes the look and feel so it's consistent among all platforms, web, ios or android, our app should get out of the way of that as much as we can.

I stand by my earlier argument, and i think @DigiH makes this point as well, which is we really don't have a use case for frequent switching between parts of the app, so we are just implementing a new UI feature for its own sake.

[DigiH]

I assumed that the tabs might be configurable, but is the whole tab option. , with or without the search option, configurable optional as well?

Let me explain how I approach app UI design.

• I I look at what the main objective of the app is. In case of the openHAB iOS app I think this is nicely displaying either a sitemap or MainUI elements, ideally as clearly visible as possible, without parts of it being covered by unnecessary UI elements - unnecessary here for the main objective.

That is why I proposed making the Search Field optional , as I have never found any use for it, nor can I think anyone would with a well structured sitemap.

I cannot think of any burger menu option or setting which I would want immediately accessible on top of my sitemap.

II'm not saying that some users might not welcome such shortcuts to some of the options and settings. There might have been issues here or requests for it in the forum I am unaware of.

BUT PLEASE make it optional, and don't force it on all users, some of which might just find it unnecessary and distracting, it taking away screen real estate for the main objective.

Just imaging the Books app not having the option of displaying book text full screen, its main objective, without any distracting tabs below or controls above.

[TAKeanice]

Hi @DigiH , after the previous discussions here, and with the incompatibilities with WebView and more shortcomings that the Tabbar currently has, I would not want to follow this design any more.

I like my idea of having the main menu of the app configurable, but otherwise I think a button in the top right that opens a popup, like in one of @timbms drafts is overall the better choice for now.

So what do you think of a popup menu that sits where the side menu did before (although I'd want to not hide it when there is a button in the MainUI, this just causes technical issues), which is fully configurable with a settings button and buttons for the most needed sitemaps, MainUI pages and homes?

Please don't jump to conclusions regarding the design, if this sounds too vague for you yet, I will make a prototype anyway!

[DigiH]

I like my idea of having the main menu of the app configurable,

Are you still talking about an always visible menu bar for which the individual buttons are configurable, or a setting to make it configurable if such a menu would be visible at all or not?

but otherwise I think a button in the top right that opens a popup, like in one of @timbms drafts is overall the better choice for now.

I generally like popup sheets, when they are appropriate, but if I understand you correctly this would also mean the settings in a popup sheet, and then if using the Bonjour Browser its popup sheet over an already existing popup sheet? I'm sure the UI guidelines have something to say about this somewhere ;) but I might also have complrel;ty misunderstood you.

Please don't jump to conclusions regarding the design, if this sounds too vague for you yet, I will make a prototype anyway!

I think that might be the best idea, so that everyone can see exactly how you envision it. And as direct and open I am with my opinion, I'm just as open to change my mind if something better comes along. And ultimately it's the decision of everyone else as a group.

[DigiH]

@TAKeanice apologies for editing your post! I was so sure I hit Quote and was in my own reply.

That's what can happen when I'm rushing to get to dinner ;) laters …

@DigiH no problem, I can return the favour :D have a nice dinner!