Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.x] [tvOS] tvOS Support #58976

Open
wants to merge 11 commits into
base: 3.x
Choose a base branch
from

Conversation

naithar
Copy link
Contributor

@naithar naithar commented Mar 10, 2022

Rework of #45829 and #45830 PRs.
Implements proposal: godotengine/godot-proposals#224

tvOS and iOS platform uses new UIKit platform to share functionality and code.
UIKIT_ENABLED flag is used instead of IPHONE_ENABLED.

Export code is from previous PRs:

  • Launch screen is storyboard based (no need for launch images)
  • tvOS project supports empty Apple Team ID
  • Icons, Signatures and certificates are handled by Xcode project

Mono haven't been ported.
GDNative uses same configuration as iOS platform.
Support plugins that works the same way as iOS, but configuration is using .gdatvp

Related PRs: godotengine/build-containers#71, godotengine/godot-build-scripts#21 will be reworked for tvOS in future.

@@ -260,7 +260,7 @@ class PortalOcclusionCuller {

Occlusion::PolyPlane poly;
uint32_t flags;
#ifdef TOOLS_ENABLED
#if defined(DEV_ENABLED) || defined(TOOLS_ENABLED)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without this change it's not possible to build debug binaries for iOS and tvOS platforms.

@naithar naithar force-pushed the feature/tvos-uikit-3.x branch from d06d02c to ba49259 Compare March 22, 2022 18:28
@jordo
Copy link
Contributor

jordo commented Mar 23, 2022

Great to see tvOS and iOS refactored to a commonish UIKit platform. UIKIT_ENABLED instead of IPHONE_ENABLED is nice

@jordo
Copy link
Contributor

jordo commented Mar 23, 2022

Could we not share the existing xcode .xcodeproj and define multiple build targets within that project, instead of having a separate one to maintain alongside the iOS one? Actually, it would kinda be nice to just have misc/dist/xcode and have separate build targets for iOS, tvOS, and macOS...

@naithar
Copy link
Contributor Author

naithar commented Mar 24, 2022

Could we not share the existing xcode .xcodeproj and define multiple build targets within that project, instead of having a separate one to maintain alongside the iOS one? Actually, it would kinda be nice to just have misc/dist/xcode and have separate build targets for iOS, tvOS, and macOS...

I don't see a benefit in sharing single project with multiple targets for completely different export profiles that have completely different setting for each platform, plugins system and other stuff.
There will be no benefit for a user to have a single project that require them to fill all fields unrelated to their target platform. Without filling them project wouldn't load. iOS, tvOS and macOS can share bundleID, teamID, maybe some more fields, but after that, they come with different configuration that's better to keep separate.
Also separate .xcprojects are easier to maintain in case we need specific configuration without changing non-target platform template.

@jordo
Copy link
Contributor

jordo commented Mar 24, 2022

Could we not share the existing xcode .xcodeproj and define multiple build targets within that project, instead of having a separate one to maintain alongside the iOS one? Actually, it would kinda be nice to just have misc/dist/xcode and have separate build targets for iOS, tvOS, and macOS...

I don't see a benefit in sharing single project with multiple targets for completely different export profiles that have completely different setting for each platform, plugins system and other stuff. There will be no benefit for a user to have a single project that require them to fill all fields unrelated to their target platform. Without filling them project wouldn't load. iOS, tvOS and macOS can share bundleID, teamID, maybe some more fields, but after that, they come with different configuration that's better to keep separate. Also separate .xcprojects are easier to maintain in case we need specific configuration without changing non-target platform template.

Fair enough, we just had quite a few frameworks that are universal and our own workflow is usually out of a single .xcodeproj with multiple build targets instead of multiple .xcodeproj for each platform (iOS, MacOS, tvOS). Seemed like maintaining a single .xcodeproj with multiple build targets might have been easier than 3 separate, (Storyboard, launchscreen, could be shared, or whatever other universal resource or framework).

I think the benefit may come from more in the maintenance of the .xcodeproj template in the godot repo itself (upgrade formats with new xcode versions, etc), not necessarily from sharing bundle ids, team ids, etc from a user's perspective. For specific configuration changes to a platform build target, we've always managed to achieve that pretty simple per target.

But all-in-all, minor suggestion.

@jordo
Copy link
Contributor

jordo commented Apr 15, 2022

@akien-mga is this PR supposed to be added to 4.0 milestone? #58977 is the [4.0] PR.

@Calinou Calinou modified the milestones: 4.0, 3.5 Apr 15, 2022
@akien-mga akien-mga modified the milestones: 3.5, 3.x Jul 2, 2022
@gustaflindqvist
Copy link

gustaflindqvist commented Aug 14, 2022

@akien-mga is this PR supposed to be added to 4.0 milestone? #58977 is the [4.0] PR.

@jordo @naithar Is the minor suggestion of keeping only one .xcproject file hold this PR back from being added to the 4.0 milestone? Or will it might be added to the 4.1?

Would love to be able to support Apple Arcade demands of tvOS as well, when developing for their services.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants