How to Send an IPA to a Client

Send an existing iOS build through a legitimate installable workflow by checking its signing, client-device authorization, and delivery method first.

Updated August 15, 2026

Sending an IPA is not the same as making it installable. Email, cloud storage, and an upload link can transfer the file, but iOS will install it only when the build’s distribution method, signature, provisioning profile, app identity, and target device all agree.

Start by identifying the artifact you actually have. Do not send the client a link until you know whether that exact IPA can authorize their iPhone.

Choose the path from your current inputs

Source code and signing access are available: choose TestFlight or create a new registered-device build. Rebuilding from a known archive is usually safer than modifying an old binary.
Only an existing IPA is available: inspect its signature and embedded profile. If it is not already compatible, an authorized re-sign may be possible, but only with assets controlled by the app owner and entitlements the new profile permits.
The client device is already registered: prove that the IPA’s embedded profile includes the correct UDID. A portal record alone is not enough.
The client is not registered: a Development or Ad Hoc workflow requires device collection, registration, a refreshed profile, and a replacement artifact.
This is one known client: Ad Hoc can fit when the team can own the device-specific work.
Clients or devices change repeatedly: compare TestFlight or a managed onboarding workflow before turning every release into a manual profile update.

The iPhone installation guide explains the supported paths from the tester’s side. The steps below focus on the developer or agency handing off the build.

Step 1: identify how the IPA is signed

Inspect the final artifact, not a similarly named profile in Downloads or the settings in an Xcode project that may have produced a different build.

unzip -q ClientBuild.ipa -d ClientBuild-unpacked
APP_PATH=$(find ClientBuild-unpacked/Payload \
  -maxdepth 1 -name '*.app' -print -quit)

codesign --display --verbose=4 "$APP_PATH" 2>&1
codesign --verify --strict --verbose=4 "$APP_PATH"

If the app contains embedded.mobileprovision, decode it:

security cms -D \
  -i "$APP_PATH/embedded.mobileprovision" \
  -o /tmp/client-profile.plist

plutil -extract Name raw -o - /tmp/client-profile.plist
plutil -extract ExpirationDate raw -o - /tmp/client-profile.plist
plutil -extract Entitlements.application-identifier raw \
  -o - /tmp/client-profile.plist

Apple describes a provisioning profile as the signed authorization that constrains who may sign, which app is authorized, where it may run, when it is valid, and which entitlements are allowed. Use the IPA signature inspection guide for the full comparison.

Step 2: decide whether the existing build can be used

An existing Ad Hoc IPA can be reused only when the intended client’s device is already registered in the correct Apple Developer team and appears in the profile embedded in that IPA. Also verify that the profile is current, its App ID matches the bundle ID, and the code signature uses a certificate allowed by the profile.

Do not assume that an arbitrary IPA can be uploaded to TestFlight. TestFlight is an App Store Connect beta workflow with its own eligible build, signing, upload, processing, and tester requirements. When source and App Store Connect access are available, produce and upload the correct build instead of treating TestFlight as a generic IPA host.

If only the binary is available and its authorization is wrong, read how IPA re-signing works. Re-signing is not a bypass: the app owner must control a compatible certificate, private key, profile, App ID, and entitlements.

Step 3: complete the Ad Hoc authorization chain

For a registered-device handoff:

Collect the physical iPhone’s correct UDID with the client’s knowledge and consent.
Validate it and register the iPhone UDID in the intended Apple Developer team.
Create or edit the Ad Hoc profile so it selects the matching App ID, an active distribution certificate, and the client device.
Download the refreshed profile.
Rebuild from source or perform an authorized re-sign with compatible assets.
Inspect the profile embedded in the replacement IPA and compare its ProvisionedDevices list with the client’s UDID.
Install that exact artifact on a representative registered device before sending it.

Registering a device after the IPA was exported does not update the IPA. The client needs a replacement artifact that embeds the refreshed profile. The add-device-to-profile guide covers that transition without duplicating the full portal procedure here.

Step 4: choose the delivery surface

Once the artifact is proven installable, choose a transport that matches its signing type:

TestFlight invitations for an eligible TestFlight build;
Xcode or Apple Configurator when a trusted operator has the physical device;
a maintained hosted tester workflow that explicitly supports the build’s registered-device requirements; or
an OTA installation workflow only where the current platform and distribution context support it.

A direct .ipa URL is not automatically an iOS installation flow. Hosting also does not add a UDID, refresh a profile, repair a signature, or change the distribution method.

Step 5: send minimal client instructions

Give the client one message containing:

app name, version, and build number;
the intended installation link or supported install path;
the target device label you onboarded;
any browser requirement documented by the delivery provider;
one support channel; and
a request for the exact error text and the step where it appeared.

Do not ask a client for Apple credentials, P8 or P12 files, private keys, or signing certificates. Client onboarding should collect only what the authorized workflow actually needs. See the client-device onboarding workflow for the consent and status checkpoints.

If installation fails

First ask whether the same IPA installs on another intended device. Then confirm the failing device was meant to be authorized, compare its UDID with the profile embedded in the delivered IPA, verify app identity and expiry, and only then inspect the delivery link.

Use the Unable to Install App diagnostic hub to select the next evidence-based check. Re-uploading the same stale IPA under a new link only hides which artifact the client received.

When this becomes an operational problem

A one-client handoff can be managed with a careful checklist. Repeated client delivery adds consent-based device intake, team selection, profile changes, artifact versions, link retirement, and support history. IPAFlow is in Private Beta / In Development to explore that authorized workflow. Review the product boundaries and join Early Access only if that repeated operation—not merely file hosting—is the problem you need to solve.

Related next steps

Next step. Inspect the current IPA first, then join IPAFlow Early Access if client-device onboarding and repeat delivery are the recurring bottlenecks.