Why does a read fail with a tag lost error?
Because the tag left the field before the exchange finished, which a hand does in half a second. Android raises TagLostException from any operation that touches the radio, iOS fails with a connection lost error, and a write interrupted this way leaves an outcome nobody knows yet.
What each platform raises
On Android every operation that touches the radio can raise it. The TagLostException reference makes it a subclass of IOException, and connect(), transceive(), readPages() and writePage() all declare it. A different error means a different problem: reusing a Tag object after its tag has gone raises SecurityException, since that object belonged to one appearance.
On iOS the same event arrives as an error code. readerTransceiveErrorTagConnectionLost says the reader lost the connection to the tag, and its neighbours name the other cases: readerTransceiveErrorTagNotConnected when the tag is not in the connected state, readerTransceiveErrorSessionInvalidated when the session has ended under it, readerTransceiveErrorRetryExceeded when too many retries have happened.
The hand first, the code second
The physical causes come first because they are the frequent ones. A write takes longer than a read, so a gesture that reads reliably can be too brief to write, which the halfway page describes from the user's side. A thick case, a small tag or an awkward angle leaves no margin, and the tag crosses out of range with a millimetre of movement.
The code causes are subtler. Every command is a round trip, so a sequence of twenty leaves twenty chances to lose the tag, and work done between two commands, a computation or worse a network call, holds the tag open for no reason. Opening another technology class mid sequence can make the platform reselect the tag, which the authentication page covers where it costs the most.
What to do with the tag you lost
Treat a lost tag during a write as an unknown outcome rather than a failure. The command may have reached the tag before the answer was lost, so the next step is to read the memory back, not to write again, and an ordering that leaves nothing half valid makes that readable: the interrupted writes page sets it out.
Then start from the beginning. The tag that comes back is a new detection, a new Tag object on Android and a new detection on iOS, any authentication is gone, and a sequence cannot be resumed from its middle. Code that keeps state across a loss has to reconcile it with what it reads back.
Making the window wide enough
Shorten the exchange rather than lengthen the timeout. Read in the largest blocks the protocol offers, keep the number of commands down, and do everything that does not need the tag before the tap, the arithmetic the timeouts page makes explicit.
Then design the interface for a hand. Tell the user when to move away, show completion only when the call has returned, and test in a hand rather than with the phone flat on a desk, where the window never closes and the bug never appears.
Frequently asked questions
Is a tag lost error a broken tag?
Almost never. It means the tag left the field mid exchange. The same tag usually reads on the next attempt if the phone is held still.
Can I resume an exchange after the tag comes back?
No. The tag that returns is a new detection, and any authentication is gone. Start from detection, and read back before writing again.
Why does a write fail more often than a read?
It takes longer, so it needs a longer hold. A gesture that reads reliably is regularly too brief to write.
What is SecurityException doing here?
It means the code reused a Tag object from an earlier appearance. Each detection gives a new object, and only the newest one works.