@Dave S Personally I think this functionality should be built into to iOS so the developer never needs to care... .but alas it is not.
I can't speak for Xojo for iOS because I have not used it yet. Most all my iOS apps are currently done in another product where it is handled for me automagically *if* do it a certain way.
If I just define a window and place text fields on that window, they get overlaid by the virtual keyboard.
However, if I place the text fields in what is called a "Scroll View" and that scroll view either covers the whole window or at least enough area above the virtual keyboard area, then setting the focus into a field (either by the user tapping a field, or via code) when the keyboard appears it scrolls the text field to where it is visible. I don't add any code to make that happen.
To answer your original question, if the user had tapped into field B and the contents needed to scroll and then tapped into field A and it was already visible, then contents does not scroll again. In other words, in my experience if a field is already visible the contents does not move. If not, it scrolls the necessary amount to put that field above the virtual keyboard (and toolbar, if any).
But perhaps it is not iOS doing that -- I always assumed it was.
But to make that happen in the product I use, I need to place the UI controls like text fields in a so called "Scroll View". I don't know if Xojo has an equivalent. But think of it as a container control or canvas that scrolls.