ASWebAuthenticationSession cookie

I have been implementing an sdk for authenticating a user. I have noticed that on iOS 18.5, whether using SFSafariViewController, or the sdk (built on ASWebAuthenticationSession), password autofill does not work. I have confirmed it works on a different device running iOS 18.0.1. Are there any work arounds for this at this time? Specifically for ASWebAuthenticationSession?

Problem Description: In our App, When we launch the web login part using ASWebAuthentication + Universal Links with callback scheme as https, we are not receiving callback. Note: We are using SwiftUIWebAuthentication Swift Package Manager to display page in ASWebAuth. But when we use custom url scheme instead of Universal link, app able to receive call back every time. We use .onOpenURL to receive universal link callback scheme.

Hello Apple App Review Team, We are using Privy to enable sign in with Farcaster in our app. Privy is a 3rd party authentication SDK, and it currently opens the authentication URL using the system browser. Unfortunately, this behavior is handled internally by Privy and we do not have access or control to override it in order to present the sign-in flow in-app using SFSafariViewController. We understand the importance of maintaining a seamless and secure user experience, and we fully support the use of SFSafariViewController or ASWebAuthenticationSession. However, since Privy does not expose an option to change this behavior at the moment, we are limited by their current implementation. We have reached out to the Privy team requesting a change or improvement that would allow us to use SFSafariViewController instead of the external browser. In the meantime, we would appreciate your guidance on how to proceed, or whether an exception could be granted due to this 3rd party SDK limitation. Thank you for y

I reported this as a bug (FB18614667), but also wanted to ask here in case this is actually just me doing something wrong, or maybe I'm misunderstanding the entire use case of metadataRead. (My understanding is that metadataRead is basically read but it checks a cache that the kernel manages before trying to read the physical resource, and in the case of a cache miss it would just go to the physical resource and then add the bytes to the cache. Is that right?) I’m encountering an issue in an FSKit file system extension where (for example) read(into: buf, startingAt: 0, length: Int(physicalBlockSize)) works, but metadataRead(into: buf, startingAt: 0, length: Int(physicalBlockSize)) throws an EIO error (Input/output error) no matter what I do. (Note: physicalBlockSize is 512 in this example.) The documentation (https://developer.apple.com/documentation/fskit/fsblockdeviceresource/metadataread(into:startingat:length:)) indicates that the restrictions on metadataRead are that the operations must be sector-address

I had a two CS from customers that they couldn't buy a cookies(IAP). they got an alert Purchases in this app are already purchased items. I was wondering if anyone has any similar experiences.

When presenting a cookie banner for GDPR purposes, should ATT precede the cookie banner? It seems that showing a Cookie Banner and then showing the ATT permission prompt afterwards (if a user elects to allow cookies/tracking) would be more appropriate. Related question: Should the “Allow Tracking” toggle for an app in system settings serve as a master switch for any granular tracking that might be managed by a 3rd party Consent Management Platform? If ATT is intended to serve as a master switch for tracking consent, if the ATT prompt is presented before a cookie banner, should the banner even appear if a user declines tracking consent? I’m not finding any good resources that describe this flow in detail and I’m seeing implementations all over the place on this. Help! Thanks!!!

Hi Apple team and community, We’re currently integrating with the Apps and Books for Organizations API as part of our device management solution and would like to highlight a few critical points we've encountered — including a reliability issue, an enhancement suggestion, and a request for clarification on API rate limits. 1. Issue: Intermittent 403 Errors with stoken-authenticated-apps Endpoint We are encountering intermittent 403 Forbidden responses from the stoken-authenticated-apps endpoint. Approximately 30–35% of the requests fail with a 403 status code. These failures are inconsistent — the same request (using the same Content Token and Storefront) may succeed upon retry. All requests are properly authenticated and include the required Cookie and other headers as specified in the API documentation. This issue is impacting our ability to reliably fetch app metadata at scale, particularly in workflows. We’d like to know: Is this a known issue? Could it be due to a rate limit or token misconfigur

