Remove tvOS platform from react-native repo

[matthargett]

Introduction

Support for the tvOS platform was contributed primarily by @dlowder-salesforce a few years ago. Due to the SDK similarities between tvOS and iOS, quite a few things became seemingly easy to implement with simple compile-time flags.

Due to a lack of users shipping React Native apps on the tvOS platform, challenging real-world disparities reported by users who have tried porting React Native iOS/Android TV apps to the platform, and the overhead of keeping the build running and working by the Core Team, we think the platform should be removed from the main repo.

The Core of It

As we start to make build system changes to accomodate podspecs, carthage, Fabric, TurboModules, and other upcoming changes, tvOS remains a source of friction.

React Native on tvOS has had two years to build up a user base, but due to underlying limitations of tvOS itself, it seems most people go entirely native on that platform. After several polls on social media, and asking the original contributors, we have been unable to find anyone who is shipping React Native apps on tvOS.

For users who decide to do this, React Native 0.59 is a great release (with Hooks, etc) they can still use. For future releases, we would suggest someone sponsor an out-of-tree tvOS platform plugin, like other platforms (react-native-windows, react-native-linux, react-native-dom, etc) have done very successfully.

Discussion points

1. Can we remove this platform and it's build/ObjC cruft in 0.60?
2. Is there anyone who wants to champion this platform and work on its extraction to be out-of-tree?
3. Should we mention commercial React Native platform providers in the documentation, like You.i TV, which support tvOS and others? https://www.youi.tv/made-with-youi/

[rhdeck]

A case to remove it from core: The build targets for tvos cause a headache for those of us tooling pbxproj files. Being able to trust that the pbxproj contains build and test targets, rather than alien life-forms, would make manipulating that file and providing tooling around native components for iOS much easier.

[matt-oakes]

I don't personally use React Native with tvOS, however, there was a recent contribution to the Lean Core NetInfo package by @hufkens. Maybe they could provide a counter point?

[matthargett]

@brunolemos and @holospeed , can you give some detailed comments on your current shipping (or plans to ship) React Native tvOS apps? or just provide more detail? :D

[hufkens]

We are currenly working on an app for Apple TV, Android TV, Tablets and Phones. The app is almost in beta and will be released. So it is possible in my opinion.

The fact is that there are not a lot of developers making apps for tvOS in general.

[matthargett]

@hufkens thanks for answering! can you elaborate on your projected monthly active users for that platform? are you doing full pass QA on all platforms in parallel? is a commercial vendor like You.i TV an option for the tvOS platform? (if you're trying to cover TV and STBs, they also provide support for Fire Stick, video game consoles, etc).

[hufkens]

We are building a new platform for a TV provider that would be used by thousands of users cross-platform. The main focus would be Android TV, but we also are building an Apple TV app and the Mobile apps. With react-native we can reuse a lot of code between the mobile apps and the tv apps.

We had a lot of issues with the focus engine (both on tvOS and on Android) but these were in most cases related to navigation and stacking screens, (more specifically with react-navigation). We fixed these issues. I've been adding support for tvOS already to several libraries: react-native-netinfo, react-native-screens, react-native-gesture-hander, ...

Adding support is not that hard. Most of the times it's copying the main target changing the platform and it should work. Sometimes you'll need to add some compiler flags for API's that are not available on tvOS.

[matthargett]

This is great information, thanks for sharing it! Is maintaining the tvOS build and reviewing related PRs something your team can contribute to moving forward?

[karlasgeir]

We use React Native for the Vodafone Iceland streaming app on iOS, Android and tvOS.
Today we have around 10.000 users on tvOS and the tvOS app has been in production since October.

We had a few issues when we were developing the tvOS app, mainly build issues and issues with the focus engine not behaving as we wanted it to (especially with react-navigation).
However we’ve put in a lot of work, including writing a custom native focus component and it has been working very well in production.
Also we are managing to reuse around 90% of the code for the iOS and Android apps.

We are a very small team (2 developers) developing tv streaming solutions for tvOS, Android, iOS, Web and STBs, so it is very important for us to be able to reuse as much code as possible.

[kelset]

Thanks for all the feedback so far!

I feel that the ideal solution would be, similarly to other out-of-core platforms like web and windows, to extract it to its own repo; something like react-native-tvos. So that it could follow the same principle of the Lean Core: proper maintenance by developers who use it.

[douglowder]

I'm gratified to see that there are a few developers and companies who are building RN tvOS apps! 👍

At the time my work was merged, the main issues with tvOS were happening when Facebook would push changes to open source master while running only their own CI, not the open source CI. I don't know if this process is still in place or not.

I know podspecs supports tvOS, not sure about carthage. I'll have to think about what Fabric and the other upcoming changes @matthargett mentioned would do from a tvOS perspective.

To answer the questions in the original post:

1. I'd prefer that it not be removed from the main repo, since there is so much code overlap with iOS and the CI for it is already there. If it would be helpful, I can make changes to separate out tvOS build projects and targets. I originally did things that way, but was advised at the time by the Facebook team to keep a single Xcode project in the main repo.
2. If there is a community decision to separate out tvOS into its own repo, I could create and maintain it.
3. It would be great to have tvOS support and apps mentioned in the showcase.

[hufkens]

How would that work then? Now we have the advantage that almost every library can easily be supported because iOS and tvOS are very similar. Only some API’s are not available on tvOS and some extra features (focus) are added.

Also what about Android TV? A lot of the API’s about focus are similar to the tvOS API. Will that then be removed from the core too?

Don’t get me wrong. If this is a better way to go forward let’s do so. But I think it would be react-native-tv and not react-native-tvos which will include tvOS and the Android tv API’s.

[douglowder]

Adding
https://github.com/krzysztofciombor , who was the author of the Android TV PR.
facebook/react-native#16500

[muescha]

@krzysztofciombor

[grabbou]

+1 to what @rdheck said. Multiple targets were an issue for link and CLI from the very beginning since we haven’t designed the system to support multiple targets. It’s doable, but it’s an added complexity that we haven’t had time to support properly yet.

[sergeyzhukov]

I'm voting for extract tvOS support to separate repo, something like react-native-tvos

[douglowder]

@kelset and @grabbou , given the very high overlap between iOS and tvOS code, and the fact that the main point of friction is the presence of tvOS targets in iOS projects, would this issue be resolved by just having separate tvOS project files?

[JoaoPauloCMarra]

Why not react-native init AwesomeProject --withTvOs(optional).
Having separated repo for that would be good idea.

[grabbou]

given the very high overlap between iOS and tvOS code, and the fact that the main point of friction is the presence of tvOS targets in iOS projects, would this issue be resolved by just having separate tvOS project files?

Yeah, @dlowder-salesforce, that would be good step towards decreasing the burden. On the other hand, maybe it's no longer the case, since we are migrating towards CocoaPods. Including @orta and @alloy that work on this feature - would tvOS support be something we can easily handle with CocoaPods?

Regarding keeping it in a separate project, while this is technically good and valid approach, the similarity between these two platforms is an interesting opportunity (aka low hanging fruit).

Technically, I think we should be able to have a separate project, with its separate .xcodeproj files that re-export some of the React Native ones via node_modules and add additional ones.

I am just not sure about the files that use some APIs that are not supported on tvOS. Right now, I think we overcome this by a bunch of macros. While this approach isn't maintainable from the long term perspective, it allows us to share majority of the codebase, which indeed, is similar between tvOS and iOS.

Keeping them entirely separate would increase the effort to keep it up to date.

[orta]

I think even in the CocoaPods world, you'd have a similar-ish experience - it makes it easier for users of React Native to use tvOS, but it probably won't affect the core dev maintenance experience

[elicwhite]

Whatever the plan is for tvOS, it is probably similar to macOS from Microsoft as they’ve also mentioned it shares a significant amount of code with iOS. Maybe @acoates-ms can connect the right person who works on that platform.

[alloy]

(I’m still catching up somewhat on the state of Lean Core, the separation of platform support, and how CocoaPods ties in exactly, but I’d be happy to join a meeting with people actively doing this and see how I could contribute.)

[acoates-ms]

@tom-un would really be the right person to talk about macOS.

The main issue with getting macOS to be out of tree, and this presumably applies to tvOS too is that code is so similar that a couple of #ifdefs in the iOS code basically gets you there. To properly have the core not know about macOS or tvOS we'd have to do massive refactoring to create a base set of "apple" files in core (or even in a seperate apple package that the ios package and macOS packages would both depend on), that we can share without having to change the core.

Given the scope of that work, we are at least waiting until after fabric to do reevaluate what that work would look like.

[douglowder]

@acoates-ms thanks for the explanation. Is macOS already using the same UIKit APIs that iOS does? I remember seeing macOS/iOS unification demoed at WWDC last year, but thought it was still not released by Apple.

[mxmtsk]

It's great to have this discussion and I wouldn't mind a separate tvOS package to get it off the core but abandoning the platform completely would be sad imo.

I shipped a tvOS app built with React Native for a non profit in Germany with around 1000 users. That's nothing compared to the >500k iOS app but porting the iOS app to the tvOS platform was done in no time and I really admired React Native for that.

We're now preparing a launch across Europe and I was a bit sad to see that TabBarIOS was removed in 0.59 cause that was quite vital for tvOS. Feels a bit like RN already leaving tvOS behind, haha. Couldn't find an alternative package for that so it's either implementing our own or not upgrade to 59 for now.

[hufkens]

@mxmtsk We also use the TabBarIOS because other the alternatives provided bij react-navigation and react-native-navigation don't work for us.

We use react-navigation for most of the navigation work, but not for the main navigation because it doesn't work well with focus. They also don't explicitly support tvOS:

• Latest version 3.0.9 doesn't work anymore on tvOS react-navigation/react-navigation#5552

react-native-navigation could work but doesn't have support for `tvOS. There were 2 PR's closed trying to add it. So any help there might work.

• Add support for tvOS  wix/react-native-navigation#4763

• [v2] Add tvOS support wix/react-native-navigation#2012

Isn't there a way to move TabBarIOS (and NavigatorIOS) to a separate community repo, before removing them? The same as NetInfo for example. Because otherwise there is no native navigation option for tvOS. And it's not only an issue for tvOS. A lot of the same Focus issues occur on Android TV also.

[kelset]

abandoning the platform completely would be sad imo.

just PSA: noone is proposing to do that. We are simply trying to figure out the best way to get it maintained while not being an overhead on the main dev cycle for the main repo.

[douglowder]

Ok, given what I just saw about TabBarIOS removal, it seems tvOS is going to be broken unless it gets its own repo. I volunteer to create and maintain that repo. I’d prefer that it be in the react-native-community workspace.... who can give me the required access?

[kelset]

that's great, thanks @dlowder-salesforce! Btw if anyone wants to help you maintaining it it would be great, given that a few developers here seem to be using it extensively!

(are you on the new Discord btw? It would be easier to comm there for the extraction)

[douglowder]

Yep I'm on Discord, we can continue this discussion there. For you sports fans following at home, the new repo will be at https://github.com/react-native-community/react-native-tvos (nothing there yet, so be patient :) )

[kelset]

I'm going to close this an invite you all over at https://github.com/react-native-community/react-native-tvos - if you want to help @dlowder-salesforce please feel free to write here or reach out on the repo or DM me directly on twitter and we'll help you out 🤗

[hufkens]

I'm interested to join the discussion and also contribute. I'm on Discord and Twitter so feel free to contact me.

[tom-un]

@dlowder-salesforce: for the macOS port of react-native (in our ms fork) we wrote a thin UIKit api layer for macOS. This api is in the fork's RCTUIKit.h header. For some types that are semantically very similar between iOS and macOS, like NSColor/UIColor, NSFont/UIFont, etc, we merely made aliases (like @compatibility_alias UIColor NSColor;) with flat C functions for methods that needed iOS and macOS differing implementations like UIFontWithSize() instead of calling -[UIFont fontWithSize:]. For substantially different classes like UIView, we made a mac UIView that subclass NSView and added iOS UIView method implementations. This is very different than what Apple previewed at WWDC which is essentially running the iOS simulator by using macOS UI idioms.

The macOS fork, like the tvOS implementation, obviously relies heavily on the iOS RN implementation. For the macOS and tvOS implementation to live outside of the rn repo, we'd either have to duplicate a ton of ObjC code, or refactor code into shared Apple modules with ios, tvos, and macOS implementations dependent on the core Apple pieces.

[matthargett]

Is there a reason that tvOS or macOS can’t have react-native as a git sub-module and reference the shared code from an xcode project? Having out of tree platforms leverage the platform plugin, rather than mixing custom code in a fork, seems like the better approach for reducing maintenance overhead.

[acoates-ms]

Its not just referencing the code RN, but at least right now adding huge numbers of #ifdef MAC to the ios code which also currently has a bunch of #ifdef tvOS.

To do it properly would involve refactoring all those files into applebase and ios files, in the main RN repo. -- Which I think is still the long term goal. But together with facebook we decided not to try to do all that until post fabric.

[kononenkoAnton]

We use React Native for the Vodafone Iceland streaming app on iOS, Android and tvOS.
Today we have around 10.000 users on tvOS and the tvOS app has been in production since October.

We had a few issues when we were developing the tvOS app, mainly build issues and issues with the focus engine not behaving as we wanted it to (especially with react-navigation).
However we’ve put in a lot of work, including writing a custom native focus component and it has been working very well in production.
Also we are managing to reuse around 90% of the code for the iOS and Android apps.

We are a very small team (2 developers) developing tv streaming solutions for tvOS, Android, iOS, Web and STBs, so it is very important for us to be able to reuse as much code as possible.

Can you please advice what have you done with custom native focus component for tvOS? We are trying to find solution how better can we write our custom focus component

[pavjacko]

There are few differences still hanging around. ie resolution of WKWebView and focus management
FM especially would require some extra attention. because of some of the fundamental differences of tvOS platform I believe it should be treated as separate platform rather than be part of standard iOS flow.
tvOS support is actively used in https://github.com/pavjacko/renative.
I believe RN way forward is to add support for tvos conditional compilation ie index.tvos.js vs index.ios.js

[nihp]

I have some questions about tvos and ios in react-native apps

I am using react-native to build ios apps. Here I found tvOS file in my project. These are the questions

1. Can I run the tvos files without chnaging anything in Xcode
2. If I remove the file does it makes any run time issues while bundling the app
3. What is the main differences of iOS and tvOS files in react-native.
4. What are the files are used by tvos

[zero298]

I have been trying to leverage the react-native-community/react-native-tvos fork for the past few days in hopes of migrating an existing React Native application that already runs on iOS and Android. However, I am having so many issues just getting the application to build or deploy.

First I tried just creating a new project target in the existing workspace, but that proved very difficult. Then I tried initializing a brand new react native project with the default RN commands which failed since I now need to use this fork. Then I tried creating another new project following the instructions in this fork which did let me at least build a tvOS application with the starter code.

However, now that I'm trying to move in all my original code, I get constant problems because none of the podfiles for existing extensions have tvOS listed in their supported platforms (like react-native-reanimated) which causes pod install to fail even though the extension, I would think, would work. This also extends to any unimodules if you are trying to leverage Expo.

If you are going to drop support, please provide some sort of migration path or suggestions on how someone seeking to migrate an existing app which runs on iOS to tvOS can move forward. I knew that touch gestures would obviously not work, but going by the React Native docs which I understand are out of date with respect to this fork, it should all just "just work".

One thought in the react-native-tvos/react-native-tvos#11 discussion is to have a dedicated tvos directory. However, this seems like it would cause more pain points given that most extensions are operating on the assumption that the ios directory means "Apple Ecosystem".

[douglowder]

@zero298 besides react-native-reanimated, what are your other third party dependencies? I will be happy to try and help you if I can.

[hufkens]

@zero298 Your problem is indeed in the 3rd party libraries. Some have tvOS support, but forgot to add the correct platforms in the .podspec file. I already tried to fix some of them by submitting a PR. It's a very small change and library maintainers will be happy to merge it.

Here's an example: zoontek/react-native-localize#70

[benoitdion]

I realize this issue is already closed but wanted to add our 2 cents.

We evaluated react-native-community/react-native-tvos for our tv apps and have currently decided against using it and instead continue building off of core.

• Douglas has done an amazing job building out react-native-tvos but the forking approach really scares us. A lot of the reasons are similar to why microsoft would like to eventually kill off their fork . Unless there's a ton of resources behind them, forks of active projects are very rarely successful.
• With the migration to pods, incremental tvOS specific maintenance should decrease
• pretty much 0 community packages are testing with react-native-community/react-native-tvos so regression risks are pretty high.
• After a few build and set up hurdles, tvOS support mostly just works with RN core alone. As long as nobody removes the #ifdef and PRs like Add missing available guard to RCTInputAccessoryViewContent facebook/react-native#26332 continue getting merged, we should be fine. Peloton intends to continue contributing back tv and focus related fixes to core.
• What doesn't work well out of the box is focus management but we believe focus management shouldn't be specific to tv as it generally applies to accessible and keyboard aware applications too. It's often an afterthought but is actually super important as apps mature and audience diversify. We currently have a custom solution for this that, when proven internally, we'd like to contribute back either to core or to a community repo. A lot of this applies to android as well and can be cross-platform.

We'd like folks reading this issue to reconsider dropping support for tvOS from core but instead continue merging PRs that

• Include things like #ifdef fixes and minimal conditional logic
• podfile tweaks and optional tvOS tooling
• addition to a focus system and/or extension points to enable creating one in a community repo.

[douglowder]

@benoitdion -- I do agree that having a fork is not ideal.

However, tvOS really is not supported any more in core, even though it may almost work "after a few build and setup hurdles". There is no longer any CI to make sure that tvOS even compiles. The #ifdef TARGET_OS_TV macros can be removed or broken at any time, and the focus guide and menu button improvements from react-native-tvos are not there. Also, I think it's likely that Fabric will require quite a bit of work to run on tvOS, and that will not happen in core.

If the core team would like to change their minds and go back to supporting tvOS, that would be great, and I personally would love that.... but I don't think that's likely to happen.

See this comment for why I made the tvOS repo a fork and not a module.

Right now, I think the big gaps for tvOS are

• third party libraries
• Detox testing

and those are issues regardless of whether tvOS is supported in core or not.

P.S. Once it's ready, I'd love to see your custom solution for focus management! :)