IPAFlowEarly Access

IPAFlow / udid / apple device limits

UDID

Apple Developer Device Limits and Membership-Year Planning

Verify Apple's current 100-device-per-family limit, reset roles, disabling rules, processing states, and practical Ad Hoc capacity planning.

Updated August 15, 2026

As verified against current Apple Developer Account Help on August 15, 2026, Apple Developer Program and Apple Developer Enterprise Program memberships can register up to 100 devices per product family, per membership year. The allowance is team-wide. It is not 100 devices for each app and not a promise that every profile or app should contain all 100.

Apple currently lists these product families:

Product family Maximum registrations per membership year
Apple TV 100
Apple Vision Pro 100
Apple Watch 100
iPad 100
iPhone 100
iPod touch 100
Mac 100

Apple can change program terms or supported families. Recheck the official Devices overview before a large registration campaign or renewal decision.

Three limits that are not interchangeable

1. Team device capacity

This is the membership-year inventory: how many physical devices the developer team has registered in each product family. Multiple apps, client projects, profiles, and release engineers operating under the same team draw from this inventory.

2. Provisioning-profile device set

A Development or Ad Hoc profile authorizes selected registered devices. Its device list can be smaller than the team inventory. A device in the account is not automatically evidence that a manually managed profile includes it.

With automatic signing, Xcode can create or refresh profiles using registered devices according to its signing workflow. With manual signing, the team selects the intended devices when creating or editing the profile.

3. App-specific audience

The business may intend 20 testers for App A and 35 for App B. Apple does not create a separate annual capacity pool for each app. The app-specific audience is an operational subset of the team inventory and of any profile used for that release.

team-wide annual device inventory
  != devices selected in one profile
  != testers intended for one app

Capacity is shared across projects

Consider these examples:

The practical unit to deduplicate is the exact, consented physical-device UDID—not a person’s name or email address.

Disabling does not restore capacity during the year

Apple currently states that a device can be disabled and enabled, but it cannot be deleted from the developer account during the active membership year. Disabling it:

Therefore, “delete old devices and get the slots back immediately” is not a valid capacity plan. Disable only after understanding the profile impact, and do not disable active devices merely to clean labels.

What disabling proves: the team no longer intends the record to be enabled for current development/testing.

What it does not do: refund the membership-year registration or rewrite an IPA already exported with earlier signing state.

Membership-year reset behavior

The reset is tied to the team’s membership year, not January 1.

At the start of a new membership year, Apple currently presents Account Holders, Admins, and App Managers with a device-list restoration choice when they first sign in to Certificates, Identifiers & Profiles. The eligible operator can:

Review the intended retained inventory before completing this one-time workflow. Removing every record without mapping active profiles and projects can create signing work; retaining every stale record wastes the clean-year capacity opportunity.

Apple also documents expiration behavior. Starting 30 days before membership expiration, the team can download a device-list copy and may opt to have devices removed when an unrenewed membership expires. If the team does not opt in, Apple says the devices are removed automatically 180 days after expiration. This is not an immediate mid-year capacity-reset technique for an active program.

Roles differ by action

Do not assume every role that can participate in the membership-year reset can perform every device-management action.

Use role-appropriate access. Do not share the Account Holder’s Apple Account credentials to work around a permission boundary.

Processing and eligibility are separate from capacity

A successfully created record can still be temporarily unavailable for provisioning in specific account states.

Apple’s current Device Registration Updates reference applies special processing to:

For those affected memberships, Apple currently lists 1–10 registered test devices as available upon registration and 11–100 as potentially processing within 24–72 hours. Existing active memberships are not impacted by that change. Apple also documents that a provisioning device identifier previously associated with memberships terminated for license violations may be moved to an ineligible state for up to 30 days.

Do not promise these windows for every team and do not call processing a malformed UDID. Preserve the portal/API status and wait for Apple eligibility when that is the reported state.

Capacity planning for agencies and QA teams

Before registering a device:

  1. Validate the UDID locally. Catch presentation damage before consuming a slot.
  2. Search and deduplicate. Reuse an enabled record when the exact physical device already exists in the correct team.
  3. Use meaningful labels. Include a consented tester or asset reference, model, client/project, and lifecycle context without unnecessary personal data.
  4. Maintain a consented inventory. Record who approved the device, why it was registered, and the retention/deletion policy.
  5. Map device → client/project. One team-wide inventory needs an operational owner for each active record.
  6. Track replacement devices separately. Do not overwrite the old phone’s record with the new phone’s UDID.
  7. Reserve capacity. Leave room for failed hardware, urgent reviewers, and replacement testers.
  8. Review before renewal. Prepare the keep/remove decision before the first eligible role signs in and completes the reset.

A useful dashboard separates registered, enabled, processing, ineligible, profile-selected, and retired operational states. A single “tester count” hides the capacity decisions.

Choose a method that fits the audience

Use registered-device capacity as a method-selection input, not as a target to fill.

small, stable, known device fleet
  → Ad Hoc may fit

large or frequently rotating tester audience
  → evaluate TestFlight or another eligible Apple-supported route

Ad Hoc remains valuable for known devices and controlled client/UAT delivery. It becomes operationally expensive when onboarding is continuous, the audience changes faster than profiles can be refreshed, or the team approaches its annual limit.

Use How to Distribute an iOS App with Ad Hoc for the full registered-device workflow, How to Register an iPhone UDID for one device, and TestFlight vs Ad Hoc for the distribution decision. The browser-local Distribution Method Selector can structure that choice without uploading project data.

For an agency or UAT program, iOS Agencies and iOS UAT cover the wider operating model. Capacity alone does not authorize an app: the profile, certificate, App ID, signing state, and exact delivered artifact must still agree.

Related next steps

Next step. Audit and deduplicate the team-wide device inventory before registration, then choose a better-fitting distribution method for large or rotating audiences. Join Early Access.

Sources