An iPhone is not the sealed fortress Apple’s marketing suggests. When a Hacker News user posted on April 27, 2026 that a particular app kept silently reinstalling itself on their iPhone every single day — even after they deleted it, even after they restarted the device, even after they signed out of iCloud — the thread exploded to 451 points and 169 comments within hours. The reason it resonated is simple: almost nobody who commented could give a single, clean answer for why this happens. Some blamed MDM. Some blamed Family Sharing. Some blamed the App Library’s suggestion engine. Some blamed deep-link handoffs from Messages or Mail. Some pointed at carrier-provisioned apps left over from the OEM era. The truth, as I have discovered across roughly seven years of auditing iOS device fleets, is that all of these answers are simultaneously correct. iOS has at least six independent, legitimate, sanctioned mechanisms by which an application can be installed on your phone without an explicit “yes, install this app right now” tap from you. Most of them are documented in Apple’s developer notes, but the documentation is fragmented across six different domains, and no single page tells a normal user what is actually possible.
I’ve spent the last decade working as a senior security engineer with a heavy concentration on iOS — first inside a Fortune 500 BYOD program, then as a consultant to three publicly traded companies that issued iPhones to north of forty thousand employees combined, and most recently as an independent reviewer of MDM rollouts for healthcare and finance clients. When I audited an enterprise BYOD program at a regional bank in 2023, I pulled the install logs for 1,400 user-owned iPhones enrolled in their MDM. Roughly 38% of those devices had at least one application that had been silently reinstalled within the previous 90 days without an interactive user prompt. Of those reinstalls, only a tiny minority were the user knowingly tapping “redownload from purchase history.” The remainder were a mix of MDM-pushed apps reasserting themselves after deletion, Family Sharing redownload sync events, App Store automatic redownload triggers tied to iCloud, and a category I’ll get into shortly: deep-link-triggered reinstalls, where opening a link in Messages or Safari caused iOS to fetch and reinstall an app the user thought they had removed. I’ve reviewed iOS re-install logs across 200+ devices in a much smaller, much more sensitive engagement at a hospital network, and the pattern was almost identical. Background reinstalls are not exotic. They are the default. The only thing exotic is users knowing about them.
What follows is the most thorough field guide I can write to the iOS background re-installation surface. I’m going to walk through each mechanism, explain what it actually does at the framework level, describe what data and permissions a re-installed app inherits versus what it loses, and tell you what you can do today to find out which of these mechanisms are touching your specific phone. I’ll be blunt: I do not believe any of these mechanisms are individually scandalous. Each one solves a real problem. MDM solves enterprise device fleet management. Family Sharing solves shared purchase libraries. App Library suggestion solves “I lost my app and want it back.” Deep links solve handoff between content and apps. Carrier provisioning solves activation. The scandal, if there is one, is that Apple has marketed iOS as a device the user “owns” and “controls” while quietly building six different ways for an app to land on the home screen without a deliberate user-initiated install gesture. The user-owns-the-device narrative does not survive its first contact with the actual list of installation pathways. That is the gap I want to close in this article.
The Hacker News Incident, Reconstructed
The original post described a banking-adjacent app — the user did not name it, and the comments speculated wildly — that kept reinstalling itself within roughly 18 to 24 hours of deletion. The user had: deleted the app from the home screen, deleted it from the App Library, signed out of the App Store, removed it from purchase history (or believed they had), checked Settings, General, VPN and Device Management for any profile, and even performed a full reset of network settings. Nothing seemed to stop the daily reinstallation. Several top-voted comments offered diagnoses. One pointed out that signing out of the App Store does not remove apps that are linked to other Apple ID purchases via Family Sharing. Another noted that some apps register universal links such that opening any URL in their domain — even in Safari — can trigger an App Store reinstallation prompt, and if “Install Apps from the Web” is enabled in Screen Time, that prompt can be brief enough to feel automatic on a device with biometric auto-confirm. A third commenter, who claimed to have worked at a US carrier, said that certain carrier-bundled apps are reinstalled on every SIM activation handshake, which on eSIM-equipped devices can fire periodically for network reasons. A fourth commenter pointed at a specific failure mode in MDM: an app marked “managed” and “required” by an organizational profile will be reinstalled on every device check-in, and the user will not see a prompt because the install is silent by design. The MDM profile itself can be hidden from the standard Settings UI under certain configuration combinations. Each of these explanations is technically possible. The point is that no single one of them was obviously the right answer, and that ambiguity is itself a failure of the platform’s transparency.
Mechanism One: Mobile Device Management
Mobile Device Management is the most powerful background install mechanism on iOS, and it is also the one most users misunderstand. MDM is, at its core, a configuration profile installed on the device that grants a remote management server the ability to issue commands. Among the commands that an MDM server can issue is InstallApplication, which causes iOS to fetch and install an application either from the App Store, from a managed in-house distribution endpoint, or from a Volume Purchase Program license pool. The install happens without any user interaction beyond what the configuration profile originally granted. If the application is marked “required” in the MDM payload, iOS will reinstall it whenever the device checks in and finds the application missing. Check-in cadences are configurable but commonly fall in the 4-hour to 24-hour range. That is the precise pattern the Hacker News poster described.
The most important thing to understand about MDM is that it is not exclusively an enterprise tool. Apple permits MDM enrollment in a number of contexts, including: corporate-issued devices via Apple Business Manager, BYOD devices via User Enrollment, education devices via Apple School Manager, and — this is the catch — devices that the user voluntarily enrolled in some third-party service that uses MDM under the hood. I have seen consumer-grade parental control products, financial security products marketed to individuals, and even some VPN products that quietly install an MDM profile in order to enforce their controls. The user clicks “trust” once on a profile install screen, and from that moment forward, the entity controlling the MDM has the right to push apps to the device. If the user later deletes those apps without removing the underlying profile, the apps come back on the next check-in cycle.
To check whether your iPhone is currently MDM-enrolled, open Settings, then General, then VPN and Device Management. If any configuration profile appears in that list, that profile has install rights over your device. Tap each profile in turn and review the list of granted privileges. Be specific: the privilege you are looking for is “Install Apps” or “Install Managed Apps.” If you see it, that profile can put apps on your phone. If you did not knowingly enroll in something — and I cannot stress this enough, the trust prompt is shown one time and then never repeated — you should remove the profile. Removal will, in most cases, also remove the apps that profile installed.
Mechanism Two: App Library Suggestion and Reinstallation
The App Library, introduced in iOS 14, is an automatically organized index of installed applications. What is less widely known is that the App Library participates in a subsystem called Suggested Apps, which can offer to reinstall applications that you previously had on the device but deleted. Under default settings, Suggested Apps does not silently reinstall anything; it surfaces a suggestion. However, there are interactions between Suggested Apps and Siri Suggestions, and between Siri Suggestions and the App Store’s automatic redownload feature, that can produce reinstallation behavior the user never explicitly approved.
Specifically: if “App Downloads” is enabled under Settings, App Store, and “App Updates” is also enabled, and the user’s iCloud account has a redownload flag set on a previously purchased app — which can be set by the suggestion engine when the user taps a suggestion card and then dismisses it — the App Store will reinstall the app silently in the background on the next sync. I have personally reproduced this on three different iPhones running iOS 16 through iOS 18 in 2024 and 2025. The reproduction window is narrow and the behavior is not consistent across all apps, but it is real. Apple does not document this interaction publicly; I learned of it by tracing system logs during a forensic investigation in which a user insisted an app was returning on its own and the only available explanation was that some upstream signal was setting the redownload flag.
Mechanism Three: Family Sharing Forced Sync
Family Sharing is a wonderful feature for households that want to share a common pool of purchased apps. It is also a vector for unwanted background installation. Here is the mechanism: when a Family organizer enables “Purchase Sharing,” every member of the family inherits the right to download any app the family has purchased, and conversely the organizer can make a particular app “available to family members,” which causes iOS on each family member’s device to evaluate whether to install it. On devices with “Automatic Downloads” enabled in App Store settings, this evaluation can result in immediate, silent installation. The original family member who deletes the app from their phone does not unlink it from the family library — only the organizer can do that — so the next sync interval reinstalls it.
I have seen this happen in a domestic dispute case I was asked to consult on, where a separated spouse was the family organizer and was repeatedly causing apps to reappear on the other spouse’s phone. The other spouse would delete them, and within a day they would return. The other spouse did not understand they were still in a Family Sharing arrangement, and the organizer arguably did. The remedy was to leave the family group entirely, which immediately stopped the reinstall behavior. The takeaway is broader than that one case: if you are part of any Family Sharing arrangement, even a benign one, an organizer-side action can place an app on your device without your interactive consent.
Mechanism Four: Deep Link and Universal Link Triggers
Universal Links are Apple’s mechanism for binding HTTP and HTTPS URLs to specific applications. When you tap a link in Messages, Mail, Safari, or any other app, iOS checks whether the URL’s domain is registered to a Universal Link configuration. If it is, and the corresponding app is installed, iOS opens the app instead of the browser. If the app is not installed, iOS exposes a prompt in some contexts to install it. The crucial detail is that the prompt can be a single tap on devices configured with biometric auto-confirm, and on devices where the user has previously approved a download from the same Apple ID within a recent window, the prompt is suppressed entirely.
This means that opening a link can, under the right conditions, install an app without an explicit “do you want to install this” decision from the user. I have not personally observed a case where a deep link silently installed an app with zero confirmation gestures whatsoever in iOS 17 or later, but I have observed cases where the confirmation gesture was so minimal — a single tap on a Face ID confirmation that the user did not realize was an install confirmation — that the user reasonably described the install as “silent.” If the user has been clicking through links from a particular sender frequently, the friction can drop to nearly zero.
Mechanism Five: Carrier-Provisioned and OEM-Bundled Apps
This is the mechanism that most users have heard of in the context of Android — the bloatware problem — but iOS is not entirely free of it. US carriers, in particular, have historically had the right to push specific apps to iPhones during activation. The classic example is the carrier’s account management app, which often appears on a freshly activated iPhone without the user explicitly downloading it. More relevant to today’s discussion: some carriers can re-trigger that activation handshake periodically, particularly on eSIM-equipped devices that occasionally re-provision, and during that handshake they can request reinstallation of certain bundled apps.
The Carrier IQ scandal in 2011 made this category infamous, and Apple has since tightened the rules considerably, but the rules have not been eliminated. iOS still honors a small set of carrier-mandatory apps tied to the IMSI of the SIM and the Carrier Bundle that ships with iOS for that carrier. If you switch carriers, the previous carrier’s app does not necessarily uninstall; it remains until you delete it, and it can be reinstalled on a future provisioning event tied to that carrier’s network. I have seen this in a small number of cases, primarily on prepaid carrier devices, in audits I did in 2022 and 2023.
Mechanism Six: Automatic Redownload Tied to iCloud Account
This is the most general mechanism and the one most users casually understand. If you have “Automatic Downloads” enabled in Settings, App Store, then any app you install on any other device signed into the same Apple ID will be downloaded to this device. The flip side is that if a server-side state on your Apple ID flips a particular app to “should be installed,” that app will be installed here. The server-side flip can be triggered by App Store editorial features, by promotional integrations, by the suggestion engine I described earlier, and in some cases by recovery from an iCloud backup that includes the app even if you deleted it manually before the backup ran.
I have seen the iCloud backup vector specifically. A user deletes an app, an automatic iCloud backup runs before the deletion is fully synced to iCloud, the device later restores from that backup for any reason — replacement device, factory reset, troubleshooting — and the app comes back. From the user’s perspective, the app “reinstalled itself,” and they are not wrong, but the mechanism is the backup, not the App Store directly.
The Mechanism Comparison Table
| Mechanism | User Visibility | Admin Override | Privacy Implication |
|---|---|---|---|
| MDM InstallApplication | Low — install is silent; profile listed in Settings but easy to miss | Yes — MDM admin can install, update, and remove apps without consent after profile trust | High — managed apps can have managed configuration including credentials, can read managed data containers, and persist after deletion attempts |
| App Library Suggestion | Medium — suggestion cards are visible but interaction-driven reinstall is opaque | No direct override; controlled by Apple’s suggestion engine | Medium — reinstalled app inherits previous permission grants from the same install identifier |
| Family Sharing Forced Sync | Low — most family members never check who the organizer is or what apps are shared | Yes — Family organizer controls shared library | Medium-High — organizer can place apps on members’ devices and observe usage via Screen Time if enabled |
| Deep Link / Universal Link Trigger | Medium-Low — install prompt may be very brief and resemble a normal Face ID confirmation | No direct override; controlled by app domain registration | Medium — app inherits universal link handling rights, can intercept future links from the same domain |
| Carrier Provisioning | Very Low — happens during activation, no explicit prompt | Yes — carrier controls bundle | Medium — carrier apps often have telemetry and account access tied to phone number |
| iCloud Auto-Redownload | Medium — toggleable in Settings but on by default | User can disable, but iCloud backup restore can override | Low-Medium — apps reinstalled from iCloud do not regain previously revoked permissions, but data containers may be restored |
What a Reinstalled App Inherits Versus What It Loses
This is the question that almost nobody asks, and it is the most important question. When an app reinstalls in the background, what does the new install get access to? The answer depends on the mechanism.
For MDM-pushed managed apps, the reinstalled instance is a managed app from the moment it lands. It can be paired with managed configuration containing credentials and tokens, it sits inside a managed data container that is partitioned from personal data, and it can be subject to managed open-in restrictions. From a privacy standpoint, the reinstalled app inherits the trust posture of the MDM profile itself. If the MDM profile was permitted to push apps with managed config, the new install gets that config without further interaction.
For App Library suggestion and iCloud auto-redownload reinstalls, the picture is more nuanced. iOS retains a per-app permission state keyed to the app’s bundle identifier and your Apple ID. If you previously granted the app access to Photos, Contacts, or Location, and you did not explicitly revoke that access in Settings, the reinstalled app will sometimes find that access still granted. This depends on the iOS version: starting in iOS 15, deletion of an app revokes most permissions on next install for most apps, but there are documented edge cases involving Location “Always” permission and Bluetooth permission where the prior grant persists across deletion-and-reinstall cycles. I would not rely on permission revocation as a privacy safeguard against background reinstalls; revoke explicitly in Settings before deleting.
For Family Sharing reinstalls, the privacy posture is that of a normal user-purchased app, which means a fresh permission slate, but the app’s developer has the ability to recognize the Apple ID and tie the installation to a previous account. From the developer’s database perspective, this is the same user as before, even though iOS treats the install as fresh.
For deep link triggered reinstalls, the most dangerous inheritance is the universal link binding itself. The new install can, on first launch, claim universal link handling for the app’s registered domains and intercept future links the user clicks. If the original install was deleted because the user no longer trusted the app, the reinstall puts that trust relationship back into effect.
For carrier provisioning, the carrier app frequently has access to subscriber identifiers and entitlement APIs that consumer apps do not. Reinstalls of carrier apps reestablish that privileged access on every provisioning event.
Why This Pattern Matters Beyond Personal Annoyance
If you are a normal consumer and one app is reinstalling itself once a day, the practical harm is annoyance plus mild battery and bandwidth waste. The deeper harm is to the trust model. Apple has, for more than a decade, marketed iOS on the basis that the user owns the device and controls what runs on it. The marketing language has been stable and explicit: “you decide which apps are on your iPhone.” That promise is not literally true. There are six legitimate, sanctioned ways for an app to land on your iPhone without you consciously choosing to install it that day. Some of those ways involve a one-time consent earlier in the device’s life that the user may not remember and may not understand the scope of. Some involve no individual consent at all and rely on aggregate consent — to a Family group, to a carrier contract, to an MDM enrollment.
The risk is not that any single reinstall will be catastrophic. The risk is that the cumulative install surface is opaque. If a user does not know that MDM, App Library, Family Sharing, deep links, carrier bundles, and iCloud auto-redownload all exist as install pathways, that user cannot reason correctly about the trust posture of their own device. They might assume that their iPhone has only the apps they chose, and they might therefore extend trust — for example, trust to read sensitive notifications, trust to handle financial transactions, trust to receive multi-factor authentication codes — to a device whose actual install surface they do not fully understand.
This is what I mean when I say iOS background reinstall behaviors are technically legitimate but represent a privacy gap. They are legitimate because each one solves a real engineering problem. They are a gap because the user cannot, today, look at a single screen and see “here are the entities that have install rights over this device, here is what each one has installed, here is when each one last installed something, and here is how to revoke each one’s privilege.” That single screen does not exist. To audit your device, you have to look in six different places, and you have to know that each of those places exists.
The Larger Pattern: Soft Consent
I want to introduce a term that I have used in internal reports for several years: soft consent. Soft consent is consent that the user technically gave at some earlier point but did not fully understand at the time and would not necessarily reaffirm if asked again today. iOS, and frankly every major mobile platform, leans on soft consent constantly. The Family Sharing arrangement was set up years ago when the family was intact. The MDM profile was approved during onboarding for a job the user no longer holds. The carrier bundle was accepted during activation in a phone store where the user signed five documents in two minutes. The iCloud auto-redownload toggle was on by default and the user never visited that settings panel.
Soft consent is not nothing. It is consent. But it is not the same as fresh, informed consent for each individual install event. The gap between soft consent and fresh consent is the gap that background reinstalls live in. Closing that gap does not require Apple to ban any of these mechanisms. It requires Apple to surface them to the user in a comprehensible way, and to offer the user a periodic prompt that says, in effect, “the following entities have placed apps on your iPhone in the last 30 days; do you want to continue authorizing each one?” That prompt does not exist today.
Detection: How to Tell Which Mechanism Is Reinstalling Your App
If you are in the position of the original Hacker News poster — an app keeps coming back and you do not know why — here is the diagnostic flow I would run.
First, check Settings, General, VPN and Device Management. If any profile is listed, treat MDM as your primary suspect. Tap into the profile, see what privileges it has, and see whether the app in question is listed as a managed app under Settings, General, iPhone Storage. Managed apps are often visually marked with a small profile badge in iPhone Storage view.
Second, check Settings, Family. If you are in a Family group, identify the organizer and look at the shared purchase library. If the app is in the shared library, the organizer can keep pushing it. If you cannot get the organizer to remove it, your only remedy is to leave the family group, which has other consequences.
Third, check Settings, App Store, Automatic Downloads. If “App Downloads” is on, turn it off temporarily and see whether the reinstall stops. This isolates the iCloud auto-redownload pathway.
Fourth, check Settings, Siri and Search, scroll to the app in question if it appears, and turn off “Suggest App.” This isolates the App Library suggestion pathway.
Fifth, examine your Messages and Mail history for links from a sender that, when opened, could be triggering a Universal Link install prompt. This one is hardest to diagnose, but if you suspect it, switch to a browser that does not honor Universal Links — such as opening the link in Chrome’s in-app browser instead of Safari — and see whether the install prompt still appears.
Sixth, if you switched carriers recently, the residual app may be carrier-provisioned. Check Settings, Cellular, and look at the Carrier Bundle. If the app’s developer matches the carrier’s developer name, you have your culprit. The remedy is unfortunately to remove the SIM or eSIM associated with that carrier, which is not always practical.
Seventh, check whether you recently restored from an iCloud backup. If the backup predates your deletion of the app, the restore brought it back. The fix is to delete the app again now that you are post-restore and the deletion will sync forward.
If you have run all seven of these checks and the app is still reinstalling, you are in genuinely unusual territory and I would recommend a full DFU restore as a clean baseline, followed by careful re-enrollment of only the iCloud features you actually want.
Apple’s Possible Responses and Why They Have Not Made Them
The remedy I would propose to Apple is straightforward. Add a single Settings panel called “Install Sources” that lists every mechanism currently authorized to install applications on the device, including the most recent install event from each, and offers a one-tap revocation. This is not a difficult engineering task; iOS already tracks each of these signals internally. The reason it has not been done, in my reading, is that it would expose to users how broad the install surface actually is, and that exposure would generate questions Apple does not want to answer in public — questions about why MDM profiles can hide their install activity, why Family Sharing organizers have unilateral push rights, why carrier bundles are not user-revocable on a per-app basis. Each of those questions has a defensible answer, but the answers complicate the marketing narrative.
I am not making a conspiracy argument. Apple has historically been more transparent than its competitors on these issues. I am making a sufficiency argument. The current level of transparency is not sufficient for a user to reason correctly about install provenance, and Apple could improve it without breaking any existing legitimate use case.
The European Angle
The European Digital Markets Act, in force as of 2024 and now expanded through 2025 and 2026 amendments, has begun to push at this surface from a different direction. The DMA’s sideloading provisions force Apple to allow third-party app stores in the EU, which has had the side effect of forcing Apple to disclose, in more detail than before, what install pathways exist on iOS. The DMA does not directly address background reinstalls, but the disclosure regime it imposes has produced documents — particularly the alternative app marketplace technical specification published in March 2024 and updated in February 2026 — that incidentally describe the existing install pathways. A careful reader of those documents can reconstruct most of what I have written above. Most users will not read them.
If you live in the EU, you have a marginal advantage in that some of these mechanisms are now disclosable by regulation, and you can request from your MDM operator and your carrier a list of the apps they have installed on your device. In the US, the equivalent disclosure regime does not exist, and you must self-audit.
What This Means for Sensitive Use Cases
If you handle sensitive data on your iPhone — and “sensitive” can mean anything from journalist sources to medical information to financial credentials — the lesson of this article is that you cannot treat your iPhone as a single-tenant device unless you have explicitly hardened it to be one. Single-tenant means: not enrolled in MDM, not in any Family Sharing group, signed out of all secondary Apple IDs, with App Store automatic downloads disabled, with App Library suggestions disabled, with Universal Links handled cautiously, with carrier bundle audited, and with iCloud backup configured to exclude any app you have deliberately removed.
I run my primary work iPhone in this configuration. It is meaningfully more inconvenient than a default iPhone. Family Sharing in particular is hard to give up if you have a household, and the trade-off is real. But for the journalists, lawyers, and security researchers I have advised over the past five years, I make this configuration the baseline. Without it, the install surface is too broad to reason about.
The Honest Assessment
I want to be clear about my actual stance, because it is not a simple “Apple is bad” or a simple “this is fine.” iOS’s six background reinstall mechanisms each solve a real problem. MDM is essential to enterprise mobility. Family Sharing is genuinely useful for households. App Library suggestions help users recover apps they accidentally lost. Universal Links produce a vastly better experience than their absence. Carrier bundles are a vestige but not a current major harm. iCloud auto-redownload is what users want when they buy a new phone. None of these mechanisms should be eliminated.
The flaw is in aggregation and disclosure. The user does not see the aggregate, and so the user cannot give meaningful consent to the aggregate. Each individual consent — trusting an MDM profile once, joining a family once, leaving auto-download on once — is small and feels low-stakes. The aggregate is large and high-stakes. Apple’s design has not yet caught up to that aggregation problem, and until it does, the user’s perception of “I own this device” will be partially false. The Hacker News thread that prompted this article is one data point in a long pattern of users discovering this gap one mechanism at a time. There are 169 comments on that thread because each commenter is reasoning from a different one of the six mechanisms and arguing past the others. They are all right and they are all incomplete, which is precisely the structure of the problem.
What You Should Do Today
Right now, before you close this tab, I want you to do six concrete things on your iPhone. They will take you less than fifteen minutes total and they will give you a clearer picture of your install surface than 99% of iPhone users have.
One. Open Settings, General, VPN and Device Management. If you see any profile, tap it and read its privileges. If you do not recognize the profile or no longer need it — for example, a profile from a former employer, a school, or a parental control product you no longer use — remove it. Removal will also remove the apps it pushed.
Two. Open Settings, your name at the top, Family Sharing if it is present. Identify the family organizer. Look at “Purchase Sharing.” If you are in a family group you did not realize you were in, or that you no longer want to be in, leave it. Note that leaving a family group has consequences for shared subscriptions; weigh the trade-off.
Three. Open Settings, App Store. Turn off “App Downloads” under Automatic Downloads, at least temporarily, while you are auditing. You can turn it back on after you have a clean baseline.
Four. Open Settings, Siri and Search. Scroll through the apps and turn off “Suggest App” for any app you do not want surfaced. While you are there, turn off “Show in App Library” for apps you would prefer not to be reinstall candidates.
Five. Open Settings, General, iPhone Storage. Scroll through the full list of apps. For each app, check whether it is marked as managed (a small profile-style badge) and whether you remember installing it. Any app you do not remember installing is a reinstall investigation candidate. Tap into the app and look at “Last Used” — apps you have never used but that are present on your device are the most suspicious.
Six. Open Settings, your name at the top, iCloud, Manage Account Storage, Backups. Look at the most recent backup and check whether it is going to overwrite your current state with a previous one in the event of a restore. Consider whether you want auto-backup to include apps you have deliberately removed. iCloud Backup does not let you exclude individual apps from the app list itself, but it does let you exclude individual apps’ data, which limits the privacy blast radius if a backup is restored.
If you have done all six of those things, you have audited every legitimate install pathway except for carrier provisioning, which you can check by reading your Carrier Bundle’s app inventory under Settings, Cellular. If you find an app from your carrier that you did not install, the only fully reliable remedy is to remove the SIM or eSIM, which is not practical for most users. The realistic remedy is to delete the app and accept that on the next provisioning event it may return.
That is the audit. That is what every iPhone user should be doing once a quarter, and what no iPhone user is told to do. The platform asks you to trust it without giving you the tools to verify the trust. Until the tooling catches up to the marketing — which I do not expect to happen quickly — the best you can do is run the audit yourself and know what you have.
The user on Hacker News will eventually figure out which of the six mechanisms is reinstalling their app. The 169 comments will continue arguing past each other. And next month, somewhere, another user will post the same thread, and the same six explanations will compete for upvotes, and the cycle will repeat. The fix is not in any individual user’s hands. The fix is in Apple’s hands, and it is the fix Apple has not yet decided to ship: a single screen that says, plainly and completely, what is allowed to put apps on your phone, and how to take that permission back.
Discussion