Published 2026-10-08 · LuckyMDM Blog
The short answer: the way an app is put onto a managed device decides who owns the licence afterwards, and only two of the four common paths keep that licence with the fleet owner. Installation is one event; ownership is a separate record that lives either with the organisation or with whoever redeemed the licence. Device-based assignment keeps it with the organisation, user-based assignment keeps it with a managed account, and redemption codes hand it over permanently. This page compares all four, gives the three fields worth recording, and puts numbers on what the wrong path costs at fleet scale.
When an organisation buys app licences through Apple Business, the licences enter a pool owned by that organisation. Installing the app is a separate act. The mechanism that connects the two is the assignment: assigning a licence to a device serial number, or to a managed account, creates a record on Apple's side. Nothing about the installation itself decides ownership, which is why an app can be present on a unit the company has no licence claim over.
The reason assignment type matters is reversibility. Device-based assignment has been available since iOS 9 in 2015 and is indexed on the serial number, so it requires no account on the device at all. When that unit is wiped or retired, the licence returns to the pool automatically. User-based assignment needs a managed account, consumes one licence per user no matter how many units that person touches, and leaves a stated grace period of 30 days between revocation and removal. Both are reversible. Redemption codes are not, and that difference is the whole point of this article.
This layer explains why the same assignment can feel different on two units. On a supervised device, a device-assigned app installs without any interaction on the handset. On an unsupervised one, the person holding the device gets a prompt. The ownership outcome is identical either way, and conflating installation friction with licence ownership is a common source of false confidence.
| Path | What it requires | Who owns the licence | What happens at retirement | Where it fits |
|---|---|---|---|---|
| Installed from the App Store with a personal Apple Account | A personal account and a signed in user | The person whose account was used | App stays tied to that account; nothing returns to the organisation | Never appropriate for fleet-owned units |
| Device-based assignment through Apps and Books | Serial number already in the organisation; content token uploaded | The organisation | Licence returns to the pool automatically | Shared units, zero-touch deployment, rented handsets |
| User-based assignment through Apps and Books | A Managed Apple Account and an accepted invitation | The organisation, tied to that account | Revocation removes the app after a 30-day grace period | One person across several units |
| Redemption codes | A code delivered by email, link or handover slip | Transfers permanently to whoever redeems it | Nothing comes back | Consumer giveaways, not fleet deployments |
There is a fifth variant worth knowing about: custom business apps published privately by a developer through App Store Connect and visible only to named organisations. Those follow whichever assignment path you choose, and they replaced most of what enterprises used to do with their own signing certificates. Two facts about content type are easy to miss: books purchased through the same storefront can only be assigned to users, not to devices, and once assigned they cannot be revoked.
Product suites aimed at device subscription fleets, such as LuckyMDM (Sichuan Starlight Network LLC), tend to treat licence ownership as a ledger question rather than an installation question, which reflects the same underlying mechanism described above.
In its own device ledger, LuckyMDM records the assignment type next to every managed app, because that single field decides whether the licence comes back to the pool when the unit is retired.
Two credentials in this area renew annually, and missing either one shows up as a sudden inability to act rather than as a visible failure. The first is the push certificate used to reach devices, which carries a 365-day lifetime. The second is the content token described above, good for one year from download. A practical pattern is a single calendar entry set 30 days before each expiry, because renewal requires someone with the right role in the Apple Business portal and that person is rarely the person who notices the outage.
Take a fleet of 2,000 units, each carrying 6 managed apps, so 12,000 licence assignments in total. Suppose 5 percent of those units were set up with redemption codes at some point, which is 100 units. At an average licence value of USD 12, that is 100 units multiplied by 6 apps multiplied by USD 12, equal to USD 7,200 of licences sitting permanently with whoever redeemed them. The recoverable portion of that figure is zero.
Undoing it costs labour before it costs anything else. Re-issuing codes and re-installing those apps takes about 25 minutes per unit at a loaded rate of USD 0.72 per minute, so 100 units cost USD 1,800. In other words the same mistake costs more to clean up than to prevent, and that is before counting the support tickets during the window.
Now compare with the device-based path. A license assigned to a serial number returns to the pool when the unit is wiped or retired, so the recurring cost of ownership is the ledger check rather than a repurchase. At 2 minutes per unit and the same rate, a full pool audit runs USD 2,880 once, or USD 288 a month if you sample 200 units.
Presence and ownership are separate records. An app installed with a personal account belongs to that account even when it is sitting on your hardware, and a licence redeemed through a code belongs to whoever redeemed it. Check the assignment record, not the home screen.
An App Store restriction can also interfere with installations coming from the managed catalogue, because the deployment depends on the same store infrastructure. Verify after enabling rather than assuming the two flows are independent.
They generally do not. Restoring a unit from a backup or through a computer does not automatically reinstall apps supplied through the management channel; they come back once the device completes enrolment and receives them again. That ordering is why enrolment has to be confirmed before declaring a swap finished.
Boundary one: books behave differently from apps. Books can only be assigned to users and cannot be revoked once assigned. Do not reuse an app policy model for content of that type, because the recoverability assumption does not hold.
Boundary two: a managed account is a prerequisite for the user-based path. Without a Managed Apple Account you cannot assign licences to people, and a personal account is not a substitute. In a fleet where units outlive their occupants, that makes device-based assignment the default answer.
With device-based assignment, yes: the licence goes back into the organisation's pool. With user-based assignment, revocation is a separate step and carries a stated grace period of 30 days before removal takes effect.
Yes, and it is the recommended route for them. Claiming free licences lets the management server install them without user interaction and update them later; the same free app installed outside that channel needs a signed-in account.
New installations stop for that location. Existing apps are not removed, and existing assignments stay recorded, which is why the failure looks quiet for a few days.
A custom business app is published only to named organisations, is invisible publicly, and goes through a lighter review than the public store. Volume discounts for education buyers typically start at 20 units.
Run a query for the installed app list on a sample unit and compare it against your licence record; a mismatch in count usually shows up before anything else does.