That means the app internally needs to be able to handle IPv6 addresses and not hardcore any IPv4 addresses as those can’t be reached. There’s no requirement that the service underlying the app is directly reachable via IPv6.
Apple's requirement is that even though you know your server is definitely 10.20.30.40† on the public network, and you hate IPv6 you must not hard code 10.20.30.40 inside the app and ship that to the App Store.
Once you reluctantly change it to a DNS name ten-twenty-thirty-forty.fuck-off-apple.example that resolves to 10.20.30.40 - Apple allows that.
Because now when your app is used on some IPv6-only carrier network, the carrier goes "ten-twenty-thirty-forty.fuck-off-apple.example ?" and it gets 10.20.30.40 and it says that's an IPv4 address, don't use those around here, and it adds a translator step, it gives the phone an IPv6 address for ten-twenty-thirty-forty.fuck-off-apple.example and the phone connects to that address, which is a translator that connects to 10.20.30.40 on the IPv4 Internet.
This stuff happens all the time and you don't notice. But if Apple allowed app vendors to just scribble IPv4 addresses inside their app software it would break.
† No that isn't a public IP address. It's an example.
“The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation.”
— RFC 5737, IPv4 Address Blocks Reserved for Documentation https://www.rfc-editor.org/rfc/rfc5737.html
(No I don't use RFC1918 addressing at home; Yes, every machine in my home has public IPv4 and/or IPv6 addresses; No that doesn't make it "really easy to break in" because having an address is not the same thing as being accessible)
I would have thought that an app that is purportedly an app for site X but that cannot actually talk to site X when on an IPv6-only network would fail that requirement, but maybe I'm overestimating what Apple actually checks. Are they only checking that the app will correctly attempt an IPv6 connection to the site?