Platform Request: `react-native-tvos`

[TheUltDev]

Proposal

Can the https://github.com/react-native-tvos/react-native-tvos platform be added to this project?

Alternatives

Alternatively schemes could be added, I'm unfamiliar with what changes the tvos fork adds, it may be possible to support it in another way.

Implementation Details

I assume tvOS could be implement in a similar was of how visionOS is implemented

Additional Context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[kelset]

Hey there! Thanks for asking - the short answer is similar to the one we gave for the RNWeb issue: "sure, why not".

But of course there are a few considerations that we need to be kept in mind: adding an extra platform always adds complexity, and because we don't use tvOS internally we'd need to have an external owner for this that would make sure to keep RNTA's support up to our standards.

You asking did push us to engage with a some of the key players in the tvOS space and we'll be exploring viability (also given things like the fact that the actual tv OSs ecosystem is much more fragmented and inconsistent than something like the Apple ones), but no promises at this point.

[mojavad]

Heya! Just to add on to what @kelset is saying - the fragmentation is quite large in the TV space, so it could include:

• tvOS
• Android TV (which also includes the FireOS ecosystem)
• Tizen (which is web based)
• WebOS (which is also web based)
• and many more

The number of OSs is only increasing (for example, Sharp recently announced they're launching their own OS) 😬

Having worked on several RN TV apps, we've found that most large scale TV apps will want to support not just AppleTV and Android TV, but most of the web-based platforms as well.

Effectively, this means that it's a large task to maintain RNTA for all of these (tvOS, Android TV, & RNW).

Out of curiosity, @TheUltDev, which OSs are you particularly interested in?

[TheUltDev]

@kelset thanks for the prompt reply and the engagement.

@mojavad I was mainly interested in adding tvOS + Android TV in the existing pipeline through https://github.com/react-native-tvos/react-native-tvos.

I do realize there are other tv OSes, but as pointed out they are mostly all web-based. I am handling the web-toolchain differently so it's of little concern. I plan on accomplishing that by supporting multiple wrappers around the RNW build (this could also include Tauri for linux and other unsupported desktop platforms)

I do think the web-based tooling is out-of-scope of this project. That is my speciality so maybe I can contribute it to this project once I'm more familiar with it. For now I'm handling it separately.

For reference, I'm building a cross-platform framework that supports as many platforms as possible:
https://github.com/kat-tax/exo (https://exo.ult.dev)

The web tooling is located here fyi:
https://github.com/kat-tax/exo/tree/master/toolkit/web

I'm currently evaluating RNTA's use-case in building production apps via singleApp mode.

[mikehardy]

Having react-native-tvos support as a narrowly scoped item, via support for https://github.com/react-native-tvos/react-native-tvos/ alone is useful - I'm frequently requested to maintain and/or verify support for tvOS in a few of my repos and I have no easy way to know if new PRs use APIs not available in tvOS so I've regressed support previously.

I can't see a future state where TV fragmentation is supported by anything other than modules-per-fragment so support for react-native-tvos as a narrow item seems like part of any maximal solution anyway, that is, it may only be incremental but it is necessary regardless thus reasonable as a first step even if thinking of maximal TV fragmentation support.

The other frequent request that also gets a "sure, why not" would be web support, but that's already tracked of course

So: if react-native-tvos support was PRd here, I assume this would be received well? Not committing to it, and even if I were, no timeline, but want to get confirmation before even thinking farther

[Saadnajmi]

My two cents I think one challenge with tvOS is they would have to publish more standard version numbers (0.76.0, 0.76.1 instead of 0.76.0-0, 0.76.0-1). When react-native-visionos used the same scheme, we couldn't add visionOS support here till they went to standard semver.

[mikehardy]

@Saadnajmi great input, did not even know that I did not know that. Do you have a reference for this in repo? I see you did the visionos integration in #1803 (awesome!) just not sure on the technical reason why using optional (but valid semver) build version components is a blocker here

Perhaps a question for @douglowder ? Doug - it appears the current versioning scheme is an active barrier to react-native-test-app support for react-native-tvos. Is this something that react-native-tvos feels strongly about? If so, can anyone think of a workaround for it? (Perhaps some work here would make it so it was possible)

[douglowder]

@mikehardy Ok I'll block out some time to have a look at this, now that RNTV is up to the 0.76.1 level. Probably get to work on it seriously after Expo SDK 52 release.

Hopefully some day, I can figure out how to have RNTV work the same as other out of tree platforms... but the issue is that Android TV requires separate Maven artifacts, so right now it's much easier to have it be separate and actually replace the RN dependency for TV apps.

I'll see if the issues with test-app can be resolved without needing to do the above 👍

@Saadnajmi I had the impression that having a prerelease number in the version is part of standard semver. What if you wanted to test a RN core version like 0.76.0-rc.6, for example?

[Saadnajmi]

I should say my commenting isn't any indication on landing anything in RNTA (I don't maintain the repo), I was just commenting on my experience. And TIL that the pre-release number is part of standard semver.. so that's interesting. I can't find the original thread, but it messed with some of the version resolution (perhaps in Ruby scripts) that RNTA did.

I see the value of knowing which patch version of RN that RN-out-of-tree platform coincides with, if simply so you can use the same version of Hermes. For RNM, I was thinking of setting the RN patch version as a peer dependency to signal that.

[douglowder]

@Saadnajmi hopefully in 0.77 (or maybe sooner), TV will just use the Hermes artifacts from core, so the RN patch version will be the same for all.

[tido64]

IIRC, the problem is how semver is calculated by package managers. RNTA typically wants to support a version range e.g., 0.70 - 0.77, but if you input this in https://semver.npmjs.com, you won't get any releases:

Edit: An alternative is that we explicitly list all minors, but this can get unwieldy:

(It's also really weird that >=0.73.0-0 only returns prereleases for 0.73.)

[tido64]

So: if react-native-tvos support was PRd here, I assume this would be received well? Not committing to it, and even if I were, no timeline, but want to get confirmation before even thinking farther

@mikehardy: We spoke in the web thread, and my answer is the same here. Yes, we can add it. But only if you (or others) are willing to support it.

[mikehardy]

🤔

Edit: An alternative is that we explicitly list all minors, but this can get unwieldy:

I'll freely admit, that is not awesome. However, the minors list is at least constrained. That is: you are about to drop a bunch of minors - 0.66 through 0.70 - meaning that in practice it appears the list would be 10 minors long before trimming and somewhere between 6 and 10 minors will be what it bounces between.

A quick utility function to generate the version range is possible, but even maintaining it by hand is - again - admittedly not awesome but may actually work

And this may be the only technical way it would work. They are valid semvers so it should be possible, and out-of-tree platforms should be workable without constraining them to a semver subset in my opinion, if there is a workable solution

[tido64]

Just to be clear, I'm fine with it if there is no other way. We only change the numbers a few times a year so I think we can manage.