It (most likely) works like this: the device request the context directly to the edge server (several strategies available to accomplish this: you can ask a master server for the content who issues a redirect to the edge server, Apple could use a single name server and route via DNS, they could use a single name and IP and route via BGP, etc). The edge server, which is the terminating end in the TLS protocol, is aware of the content being requested. Now the edge server can determine if that content is available or not locally and server it back to the user or request it from the origin server first and then back to the user.
The problem isn't with terminating SSL, it's with keeping your keys safe on exposed infrastructure.
A single domain name and DNS to route is uncommon because it doesn't give you fine-grained control of load - you need to be mindful of the rack's capacity, and you also need to make sure that most of that ISP's customers go to the rack/people who aren't that ISP's customers don't go to it.
Anycasting isn't going to be great for traffic management or long-lived TCP conns, and if you can avoid the complexity of each rack needing a bgp session into the ISP's network you're going to be much better off.
Typically this is going to be directly routed to the rack via a unique DNS name after some form of service call.
