As long as you use DNS instead of hardcoding IPv4 addresses (and if you are using AWS's ELB, you are using DNS instead of hardcoded IPv4 addresses), a mobile phone in an IPv6-only network will connect to your backend as if it had a IPv6 address, with the mobile network doing all the translation.
That's probably why Apple is adding the requirement: no matter whether your backend is on IPv4 or IPv6, your client must be able to connect to it as if it were on IPv6. Due to IPv4 exhaustion and the costs of CGN, the more phones can use exclusively IPv6 (even if through NAT64 or 464XLAT), the better for the network operators.
It would be bigger news if iOS 9 required all apps to support not having access to IPv4.
1) your app/client will work just fine on ipv6-only networks with NAT64 gateways, making for a better experience for your customers (less breakage on such networks) and will help network operators transitioning to v6,
2) if it does any kind of p2p (think rtp, webrtc, bittorrent, sip, etc.), it will take advantage of nat-free v6 paths for client to client communications, regardless of which address family it uses to talk to the backend.
1. Use some sort of v6-to-v4 proxy service
2. Or chose another system for their backend
Given that Apple are apparently using AWS as part of their iCloud, I suspect it won't be an issue though. Perhaps Apple know that Amazon will be rolling out appropriate changes in a timescale sufficient that they can be reasonably sure there will be no problem?
^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$