IPAFlow / provisioning / add device to profile

Provisioning

Add a Device to an Existing Provisioning Profile

Add a registered iPhone to the correct Development or Ad Hoc profile, refresh the signing workflow, and verify the replacement IPA.

Updated August 15, 2026

Registering a device, adding it to a provisioning profile, and updating an existing IPA are three different operations. Completing the first one does not complete the other two.

For a Development or Ad Hoc build, the complete state transition is:

physical device
  → validated UDID
  → correct Apple Developer team
  → registered and enabled device
  → intended Development or Ad Hoc profile
  → device selected in that profile
  → regenerated or refreshed profile
  → signing workflow receives that profile
  → new export or authorized re-sign
  → final IPA inspection
  → replacement artifact delivered

If the tester still receives the old IPA, no portal change can make that artifact include the new device.

Before editing a profile

Confirm the inputs rather than choosing a profile by name:

Physical device: the submitted UDID came from the intended iPhone and passed a basic handoff check.
Developer team: the team owns the app’s App ID, certificate, and profile.
Device record: the device is registered, enabled, on the correct platform, and eligible for profile selection.
Distribution method: the build is Development or Ad Hoc. App Store and TestFlight distribution do not use this registered-device step.
App ID: the profile belongs to the main app bundle identifier you intend to ship.
Certificate: the selected current certificate matches the signing identity and private key available to the build or authorized re-sign workflow.
Device-set policy: you know whether the profile should contain one new device, a reviewed client cohort, or all eligible team devices.

Use How to Register an iPhone UDID if the team device record is absent. Registration is that page’s task; this page starts when a registered device must become part of a specific profile and replacement artifact.

Manual profile workflow

Apple’s current account help allows an authorized operator to edit a provisioning profile’s name, App ID, certificate selection, and device set. For the intended manually managed Development or Ad Hoc profile:

Open Certificates, Identifiers & Profiles under the correct team.
Select Profiles, then open the exact profile used by this app and distribution method.
Confirm the App ID before changing anything. A similar profile name is not evidence of the correct bundle identity.
Confirm the selected signing certificate is current and is the certificate the signing workflow can actually use.
Review the entire selected-device set, not only the new row.
Select the new device while preserving only the previously intended devices.
Save or generate the updated profile, then download it through the supported Apple or Xcode workflow.
Record enough evidence to distinguish the new profile from the old one: profile name, UUID, expiration, App ID, certificate context, and reviewed device count.

Apple’s Ad Hoc creation workflow requires an App ID, a single distribution certificate, and registered devices. A Development profile instead selects compatible development certificates and devices. Do not change the distribution type merely to make the new device appear.

Avoid an accidental device-set change

Adding one device is also an opportunity to accidentally remove existing testers or authorize every team device. Before saving, compare the selected set with the release’s intended audience.

Apple’s portal editor can select a different set of devices. Fastlane’s sigh --force has a different important behavior: its current documentation says force renewal also adds all available devices to the profile. That can be appropriate for a team-wide test profile, but it is not equivalent to adding one reviewed client device. Choose the method that matches your device-set policy.

Xcode-managed versus manually managed profiles

Apple states that Xcode manages Development and Ad Hoc profiles when automatic signing is used. Keep that ownership model intact.

If the project uses automatic signing:

select the correct team and target in Xcode;
let Xcode request a profile that satisfies the current App ID, entitlements, certificate, and registered-device requirements;
refresh or export through the same Xcode-managed workflow; and
inspect the profile embedded in the final IPA.

Do not create a parallel manual profile with the same app and a similar name just because an Xcode-managed profile is not convenient to edit. Fastlane’s current sigh documentation also says it does not touch or use profiles created and managed by Xcode; it manages its own set instead.

For an intentionally manual signing setup, update the named manual profile and make the build/export mapping explicit. Mixing automatic and manual profile ownership during one incident creates stale local copies and ambiguous selection.

Make sure the signing workflow receives the refreshed profile

Downloading a .mobileprovision file proves only that a file reached the Mac. It does not prove that Xcode, CI, or the re-signing workflow selected it.

