Apparently Apple announced that once iOS 9 is released, all apps will be required to support ipv6. Given the large number of apps that use AWS as a backend, how will this be feasible?

NAT64 or other transition technologies.

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.

Using hardcoded IP addresses in your code is a bad idea anyways.

Any of the down voters, do you care to share why you are down voting? This is the official development guide of Amazon as well.

The app can support IPv6 while not actually using it for communication. This would be a matter of allowing people to enter IPv6 addresses, websites, e-mail addresses, etc; logging, and displaying IPv6 addresses rather than hard-coding IPv4-only approaches, etc. Basically, prepare your app so that if your backend supports IPv6, your app already does.

It would be bigger news if iOS 9 required all apps to support not having access to IPv4.

There's really no point having IPv6 if you still require IPv4. It's a natural middle step, but you're still burning an IPv4 address.

On the contrary, there are advantages in having your apps/clients support ipv6 even if your backend is not ready to offer v6 connectivity:

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.

Supporting IPv6 doesn't necessarily mean IPv6 exclusively. Also, there's always tunneling. Hacky, but it might be the stick that is needed to whip people into actually using IPv6.

I doubt that is something that Apple consider to be their problem: what the developer chooses for their back end is their business. If the relevant parts of AWS don't support IPv6 then developers will have two choices:

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?

Android seems to have been doing a pretty good job at this. I've been using IPv6 exclusively on my Nexus 4 ever since T-Mobile rolled it out, and I've yet to come across an app that isn't compatible with it.

I'm going to hazard a guess and say that Apple probably just wants to make sure that your app doesn't try to do silly things like pass user-input network addresses (like for email apps that need the user to supply an email server address) through parsing regexes like (\d+)\.(\d+)\.(\d+)\.(\d+).

Just for the record this is not the regexp for matching IP addresses. It is for matching 4 multi digit numbers separated by dots.

IP addresses will include IPv6 addresses, so no, this is not a good regex for matching IP addresses. Which is the point.

Even in an IPv4-only world, that regexp admits strings like 123.456.7890.12345.

You're capturing the octets individually. You already have to do bounds checking on RFC 1918 ranges and such. Why wouldn't you do the octet checking in your post-match logic? This is just pedantic.

How about?

^(?:(?: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]?)$

Route53 has IPv6 support in the sense that you can get/set AAAA records. It doesn't have it in the sense that their namesrvers are IPv4 only. That's my biggest annoyance with route53.

(I wrap route53 with tinydns + git to provide DNS with flat pricing and good reliability - http://dns-api.com/ )

I agree with you that it is very important that AWS offers it everywhere. However, I would say they do offer it "where it counts": their load balancer a are already dual stack and Route 53 ALIAS records support this directly too. Your clients can access you via IPv6 and that is huge.

Their LoadBalancer is IPv6 only in EC2 Classic which is being deprecated.

When you create an AAAA alias record in Route 53 and point it to a VPC load balancer, it gives out an IPv6 address. It does only mention A record in the load balancer description's DNS Name field, so I don't know what to make of it.

Yes, this is very confusing. It assigns the IPv6 address but that does not actually work as the LB is in the VPC which does not support IPv6. Lesson I learned: testing whether IPv6 actually works is worthwile.

That's what I was afraid of...

But not in S3, or on the CDN, for example.