Your Users Said No. Does Your Product Remember?

On Monday, two separate Apple stories sat on the Hacker News front page at once. One had 800 points, the other 644. Between them they collected over 1,100 comments in a day.

Neither was about a bug. Neither was about a price rise. Both were about settings.

The first, from developer David Bushell, described upgrading a Mac and finding Apple Intelligence switched back on after he had deliberately turned it off, with the toggle to turn it off again no longer present. The second was about promotional banners for iCloud+, Apple Music and AppleCare+ appearing inside the Settings app, sticking around for weeks, and resisting dismissal.

Both are things a five-person startup does too, usually without a meeting where anyone decided to. Worth understanding why the reaction is so far out of proportion to the feature.

Take the second one first because it is simpler. Apple placed prompts for its own paid services inside the Settings app. Users found them hard or impossible to dismiss, and reported them persisting for weeks. The TechRadar write-up quoted people describing it in language you would not want applied to your own product.

The first is subtler and more instructive. A setting that was turned off came back on after a system upgrade, and the control to turn it off again was gone. Bushell's framing was about consent rather than about AI. His point was that an off switch which does not survive an update is not an off switch. It is a pause button that the vendor controls.

Apple is not unusual here. It is just legible, because a lot of people run the same software and compare notes.

Because of what the user infers.

When a feature you disabled comes back, the user does not think "migration edge case in the settings schema." They think somebody decided my preference was inconvenient. One event, and every future setting in your product becomes provisional in their mind.

That inference is expensive and it does not decay quickly. You have taught them that the controls are decorative. From then on they read your privacy toggle, your notification preferences and your data sharing switch as suggestions.

And the feature you re-enabled almost never earns enough usage to cover that. Users who explicitly turned something off are close to the worst possible cohort to force back into it. They already told you their answer.

Most products store only one of these and treat it as all three.

Not now. The user is busy and dismissed a prompt. Reasonable to ask again later.

Not this way. The user wants the outcome but rejects the mechanism. Wrong channel, wrong frequency, wrong permission ask. Worth asking again differently.

Never. The user made a considered decision and expects it to hold.

If your schema has one boolean called dismissed_at, you have collapsed all three into the weakest one. Every no becomes not now, and your product reasks forever.

Split them. A dismissal on a banner is different from a toggle flipped in Settings. The second is a considered act and deserves to be permanent until the same user reverses it in the same place.

The temptation is understandable. Settings gets high-intent traffic, it costs nothing, and attributing an upgrade to a banner there is easy.

Here is the accounting nobody runs. Settings is where people go when something is wrong or when they want control. It is the highest anxiety screen in your product. Attention there is not cheap inventory, it is borrowed trust, and you are borrowing it at the exact moment the user is least receptive.

Worse, upsell placement in Settings is measured on conversion and almost never on the counterfactual. You see 340 upgrades attributed to the banner. You do not see the 900 people who read it as a sign the product is drifting and quietly started evaluating alternatives.

If you must put commercial messaging in Settings, make it dismissible in one tap, make the dismissal permanent, and cap it to once per major release. Those three rules cost you very little revenue and remove almost all of the downside.

Founders treat this as a taste question. It shows up as a forecasting question.

Your model has a retention assumption in it. Maybe 92 percent monthly logo retention, maybe a churn curve that flattens after month four. That assumption carries the terminal value of the whole spreadsheet. Trust incidents move it, and they move it in the tail rather than in the first month, which is why they are easy to miss until a board meeting.

So when you weigh a settings-screen upsell, weigh it against the retention line, not against the acquisition line. Ask what percentage of monthly churn you are willing to buy with those upgrades. Usually the right answer is zero.

If you are building that model for the first time, you can do it in a spreadsheet, in a template from your accountant, or in a planning tool like Foundra that walks first-time founders through the assumptions section rather than leaving retention as a number you typed once and never revisited.

Four routes, all of them ordinary.

A migration script. You add a new field, backfill it with the default, and everyone who had opted out silently opts back in. Nobody reviewed the backfill because it was one line in a pull request.

A feature flag rollout. The flag defaults to on for the cohort, and cohort membership was computed before user preferences were checked.

A growth experiment with a deadline. Someone needs a number by the end of the quarter, the Settings screen is available, and the test ships without a permanence rule.

A rewrite. The new settings screen does not carry over an old preference because nobody had a list of which preferences existed. This is the most common one, and it is the reason to keep that list.

None of these involve a bad actor. All of them produce the same user experience, which is a product that does not take no for an answer.

Run this before any release that touches preferences, permissions or onboarding.

1. List every user preference in the product, including the ones stored as flags rather than as settings. If you cannot produce this list in ten minutes, that is the finding.
2. For each one, write down what happens to it during a migration, a rewrite, and a plan change.
3. Check that every backfill preserves an explicit user choice rather than writing the default over it.
4. Confirm that each no is stored with its type: dismissed, deferred, or refused.
5. Make sure a refused preference can only be reversed by the same user in the same place they set it.
6. Cap re-asks. Once per major version is generous. Once per quarter is more common.
7. Test the upgrade path with an account that has everything turned off. This single test catches most of it.

Seven steps, maybe an hour of work per release. Cheaper than one angry thread.

• An off switch that does not survive an update is not an off switch, and users describe it exactly that way.
• Store the type of no, not just the fact of it. Dismissed, deferred and refused are three different answers.
• Settings is the highest anxiety screen in your product. Attention there is borrowed trust, not free inventory.
• Upsell placements get measured on conversions and almost never on the churn they seed.
• Most re-enablement happens through migrations, flag defaults and rewrites, not through a decision anyone made.
• Test every release with an account that has opted out of everything.

Is it ever acceptable to re-enable a feature a user turned off?

Rarely, and only when the old setting no longer maps onto anything in the new version. When that happens, tell the user at first launch and give them the new control in the same screen.

How often can I re-ask for a permission that was declined?

Once per major release is the outer limit for most products. For anything privacy adjacent, treat a decline as permanent until the user raises it themselves.

We are pre-revenue. Does this matter yet?

More, not less. Early users are your reference customers, and there are few enough of them that each one who loses confidence is a measurable share of your base.

What if our upsell in Settings converts well?

Then measure the cohort ninety days out against a holdout that never saw it. Conversion without a holdout is not evidence.

Our data model already collapsed everything into one dismissed flag. Where do we start?

Add a type column, set existing rows to deferred, and treat anything set from an explicit settings screen going forward as refused. You do not need to backfill perfectly to stop the bleeding.

Does any of this change if we are enterprise rather than consumer?

The mechanics are the same, the blast radius is larger. An admin who finds a policy reset after an update will raise it in a renewal conversation, not a tweet.

1. I said no and Apple said yes, David Bushell, September 22, 2026
2. I said no and Apple said yes, Hacker News discussion, September 22, 2026
3. Apple has added persistent ads to iOS, and it is driving users crazy, TechRadar, September 22, 2026
4. Apple has added persistent ads to iOS, Hacker News discussion, September 22, 2026
5. iPhone users are flooding social media with complaints, Yahoo Tech
6. Apple showing persistent ads on iPhones, and users are unhappy, NewsBytes