Fix: Conflicting Provisioning Settings in Xcode App Extensions

Why this happens

Xcode signs each target separately. A sticker pack, a widget, a share extension and the host app are four different products with four different bundle identifiers, so each one needs its own signing configuration. When the app target is set to automatic signing with a team but the extension target still carries a manually selected profile, Xcode refuses to guess and reports:

XXX has conflicting provisioning settings. XXX is automatically provisioned,
but provisioning profile WildCard has been manually specified.

The second line, Code signing is required for product type 'Application' in SDK 'iOS 10.0', is a follow-on message, not a separate bug. The SDK number is simply whichever SDK the target is being compiled against — an old number there usually means a stale deployment target or an old project file, but it is never the cause. The cause is that a target has no valid identity and profile pair for that SDK.

There is a second trap specific to extensions: a wildcard App ID profile cannot sign an app extension. Extensions need an explicit App ID that matches their own bundle identifier, which must be prefixed by the host app’s identifier. If a wildcard profile is still attached to the extension target, no amount of re-selecting the team will fix it until that profile reference is removed.

How to fix it

1. Set the same team on the project and on every target

This is the step people skip. Signing settings exist at the project level and at each target level, and a leftover value at either level can win.

1. Select the project in the navigator, then select the project entry (not a target) and open Signing & Capabilities.
2. Tick Automatically manage signing and choose your team.
3. Now select the app target and repeat.
4. Select the extension target — the sticker pack, widget, or share extension — and repeat.

Every target must show the same team and a green, error-free status. If one target shows a red “Signing for X requires a development team” message, that target is the one blocking the build.

2. Clear stale manual values in Build Settings

If the checkbox is on but the conflict persists, a manual value is still stored in the build settings and automatic signing is reporting it rather than overwriting it.

1. Select the target, open Build Settings, and search for signing.
2. Set Code Signing Style to Automatic.
3. Set Provisioning Profile to Automatic (or clear it entirely).
4. Set Code Signing Identity to Apple Development — older Xcode versions call this iOS Developer. Set it for both Debug and Release.
5. Repeat for the project-level build settings.

Then run Product → Clean Build Folder, quit Xcode, reopen the project, and build again. The quit-and-reopen matters: Xcode caches resolved signing state per workspace, and a clean alone does not always flush it.

3. Confirm the extension uses an explicit App ID

Open the extension target’s Signing & Capabilities tab and check the bundle identifier. It should look like com.yourcompany.yourapp.StickerPack, with the host app’s identifier as the prefix. If the target is pointing at a wildcard profile, remove that reference in Build Settings → Provisioning Profile and let automatic signing create an explicit App ID for the extension.

4. Inspect what Xcode actually resolved

When the UI disagrees with reality, ask the build system directly:

xcodebuild -showBuildSettings -scheme YourApp \
  | grep -Ei "CODE_SIGN|DEVELOPMENT_TEAM|PROVISIONING"

Run it once per scheme that includes the extension. If DEVELOPMENT_TEAM is empty for any target, that target is not signed and the archive will fail even though the app target looks fine.

5. If archiving still fails after all of the above

Delete the derived data for the project (File → Project Settings → Derived Data → Delete), then in Xcode → Settings → Accounts select your Apple ID and use Download Manual Profiles. This refreshes the local copy of the team’s profiles, which is where a stale wildcard profile usually survives a clean.

How to prevent it

• Configure the team at the project level before you add any extension, so new targets inherit a working setup.
• After adding a sticker pack, widget or share extension, open its Signing & Capabilities tab immediately — new targets do not always inherit the team.
• Keep automatic signing on for every target. Manual signing is fine for a single app, but it multiplies the work with each extension.
• Never hand-edit CODE_SIGN_IDENTITY or PROVISIONING_PROFILE in project.pbxproj; the values are easy to set and very hard to find later.
• Use explicit App IDs for anything that ships an extension.

FAQ

Why does the error mention an old SDK like iOS 10.0?

The SDK name in that message is just the SDK the target is being compiled against. It reflects the project’s deployment target or an old build setting, not the reason signing failed. Fix the signing configuration and the message disappears regardless of the number.

Can a sticker pack extension use a wildcard provisioning profile?

No. App extensions require an explicit App ID whose bundle identifier matches the extension’s own identifier, prefixed by the host app’s. A wildcard profile can sign the main app but not the extension, which is exactly the conflict Xcode reports.

Do I need a paid Apple Developer account to build a sticker pack?

A free Apple ID personal team is enough to build and run on your own device with automatic signing. Uploading to App Store Connect and distributing through TestFlight or the App Store requires a paid Apple Developer Program membership.