View your CI Pipeline Execution ↗ for commit 4563f45

☁️ Nx Cloud last updated this comment at 2026-05-07 22:07:40 UTC

This does not supersede or replace community's material components, this just provides the baseline to give best of class on both platforms out of the box since TabView already uses modern iOS API's with glass and on bottom - this now provides consistent expectations to both.

I think this is a bit sudden and doesn't feel very practical to add a heavy dependency like material just for TabView.
@NathanWalker Core simulated the look 'n feel at a certain point in v6 (BottomNavigation and Tabs?) and there are still some leftover java classes in ui-mobile-base we could probably reuse.

https://github.com/NativeScript/NativeScript/blob/main/packages/ui-mobile-base/android/widgets/src/main/java/org/nativescript/widgets/BottomNavigationBar.java
https://github.com/NativeScript/NativeScript/blob/main/packages/ui-mobile-base/android/widgets/src/main/java/org/nativescript/widgets/TabsBar.java

This link is from BottomNavigation back then:

• if can provide alternate way for TabView to provide consistent experience other route, feel free to try in alternate PR
• TabView provides glass tabs (best of class) on iOS
• TabView on Android does not match that experience (I'd argue right now it provides worst in class experience)
• the dependency case is a concern because it brings it in for anyone using core (whether they use TabView or not)

I believe only other alternate view is to just remove all ui components from core and make them all ad hoc pick your own one at a time for each project which there’s a good case for that if clear and easy enough to browse best in class options altogether in official docs. Plan bigger move like that for v10 or v11.

I agree 100% with @CatchABus and it was my first thought when I saw the PR.

• you cant compare IOS design vs material on android. material comes as a dependency and not included In android by default. I think there are multiple reasons for that, one being faster Releasing cycle. However if we follow the basics of core following the platform and other features coming as plugins it should not be in core. And I think it should NOT be in core. Material.components are here exactly for that. And we can still create templates with them added by default
• that dependency is huge and with the things we keep on adding N is becoming a fat framework which it should not. I always said that (I think the same with the runtimes). And I even think I am the one which had it removed in N 6 or something. and remember N still does not support correct tree shaking and proguard yet without tricky integration like I do. If we did things would be a bit different even though still mean longer build for no reason for everyone not using it.

I do believe this PR should not get in.

Let's close this, we'll continue chats in discord on the ui decoupling.