Open Radar

 
openURL used to recognize URLs like "https://itunes.apple.com/app/id1031093592" as App Store app URLs and would open the native App Store app directly.

It looks like a configuration change from Apple has been pushed to all iOS devices that removes support for this URL pattern and replaces it with "https://appsto.re/app/id1031093592".  This happened in the last 1-2 days, and affects iOS versions 7.0 through the latest.

When we call openURL using the old itunes.apple.com pattern, iOS opens Mobile Safari which then redirects to the App Store app.  This adds an extra hop for the user and breaks the back breadcrumb.  Pressing back returns to Safari, not the original app that opened the URL.

We can modify many of our iOS app URLs on the server-side to start using the "appsto.re" domain, but some are compiled into our production apps.  I imagine this is the case for many developers.

Would it be possible for Apple to add back in support for the long-standing "itunes.apple.com" URLs?

--------------------------------------------------------------

How we know it was a configuration change from Apple:

- MobileCoreServices.framework includes a file (iTunesStoreURLPatterns.plist) that openURL uses to decide if a http/https URL should be rewritten into a native URL.  This is how URLs like "https://itunes.apple.com/app/id1031093592" get converted to  "itms-appps://itunes.apple.com/app/id1031093592" before opening.

- The rule that's shipped with iOS for mapping App Store URLs looks like --

```
{
    "host-patterns" =             (
        "phobos\\.apple\\.com$",
        "((buy|my|search|c|itunesu|vpp)\\.)?itunes\\.apple\\.com$"
    );
    "path-patterns" =             (
        "[&?](mt=8|media=software)(&|$)",
        "^/webobjects/mzsoftwareupdate.woa/wa/(availablesoftwareupdates)",
        "^/webobjects/mzstore.woa/wa/(viewsoftware|pandastorefront|viewfeaturedsoftwarecategories)",
        "^/webobjects/mzfinance.woa/wa/(com.apple.jingle.app.finance.directaction/)?(verifyaccountemail)",
        "^/webobjects/mzfinance.woa/wa/associatevppusertoitsaccountsrv",
        "^/([a-z][a-z]/)?(app|apps-store|developer)(/|\\?|$)"
    );
    "scheme-mapping" =             {
        http = "itms-apps";
        https = "itms-appss";
    };
},
```

From the above, we can see that itunes.apple.com URLs should work based on this (itunes.apple.com is a supported host pattern).

- iOS also downloads a "url-resolution.plist" file and stores it at: "/var/mobile/Library/Caches/com.apple.itunesstored/url-resolution.plist".  When present, this file takes precedence over "iTunesStoreURLPatterns.plist".

- In the "url-resolution.plist" file, the contents of the App Store URL rule looks like --

```
{
    "host-patterns" =             (
        "appsto[.]re$"
    );
    "host-suffix-whitelist" =             (
        "appsto.re",
        "itun.es",
        ".apple.com",
        "new.itunes.com",
        "apple.co"
    );
    "p2-url-section-name" = MobileSoftwareApplications;
    "path-patterns" =             (
        "[&?](mt=8|media=software|media=watch|app=watch)(&|$)",
        "^/webobjects/mzsoftwareupdate.woa/wa/(availablesoftwareupdates)",
        "^/webobjects/mzstore.woa/wa/(viewsoftware|pandastorefront|viewfeaturedsoftwarecategories)",
        "^/webobjects/mzfinance.woa/wa/(com.apple.jingle.app.finance.directaction/)?(verifyaccountemail|associatevppuserwithitsaccount)",
        "^/([a-z][a-z]/)?(app|app-bundle|apps-store|developer|vpp-associate)(/|\\?|$)",
        "^/[a-z][a-z]/[^/]+[.]i$"
    );
    "scheme-mapping" =             {
        http = "itms-apps";
        https = "itms-appss";
    };
},
```

From the above, we can see the only supported host pattern is now "appsto.re", and this is what's breaking all the old itunes.apple.com URLs.

Steps to Reproduce:
These are steps to prove this a server-driven config change from Apple --

0. Find iPhone w/ no SIM or an iPod Touch (so that data access can be completely disabled).
1. Do a "Reset All Content and Settings" so that the file "/var/mobile/Library/Caches/com.apple.itunesstored/url-resolution.plist" can be removed.
2. Start device.
3. Choose English language.
4. Choose United State.
5. Skip Wifi setup (so that iOS cannot download a new url-resolution.plist file yet).
6. Choose Setup as new iPhone.
7. Deploy test iOS app to the device which calls openURL to an itunes.apple.com URL on startup.

```
NSString *iTunesLink = @"https://itunes.apple.com/us/app/id1048542880";
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:iTunesLink]];
```

8. Run app.  

OBSERVE: App starts and app switches directly to the Apple App Store.  Since WiFi isn't on and we have no data, the store content doesn't load.  But, at least the store app was opened directly w/out hopping through Safari.

-----

# Next we'll show that itunes.apple.com URLs stop working once the new configuration is downloaded from Apple.

1. Quit test app.
2. Enable WiFi.
3. Open the App Store app so we can be sure "/var/mobile/Library/Caches/com.apple.itunesstored/url-resolution.plist" has been fetched.
4. Re-run test app that we made earlier.

OBSERVE: App starts; app switches to Mobile Safari which in turn app switches to the App Store app.