The only small caveat that should go along with that: that there is no native IPv6 connection to the Internet, i.e. it is an IPv6-only hotspot with an IPv4-only uplink to the Internet.
So, while the basic behaviour should be fine, it's best to set up a full-fledged IPv6-only access network, to ensure you can test the usage of the native IPv6 by the app as well, and verify there are no unexpected issues. (If the app talks to the resources that are IPv6-enabled, that is).
NAT64/DNS64 is completely invisible to the endpoint - there is zero differentiation between how a client talks to a native IPv6 resource and an IPv4 resource. All of the translation is handled by the network/DNS, so if your app works with your device configured with only a v6 IP address while supported by a NAT64/DNS64 network, you're good to go.
This is oddly worded to me and likely going to cause grief as it sounds like your app can only run on IPV6. I would interpret is as your app must be able to run internet connected when IPV4 is not available. This likely includes your local loopback if you are using 127.0.0.1 (which I infer from the hard code statement).
Or another weird to put it, your application must be IPV6 with the option of a IPV4 add-on.
If your ISP does not give you IPv6, you can get it for example at tunnelbroker.net - though beware that the properties of that connection, primarily when talking about MTU will be slightly different than from the "native" one.
Feel free to give a read and leave the feedback - I'll be happy to tweak the document to make it more friendly/useful.
I guess running the phone on an IPV6 only network and confirming it works would be all it takes?
I'm sure there are things I'm missing, what are others doing?