Hi everyone, I’m sharing this because I’ve been stuck with this issue for over two weeks, and I still haven’t found a solution — or received a meaningful response from Apple Support. A yellow banner has appeared on my account saying: “The Apple Developer Program License Agreement has been updated and needs to be reviewed.” But here’s the problem: I’ve already accepted the latest agreement long ago. When I log into both: App Store Connect Developer Portal …there’s no new agreement to accept, no prompt, no button — absolutely nothing new. The yellow banner simply refuses to go away, and it's preventing updates. I’ve already: Cleared cache & cookies Tried Safari, Chrome, Firefox Logged in from different devices/networks Verified that I am the Account Holder Reported the issue via Apple Developer Support (more than a week ago) Despite clearly stating the urgency of the matter, I’ve received no fix and no timeline. This is beginning to feel like developers’ time — especially for those who depend on ti

Summary: I'm developing an iOS audio app in Flutter that requires background audio playback for long-form content. Despite having a paid Apple Developer Program account, the Background Modes capability does not appear as an option when creating or editing App IDs in the Developer Portal, preventing me from enabling the required com.apple.developer.background-modes entitlement. Technical Details: In the app that I am developing, users expect uninterrupted playback when app is backgrounded or device is locked similar to Audible, Spotify, or other audio apps that continue playing in background The Problem: When building for device testing or App Store submission, Xcode shows: Provisioning profile iOS Team Provisioning Profile: com.xxxxx-vxxx doesn't include the com.apple.developer.background-modes entitlement. However, the Background Modes capability is completely missing from the Developer Portal when creating or editing any App ID. I cannot enable it because the option simply doesn't exist in the capabilities

Hello, I'm currently unable to access App Store Connect. When I try to open https://appstoreconnect.apple.com, I receive the following error message: “appstoreconnect.apple.com is currently unable to handle this request.” I’ve tried the following steps, but the issue persists: Cleared browser cache and cookies Tried different browsers (Safari, Chrome) Attempted from multiple devices and networks Is this a known issue or is there any workaround available? Would appreciate any help or update on the current status. Thank you,

When CHIPS was introduced in 18.4 it worked well, however on 18.5 it does not appear to work. There do not appear to be release notes about this in 18.5, so can someone provide definitive if this is a defect that will be fixed, or have they already been deprecated?

Hello, We are developing a Safari Web Extension that uses a cookie-based authentication mechanism. The extension makes a request to an endpoint e.g. /login, and this endpoint expects a cookie (e.g., sessionId) to be included with the request. Everything works correctly when running in the default Safari profile. However, when I install and run the same extension in a new, non-default profile, the behaviour changes: The request to /login is still made The cookie sent is not as expected As a result, the response returns null user data I confirmed that logging into the site in the new profile (in a tab) works, but the extension does not appear to share the session/cookie state with the login tab We’ve tried explicitly setting credentials: include in the request but that still didn’t share the cookie in the extension context in the non-default profile. My questions: Is there away to allow cookie-based session sharing between a tab and an extension in non-defau

I use WKWebView to display a webpage that requires authentication through an authentication provider. This works as expected, but when I close and reopen the app, I have to reauthenticate. However, if I open the same page in Safari, I only have to authenticate once. If I close Safari and reopen it, the page displays without prompting me to authenticate again. I see some cookies stored in httpCookieStore, so I assume that storing cookies works. Does anyone have an idea why authentication is not persistent between app launches? Thanks in advance. Best regards, Marc

Hello, I have encountered an issue with an iPhone 15PM with iOS 18.5. The NSHTTPCookieStorage failed to clear cookies, after clearing them, I was still able to retrieve them. However, on the same system NSHTTPCookie *cookie; NSHTTPCookieStorage *storage = [NSHTTPCookieStorage sharedHTTPCookieStorage]; for (cookie in [storage cookies]) { [storage deleteCookie:cookie]; } NSArray *cookies = [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookiesForURL:[[self url] absoluteURL]]; // still able to get cookies,why???