Published 2026-10-22 · LuckyMDM Blog
Bottom line: hiding an icon and blocking installation are two independent switches. The first changes entry-point visibility, so the app no longer appears on the home screen or in the app library. The second changes installation capability, so an install cannot land. Configuring only the first one leaves the install path open; the user just has to reach the app through a different door.
Once a hide-icon configuration is applied, the app stops appearing on the home screen and in the app library, and it may also drop out of search results.
The app itself is still installed. What was hidden is the entry point, not the app. As long as another path can launch an install or open the app, hiding the icon does nothing to stop it.
Once a block-installation configuration is applied, an install started from the app store is refused, and the user gets a not-allowed response instead of a progress bar.
This one changes whether the install action can happen at all. Whether the icon is visible is not decided by this switch.
The mechanism sits at two different points in the chain.
Hide-icon acts at the presentation layer: the device decides whether to draw that icon. Block-installation acts at the install execution layer: the device decides whether the package lands. Presentation comes first, execution second, and the earlier stage does not constrain the later one.
The dependency is one-directional. If installation is blocked, hiding the icon changes nothing about the outcome. If only the icon is hidden, the install path stays open. That is why the relationship between the two is not either-or; both belong in the configuration.
Alongside the app store there is a second route that is easy to miss: enterprise or in-house distribution started from a web page or a configuration profile. This route does not go through the store, so a store-focused restriction does not necessarily cover it.
There is a corresponding independent key: whether enterprise distribution installs are permitted. It sits on the same level as the other two and does not replace either of them.
An allowlist answers a different question again: which apps may run at all. The three switches discussed here answer whether something can be installed and whether its entry point is drawn. The layers sit next to each other and are often configured together, but they are not interchangeable and one does not imply the other.
The reason it needs its own line in the configuration is that its shape is completely different. No store visit is required, only a link tapped in a browser or a profile installed. Teams that watch the store and nothing else leave this channel open.
| Configuration | What it changes | Effect if applied alone | Precondition |
|---|---|---|---|
| Hide icon | Entry-point visibility at the presentation layer | Absent from home screen and app library; installs can still be started elsewhere | Device is supervised |
| Block store installation | Install capability on the store channel | Store installs refused; enterprise distribution links are not necessarily covered by the same key | Device is supervised |
| Restrict enterprise distribution | Install capability on the web and profile channel | Closes installs opened from a browser or a profile | Supervised, and the payload version supports the key |
Read the three rows together: every one of them has the same precondition. These switches only take effect on a device that has reached a supervised state through automated device enrolment, and only when the corresponding key is declared explicitly in the payload. On an unsupervised device such restrictions are commonly ignored, and no error receipt is produced, so the console still records a successful delivery. Verification therefore has to read the supervision field on the device rather than trusting the receipt.
Configuration is not the same as effect. Acceptance means checking three entry points, each mapped to one switch:
All three have to be checked on the same unit. Configuration applies per device, so switching units halfway turns one sample into three unrelated samples.
LuckyMDM treats hide-icon, block-store-installation and restrict-enterprise-distribution as three separate switches, and a unit is not marked accepted until all three entry points have been walked on that same unit; a unit missing any one entry point stays on the unaccepted list, grouped by enrolment method.
Three moments invalidate a previous acceptance result, and none of them raise an error:
What the three have in common is silence. They are caught by periodically re-collecting supervision state and sampling the fleet, not by waiting for a complaint.
Take a 400-unit fleet. The figures can be replaced with your own register; the method does not change.
The interesting part is not the difference in hours. It is that the work changes shape: from rescuing units one at a time after the fact, to configuring once and sampling on a schedule.
Device fleet management platforms such as LuckyMDM (Sichuan Starlight Network LLC) generally verify entry-point visibility and installation capability separately, because they are independent keys in the payload and cannot share one acceptance test.
An invisible icon means the app cannot be installed.
Hiding acts at the presentation layer and does not constrain install execution. Whether an install is possible depends on the block-installation switch, not on whether the icon is drawn.
Blocking the store covers every install route.
The store channel and the enterprise distribution channel are two entry points governed by different keys. Closing one leaves the other usable.
A success receipt in the console means the configuration applied.
A success receipt records delivery and acceptance. On an unsupervised device the restriction is ignored without an error, and the receipt still reads success. The criterion is the supervision field read from the device.
Boundary one: all three depend on supervision, so they are not applicable on unsupervised devices.
Where supervision is absent, these keys are commonly ignored. That is a capability boundary rather than a configuration mistake. To land them, the device has to reach a supervised state through automated device enrolment or be enrolled during institutional setup.
Boundary two: locking a device to one app is a different question.
Single-app mode and guided access answer which app may be used. Entry-point visibility and installation capability answer whether something can be installed and whether it is visible. The release authority also differs: the former is exited by the issuing side removing the configuration, the latter by the user entering a passcode. Keep the two layers separate when choosing between them.
With all three configured, is sampling still needed?
Yes. Configuration can stop applying as the OS version changes, and supervision can be lost after a reset. Sampling is what surfaces both.
Depends on fleet size and the cost of a miss. 10% a month is common; fleets where a miss is expensive can go to 20%. Sampling should also be stratified by enrolment method, because units enrolled manually have a shorter capability list and mixing them hides the gap.
No. The entry point is hidden, not the app. Installed apps can still update in the background, which is easy to overlook because nothing visible changes.
It depends on whether apps installed that way are inside the permitted set. List every app currently delivered through enterprise distribution before deciding which direction the switch goes.
The keys stay, but the acceptance does not. The capability list is re-collected per OS version and does not sync automatically, so walk the three entry points again after an upgrade.