Automation
How Automatic UDID Registration Works
Design the complete authorized workflow from tester consent and UDID validation through Apple registration, profile refresh, artifact replacement, and verification.
Automatic UDID registration is a controlled workflow that validates an approved tester’s device identifier, registers it in the correct Apple Developer team, verifies the result, refreshes the affected provisioning profile, and produces a replacement artifact that actually authorizes the device.
The Apple registration API call is only one step. Registration alone does not update an existing provisioning profile or IPA.
The complete automation chain
tester consent
→ device identifier collection
→ format and source validation
→ duplicate and existing-state check
→ Apple Developer Team selection
→ authorization and capacity check
→ device registration
→ result verification
→ provisioning-profile refresh
→ source rebuild or authorized re-sign
→ final artifact verification
→ release-specific deliveryA workflow that stops after “device created” has automated an account mutation, not client delivery.
1. Obtain explicit tester consent
Before collection, tell the tester:
- which identifier is requested and why;
- which organization and Apple Developer team will register it;
- which app or testing engagement it supports;
- how long the record will be retained; and
- who handles correction or deletion requests in the agency’s own system.
Do not disguise device enrollment as an ordinary download button. Do not collect Apple passwords, two-factor codes, P8 keys, P12 files, signing certificates, or private keys from testers. The tester supplies a device identifier; the authorized app owner supplies the Apple-side authorization.
Client Device Onboarding owns the tester-facing intake sequence. This page begins at the automation boundary around that approved intake.
2. Collect the identifier from a transparent source
Capture the UDID with enough context to prevent misrouting:
- tester or request reference;
- physical device label and platform;
- UDID exactly as collected;
- collection method and timestamp;
- client/project and intended app; and
- consent version or evidence reference.
Remote collection must clearly explain what the user is installing or approving. If the identifier came through manual copy and paste, preserve the original value for audit while creating a normalized comparison value separately.
3. Validate before touching Apple
Validation should reject obvious problems early:
- empty or malformed values;
- spaces or presentation separators that can be normalized without changing the identifier;
- serial numbers, IMEI, EID, phone numbers, or other non-UDID values;
- a device platform inconsistent with the request; and
- records whose source or consent cannot be established.
A format-compatible string is not proof that it belongs to the intended physical device. Route uncertain input to manual review and use Invalid iPhone UDID for the diagnostic branches. The UDID Validator performs only a browser-local format check; it does not query Apple or prove ownership.
4. Make duplicate handling idempotent at the workflow level
Create a stable request key from the client/project, Apple team, normalized UDID, and intended operation. Before registration:
- look for an existing successful request with the same team and UDID;
- query the Apple device state when authorized;
- return the existing result when it already satisfies the request; and
- prevent concurrent workers from registering the same submission twice.
Keep retries attached to the original request record. Do not create a new release or claim a new registration merely because a tester clicked twice.
Idempotency must include team context. The same UDID in another client’s team is not a reusable authorization result.
5. Select the Apple Developer team explicitly
Many agency and developer accounts can access more than one team. Never rely on a default team chosen by a local login session.
The automation record should resolve:
- client/project to the owning team ID;
- the approved app or bundle ID;
- the authorized operator or service identity; and
- the permitted operation for that team.
If the client/project cannot resolve to exactly one approved team, stop for review. A successful API response from the wrong team is not success.
6. Use supported authorization with least privilege
Apple’s App Store Connect API exposes device resources for registering devices used in development and testing, listing them, reading one device, and modifying limited device metadata. Use that supported API boundary when it fits the team’s access model.
Fastlane’s current App Store Connect API guidance recommends API-key authentication where supported and notes that provisioning-related access requires a Team API key rather than an Individual key. Give the key only the role required for the workflow, store its P8 material in a managed secret store, keep it out of logs and source control, and separate it from tester-facing systems.
The public intake layer should enqueue an approved request. It should not hold broadly privileged signing assets or expose Apple credentials to a browser.
7. Check capacity and eligibility before registration
Apple currently permits up to 100 registered devices per product family per membership year for Apple Developer Program teams. Disabling a device during the year does not restore that slot. Check the current product-family capacity and the organization’s policy before mutating the account.
Also account for Apple’s documented processing state. For some new memberships or memberships renewed after a long expiration, registered devices may not become eligible for provisioning immediately. Apple documents that additional processing can apply, including a 24–72 hour window for certain device counts. Treat “registered but not yet eligible for profiles” as a distinct state, not a reason to loop registration calls.
Use Apple Developer Device Limits for the detailed capacity and membership-year rules.
8. Register and verify the Apple result
Submit the validated device name, UDID, platform, and explicit team context through the supported operation. Record:
- internal request ID;
- Apple team ID;
- normalized UDID or protected device reference;
- operation time and actor/service identity;
- Apple device resource identifier and status, when returned; and
- a redacted response classification.
Do not mark the workflow successful only because the HTTP request completed. Read or list the resulting device state through the supported API and confirm that the returned UDID, platform, team context, and eligibility are consistent with the request.
For a manual equivalent and its Apple account prerequisites, see Register an iPhone UDID.
9. Refresh the provisioning profile
Registration creates a team device record. The affected Development or Ad Hoc profile must then be created or refreshed with that device selected.
The workflow must know:
- which app and profile should include the device;
- whether Xcode automatic signing, manual profile management, Fastlane, or another supported process owns the refresh;
- which certificate the profile authorizes; and
- whether app capabilities changed since the previous profile.
Do not refresh every profile in the team indiscriminately. Add a Device to an Existing Provisioning Profile owns the profile update sequence.
10. Produce a replacement artifact
A refreshed .mobileprovision file on a build machine does not modify an old IPA. Complete one authorized path:
- rebuild from source or a known archive using the refreshed signing state; or
- re-sign an existing IPA when the app owner authorizes it, the matching certificate/private key are available, and the app’s entitlements fit the new profile.
Assign a new release record and checksum to the result. Never silently replace a hosted IPA under an old link while support is still comparing artifacts.
11. Verify the final IPA, not the intention
Before delivery, prove that the exact output:
- has the intended bundle identifier and team;
- contains the target UDID in its embedded profile;
- uses a current profile and authorized signing certificate;
- has signed entitlements permitted by that profile;
- passes signature verification; and
- matches the checksum attached to the release record.
If the device is registered but absent from the final IPA, the failure is after registration. Do not create another device record; inspect the profile-refresh and artifact stages.
Failure handling by boundary
Treat failures as explicit states rather than one generic retry queue:
- Malformed or ambiguous UDID: reject and request recollection; do not retry Apple.
- Duplicate submission: return the existing workflow status; do not create a fake second success.
- Wrong or ambiguous team: stop for an accountable operator.
- Authorization failure: quarantine the request and rotate or repair access outside the tester flow.
- Capacity exhausted: do not bypass the limit; choose another approved distribution method or wait for the membership-year process.
- Registered but ineligible: retain the Apple state and recheck according to Apple’s documented timing; do not register repeatedly.
- Profile refresh failure: keep the device result, fail the release step, and avoid delivering the old IPA.
- Build or re-sign failure: preserve logs without secrets, do not publish a partial artifact, and route to the signing owner.
- Delivery verification failure: retire the incorrect link or file and create a corrected release record.
Do not invent a universal retry count. Classify the official response, preserve its request/correlation information when provided, and retry only operations known to be transient. Authentication, validation, capacity, and policy failures require correction, not exponential persistence.
Audit without collecting secrets
An audit record should answer who approved the request, which team and device were affected, what state changed, which profile and release followed, and whether final verification passed.
Keep credentials separate from audit data. Redact tokens, authorization headers, P8 contents, P12 material, private keys, passwords, cookies, and full raw API responses that may expose sensitive fields. Limit access to UDIDs because they are persistent device identifiers used for a defined operational purpose.
Manual review boundaries
Require a human decision when:
- consent or device ownership is disputed;
- the team or client mapping is ambiguous;
- capacity is nearly exhausted or the device is ineligible;
- a new app capability or entitlement is involved;
- signing credentials would need new access or rotation;
- an existing IPA has uncertain provenance; or
- the requested distribution method conflicts with the client’s policy.
Automation should execute an approved policy, not silently create one.
Automating a valid workflow versus bypassing controls
Valid automation preserves Apple team ownership, registered-device limits, profile membership, certificate/private-key control, entitlement authorization, and artifact verification.
It does not use account pools, certificate pools, shared client credentials, Enterprise distribution for external clients, device-limit workarounds, or revocation-avoidance schemes. Those approaches do not make the workflow scalable; they remove the controls that make the signed build legitimate.
Fastlane can implement one controlled registration step; see Fastlane Register Device. It still needs the surrounding workflow above.
IPAFlow is in Private Beta / In Development and is exploring authorized client-device onboarding and delivery automation while each customer uses its own Apple Developer account. Review the product boundaries or join Early Access if this complete workflow—not merely one API call—is the recurring problem.