Add Support for tvOS

[ghost]

Latest status: #47928 (comment)

---

@lesnitsky commented on Dec 24, 2019, 4:08 PM UTC:

I'm trying to build Flutter.framework for tvOS and getting this error. Is there a way to workaround this issue?

This issue was moved by devoncarew from dart-lang/sdk#39918.

[ghost]

@lesnitsky commented on Dec 24, 2019, 4:10 PM UTC:

https://github.com/dart-lang/sdk/blob/master/runtime/bin/process_macos.cc#L164

[ghost]

@devoncarew commented on Dec 28, 2019, 8:15 PM UTC:

I'm not sure that tvOS is a supported iOS target for Flutter; will move this issue to the flutter repo.

[iapicca]

I took the liberty to change the title

#2058 (comment)

[lesnitsky]

Just to be clear: I'm not asking for official support of tvOS from flutter team, just some guidance on how to get things working... as per update from @mraleph fork and execvp shouldn't be critical in order to make flutter work, but I didn't have a chance to revisit apple tv build yet

[jmagman]

From dart-lang/sdk#39918 (comment)

I don't think this should have been moved.

HOST_OS_IOS is 1 if TARGET_OS_IPHONE, so watchOS, tvOS, Catalyst, etc. But it looks like HOST_OS_IOS is synonymous in dart-lang with iOS-only.

           TARGET_OS_IPHONE          - Generated code for firmware, devices, or simulator
              TARGET_OS_IOS             - Generated code will run under iOS 
              TARGET_OS_TV              - Generated code will run under Apple TV OS
              TARGET_OS_WATCH           - Generated code will run under Apple Watch OS
              TARGET_OS_BRIDGE          - Generated code will run under Bridge devices
              TARGET_OS_MACCATALYST     - Generated code will run under macOS

I believe @lesnitsky is asking for "sdk/runtime/bin/process_macos.cc" and friends to handle TARGET_OS_TV functions.
https://github.com/dart-lang/sdk/blob/master/runtime/bin/process_macos.cc#L164

@devoncarew I'd like to close this Flutter issue, but will wait until dart-lang/sdk#39918 is re-opened.

If supporting tvOS or watchOS was going to be supported in Flutter, @lesnitsky's request for dart to not just crash calling fork or execvp or other forbidden functions would be a dependency.

[jwoelke]

We shared a solution that shows that flutter based application can work on Apple TV.
See https://github.com/LibertyGlobal/flutter-tvos-demo

[jmagman]

@jwoelke That's really neat! Are you intending to send PRs to the impressive number of repos you had to edit to get this working (buildroot, engine, dart, and skia)?

[xster]

Bitcode can be turned on but it looks like we're inlining the AOT assembly into the bitcode container rather than compiling Dart code to bitcode (#46707 (comment)).

Wonder if "bitcode enabled" projects as such can be submitted to the App Store since Apple does seem to be monitoring for these, as seen in https://developer.apple.com/forums/thread/660365

ITMS-90562: Invalid Bundle - Bitcode failed to compile for your watchOS binary because it includes assembly source code or inline assembly. To resolve this issue, rewrite the corresponding code in a higher-level language such as Objective-C or Swift and redeliver your app.

though that's for watchOS.

@jwoelke, have you tried to submit an archive to TestFlight?

[lesnitsky]

yes, apple accepted AppleTV app and we were able to install it via testflight

…

On Wed, Apr 14, 2021, 10:09 PM xster ***@***.***> wrote: Bitcode can be turned on but it looks like we're inlining the AOT assembly into the bitcode container rather than compiling Dart code to bitcode (#46707 (comment) <#46707 (comment)>). Wonder if "bitcode enabled" projects as such can be submitted to the App Store since Apple does seem to be monitoring for these, as seen in https://developer.apple.com/forums/thread/660365 ITMS-90562: Invalid Bundle - Bitcode failed to compile for your watchOS binary because it includes assembly source code or inline assembly. To resolve this issue, rewrite the corresponding code in a higher-level language such as Objective-C or Swift and redeliver your app. though that's for watchOS. @jwoelke <https://github.com/jwoelke>, have you tried to submit an archive to TestFlight? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#47928 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPYUNW2FYX6CYFD5YISTYDTIXR7DANCNFSM4KARUFCQ> .

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

[workerbee22]

Given that Apple has now deprecated the requirement for bitcode, any new approaches here?

Apple Reference to deprecation of bitcode

"Starting with Xcode 14, bitcode is no longer required for watchOS and tvOS applications, and the App Store no longer accepts bitcode submissions from Xcode 14."

I would think that this changes things and makes them easier to get Flutter apps to tvOS?

[jmagman]

