Hi, it's very urgency! https://developer.apple.com/forums/thread/818346 After long time preparation, We finally execute this transfer operation today. Works fine at preliminary stage, lots of users had been transferred successfully. However, about 25% users transferred failed at the end, 'invalid_request' response from https://appleid.apple.com/auth/usermigrationinfo. No matter how many times we retry, it does work. Please help! 700,000 users are waiting us!

Hello, We are currently unable to access our Apple account. We previously initiated an account recovery request. According to the notification we received, the recovery process was scheduled to be completed on April 26, 2026, and we were informed that we would receive a phone call or SMS to proceed. However, we did not receive any call, SMS, or email communication. Details from the recovery notification: Recovery request date: April 16, 2026 Expected contact date: April 26, 2026 As of now: We still do not have access to the account No follow-up communication was received The recovery process appears to be stalled We would like to understand: What is the current status of the account recovery request? Why no contact was made on the scheduled date? What steps we should take next to regain access to the account? This account is critical for our Apple Developer operations, so we would appreciate your assistance. We can provide any additional verification information if required. Thank you.

Hello, We are reaching out as a company providing Wi-Fi connectivity services through captive portals to report a potential issue identified after upgrading to iOS 26. Since the release of this version, we have received multiple reports from customers who are unable to complete the authentication process on captive portal networks. The observed behavior is as follows: The device correctly detects the Wi-Fi network. The connection is established at the link level, but after entering access credentials and proceeding to the next login step, an “error opening page” message is consistently displayed. When the user taps “OK,” the captive portal mini-browser closes. As a result, the user is unable to authenticate or gain internet access. We have verified that: Our network infrastructure and captive portals function correctly on other operating systems (Android, Windows, and previous iOS versions). No recent changes have been made to our platforms that could explain this behavior. The issue appears to be consistently reproducible on devices running iOS 26. Additionally, we have identified similar reports from users in public communities like reddit, suggesting this is not an isolated case. https://www.reddit.com/r/ios/comments/1no4vzt/switched_to_ios_26_and_now_i_cant_connect_to/ Given the direct impact on user experience and services relying on web-based authentication, we would appreciate any information on whether this behavior is being investigated or if there are any technical recommendations to mitigate the issue. Thank you for your attention.

เนื่องจากได้อ่านรายละเอียดเกี่ยวกับแล้วตรงและสิ่งที่เจอทั้งหมดหลังจากได้ทีการแจ้งไปเรื่องโดนแฮ็กข้อมูลและถูกโจรกรรมข้อมูลส่วนบุคคลทั้งหมด เจอสถานณ์ตรงตามส่วน คำเตือนเนื้อหาที่ละเอียดอ่อนทั้งหมด ตอนนี้สภาพจิตใจย้ำแย่เป็นอย่างมากและท้อใจอย่างที่สุดเพราะโดเดี่ยวสู้กับปัญหาและพยายามหาหลักฐานเพียงผู้เดียวซึ่งไม่เหลืแคนที่ไว้วางใจได้แม้แต่คนเดียว เพราะโดนใส่ร้ายทุกรูปแบบจนเสียงชื่อเสียงเหมือนกับผลักทุกคนออกไปจากชีวิตจนไม่เหลือแม้คนเดียวที่รับฟังทำให้พูดความจริงทั้งหมดไม่มีใครเชื่อและรับฟังแม้แต่คนเดียว เหตุที่แจ้งไปก่อนหน้านี้เป็นเวลาเกือบ 8 เดือนกว่าๆแล้วจนถึงปัจจุบันนี้ ยังไม่ได้รับกาคช่วยเหลือหรือไม่มีการช่วยเหลือใดๆทั้งสิ้น

When i request 'https://appleid.apple.com/auth/keys' via my browser I do get 3 keys, But requesting from several cloud providers i get only a bogus reply: { "url": "https://appleid.apple.com/auth/keys" } Why is that? I'm using a very bare bones node request: fetch('https://appleid.apple.com/auth/keys');

Hello Everyone I'm encountering a problem with the Apple Mail Private. I created a website with the possibility to log in with apple account and apple gives the possibility to privatize the mail address with xxxxx@privaterelay. appleid.com but also blocked the mail come from my server. In the log I get the error: relay=smtp3.privaterelay. appleid.com[17.56.9.14]:25, delay=2.4, delays=0.11/0/1.8/0.48, dsn=5.1.1, status=bounced (host smtp3.privaterelay. appleid.com[17.56.9.14] said: 550 5.1.1 mymail@mail. com: unauthorized sender (in reply to RCPT TO command)) How can I fix it ?

