How do you test a tag on both platforms before deploying?
With four devices and one rule: test the outcome rather than the read. A tag that is detected and does nothing has passed the wrong test, and that is the commonest way a deployment ships broken across half its audience.
Four devices
The oldest Android phone you can borrow, with its case on.
The oldest iPhone that supports tag reading at all, since that is the group most likely to surprise you and the least likely to be in your office.
A recent phone of each, which tells you the deployment works at its best. On Android, a recent phone running Android 17 also shows the open link notification that the older one does not.
Take NFC Tools. On iOS it requires an iPhone 7 or later running iOS 15.6 or later, and the app must be launched manually. Background reading is available from the iPhone XS and XR onwards.
Four devices cover the range that matters. Testing on one recent phone tells you almost nothing about the other three.
Test the outcome
Tap the tag and watch what happens, all the way to the thing you wanted the person to see.
Reading the tag with a diagnostic tool is a different test. It tells you the content is correct, which a tag can be while doing nothing useful.
On an iPhone, and on Android 17 for a web link, that includes tapping the notification, because a tag whose notification is dismissed has produced nothing.
And it includes the page loading, on a mobile connection, in the place the tag will live.
Under real conditions
On the real surface, since a bench and a steel doorframe are different products.
At the real height and angle, because a tag you lean over on a table is not the tag someone reaches on a wall.
With the real gesture, performed by somebody who has never seen it, without instruction.
And with the real content, since a test address is shorter than the production one and shorter is easier.
Record what you tested
Which devices, which conditions, what happened. A line each.
That record is what lets you answer a complaint six months later without re establishing everything, and what tells a successor what was and was not verified.
Note the failures as well as the successes, particularly the ones you decided to accept. An accepted limitation that nobody wrote down becomes a bug report.
And repeat the test when anything changes: a new tag supplier, a new content type, a new location type.
Frequently asked questions
Is one phone of each enough?
No. Old devices behave differently and they are what your audience carries. Test the oldest you can borrow of each.
Why test the outcome rather than the read?
Because a tag can be read perfectly and produce nothing. Reading proves the content, and only the outcome proves the deployment.
What if it works on Android and not iPhone?
Check the record type first, since iOS acts on fewer types. If the iPhone shows no reaction at all, it is a reading problem instead.
How often should I retest?
Whenever the tag supplier, the content type or the location type changes. Those are the three that invalidate an earlier result.