I don't think so. It only applies to network connections you make directly through that framework - WKWebView operates independently with its own networking stack.

This smells like a Safari-side change/regression in the capability probe, not in the payment sheet itself. Treat applePayCapabilities() as advisory only for now. Implement a graceful fallback: always show the button when Apple Pay is supported, then try to launch a session. Use canMakePayments() (and optionally canMakePaymentsWithActiveCard) only to influence prominence, not eligibility. This is consistent with Apple’s guidance and long-standing WebKit advice. File a bug with reproducibles via Feedback Assistant. Assume this is a Safari capability-probe issue (and possibly anti-fingerprinting collateral) rather than your integration. Don’t block Apple Pay on the probe; keep the button visible and let the session tell you the truth. This both fixes your users today and aligns you with Apple/WebKit’s recommended UX.

You will need a Developer account. Then, you can do: Ad Hoc Distribution (provide you iPhone UDIDs, Distribute via AirDrop, email) TestFlight both will last for 1year.

Some of the information was previously available but then got stripped out a couple years back by new iOS versions.

that's what ETag is used for. Might be a bit fragile depending on how requests and responses are structured but no reason why ETag shouldn't work. Obviously implementing your own solution provides more flexibility.

The notificationType from Apple you are looking for is "REFUND". Expired will only be true after the time frame of theninapp/subscription. In your example REFUND is notified immediately (after the 3 months), EXPIRED occurs after the full term (1y).

I'll set aside if it will be approved for the public but you could use script injection. function injectScript() { const script = document.createElement('script'); script.textContent = ` // Store the original fetch const originalFetch = window.fetch; // Decorate fetch with your custom logic window.fetch = function(...args) { // Your custom logic here console.log('Fetch intercepted:', args[0]); // Example: Add custom headers if (args[1] && args[1].headers) { args[1].headers = { ...args[1].headers, 'X-Custom-Header': 'MyValue' }; } // Call original fetch with modified arguments return originalFetch.apply(this, args); }; `; // Inject script into webpage (document.head || document.documentElement).appendChild(script); // Clean up - remove the script tag after injection script.remove(); } // Execute the injection when content script loads injectScript();

Apple Review Team doe indeed usually use iPads. If you're unable to recreate, I'd add logging to know where/when the issue happens.

The url for your app is based on AppID and should never change, assuming it's the same app. Make sure you're not including the app name (which is editable) in the URL.

Check the logs when testing with public link.

This will most likely be rejected.

Submitted an app update on the 24th and it was live within 24h.

You either reply to the objection (if you think you're right) or submit a new build (if they're right).

If outside China, this is not a requirement.

use methods intended for your specific need (ie fileExistsAtPath to check if file exists)