Hi everyone, I'm experiencing a persistent issue with Sign in with Apple on my iOS app that I cannot resolve from my side. I've already opened a support case (ID: 20000115382721) and received a reply directing me back to the Developer Forum, so I'm posting here in hopes someone has encountered the same issue or can offer guidance. Error message: FirebaseAuthException: [firebase_auth/invalid-credential] Invalid OAuth response from apple.com Critical observation: The Apple authentication screen never appears. When the user taps "Continue with Apple", the error is returned immediately. This suggests the request is being rejected before reaching Apple's authentication servers — pointing to a backend configuration issue on Apple's side for my Team ID. My setup: Team ID: DHKU23JL7H Bundle ID: com.expensespy.app Framework: Flutter with sign_in_with_apple package v7.0.1 Backend: Firebase Authentication Other auth methods (Google Sign-In, Email/Password): working correctly Verified configuration (all done correctly): App ID (com.expensespy.app): Sign In with Apple capability is enabled Configured as a primary App ID Not grouped with any other App ID Service ID (com.expensespy.app.auth): Created and linked to the primary App ID Domain: expensespy-e11ab.firebaseapp.com Return URL: https://expensespy-e11ab.firebaseapp.com/__/auth/handler All other redundant Service IDs have been removed Sign In with Apple Key: Created with Key ID X8T9NLBT4Y Linked to the primary App ID .p8 file is available Firebase Apple provider: Tested with OAuth code flow fields populated (Services ID, Team ID, Key ID, Private Key) — same error Tested with OAuth code flow fields empty (recommended for iOS-only) — same error Client-side implementation: Proper nonce generation with SHA256 hashing OAuthProvider('apple.com').credential() with idToken and rawNonce Tested across 3 different builds (Build 12, 13, 14) Tested on multiple iOS devices (iOS 18+) What I've ruled out: Client-side code (tested 3 different implementations) Firebase configuration (tested both populated and empty) Multiple Service IDs (cleaned up to just one) App ID configuration (verified primary status) Context: During my Apple Developer Program enrollment, I experienced an error that was not fully resolved. I suspect this may have left my account in a state where Sign in with Apple is not fully activated on the Apple backend for my Team ID. Question: Has anyone encountered this where the Apple auth screen never appears at all? Is there a way to verify that Sign in with Apple is properly provisioned for a specific Team ID on Apple's backend? My App Store submission is blocked by this since Sign in with Apple is required when offering third-party authentication. Any guidance from Apple engineers or developers who solved a similar issue would be deeply appreciated. Thanks!

Hello, We are preparing to transfer an App Store app from one Apple Developer account/team to another. Our iOS app uses Sign in with Apple. However, in our legacy implementation, we did not store the Apple user subject identifier (sub) for many existing Apple login users. Our service primarily matched users by email. After reviewing Apple’s app transfer and Sign in with Apple migration documentation, we understood that we should generate a transfer identifier for each Sign in with Apple user before transferring the app. We have now started collecting and storing the sub value, but many legacy Apple login users still do not have their original sub value stored in our database. We are concerned about two main cases: Legacy users whose original Apple sub value was never stored For these users, we may not be able to generate the required transfer identifier before the app transfer. If the user uses Private Relay, we are also concerned that the email address we receive after the transfer may not match the email address we previously stored. In that case, our backend may not be able to match the post-transfer Sign in with Apple login to the user’s existing account, and the user may be treated as a new account. Users whose sub value is stored, but who do not sign in during the migration period For some users, we do have the Apple sub value and may be able to generate the transfer identifier before the app transfer. However, we are not sure what happens if those users do not sign in during the available Sign in with Apple migration period after the app transfer. If they sign in only after that period has ended, will the post-transfer Sign in with Apple user still be reliably mapped to the original pre-transfer user? The scenario we are worried about is: A user originally signed in with Apple before the app transfer. The app is transferred to another Apple Developer account/team. The user does not sign in during the Sign in with Apple migration period. After the migration period has ended, the same user signs in with Apple again. Our backend receives a new Apple user identifier and/or a different Private Relay email address. Our backend cannot correlate that login with the user’s original service account. The user may be treated as a new user and may lose access to their existing profile, activity history, chats, purchases, or other account data. Could someone confirm the expected behavior? Questions: If we have a legacy sub value and generate the transfer identifier before the app transfer, can the user still be mapped to the original account if they do not sign in during the Sign in with Apple migration period? After the migration period has ended, does Apple provide any identifier, token claim, API response, or other mechanism that allows us to correlate the post-transfer Sign in with Apple user with the pre-transfer user? For legacy users whose original sub value was never stored, is there any Apple-provided way to recover or map those users after the app transfer? Can a Private Relay email address change as part of or after an App Store app transfer? Should we avoid using email as a stable identifier for this migration? Should we delay the app transfer until we implement our own account recovery and account re-linking flow for all Sign in with Apple users? Environment: Platform: iOS Development environment: Xcode Runtime: iOS Framework: AuthenticationServices Feature: Sign in with Apple Context: App Store Connect app transfer between Apple Developer teams/accounts This issue does not appear to be specific to a particular iOS or Xcode version. We expect the development and runtime environments to be using the latest available versions of Xcode, macOS, and iOS at the time of submission. Any guidance on the correct migration behavior and the recommended implementation approach would be greatly appreciated.