@nativescript/core and @nativescript/ui-mobile

[NathanWalker]

@nativescript/core currently provides a suite of standard utilities and low level classes for it's fundamental behavior in addition to providing a suite of Mobile specific (ios/android) ui classes altogether.

Proposal: Split the ui folder in core out into a separate package @nativescript/ui-mobile which provides the exact same structure but in a separate package.

Prior art: NativeScript potential use cases and applicability are broader than just iOS/Android mobile development. Splitting out the UI classes to a separate package will allow better natural scalability into other platform development.

Benefit: Allows a slimmer core to be installed with other platform development when the UI layer may not be needed (Ionic for example when just using {N} for SDK integrations and not using UI layer). The naming scheme allows a natural evolution of expansion into Desktop development by providing a future @nativescript/ui-desktop.

There is also the potential that @nativescript/ui-mobile could be a convenient rollup of @nativescript/ui-ios and @nativescript/ui-android if we want to have the granularity in flexibility. As we know well that some teams and efforts may only desire one platform or the other for any particular reason. This allows a path forward for more specific platform goals and timelines which may only need one or the other and not both by default.

Since {N} 7 introduced a singular @nativescript/core import barrel this makes it possible to create an easy AST walker migration handler which would just move UI import symbols into a @nativescript/ui-mobile import barrel via ns migrate

[shirakaba]

The React Native team have regretted for years having to group up two platforms (Android and iOS) just because they’re the same idiom (mobile). They’re gradually planning to split them out, but it’s years of tech debt to unravel.

Rather than the idiom-based names ui-mobile and ui-desktop, I would suggest platform-by-platform names: ui-ios, ui-android, ui-macos, ui-windows, ui-linux.

For UI frameworks like Qt that target multiple platforms, naming after the UI runtime itself, e.g., ui-qt, would be acceptable.

Edit below:

I'm totally in favour of splitting out ui, but I'll vote a thumbs-down if the proposal is to use the name @nativescript/ui-mobile. Bear in mind that there are many possible ways to deliver desktop UI (Qt, Flutter, AppKit, UIKit, React Native macOS, Ionic, Electron, etc.), so naming as @nativescript/ui-desktop would be restricting ourselves to one possible canonical implementation.

As we already have completed iOS and Android implementations, I think it would be fair to name those @nativescript/ui-ios and @nativescript/ui-android, but future implementations should use the name of the UI runtime (e.g. @nativescript/ui-ionic, @nativescript/ui-electron, etc.) to allow different approaches for tackling the same idiom.

In cases where the UI runtime differs substantially between platforms, sub-namespacing would be acceptable, e.g. @nativescript/ui-uikit-macos, @nativescript/ui-uikit-watchos, and @nativescript/ui-uikit-tvos.

In cases where the UI runtime differs substantially between idioms but not platforms, sub-namespacing would again be acceptable. e.g. @nativescript/ui-qt-desktop and @nativescript/ui-qt-mobile.

To reiterate, I am only opposed to implying one canonical implementation per platform (as the naming @nativescript/ui-desktop would).