application-identifier entitlement in Simulator about rules_apple

[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

[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.