Which platform limits will not be lifted by an update?
The ones that follow from a deliberate position rather than from a missing feature. Those are worth designing around permanently and without complaint. Limits tied to hardware generations are worth waiting out instead, since the installed base turns over on its own.
Structural limits
An application cannot start itself from a tag on iOS. Reading is initiated by an application asking or by the system noticing, never by the tag.
There is no background writing on iOS. Writing always requires an application in front of the user.
The background path presents a confirmation the user must take, rather than acting directly. Android now does the same for web links: from Android 17, the Android NFC basics guide says a tag holding one shows an open link notification first.
And phone to phone exchange by touching is gone from both platforms, so it is not a fallback for anything.
Each of these reflects a position about consent and control rather than an unfinished feature, which is why they have held.
Generational limits
Background reading on iPhone, which is available from the iPhone XS and XR onwards. Nothing in software extends it downwards, and the proportion of older devices falls on its own.
Support for particular tag technologies in older Android controllers, which likewise resolves as devices are replaced.
Field strength and antenna position, which vary by model and improve unevenly.
These are worth waiting out for a deployment measured in years, and not worth waiting for in a campaign measured in weeks.
Telling them apart
Ask what the limit protects. If the answer is a user decision, it is structural.
Ask whether it applies on the newest hardware. If it does, no amount of device turnover helps.
Ask whether the platform documents it as behaviour rather than as a restriction. Documented behaviour rarely reverses.
And be suspicious of any supplier who says a limit will be lifted. That is a prediction about somebody else's product, offered to close a sale.
Planning accordingly
Design around the structural ones permanently: assume a deliberate tap, an awake phone, a confirmation step, and no application launching itself.
Accept the generational ones with a fallback, and revisit the assumption in two years rather than building for a future that has not arrived.
Write down which of your design decisions exist because of which limit. A successor who does not know why will remove the fallback.
And never commit contractually to a limit being lifted, since you do not control the platform and the client will hold you to it.
Frequently asked questions
Will iOS ever let a tag launch an app?
It has not, and the model has been consistent. Treat it as structural rather than pending.
Will older iPhones get background reading?
No. It is tied to a hardware generation, so it resolves through device replacement rather than through updates.
How do I tell a structural limit from a temporary one?
Ask what it protects and whether it applies on the newest hardware. A limit protecting a user decision, present on new devices, is structural.
Can I promise a client this will improve?
No. It is a prediction about someone else's product, and you will be held to it.