Every product that runs on a physical Apple device has to be signed, with no exceptions and no debug escape hatch. This error means Xcode reached the signing phase for a device build and found nothing to work with: no team, no signing identity, no profile. It is a configuration gap, not a certificate problem, which is why none of the usual keychain fixes do anything for it.
The SDK name in the message tells you the build is targeting device hardware. Simulator builds use an SDK like 'iOS Simulator 18.0' and do not require signing at all, so if you did not intend to build for a device, that is the first thing to check.
Which target is it complaining about
The message names a product type, not a target, and in a project with dependencies the failing target is often not the one you are building. Pods, Swift packages that build as frameworks, extensions, and test hosts all have their own signing settings. Look at the full build log line above the error to find the target name.
# What the build system thinks the signing settings are xcodebuild -showBuildSettings -scheme MyApp -destination 'generic/platform=iOS' \ | grep -E 'DEVELOPMENT_TEAM|CODE_SIGN_STYLE|CODE_SIGN_IDENTITY|PRODUCT_BUNDLE_IDENTIFIER'
An empty DEVELOPMENT_TEAM is the tell. If it is blank, nothing downstream can resolve an identity, regardless of what is in your keychain.
The common situations
- Fresh clone of someone else's project
- DEVELOPMENT_TEAM is often deliberately left out of version control, or the .xcodeproj carries a team ID your Apple ID is not a member of. Set your own team once and the build works.
- Free Apple ID, distribution build
- A free account can sign for local development only. Ask it for a Release or archive build and there is no identity to use, so this error appears rather than something more descriptive.
- Flutter, React Native, or Capacitor project
- The generated iOS project ships with no team set, and the first device build hits this immediately. Open the ios/Runner.xcworkspace (or equivalent) in Xcode and set the team, rather than trying to patch the generated project file.
- Opened the .xcodeproj instead of the .xcworkspace
- With CocoaPods, building the project directly skips the pods configuration and can leave targets without their expected settings. Always open the workspace.
- CI with no signing configured
- The runner never imported an identity or set a team, and the build is archiving for a device. This is the same gap, just on a machine where nobody notices until the log arrives.
Fixing it in Xcode
- 1
Select the target, then Signing and Capabilities
Not the project, the target. Tick Automatically manage signing and choose your team from the dropdown. If the dropdown is empty, add your Apple ID under Xcode, Settings, Accounts first.
- 2
Repeat for every target that produces a signed product
App, widgets, notification extensions, watch app, app clip. Test targets that run on a device need it too. Each one is configured independently.
- 3
Check the bundle ID is something you can register
Automatic signing tries to register the App ID as part of resolving. A placeholder like com.example.app will fail, since somebody else already owns it.
Fixing it from the command line
xcodebuild archive \ -workspace MyApp.xcworkspace \ -scheme MyApp \ -destination 'generic/platform=iOS' \ -archivePath build/MyApp.xcarchive \ DEVELOPMENT_TEAM=ABCDE12345 \ CODE_SIGN_STYLE=Automatic \ -allowProvisioningUpdates
For manual signing, supply the identity and the profile explicitly instead, and make sure the profile is installed on the machine first. See No profiles for 'com.example.app' were found for what happens when it is not.
xcodebuild archive \ -workspace MyApp.xcworkspace \ -scheme MyApp \ -destination 'generic/platform=iOS' \ -archivePath build/MyApp.xcarchive \ CODE_SIGN_STYLE=Manual \ DEVELOPMENT_TEAM=ABCDE12345 \ CODE_SIGN_IDENTITY="Apple Distribution" \ PROVISIONING_PROFILE_SPECIFIER="MyApp App Store"
About CODE_SIGNING_ALLOWED=NO
Search results will tell you to set CODE_SIGNING_ALLOWED=NO or CODE_SIGNING_REQUIRED=NO and the error goes away. It does, because you have told the build system not to sign. That is a legitimate answer in exactly two cases: simulator-only builds, and CI jobs that compile to check for errors and never install the result anywhere.
The one place it genuinely belongs is a Podfile post_install hook for pod targets that produce resource bundles, which do not need signing and occasionally fail on it.
post_install do |installer|
installer.pods_project.targets.each do |target|
next unless target.respond_to?(:product_type)
next unless target.product_type == 'com.apple.product-type.bundle'
target.build_configurations.each do |config|
config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
end
end
end