Earlier this month, Apple redesigned https://apps.apple.com, which is essentially a web preview of the App Store. It’s not really the App Store on the web, because you can’t purchase or download apps from the website. I’ve already blogged about how the redesign affects Safari on macOS, and now I’ll blog about how it affects Safari on iOS. There’s some overlap but also some iOS-specific behavior.
Curiously, the new website works only on iOS 26. In my testing, Safari on iOS 18 refuses to load any apps.apple.com pages, not even the front page. All apps.apple.com URLs are sent to the App Store app, either immediately in non-private windows or after you grant permission in private windows. If you cancel in a private window, then nothing gets loaded anywhere.
This restriction appears to be hard-coded into Safari 18, because nothing on the server side prevents the website from loading. The following URL request successfully returns an HTML page:
curl -v -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.7.2 Mobile/15E148 Safari/604.1' 'https://apps.apple.com/us/iphone/today' On iOS 26, you can open https://apps.apple.com in Safari, and you can navigate to individual app pages via links within the site or via the search field. However, you can’t open an App Store app page such as https://apps.apple.com
curl -v -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.1 Mobile/15E148 Safari/604.1' 'https://apps.apple.com/us/app/stopthemadness-pro/id6471380298' Notice that the only difference between Safari 26 and Safari 18 is the Version/ number; otherwise, WebKit has intentionally frozen the User-Agent HTTP header.
The above URL request returns an HTTP 301 redirect response with this Location header value:
itms-appss://apps.apple.com/us/app/stopthemadness-pro/id6471380298 The URL scheme is not https for the web but rather itms-appss for the App Store, which is why Safari sends the URL to the App Store app!
Compare with macOS Safari:
curl -v -A 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.1 Safari/605.1.15' 'https://apps.apple.com/us/app/stopthemadness-pro/id6471380298' This URL request returns an HTTP 200 OK response with the web page of the app. In other words, the apps.apple.com website treats iOS and macOS Safari differently.
You may ask, if an App Store app URL redirects to itms-appss on iOS, why can you navigate to app pages on the apps.apple.com website? The answer is that the apps.apple.com website hijacks your link clicks! You can see this clearly if you enable the option “Protect all links” in my Safari extension StopTheMadness Pro, whose App Store URL I’m using as an example in this blog post. When this option is enabled, clicking app page links on apps.apple.com does try to open the App Store app on iOS, because the website is no longer hijacking your clicks. Another way of viewing the same phenomenon is to disable “Protect all links” but enable the “Protect history” option in StopTheMadness Pro. You can now navigate to individual app pages on the website, but the URL in the address bar never changes from the original https://apps.apple.com/us/iphone/today, which means that the navigation is “faked” by the website. (This is common practice, which you can also see on YouTube, for example.)
The obvious workaround for itms-appss redirects with external links on iOS would be to enable Request Desktop Website for apps.apple.com in Safari Settings. Request Desktop Website uses the macOS Safari User-Agent rather than the iOS Safari User-Agent. Does this workaround actually work? Well, yes and no.
If you paste https://apps.apple.com into the Safari address bar with Request Desktop Website enabled on apps.apple.com, the web page will load. However, if you click an external link such as https://apps.apple.com
In a private window, with Request Desktop Website enabled on apps.apple.com, you can click an external link to an App Store app URL, then press Cancel in the permission dialog, and the apps.apple.com page will load in Safari. In a non-private window, on the other hand, you have to avoid clicking the link directly. One option is to press down on the link to show the contextual menu and select the Open command from the menu.
This action is equivalent to pasting the URL into the address bar, so it will load the web page in Safari instead of opening the App Store app, as long as Request Desktop Website is enabled.
On macOS, my app Stop The Mac App Store nullifies App Store Universal Links in Safari by presenting a fake App Store app with no support for Universal Links. Unfortunately, such an app is not possible on iOS. This is for your own protection, you know.