Common stale-profile paths include:

Xcode finds an older locally installed profile that still satisfies its known requirements;
a CI runner restores a cached profile from a previous job;
an export configuration maps the bundle identifier to a similarly named profile;
a Fastlane signing store was not renewed or synchronized after device registration;
the main app is refreshed while an extension still uses an older profile; or
a re-sign command receives the new profile for the outer app but not the nested targets.

Record the profile UUID or other release evidence selected by the build, then verify the embedded profile after packaging. Clearing every local profile is not a good first diagnostic step; it can disrupt unrelated builds without proving which profile was selected.

Why the existing IPA does not change

The embedded provisioning profile is signed content inside the app bundle. An IPA already exported with the old profile is an immutable release artifact for operational purposes.

These actions do not add the new device to that IPA:

registering the UDID in the portal;
saving a revised profile;
downloading the revised .mobileprovision beside the IPA;
installing the profile on a build Mac;
renaming the IPA; or
changing the client download URL.

If source is available, create a new archive/export with the refreshed signing configuration. If source is unavailable, consider authorized IPA re-signing only when the app owner controls compatible certificate, private key, profile, App ID, and entitlements. Simply replacing embedded.mobileprovision invalidates the existing signature.

Account for app extensions and nested targets

An extension, widget, App Clip, or nested app can have its own bundle identifier, App ID, entitlements, and provisioning profile. Updating only the main app profile may leave the IPA internally inconsistent.

For each signed target:

identify its bundle identifier and owning team;
determine whether it has its own embedded profile;
verify the matching certificate and entitlement authorization;
refresh the profile through the same ownership model; and
sign nested code in the correct workflow before the containing app is finalized.

Do not add the client device to an extension profile blindly. First establish whether that distribution type and target actually use device-bound provisioning.

Current Fastlane workflow boundaries

Fastlane still documents these separate actions:

register_devices adds new device records to the Apple Developer portal and does not remove existing device records.
sigh, an alias for get_provisioning_profile, can create, renew, download, and repair profiles. For Ad Hoc profiles, force renews the profile and adds all available devices.
match, an alias for sync_code_signing, synchronizes certificates and profiles through the team’s configured signing store and can renew profiles with the reviewed configuration.

A controlled lane can make the team, bundle identifier, and distribution type explicit:

register_devices(
  devices_file: "devices.txt",
  team_id: "YOUR_TEAM_ID"
)

get_provisioning_profile(
  app_identifier: "com.example.app",
  adhoc: true,
  force: true,
  team_id: "YOUR_TEAM_ID"
)

Use force: true only when authorizing all available devices matches the profile’s intended policy. The actions above still do not build the app, map separate extension profiles, verify the packaged IPA, replace the hosted object, or prove installation.

If the release already uses match, follow the established storage, team, branch, app-identifier, and profile-type configuration rather than adding a second sigh-managed profile set. Fastlane Register Device owns the registration lane; Fastlane Match for Ad Hoc owns signing-store design.

Verify and deliver the replacement

Inspect the exact newly packaged IPA, not the portal profile or an unpackaged build folder. Confirm:

the target UDID appears in the embedded device list where applicable;
the profile UUID and expiration are the expected refreshed values;
the application identifier and team match the target;
the signature verifies and the signing identity is authorized by the profile;
every nested signed target has compatible signing and provisioning; and
the delivered checksum belongs to this replacement artifact.

Inspect a Provisioning Profile Inside an IPA is the canonical evidence workflow. Check an IPA’s Code Signature covers signature and signing identity. If the device is still absent, continue with Device Not in Provisioning Profile rather than repeating portal edits.

Run the browser-local iOS Distribution Checklist before replacing the client link. IPAFlow is in Private Beta for teams that repeatedly coordinate authorized device intake, profile refresh, artifact replacement, and client handoff; it does not collect Apple signing credentials or bypass Apple’s device and program rules.

Related next steps

Next step. Verify the replacement artifact end to end; evaluate IPAFlow Private Beta only when repeated client-device updates are the operational problem. Join Early Access.