application-identifier entitlement in Simulator

[dflems]

#63 describes how entitlements are not applied unless a provisioning profile is set. To an extent, this is an expected behavior as some entitlements require replacing variables like $(AppIdentifierPrefix) which require a provisioning profile in order to get that value.

This gets a little trickier with Simulator builds as they do not explicitly require entitlements or a provisioning profile in order to build. When building with Xcode 8 targeting iOS 10 Simulator, Xcode will always add the application-identifier entitlement regardless of your entitlement settings. This entitlement seems to be required to use certain APIs, for instance the Keychain API via Security.framework.

I've created a workaround that wraps ios_application and adds a __entitlements text segment with a blank value for application-identifier when the value for provisioning_profile is not set. This seems to work to make those APIs available again, but I'm not sure how sound of a solution it is or if it may cause other problems.

Perhaps this is a thing that the bazel apple rules should do automatically to give it more parity with how Xcode does simulator builds?

[keith]

We hit this same case. Definitely using the keychain APIs requires application-identifier which Xcode always sets for simulator builds. I was able to work around this by setting it manually in my entitlements files, but should this be something bazel adds instead?

[dflems]

Yeah this is still an issue on our side as well. Still using the same old hacky workaround. I set the value to .{bundle_id} (effectively minus the prefix) and it seems to work ok. Maybe that's enough for the simulator?

[keith]

Based on this logic

rules_apple/tools/plisttool/plisttool.py

Lines 1142 to 1151 in 0e593c7

	src_app_id = entitlements.get('application-identifier')
	if src_app_id and profile_entitlements:
	profile_app_id = profile_entitlements.get('application-identifier')
	if profile_app_id and not self._does_id_match(
	src_app_id, profile_app_id, allowed_supports_wildcards=True,
	id_supports_wildcards=True):
	self._report(
	ENTITLMENTS_APP_ID_PROFILE_MISMATCH % (
	self.target, src_app_id, profile_app_id),
	**report_extras)

I don't see bazel ever adding the application-identifier to the entitlements files.

I'm personally just going to check in this key to our plists, even for use with Xcode. The value is just TEAM_ID.BUNDLE_ID so I think it should be safe to include

[thomasvl]

The rules never auto add entitlements. Just like Xcode the default ones can be extracted form the provisioning profile and and be used, but that's it.

[keith]

Ah interesting thanks for the context, would this be a reasonable addition? This can also be extracted from the profile

[thomasvl]

We only do the default extraction to match what Xcode does. In general you should manage your entitlements just like if you were using Xcode, adding exactly what you need.

For someone with multiple apps, it isn't uncommon for the default dev profile to list some common set of needs (keychain, etc.), and then each individual app opts into needing them via a local entitlements file. That way the default dev profile rarely needs tweaking, but the apps can call out what they need so they don't trigger OS requirements for things in the profile default that aren't actually used by the app.

[keith]

In general you should manage your entitlements just like if you were using Xcode, adding exactly what you need.

I guess this statement conflicts a bit, we don't add this one, but we do need it, but to manage it the same way Xcode does with bazel, bazel would have to add it for us.

but the apps can call out what they need so they don't trigger OS requirements for things in the profile default that aren't actually used by the app.

Yea for us all of our apps need this entitlement, so it is in all the profiles, including the dev ones

[thomasvl]

Trying to remember all the details here…

I think one difference between Bazel and Xcode is Xcode ends up always having a provisioning profile via the default one created for every Apple Developer account (and then downloaded via Xcode). So the real "fix" might be to figure out a way to always have a provisioning profile, maybe some way to auto find it like Xcode does. I'm pretty sure for device it will fail the build before starting if it can't find a profile to use, not so sure about simulator though.

In the mean time, it might make sense to issue a warning (print() when a build is done with entitlements but no provisioning profile to try and inform folks that part of their BUILD file is getting ignored. I'm not sure if this would end up being extremely chatty on folks and thus a negative vs. a positive change.

Given the simulator is already sloppy with validation of entitlements, it might be possible to just fake a team ID (99999.…) and capture the entitlements anyway. If the app/test is using api that need real entitlements; it likely means a real profile.

The last part in here that needs a revisit because Apple could have changed things since someone looked closely at this is get-task-allow. With macOS getting more strict in general, the rules might need to ensure entitlements always happen under the simulator to ensure the things can be debugged. i.e. - if Xcode always does this for the Simulator the rules might need to start doing it also.

[keith]

FWIW you don't have to have a provisioning profile for simulator builds since you don't have to log into any developer account in Xcode. Also even if you do if there's already a profile for the bundle ID you're trying to build I believe that will conflict and not create one for you.

[luispadron]

Just ran into this, do either of you have more details on the workarounds you're using?

Essentially, when we run in Xcode via simulator it provides a the team id as the AppIdentifierPrefix since its not signed. When running with Bazel, we need to provide the entitlements file and along with that the provisioning profile. This makes it so the AppIdentifierPrefix is the app id.

Which means, Xcode and Bazel behavior is different here which is leading to keychain access issues as our code uses the app id prefix for access.

[keith]

We pre-process a template entitlements file to set whatever values we need here, so that we just don't rely on the Xcode specific replacements anymore. So we just use a bazel rule to decide what values we should set, aka the AppIdentifierPrefix and then provide that file to the ios_application etc rule