Automatic signing: benefits and limitations on teams

WHAT THIS TESTS The interviewer wants nuanced understanding of why signing is painful with multiple developers and CI, and an honest read on where Apple's convenience feature helps versus where it falls short.

A GOOD ANSWER COVERS Common team challenges include securely sharing the distribution certificate and its private key, profiles becoming invalid when a teammate adds a device or you toggle a capability, and each developer's machine drifting into a different signing state that breaks the build for someone else. Automatically manage signing has Xcode generate and register a development certificate per developer, create and refresh the matching provisioning profiles on demand, and update entitlements in the profile when you add capabilities, which removes most manual developer-portal steps for day-to-day local development.

COMMON WRONG ANSWERS Claiming automatic signing solves CI, when headless build servers without interactive Apple sign-in struggle with it and a deterministic managed approach is better. Ignoring that it can generate a sprawl of certificates across machines, risking hitting limits. Assuming it suits complex distribution where explicit profile control matters.

LIKELY FOLLOW-UPS Why is automatic signing problematic on CI, and what do teams use instead? How does fastlane match centralize signing assets? How do you avoid running out of certificates?

ONE CONCRETE EXAMPLE A five-person team enables automatic signing, so each developer's Xcode mints their own development certificate and profiles, and adding a teammate's test device just regenerates profiles without manual portal edits, smoothing local work. But when they set up CI, the headless agent cannot interactively manage signing reliably and certificates proliferate toward the account limit, so they switch CI and distribution to fastlane match, which stores a single shared set of certificates and profiles in an encrypted repository and installs them deterministically on every machine.