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

iOS export capabilities for non paid Apple dev accounts #19996

Closed
ViktorEvil opened this issue Jul 6, 2018 · 21 comments
Closed

iOS export capabilities for non paid Apple dev accounts #19996

ViktorEvil opened this issue Jul 6, 2018 · 21 comments

Comments

@ViktorEvil
Copy link
Contributor

Godot version:
3.0.4

OS/device including version:
macOS 10.13.5 - Xcode 9.4.1

Issue description:
when exporting from Godot to an iOS Xcode project the capabilities of the project are default to support "In-App purchases" and "push notifications". These capabilities are not allowed in a non paid dev account and trying to disable them in Xcode is near impossible resulting in the user having to manually edit the "project.pbxproj" file with the project closed and even after editing this doesn't always apply the settings.
SystemCapabilities = { com.apple.GameCenter = { enabled = 1; }; com.apple.InAppPurchase = { enabled = 1; }; com.apple.Push = { enabled = 1; };
change to
SystemCapabilities = { com.apple.GameCenter = { enabled = 1; }; com.apple.InAppPurchase = { enabled = 0; }; com.apple.Push = { enabled = 0; };

Is it possible to have these disabled as default and then if a user with a paid account wants them included they can simply tick the in the capabilities settings?

@BastiaanOlij
Copy link
Contributor

Ran into this today as well. I'm going to try to find some time to dive into these. These should be tickboxes in the iOS export imho.

@akien-mga akien-mga added this to the 3.2 milestone Jan 19, 2019
@BastiaanOlij
Copy link
Contributor

BastiaanOlij commented Jan 23, 2019

Ok, something we'll eventually need to add in the docs.

When you enable options in the export that your account hasn't got access too, they are hidden in XCode stopping you from building your game even if you don't need them.

When you do have access to them and you disable them in XCode, XCode will also remove the associated frameworks which will result in your project failing to compile because Godot still links to the code. We need to thus make sure our documentation is clear on this, if you disable game center, in app purchases or push notification in XCode you won't be able to link the project because XCode removes the frameworks.

So I'm currently looking at adding the most common capabilities and selecting/deselecting them in the export window but leaving the associated frameworks in place. The question is whether iOS will allow us building them and deploying them when those frameworks are in place. We'll see.

I'll do some more work around this over the weekend :)

@ViktorEvil
Copy link
Contributor Author

Thanks

@alcroito
Copy link
Contributor

At least manually specifying the StoreKit and GameKit frameworks in the Target -> Build Phases -> Link Binary with Libraries section, after disabling all Capabilities, results in successfully building, deploying and running on a device.

@BastiaanOlij
Copy link
Contributor

@alcroito thanks for confirming that, I had made a start on changing the export logic but been a bit snowed under with ARKit.

I noticed that in xcode unticking capabilities would also remove the related libraries and lead to compile issues as the code is still in the executable, even if it sits unused. Especially for gamekit I think this will need a little more work because even when you turn gamekit off in the capabilities the app will still attempt to initialize gamekit.

This also highlights its best to ensure that we have the capabilities as checkboxes in the export (or at least the ones most likely to be involved in a Godot project) to ensure the correct libraries are still linked even if the tickboxes are off. Along with a warning in the docs that if you change the capabilities in XCode you have to be careful and ensure the libraries are still there.

Anyway, I hope to finish the work soon.

@alcroito
Copy link
Contributor

I agree that adding the capabilities as checkboxes to the export settings makes sense.

I didn't have to disable ARKit presumably because I have an older XCode (9.2) and an older iOS SDK (11.2).

I noticed as well that linking against GameKit with the capability disabled also led to its initialization (I get the sliding-out-popout when I start the app (Welcome back, xxx). But I don't think it's that big of a deal during development. Presumably if you publish to the App Store, you'll buy a dev account anyway, and thus be able to enable the capability.

I would also check if it's possible to either always, or with another checkbox in the export settings, force usage of automatic manage code signing and provisioning. Currently I have to enable it manually, otherwise I can't select a provisioning profile (you can't seem to manually create those with a free account).

@BastiaanOlij
Copy link
Contributor

I'm looking into it, I did a full comparison between the files that Godot currently produces and the files that are properly setup in XCode, they seem to be relatively minor changes for the parts we currently need. Some of the capabilities are more complex but we're not using them (say homekit) so I'll be ignoring them. The automatic provisioning I think is just a switch so I might just turn that on.

The one I had more problems with are some of the older settings in the plists and all the question strings. There are many and the Apple documentation isn't very well structured, they really are all over the place. But I guess if we make a start with the more prominent ones we set a precedent for other developers to expand upon.

@BastiaanOlij
Copy link
Contributor

#25851 adds the required options, it would be good if someone could confirm they can now test without needing a paid developer account. To me it looks like its happy to accept that GameKit and such are compiled into the binary without them being used and privileges being turned off.

Do heed the warning that turning capabilities on/off in xcode will add/remove the required libraries and potentially break your export.

@alcroito
Copy link
Contributor

Hi, I just tested with beta6, given that your PR got in, so thanks.
Unfortunately the process still doesn't work out of the box.

Here are the issues I saw:

  1. Not specifying explicitly the code signing identity, doesn't default to "iPhone Developer". Because of that, when I open the project, Signing Certificate is set to None, and pressing on "Enable Development staging" just resets the team for some reason.

Of course the app doesn't run then, because it's not signed. The workaround for me was to explicitly specify "iPhone Developer" in the Godot export parameter.

  1. Push Notifications capability stays enabled, even though the capability is disabled in Godot. Thus building fails. I can only circumvent it by switching automatic signing off, to disable it in XCode.

  2. iOS deployment target is set to 9.0, which means that at linking I get thousands of warnings that Godot was compiled with deployment target set to 10. We should probably add a select list with deployment targets into Godot's export params, or at least a text field to specify it manually.

  3. It might be useful to document how to get the Team ID for a personal account. It can be found in Keychain Access, as described in the following stackoverflow link: https://stackoverflow.com/questions/18727894/how-can-i-find-my-apple-developer-team-id-and-team-agent-apple-id

@alcroito
Copy link
Contributor

signing_xcodeproj

Here's what shown when Code Signing field in Godot is empty

@samgreen
Copy link
Contributor

I'd like to take on the work to improve the current iOS export from it's current form. Here are my thoughts on these points.

  1. Not specifying explicitly the code signing identity, doesn't default to "iPhone Developer". Because of that, when I open the project, Signing Certificate is set to None, and pressing on "Enable Development staging" just resets the team for some reason.

Xcode does a "good enough" job these days with automatic provisioning profile and certificate selection based on the bundle id. The "fix issue" button it provides can generate missing / new profiles and certificates on behalf of the developer. I agree that we should set the Signing Certificate and Provisioning Profile to "Automatic"

Push Notifications capability stays enabled, even though the capability is disabled in Godot. Thus building fails. I can only circumvent it by switching automatic signing off, to disable it in XCode.

I think enabling APNS and push notifications should be an export option since not all games will need them and having a paid account is a requirement.

2. iOS deployment target is set to 9.0, which means that at linking I get thousands of warnings that Godot was compiled with deployment target set to 10. We should probably add a select list with deployment targets into Godot's export params, or at least a text field to specify it manually.

I believe I have a PR in flight (or possibly merged) that bumps the minimum to iOS 10. This should cover 98% of active devices in reality.

3. It might be useful to document how to get the Team ID for a personal account. It can be found in Keychain Access, as described in the following stackoverflow link:

Agree we should ensure the process is well documented, it's easier than it was a few months ago and once the process is smoother we can focus on ensuring the process is well documented.

@alcroito
Copy link
Contributor

Regarding (1), my point is that there is no "fix issue" button, there's a bug.
Automatic provisioning is already enabled by default, and yet the certificate is not set, even though it exists in my keychain, unless "iPhone Developer" is specified in Godot's export params, otherwise you get the broken state I described above.
Note that when the entry is empty in Godot's export params, it still has a placeholder text that suggests that "iPhone Developer" is the default if you don't specify it. And yet it doesn't work.

Regarding (2) I disagree that a paid account should be mandatory.

@samgreen
Copy link
Contributor

To clarify on point 2. This is not an opinion. I’m saying use of these features requires paying Apple.

@samgreen
Copy link
Contributor

I'm addressing most of these issues now:

https://github.com/godotengine/godot/compare/master...samgreen:ios_export_update?expand=1

I plan to open a PR soon. All of your issues above (except point 4) should be addressed.

@samgreen
Copy link
Contributor

@alcroito #26263 is open now.

@akien-mga akien-mga modified the milestones: 3.2, 4.0 Nov 14, 2019
@alexzheng
Copy link

alexzheng commented Nov 6, 2020

Especially for gamekit I think this will need a little more work because even when you turn gamekit off in the capabilities the app will still attempt to initialize gamekit.

Is this fixed?

It's weird to popup a Game Center login window if your game do not use this feature.

@akien-mga
Copy link
Member

CC @naithar @bruvzg

@bruvzg
Copy link
Member

bruvzg commented Nov 6, 2020

Currently, it can be done by rebuilding export template with game_center=false store_kit=false cloud=false (in both 3.2 and master branches). With #41230 and #41340 it's possible to do it without rebuilding template (Game Center and other are plugins).

@naithar
Copy link
Contributor

naithar commented Nov 7, 2020

Recent changes in Godot's GameCenter also added a authorize function, so iOS's GameCenter popup will not be displayed if it's not needed.

@naithar
Copy link
Contributor

naithar commented Nov 7, 2020

Also with 3.2 having 4.0 changes now merged and objc modules being supported, capabilities should be working correctly for non paid accounts.

@akien-mga
Copy link
Member

So I think this can be closed as fixed already. Thanks!

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

No branches or pull requests

8 participants