It would involve code changes in the buildroot, and some changes to Dart and Skia (if we aren't totally off Skia and onto Impeller by then).

Most of the work would be adding an entirely new embedder in the engine, as well as test harnesses. We are working on some refactoring in the Flutter engine that should, in theory, allow more code to be shared between macOS, iOS, and future embedders like tvOS or watchOS. I would also expect some new fresh gotchas around platform view and threading models.

To get it working from flutter_tool and not just Xcode, wireless debugging would also be a prerequisite since there is no USB tether option on the TV. Once that's done, it would need to be added a new target device type.

We would also need to start supporting the tvOS simulator runtime in CI to run tests (sounds easy but nontrivial), since keeping physical TVs upright in the device lab is probably not feasible. Last I checked they required a display hooked up to run XCTests, and the wireless-only devices are practically impossible to keep tethered in a lab setting. No physical devices in CI makes real world performance regression detection also impossible.

There would also likely need to be some work in the framework/engine to account for differences in the the Apple TV remote, different keyboard, etc. There would also need to be a new tvOS design language like cupertino, but it's unlikely that would live in Flutter framework-proper.

The proof of concept at https://github.com/LibertyGlobal/flutter-tvos-demo shows it can be done. Implementing it the first time is x amount of work and detecting regressions, keeping up with new Apple features and deprecations, and keeping testing infrastructure upright is 10x amount of work, and has to be maintained as a first-class platform like Android, web, macOS (many engineers work on each of those platforms) forever.

[workerbee22]

Thanks for the overview @jmagman thats a great summary of achieving official and full support for tvOS. Clearly significant work over a long period of time. The PoC also highlights how many changes and limitations apply.

Given the relatively small marketshare that Apple TV and tvOS have, official support may not be worth the effort, when other things may be of higher priority.

Partial Support (like Android/Google TV)?

But perhaps official and full support is a longer term goal. Perhaps partial support is a more pragmatic approach. Similar to Android TV/Google TV (essentially Android with a custom launcher). Flutter does not officially support Android TV/Google TV but it can be done with not too much additional effort. This is because we have adb connect over ethernet for connectivity and they are essentially Android devices. Not sure if Apple TV and tvOS still support Ethernet connectivity to the device for debugging. So there is no special documentation, guides or flutter_tool support. But we have enough to get the job done; so it is partial support?

Perhaps tvOS could also get some degree of partial support where the embedder is in the engine, with build root, Dart and Skia/Impeller updates? So at least we could then remove the general developer effort to update and rebuild the flutter engine and could get to tvOS as a new target device type? Could then approach like early web and desktop targets ie. CLI to enable for a project and initially unsupported.

[jmagman]

Perhaps tvOS could also get some degree of partial support where the embedder is in the engine, with build root, Dart and Skia/Impeller updates?

Including testing and maintaining it over time, that's essentially the bulk of the work 🙂, you're only leaving out the tooling/IDE and ecosystem/pub changes. The wireless debugging isn't the hard part, though it is a blocker to getting the tooling piece working.

Instead of supporting Apple TV as a first-class platform, Flutter and Dart could do the minimum amount of work (but still a lot of work) for an Apple TV custom embedder to be written by an engineeringly proficient and dedicated customer. eLinux is one such example, written and maintained by Sony. Custom embedder developers need to maintain their own custom embedder build rules, tooling, plugins, and test harnesses.

In the case of Apple TV, a custom embedder would not be able to share any code between the existing Flutter iOS and macOS embedders, tooling, or plugins, though all could be forked/copied from what exists and maintained by the custom embedder author over time. Impeller custom embedder support is tracked at #112230.

Dart and Skia would still need to be updated and tested for a custom embedder work so that it explicitly has the correct behavior on tvOS. There are many places in the code with platform-specific conditional checks like this:
https://github.com/dart-lang/sdk/blob/24683da915867609b9b52bd2124e6fb603b9f160/runtime/vm/os_macos.cc#L133

Flutter does not officially support Android TV/Google TV but it can be done with not too much additional effort.

The Android/Android TV analogy is more like iPhone/iPad support (at least as I understand it, I'm not an Android developer)--both are really iOS under the covers with some minor differences, like Pencil or Stage Manager support.

The tvOS and iOS APIs are more similar than between iOS and macOS (they are practically the same), so there's more opportunity for code sharing in the embedder, especially once #112232 is complete. But Apple TV is extremely different from Android TV in this case, from Apple's development perspective it's an entirely different operating system, different SDK, simulator. The Xcode xcodebuild tooling between all the darwin platforms is similar, so again that's not the hard part.

[workerbee22]

Thanks for clarifying @jmagman that gives us a better insight and a work breakdown. Feels like we are getting closer to identifying the MVP for tvOS support, but still much more work than I realised 😁

ps. one more thought on how to approach this ... Windows is officially supported as a target, and yet its Design system Fluent is not directly supported in Flutter with specific widgets. So there is a separate unofficial package for it Fluent UI to implement UI specifics for the platform. For tvOS we could take a similar approach and leave out specific tvOS design system work initially.