Overview

Post

Replies

Boosts

Views

Activity

App Review on hold — attachment returns 404 in App Store Connect console
My app has been in review hold since August 13 (!) after responding to an Additional Information request (Submission ID: 9a1d82d0-0763-413e-a422-b8be5f8f0292). It has now been 15 days with no update. I noticed that when I attempt to access the video attachment I submitted via App Store Connect, the console returns: API Response Error: GET_SALABLE_AVAILABILITIES_RESPONSE — status code: 404 I'm concerned the attachment may not have been delivered correctly. I've been unable to send a follow-up in the Resolution Center as the thread appears closed after my response. Has anyone experienced this? Is there a way to re-submit the attachment or get confirmation it was received?
0
0
46
13h
Guideline 3.1.3(b) — showing a web-only B2B tier on iOS pricing page
We have a multiplatform SaaS app (iOS, Desktop). Individual plans are sold via IAP on iOS. We also offer a B2B multi-seat plan that's only sold through our website (per-seat billing, admin provisioning, etc.). On our iOS pricing page, we want to show all plans — including the B2B one — so users can see the full picture. The B2B plan would just show features and a starting price with a label like "Managed through our desktop platform." No purchase button, no link, no redirect. Only the individual plans would have IAP subscribe buttons. Three questions: Does showing pricing/features for a plan that can't be purchased in-app count as "steering" under 3.1.3? Is a static label like "Managed through our desktop platform" considered a call to action if there's no link or button? Would a "Contact Sales" form (just collects an email, follow-up happens outside the app) be a safer approach? We did check with Apple Developer Support (Aug 2026) and were told this should be fine, but want to hear from anyone who's shipped something similar before we submit. Thanks.
0
0
16
13h
First-time subscription submission stuck — "add an app version" error even with a fresh, unreleased build attached
I'm trying to submit my app's first-ever subscriptions for review, and I'm stuck in a loop between two different App Store Connect submission flows that seem to conflict with each other. Setup: App: HeyFlat (bundle au.com.heyflat) Subscription group "HeyFlat Casa" with 3 auto-renewable subscriptions (monthly/semiannual/annual), all status "Ready to Submit" App version 1.0 has been rejected multiple times (most recently for Guideline 2.1(b) — "In-App Purchase products have not been submitted for review") What I've tried: On the Subscriptions page, I click "Add for Review" on the subscription group → it opens a "Draft Submission" panel (breadcrumb "Submissions") listing the group as an item ready to submit. That panel shows: "Unable to submit for review — Add an app version for the selected platform." I uploaded a brand-new, never-before-submitted build (build 31, version 1.0) via CI and manually attached it to the App Store version page (Distribution → App Store Version 1.0 → Build). Went back to the Draft Submission — same error persists, plus a new one: "New subscription groups must be submitted with an auto-renewing subscription from that group." The item listed is just the subscription group itself, not the individual subscriptions. Separately, the legacy per-version thread (App Review → iOS Submission) now shows build 31 as "Ready for Review" — but that thread only lists 1 item (the app version itself), no subscriptions attached, even though they're marked "Added for Review." So I have: a subscription group with 3 ready subscriptions, and a fresh unreleased build attached to the app version — but no path in the UI actually lets me submit them together. This exact same "In-App Purchases not submitted" rejection has now happened twice, with the subscriptions in this same "ready" state both times. Has anyone run into this specific mismatch between the "Submissions" draft flow and the legacy per-version "App Review" thread? What's the correct way to get a first-time subscription group submitted alongside an app version right now?
5
0
608
13h
SwiftUI TextField autofocus retains environment-injected objects after fullScreenCover dismissal with both ObservableObject and Observation
I am seeing a SwiftUI environment object remain alive after the view hierarchy that owns it has been dismissed. The retained object is owned by @StateObject inside a fullScreenCover. A TextField presented deeper in that hierarchy receives focus through @FocusState. After navigating back and dismissing the cover, the @StateObject does not deinitialize. The memory graph shows that system keyboard/input-assistant views retain a UITraitCollection, which retains a SwiftUIEnvironmentWrapper containing the environment object. Environment macOS 26.6.1 (25G76) Xcode 26.6 (17F113) iOS 26.5 Simulator iPhone 11 26.6 Minimal reproduction import Combine import SwiftUI final class DemoCoordinator: ObservableObject { let id = UUID() init() { print("[+] DemoCoordinator INIT \(id)") } deinit { print("[-] DemoCoordinator DEINIT \(id)") } } @main struct FocusStateLeakApp: App { var body: some Scene { WindowGroup { RootView() } } } struct RootView: View { @State private var isFlowPresented = false var body: some View { Button("Present flow") { isFlowPresented = true } .fullScreenCover(isPresented: $isFlowPresented) { FlowContainer() } } } struct FlowContainer: View { @Environment(\.dismiss) private var dismiss @StateObject private var coordinator = DemoCoordinator() var body: some View { NavigationStack { NavigationLink("Push field screen") { FieldScreen() } .navigationTitle("Flow") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Close") { dismiss() } } } } .environmentObject(coordinator) } } struct FieldScreen: View { @State private var text = "" @FocusState private var isFocused: Bool var body: some View { TextField("Type something", text: $text) .textFieldStyle(.roundedBorder) .focused($isFocused) .padding() .navigationTitle("Field") .onAppear { isFocused = true } .onDisappear { isFocused = false } } } Steps to reproduce Launch the application. Tap “Present flow”. Tap “Push field screen”. The TextField automatically becomes focused and the software keyboard appears. Navigate back. Tap “Close” to dismiss the full-screen cover. Observe the console or capture a memory graph. Expected result: After the full-screen cover is dismissed, FlowContainer and its @StateObject storage should be released. The following message should be printed: [-] DemoCoordinator DEINIT ... Actual result: DemoCoordinator remains alive and its deinit is not called. The captured memory graph contains one DemoCoordinator. The same behavior occurs after migrating the reproducer to the Observation framework. Questions Is retaining the SwiftUI environment through keyboard-owned cached trait collections expected? Is there a supported way to prevent dismissed SwiftUI environments from being retained by the input-assistant hierarchy? Is this a known UIKit/SwiftUI issue for which a Feedback ID already exists? Should this be reported as a SwiftUI issue, UIKit issue, or Text Input issue in Feedback Assistant? I can provide the minimal Xcode project and the captured .memgraph file if needed.
Topic: UI Frameworks SubTopic: SwiftUI
0
0
26
13h
2 months pending enrollment
Hello, My organization enrollment in the Apple Developer Program has remained in "Your enrollment is being processed" since 3 July 2026 — eight weeks. Apple's published processing time for organization enrollments is two to four weeks, so this is well outside the expected timeframe, and I have received no communication explaining the delay. Enrollment ID: 92WKJ94M6U Could you please: Confirm which stage the enrollment is currently held at — D-U-N-S verification, legal entity verification, or signing authority review. Tell me exactly what is required from me to move it forward. I can provide any supporting documentation immediately, including our Chamber of Commerce registration certificate (visura camerale), VAT registration, and written proof of my signing authority for the company. Provide a case number for this request and an expected resolution date. This delay is blocking a project with a committed delivery date, so I would appreciate any expediting you are able to apply. Thank you, Mario Baldantoni
0
0
17
13h
NEURL Filter configuration approved under wrong Developer Team — resubmission blocked by duplicate domain
Hi, My NEURL Filter configuration (ID 9f3cbff8-63de-4c69-bf68-c19cd1c5d842) was approved on August 5, 2026, but it turned out to be attached to the wrong Apple Developer Team — an old individual account (S5VDH23BBZ) I no longer have access to, instead of my actual organization team, KRKJ76BC7W (SCOTTO), which owns and signs the app (bundle ID com.dropbet.DropBet). I contacted Developer Support, who said they couldn't transfer it and suggested replying to the original approval email — I did (on 08/08, then several times) with no response. I then tried resubmitting the same configuration under the correct team (KRKJ76BC7W), but the portal rejected it with: "A configuration with the same PIR Server Domain already exists." So a fresh submission is technically impossible while the original stays attached to the wrong account — the only real fix is transferring or re-attaching the existing approved configuration to KRKJ76BC7W. Has anyone dealt with this kind of Team ID mix-up before, or know who on the Network Extension / NEURL Filter team could help reassign an approved configuration? Happy to provide any additional details. Thanks in advance.
1
0
58
13h
Initial submission stuck "In Review" for 9 days with 3 IAPs attached
My first app submission has been in "In Review" since August 19, 2026 at 08:56 (CEST) — 9 days now, with no status change and no message of any kind. Details: Apple ID: 6799895164 Version: 1.0 (build [1]) Submission ID: 412ca140-f582-42a5-9714-e50a254e260b Platform: iOS Submitted: August 18, 2026 In Review: August 19, 2026 at 08:56 (CEST) The submission contains 1 app version and 3 in-app purchases: 2 auto-renewable subscriptions and 1 non-consumable lifetime unlock. All items show as included in the submission. Everything on my side appears complete: review screenshots for each IAP, price schedules, localizations, privacy policy URL, EULA, age rating declaration. Restore Purchases is implemented and visible on the paywall. Account status: Paid Applications Agreement: [Active] Digital Services Act trader status: [Verified] MRDP compliance: [Active] Bank and tax details: [Active] There is no rejection, no request for additional information, and nothing in Resolution Center. A support case is open as well. I have seen several recent threads describing the same pattern — in some cases requiring someone at Apple to move the IAP status forward on the backend. Could someone from App Review please check whether this submission is progressing normally, or whether something on my side is blocking it? Happy to provide any further details. Thanks in advance.
0
0
22
13h
Guideline 3.1.3(b) — showing a web-only B2B tier on iOS pricing page
We have a multiplatform SaaS app (iOS, Desktop). Individual plans are sold via IAP on iOS. We also offer a B2B multi-seat plan that's only sold through our website (per-seat billing, admin provisioning, etc.). On our iOS pricing page, we want to show all plans — including the B2B one — so users can see the full picture. The B2B plan would just show features and a starting price with a label like "Managed through our desktop platform." No purchase button, no link, no redirect. Only the individual plans would have IAP subscribe buttons. Three questions: Does showing pricing/features for a plan that can't be purchased in-app count as "steering" under 3.1.3? Is a static label like "Managed through our desktop platform" considered a call to action if there's no link or button? Would a "Contact Sales" form (just collects an email, follow-up happens outside the app) be a safer approach? We did check with Apple Developer Support (Aug 2026) and were told this should be fine, but want to hear from anyone who's shipped something similar before we submit. Thanks.
0
0
7
13h
App stuck in "Waiting for Review" for 14 days — Apple ID 6768742372
Dear App Review Team, Our app No.IA (Apple ID: 6768742372) has been in "Waiting for Review" since July 20, 2026. This is version 3.1, resubmitted after the App Review Board cleared Guidelines 2.3.1 and 3.2.1 (Appeal Ticket APL509468). All Guideline 1.1 concerns have been addressed: metadata rewritten, in-app labels updated, screenshots replaced. We have tried: Resolution Center reply, expedited review request, phone call to Developer Support (Case 102912803305). All responses have been generic with no timeline. This app has been in review processes since May 19, 2026 — over 75 days. Any assistance would be greatly appreciated.
4
1
455
13h
Something is wrong with App Review and support.
My app is a retro game emulator. It was approved, ran on the App Store through several updates, and then got rejected as design spam. Why? Good question. Resolution Center answers with a template listing every possible cause: maybe the metadata, maybe an embedded binary, maybe I bought an app template, maybe the concept already exists on the App Store. Pick whichever one you like best. When I got that list, I assumed I needed to defend the concept. I recorded ten minutes of video showing myself using the app by hand, added test materials, descriptions, and a letter explaining everything. I got the same list back. Later I thought the cause might be the PSP emulation core — I was using an existing one, because my own wasn't finished yet. I rebuilt, resubmitted, explained. Waited two weeks, requested an expedited review. No email, no confirmation, no denial. Nothing. A week after that, I received a message from review saying the app appears to hide functionality during review. It does not. There are no feature flags, nothing of the kind. There are no dark patterns in the monetization either — no close buttons you can't hit, no trial tricks, nothing of that sort. What exactly they believed was hidden — guess for yourself. Resubmitted again. Design spam again, with the same list of possible causes. But you can't keep guessing forever. So I wrote to support — there is a dedicated form for requesting the specific reason for a rejection. I have been waiting for weeks. No confirmation that my request was received, no denial, no explanation. Nothing. I filed a separate appeal. Again: no confirmation, no denial, nothing at all. Weeks of silence. Meanwhile the app is still live on the App Store, getting thousands of downloads, people are paying for it, and it has bugs I cannot fix because I cannot ship an update. Users hit those bugs, leave bad reviews and low ratings over them, and the rating keeps dropping. I also want to talk about the "concept" item in the design spam list. Where is the line between an app that copies an existing feature on the App Store, and one that improves on what exists? Are there emulators on the App Store? Of course. Are they good? Not really. In my most recent testing, my own core reduced CPU/GPU load by up to 40% compared to emulators still running third-party code. I won't even get into UI quality, because the user reviews speak for themselves. People point out bugs and still leave five stars because of the UX. Does that mean I copied something, or that I improved on it? And on top of that, I didn't copy anything — the emulation core is my own. I know App Review has a huge amount of work right now. But why should that affect support this badly? As a paying member of this program for years, this looks like a completely broken process with no transparency at all. People on these forums say that after a design spam rejection your app goes into some different review queue. But even if that's true — why is that my problem? I have no alert about it, no notification of any kind, and no reason to be ignored for months. Let's be honest. Design spam is bad, no question. But it is a rejection like any other. You tell me what's wrong, I fix it, you re-check. Please don't turn "design spam" into a mark that makes developers want to give up and stop trying entirely. App ID: 6790321094 Submission ID: 883d7004-33a3-4fd7-b229-756a15b51cb9
0
1
29
13h
CloudKit private database: all writes fail with HTTP 500 (empty body), CKErrorDomain 15 / CKInternalErrorDomain 2001, account-scoped, reads unaffected. Began immediately after Apple Account legal name change
Since approximately 03:11 UTC on 2026-08-28, every CloudKit private-database write from my iCloud account fails. The app had been syncing normally for weeks before this moment. Failure signature: Every record save returns HTTP 500 with an empty response body (Server: AppleHttpServer, via icloud-xrail). Client-side error: CKErrorDomain 15 (Server Rejected Request) with underlying CKInternalErrorDomain: 2001. Reads succeed. CKContainer.accountStatus reports available. Authentication is fine. Only writes fail. Reproduces identically via NSPersistentCloudKitContainer mirroring and via a raw CKModifyRecordsOperation probe. Device: iPhone 15 Pro Max, iOS 17.2.1. Development environment, private database. Evidence this is account-scoped server state, not app configuration: It reproduces identically in two containers: the original production container and a freshly created container set up after the failures began. A brand-new container failing the same way rules out container-specific corruption or schema issues. Entitlements, embedded provisioning profile, and App ID iCloud capability have all been verified correct (codesign inspection and App Store Connect API). No code or configuration change coincided with the onset. The failure follows my Apple ID across probes over many hours. Every write 500s, without exception. Correlating event: the legal name on my Apple Account was changed at account.apple.com the same morning, shortly before the failures began. I cannot prove causation, but the timing is exact, and the account-scoped, writes-only signature is consistent with a wedge in the account's server-side state (PCS / user-record layer) introduced by the identity change. I request a check of this account's CloudKit/PCS state. Sample failing request UUIDs (x-apple-request-uuid) for locating these in server logs: 244DA811-E4AA-4771-88F0-7C092EFD8DEF, 2026-08-28 ~09:57 UTC 1FD544D6-6ED2-4181-8976-B4F4C35830D9 E55EFF8F-FC32-48BD-9165-F4EA263F130A Many more available on request. The app logs every attempt. Related reports: this appears closely related to thread 843819 (same week, same signature: private-db writes CKError 15 / HTTP 500, fresh container also affected, Console works), and possibly to the recent cluster of private-database reports in threads 838743, 840248, and 839650. Please correlate rather than triage in isolation. Impact: this blocks shipping a family-sharing feature built on CKShare, the purchase-deciding feature of the app. All development on sync is stopped. I can supply on request: a CloudKit sysdiagnose captured during a failing save (per TN3163), additional request UUIDs with timestamps, and the exact local timeline of the account name change.
0
0
19
13h
CloudKit Private Database requests fail with CKError 15 / HTTP 500, while Console works
Hi, I’m running into a strange CloudKit issue and I’m trying to figure out whether this could be related to the China mainland iCloud environment, or whether I’m missing something on the client side. I’m testing on macOS with Xcode 26.6, using the CloudKit Development environment and the Private Database. The Apple Account signed in on the Mac is a China mainland account, and CKAccountStatus reports available. The original container is: iCloud.com.hu.sujian With that container: I can create a custom zone in CloudKit Console. The app can save a normal CKRecord to the Private Database default zone. But the app consistently fails when creating a custom CKRecordZone. The error is: CKErrorDomain Code=15 (serverRejectedRequest) Underlying CKInternalErrorDomain Code=2000 I also opened DTS case 21678909 and filed FB24394907. As part of the DTS investigation, I created a completely new CloudKit container: iCloud.com.hu.sujian.dtstest21678909 I then repeated the same tests using the same Apple Account and the same minimal test app. On the new container, both of these app-side operations fail: Saving a CKRecord to the Private Database default zone CKErrorDomain Code=15 (serverRejectedRequest) CKInternalErrorDomain Code=2000 HTTP status: 500 Request UUID: D4B4DC7A-4167-4987-8BB1-4C61E658EDB6 Creating a custom CKRecordZone named SujianLibrary CKErrorDomain Code=15 (serverRejectedRequest) CKInternalErrorDomain Code=2000 HTTP status: 500 Request UUID: 00B4A294-9C63-4DBC-9133-03D969536B73 However, if I open CloudKit Console for that same new container, I can create a custom Private Database zone successfully. I created: DTSConsoleTest21678909 and it shows up normally as: REGULAR_CUSTOM_ZONE The code is very small. The relevant paths are essentially: let container = CKContainer(identifier: containerIdentifier) let database = container.privateCloudDatabase let record = CKRecord(recordType: "DTSWriteTest") record["message"] = "test" as CKRecordValue try await database.save(record) and: let zone = CKRecordZone(zoneName: "SujianLibrary") try await database.save(zone) What confuses me is that CloudKit Console works, while the app receives an HTTP 500 from the CloudKit service. The behavior also changed slightly between the two containers: Original container: default-zone record write from app: works custom-zone creation from app: fails custom-zone creation in Console: works New container: default-zone record write from app: fails custom-zone creation from app: fails custom-zone creation in Console: works FB24394907 contains the full reproduction details and logs. Has anyone seen something similar, especially with a China mainland iCloud account? I also have a small standalone reproduction project if that would be useful. Thanks.
1
0
222
13h
SwiftUI iOS 26: Root ScrollView jumps during interactive pop when the Tab Bar is hidden
I encountered a SwiftUI navigation issue on iOS 26.3.1 with this structure: TabView NavigationStack(path:) custom root ScrollView The navigation stack hides the system Tab Bar while a destination is presented. When the root ScrollView is near its bottom, an interactive pop briefly exposes the root list at a lower vertical position, then snaps it back when the transition completes. Measured geometry on an iPhone 17 Pro Max simulator: Before navigation: offset 754.67, container height 733, bottom inset 107 During pop: offset 705.67, container height 782, bottom inset 58 After pop: offset 754.67, container height 733, bottom inset 107 The effective Tab Bar occupancy on this device was 49 points. During the transition, the container became 49 points taller and its bottom inset became 49 points smaller, causing SwiftUI to clamp the content offset near the bottom. The following approaches did not prevent the visible intermediate state: Adding more bottom spacing Disabling scroll content offset adjustment in the navigation path transaction Saving and restoring ScrollPosition after the pop .defaultScrollAnchor(.top, for: .sizeChanges) Moving Tab Bar visibility ownership to each destination view; this also produced a noticeable delay before the Tab Bar returned The workaround that has been reliable is: Keep Tab Bar visibility synchronized with whether the tab-owned NavigationStack path is empty. This preserves the normal system animation timing. Measure the Tab Bar's effective occupancy from public geometry: root ScrollView bottom inset window bottom safe-area inset the app's normal trailing scroll margin While navigation depth is greater than zero, preserve that measured amount with a clear safeAreaInset on the root ScrollView. When onScrollGeometryChange reports that the root page's system bottom inset has returned, release the reserved inset in a transaction with animations disabled. With this approach, the offset remained 754.67 throughout push and pop. The Tab Bar also returned at its original system-controlled time. The implementation uses public APIs only. It does not hard-code 49 points, traverse the UITabBar view hierarchy, poll system UI state, or restore an offset after the transition. Has anyone found an Apple-recommended alternative, or observed the same behavior on other iOS 26 versions?
0
0
17
13h
App Store US Search Indexing Bug: Unique name, global availability enabled, but searchable everywhere except the US App Store (Anyone else?)
Hi everyone, I’m sharing this to see if anyone else has experienced this specific geographic search suppression issue on a newly released app. The Situation: App Name: CrushPov Status: Released a few days ago, "Ready for Sale", global availability including the US is fully enabled. The Core Issue: My primary target market is the US. While the app appears in search results in other regions, searching the exact, unique app name ("CrushPov") in the US App Store yields zero results. It doesn't appear anywhere, even at the very bottom. What works: Direct App Store URLs and iTunes Search API work fine. Users can download it via direct links, but organic US search discovery is completely dead. Apple Search Ads (ASA): Apple Search Ads campaign creation flow cannot find the app in the US storefront either—neither by name search nor by pasting the canonical App Store URL. What I've Checked: Metadata, pricing, and US availability settings are fully configured in App Store Connect. There are no competing apps with this exact name. This is clearly an isolated indexing issue on the US App Store servers. If you've experienced this US-specific ghost-suppression state on a newly released app: Did it eventually resolve itself after a certain period (weeks) without intervention? Has anyone successfully gotten Apple Support to manually re-index a region-specific search drop? Any insights or shared experiences would be greatly appreciated. It's tough to kick off US-focused influencer marketing when the local App Store search completely fails to acknowledge the app exists.
0
0
15
13h
UNEXPLAINABLE 3 MONTHS TAKING TECHNICAL ISSUE DEV ACCOUNT
Dear Apple Developer Support / Apple Developer Program Team, I am writing to formally escalate an unresolved issue with my Apple Developer Program application. I initially applied for the Apple Developer Program at the beginning of June 2026. My application was subsequently accepted, and I received communication indicating that I should be able to proceed with the remaining steps to activate my Developer Program membership. However, the process has been technically blocked from the beginning. When I follow the link provided by Apple, I am unable to proceed with signing the agreement and completing the required payment. Instead, I remain stuck on the same screen: “Thank you for your submission. We’ll get back to you soon.” I have contacted Apple Support and Developer Support repeatedly about this issue. On several occasions, I have spent approximately 1–1.5 hours waiting to reach a representative. Unfortunately, most of the representatives I have spoken with have been unable to identify or resolve the underlying issue. I have repeatedly been advised to be patient and have been told that the matter appears to be related to an internal Operations department. I fully appreciate that technical issues can occur and that some cases require investigation by another department. However, this matter has now remained unresolved for approximately three months. At one point, after waiting for a significant period without a resolution, I requested that my application be withdrawn so that I could submit a new application and potentially avoid the technical issue. Even getting this request understood and processed took approximately 1.5–2 weeks. I subsequently submitted a new application and, again, the application was accepted. Unfortunately, I am now experiencing essentially the same technical problem and remain unable to complete the enrollment process. This has become extremely concerning because we are not dealing with a normal application delay. We appear to be dealing with a technical or operational issue that prevents an accepted applicant from completing the final enrollment steps, while standard support channels have been unable to resolve or meaningfully explain the situation. I have retained documentation of the entire process, including application confirmations, acceptance communications, screenshots, correspondence and support interactions, and I am able to provide these upon request. Our company is a legitimate new business and our development activities and applications are directly connected to our company website, business email infrastructure and development plans. We have also involved experienced developers who have previously worked with Apple Developer accounts at established international companies, and this situation is highly unusual compared with their previous experience. I want to emphasize that I have been patient and cooperative throughout this process. I have provided the requested information, contacted the appropriate support channels multiple times, followed the instructions given to me, and even restarted the application process when advised. During the phone calls I selected that everything can be recorded so apple should have those conversations. However, after approximately three months, I believe it is reasonable to request that this matter receive attention at a level capable of actually resolving it. I am not looking for preferential treatment. I am simply asking Apple to investigate why an application that has already been accepted cannot proceed through the enrollment process, and to provide a clear explanation and resolution. Please treat this as a formal complaint and escalation request and provide me with a reference/case number for this complaint. I am prepared to provide all supporting documentation immediately. I sincerely hope this matter can now be escalated to someone who has the authority and technical access necessary to investigate and resolve it ASAP. Kind regards,
0
0
36
13h
MKDirections returns "Directions Not Available" when A and B are outside mainland China (e.g. Tokyo–Osaka)
I use MapKit and MKDirections for driving directions. The error "Directions Not Available" appears when the two points (A and B) are outside mainland China (e.g. Tokyo → Osaka). For routes inside China (e.g. Shanghai → Beijing), the same code works. let req = MKDirections.Request() req.source = MKMapItem(placemark: MKPlacemark(coordinate: origin)) req.destination = MKMapItem(placemark: MKPlacemark(coordinate: destination)) req.transportType = .automobile MKDirections(request: req).calculate { response, error in // Tokyo–Osaka (outside China): "Directions Not Available" // Shanghai–Beijing (inside China): works } Questions: Is MKDirections intended to support only routes within the device’s region (e.g. China)? When A/B are abroad, is "Directions Not Available" expected? Is this documented? For cross-country or overseas routes (e.g. Tokyo–Osaka), what is the recommended approach—third-party routing API + drawing on MapKit? Thanks.
1
1
328
13h
TestFlight Installation Error: “The requested app is not available or doesn't exist” – Beta Contract Missing
Hello Apple Developer Community, I am experiencing a TestFlight issue with my iOS app and would appreciate any guidance. App Information: App ID: 6801854699 Bundle ID: az.idrak.liseyi App Version: 1.0.9 (14) Platform: iOS Team ID: W24294ZD96 Apple Developer Program membership: Active until December 11, 2026 Free Apps Agreement: Active Paid Apps Agreement: Active Issue: I uploaded build 1.0.9 (14) to App Store Connect using Codemagic. The build processes successfully and appears in the internal testing group. However, when an internal tester opens TestFlight and attempts to install the app, TestFlight displays: “The requested app is not available or doesn't exist.” At the same time, Codemagic reports the following API error: POST betaAppReviewSubmissions returned 422: Beta contract is missing for the app App Store Connect also previously displayed a message saying that I needed to renew my Apple Developer Program membership when attempting to create an external testing group. However, my membership is active until December 11, 2026, and all required agreements are active. Steps to reproduce: Upload build 1.0.9 (14) to App Store Connect using Codemagic. Wait for the build to finish processing. Add/select the build for TestFlight internal testing. Open TestFlight on an iPhone using an internal tester account. Attempt to install the app. TestFlight displays: “The requested app is not available or doesn't exist.” Codemagic reports: “Beta contract is missing for the app.” This issue appears to be related to a backend synchronization or Beta Contract problem. Apple Developer Support has already escalated this case to their technical team under case number 20000139248466. Has anyone experienced the same Beta Contract / TestFlight availability issue, or knows how this can be resolved? Thank you.
0
0
24
13h
Sign In with Apple - invalid_client
Hi Apple Developer Support, We are implementing Sign in with Apple for our web application hosted on example.com. In the Service ID settings, we have configured the following: Service ID (client_id): com.example.service.local Web Domain: example.com Return URL: https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple We also tested login via the following URL from our web application: https://appleid.apple.com/auth/authorize?response_mode=form_post&response_type=code&client_id=com.example.service.local&scope=name%20email&state=2f9gMY1rTe12-O7Wbnb7KWe504HQ0KWBSHTKHbg9ZEY=&redirect_uri=https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple However, we’re receiving an invalid_client error after submission. Our questions: Is it valid to use an ngrok URL like https://2db2-121-160-153-88.ngrok-free.app/... as the Return URL for development and testing? Does the Web Domain need to match the ngrok domain, or is it enough to register the production domain (e.g., example.com)? Is there any propagation delay or approval process after updating the Return URL in the Service ID? Is the client_id strictly required to match the Service ID exactly? We would greatly appreciate any insights or best practices to help us resolve this issue. Thank you in advance!
36
23
3.2k
14h
macOS 27 beta: every OS update fails — MobileSoftwareUpdate 1259 "failed to copy firmware identity" (orphaned iSCPreboot volume-group dir) — FB24342236
Every macOS update fails during preflight personalization on my MacBook Pro (Mac15,6, Apple Silicon), currently on 27.0 build 26A5378j. It's failed on every build from beta 5 (26A5406e) through beta 7. Identical failure via Software Update and via startosinstall. It fails LOCALLY, before contacting Apple (gs.apple.com and gdmf.apple.com are both reachable with valid certs). Error (install.log + unified log): reaches PREFLIGHT_PERSONALIZE (~0.15), then aborts MobileSoftwareUpdateErrorDomain Code=1259 "failed to copy firmware identity" "could not obtain device identity information through SFR installer" SUMacControllerErrorPreflightPersonalizeFailed=7723 Root cause I've traced: an orphaned volume-group boot-policy directory in /System/Volumes/iSCPreboot/. ls shows two volume-group UUID dirs — the live one (matches diskutil info /) and an orphan (3D3287DE-...) with no corresponding APFS volume group (diskutil apfs list shows only one live group). Both date to Feb 2024. The preflight can't reconcile the System Recovery boot policy in the orphaned dir. Note: NOT caused by Erase All Content and Settings (unlike the commonly reported case). The orphan predates the beta, so any pre-existing second volume-group boot-policy directory reproduces it. It was harmless for ~2 years; macOS 27's stricter preflight rejects it. Ruled out (no effect): disk space, VPN, DNS, clock, Apple Account, refreshing the beta seed entitlement, reboot, Time Machine, re-downloading the installer, and Recovery reinstall (same 1259). Filed as FB24342236 — no response across beta 5, 6, 7. Questions: Is this a known issue with a planned fix, and in which build? Any supported recovery path that does NOT require a second Mac? (Recovery reinstall fails the same way.) Or is DFU Revive/Restore the only option? Will the public 27.0 release install on this machine, or hit the same preflight?
0
0
26
14h
App Review on hold — attachment returns 404 in App Store Connect console
My app has been in review hold since August 13 (!) after responding to an Additional Information request (Submission ID: 9a1d82d0-0763-413e-a422-b8be5f8f0292). It has now been 15 days with no update. I noticed that when I attempt to access the video attachment I submitted via App Store Connect, the console returns: API Response Error: GET_SALABLE_AVAILABILITIES_RESPONSE — status code: 404 I'm concerned the attachment may not have been delivered correctly. I've been unable to send a follow-up in the Resolution Center as the thread appears closed after my response. Has anyone experienced this? Is there a way to re-submit the attachment or get confirmation it was received?
Replies
0
Boosts
0
Views
46
Activity
13h
Guideline 3.1.3(b) — showing a web-only B2B tier on iOS pricing page
We have a multiplatform SaaS app (iOS, Desktop). Individual plans are sold via IAP on iOS. We also offer a B2B multi-seat plan that's only sold through our website (per-seat billing, admin provisioning, etc.). On our iOS pricing page, we want to show all plans — including the B2B one — so users can see the full picture. The B2B plan would just show features and a starting price with a label like "Managed through our desktop platform." No purchase button, no link, no redirect. Only the individual plans would have IAP subscribe buttons. Three questions: Does showing pricing/features for a plan that can't be purchased in-app count as "steering" under 3.1.3? Is a static label like "Managed through our desktop platform" considered a call to action if there's no link or button? Would a "Contact Sales" form (just collects an email, follow-up happens outside the app) be a safer approach? We did check with Apple Developer Support (Aug 2026) and were told this should be fine, but want to hear from anyone who's shipped something similar before we submit. Thanks.
Replies
0
Boosts
0
Views
16
Activity
13h
First-time subscription submission stuck — "add an app version" error even with a fresh, unreleased build attached
I'm trying to submit my app's first-ever subscriptions for review, and I'm stuck in a loop between two different App Store Connect submission flows that seem to conflict with each other. Setup: App: HeyFlat (bundle au.com.heyflat) Subscription group "HeyFlat Casa" with 3 auto-renewable subscriptions (monthly/semiannual/annual), all status "Ready to Submit" App version 1.0 has been rejected multiple times (most recently for Guideline 2.1(b) — "In-App Purchase products have not been submitted for review") What I've tried: On the Subscriptions page, I click "Add for Review" on the subscription group → it opens a "Draft Submission" panel (breadcrumb "Submissions") listing the group as an item ready to submit. That panel shows: "Unable to submit for review — Add an app version for the selected platform." I uploaded a brand-new, never-before-submitted build (build 31, version 1.0) via CI and manually attached it to the App Store version page (Distribution → App Store Version 1.0 → Build). Went back to the Draft Submission — same error persists, plus a new one: "New subscription groups must be submitted with an auto-renewing subscription from that group." The item listed is just the subscription group itself, not the individual subscriptions. Separately, the legacy per-version thread (App Review → iOS Submission) now shows build 31 as "Ready for Review" — but that thread only lists 1 item (the app version itself), no subscriptions attached, even though they're marked "Added for Review." So I have: a subscription group with 3 ready subscriptions, and a fresh unreleased build attached to the app version — but no path in the UI actually lets me submit them together. This exact same "In-App Purchases not submitted" rejection has now happened twice, with the subscriptions in this same "ready" state both times. Has anyone run into this specific mismatch between the "Submissions" draft flow and the legacy per-version "App Review" thread? What's the correct way to get a first-time subscription group submitted alongside an app version right now?
Replies
5
Boosts
0
Views
608
Activity
13h
SwiftUI TextField autofocus retains environment-injected objects after fullScreenCover dismissal with both ObservableObject and Observation
I am seeing a SwiftUI environment object remain alive after the view hierarchy that owns it has been dismissed. The retained object is owned by @StateObject inside a fullScreenCover. A TextField presented deeper in that hierarchy receives focus through @FocusState. After navigating back and dismissing the cover, the @StateObject does not deinitialize. The memory graph shows that system keyboard/input-assistant views retain a UITraitCollection, which retains a SwiftUIEnvironmentWrapper containing the environment object. Environment macOS 26.6.1 (25G76) Xcode 26.6 (17F113) iOS 26.5 Simulator iPhone 11 26.6 Minimal reproduction import Combine import SwiftUI final class DemoCoordinator: ObservableObject { let id = UUID() init() { print("[+] DemoCoordinator INIT \(id)") } deinit { print("[-] DemoCoordinator DEINIT \(id)") } } @main struct FocusStateLeakApp: App { var body: some Scene { WindowGroup { RootView() } } } struct RootView: View { @State private var isFlowPresented = false var body: some View { Button("Present flow") { isFlowPresented = true } .fullScreenCover(isPresented: $isFlowPresented) { FlowContainer() } } } struct FlowContainer: View { @Environment(\.dismiss) private var dismiss @StateObject private var coordinator = DemoCoordinator() var body: some View { NavigationStack { NavigationLink("Push field screen") { FieldScreen() } .navigationTitle("Flow") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Close") { dismiss() } } } } .environmentObject(coordinator) } } struct FieldScreen: View { @State private var text = "" @FocusState private var isFocused: Bool var body: some View { TextField("Type something", text: $text) .textFieldStyle(.roundedBorder) .focused($isFocused) .padding() .navigationTitle("Field") .onAppear { isFocused = true } .onDisappear { isFocused = false } } } Steps to reproduce Launch the application. Tap “Present flow”. Tap “Push field screen”. The TextField automatically becomes focused and the software keyboard appears. Navigate back. Tap “Close” to dismiss the full-screen cover. Observe the console or capture a memory graph. Expected result: After the full-screen cover is dismissed, FlowContainer and its @StateObject storage should be released. The following message should be printed: [-] DemoCoordinator DEINIT ... Actual result: DemoCoordinator remains alive and its deinit is not called. The captured memory graph contains one DemoCoordinator. The same behavior occurs after migrating the reproducer to the Observation framework. Questions Is retaining the SwiftUI environment through keyboard-owned cached trait collections expected? Is there a supported way to prevent dismissed SwiftUI environments from being retained by the input-assistant hierarchy? Is this a known UIKit/SwiftUI issue for which a Feedback ID already exists? Should this be reported as a SwiftUI issue, UIKit issue, or Text Input issue in Feedback Assistant? I can provide the minimal Xcode project and the captured .memgraph file if needed.
Topic: UI Frameworks SubTopic: SwiftUI
Replies
0
Boosts
0
Views
26
Activity
13h
2 months pending enrollment
Hello, My organization enrollment in the Apple Developer Program has remained in "Your enrollment is being processed" since 3 July 2026 — eight weeks. Apple's published processing time for organization enrollments is two to four weeks, so this is well outside the expected timeframe, and I have received no communication explaining the delay. Enrollment ID: 92WKJ94M6U Could you please: Confirm which stage the enrollment is currently held at — D-U-N-S verification, legal entity verification, or signing authority review. Tell me exactly what is required from me to move it forward. I can provide any supporting documentation immediately, including our Chamber of Commerce registration certificate (visura camerale), VAT registration, and written proof of my signing authority for the company. Provide a case number for this request and an expected resolution date. This delay is blocking a project with a committed delivery date, so I would appreciate any expediting you are able to apply. Thank you, Mario Baldantoni
Replies
0
Boosts
0
Views
17
Activity
13h
NEURL Filter configuration approved under wrong Developer Team — resubmission blocked by duplicate domain
Hi, My NEURL Filter configuration (ID 9f3cbff8-63de-4c69-bf68-c19cd1c5d842) was approved on August 5, 2026, but it turned out to be attached to the wrong Apple Developer Team — an old individual account (S5VDH23BBZ) I no longer have access to, instead of my actual organization team, KRKJ76BC7W (SCOTTO), which owns and signs the app (bundle ID com.dropbet.DropBet). I contacted Developer Support, who said they couldn't transfer it and suggested replying to the original approval email — I did (on 08/08, then several times) with no response. I then tried resubmitting the same configuration under the correct team (KRKJ76BC7W), but the portal rejected it with: "A configuration with the same PIR Server Domain already exists." So a fresh submission is technically impossible while the original stays attached to the wrong account — the only real fix is transferring or re-attaching the existing approved configuration to KRKJ76BC7W. Has anyone dealt with this kind of Team ID mix-up before, or know who on the Network Extension / NEURL Filter team could help reassign an approved configuration? Happy to provide any additional details. Thanks in advance.
Replies
1
Boosts
0
Views
58
Activity
13h
Initial submission stuck "In Review" for 9 days with 3 IAPs attached
My first app submission has been in "In Review" since August 19, 2026 at 08:56 (CEST) — 9 days now, with no status change and no message of any kind. Details: Apple ID: 6799895164 Version: 1.0 (build [1]) Submission ID: 412ca140-f582-42a5-9714-e50a254e260b Platform: iOS Submitted: August 18, 2026 In Review: August 19, 2026 at 08:56 (CEST) The submission contains 1 app version and 3 in-app purchases: 2 auto-renewable subscriptions and 1 non-consumable lifetime unlock. All items show as included in the submission. Everything on my side appears complete: review screenshots for each IAP, price schedules, localizations, privacy policy URL, EULA, age rating declaration. Restore Purchases is implemented and visible on the paywall. Account status: Paid Applications Agreement: [Active] Digital Services Act trader status: [Verified] MRDP compliance: [Active] Bank and tax details: [Active] There is no rejection, no request for additional information, and nothing in Resolution Center. A support case is open as well. I have seen several recent threads describing the same pattern — in some cases requiring someone at Apple to move the IAP status forward on the backend. Could someone from App Review please check whether this submission is progressing normally, or whether something on my side is blocking it? Happy to provide any further details. Thanks in advance.
Replies
0
Boosts
0
Views
22
Activity
13h
Guideline 3.1.3(b) — showing a web-only B2B tier on iOS pricing page
We have a multiplatform SaaS app (iOS, Desktop). Individual plans are sold via IAP on iOS. We also offer a B2B multi-seat plan that's only sold through our website (per-seat billing, admin provisioning, etc.). On our iOS pricing page, we want to show all plans — including the B2B one — so users can see the full picture. The B2B plan would just show features and a starting price with a label like "Managed through our desktop platform." No purchase button, no link, no redirect. Only the individual plans would have IAP subscribe buttons. Three questions: Does showing pricing/features for a plan that can't be purchased in-app count as "steering" under 3.1.3? Is a static label like "Managed through our desktop platform" considered a call to action if there's no link or button? Would a "Contact Sales" form (just collects an email, follow-up happens outside the app) be a safer approach? We did check with Apple Developer Support (Aug 2026) and were told this should be fine, but want to hear from anyone who's shipped something similar before we submit. Thanks.
Replies
0
Boosts
0
Views
7
Activity
13h
App stuck in "Waiting for Review" for 14 days — Apple ID 6768742372
Dear App Review Team, Our app No.IA (Apple ID: 6768742372) has been in "Waiting for Review" since July 20, 2026. This is version 3.1, resubmitted after the App Review Board cleared Guidelines 2.3.1 and 3.2.1 (Appeal Ticket APL509468). All Guideline 1.1 concerns have been addressed: metadata rewritten, in-app labels updated, screenshots replaced. We have tried: Resolution Center reply, expedited review request, phone call to Developer Support (Case 102912803305). All responses have been generic with no timeline. This app has been in review processes since May 19, 2026 — over 75 days. Any assistance would be greatly appreciated.
Replies
4
Boosts
1
Views
455
Activity
13h
Something is wrong with App Review and support.
My app is a retro game emulator. It was approved, ran on the App Store through several updates, and then got rejected as design spam. Why? Good question. Resolution Center answers with a template listing every possible cause: maybe the metadata, maybe an embedded binary, maybe I bought an app template, maybe the concept already exists on the App Store. Pick whichever one you like best. When I got that list, I assumed I needed to defend the concept. I recorded ten minutes of video showing myself using the app by hand, added test materials, descriptions, and a letter explaining everything. I got the same list back. Later I thought the cause might be the PSP emulation core — I was using an existing one, because my own wasn't finished yet. I rebuilt, resubmitted, explained. Waited two weeks, requested an expedited review. No email, no confirmation, no denial. Nothing. A week after that, I received a message from review saying the app appears to hide functionality during review. It does not. There are no feature flags, nothing of the kind. There are no dark patterns in the monetization either — no close buttons you can't hit, no trial tricks, nothing of that sort. What exactly they believed was hidden — guess for yourself. Resubmitted again. Design spam again, with the same list of possible causes. But you can't keep guessing forever. So I wrote to support — there is a dedicated form for requesting the specific reason for a rejection. I have been waiting for weeks. No confirmation that my request was received, no denial, no explanation. Nothing. I filed a separate appeal. Again: no confirmation, no denial, nothing at all. Weeks of silence. Meanwhile the app is still live on the App Store, getting thousands of downloads, people are paying for it, and it has bugs I cannot fix because I cannot ship an update. Users hit those bugs, leave bad reviews and low ratings over them, and the rating keeps dropping. I also want to talk about the "concept" item in the design spam list. Where is the line between an app that copies an existing feature on the App Store, and one that improves on what exists? Are there emulators on the App Store? Of course. Are they good? Not really. In my most recent testing, my own core reduced CPU/GPU load by up to 40% compared to emulators still running third-party code. I won't even get into UI quality, because the user reviews speak for themselves. People point out bugs and still leave five stars because of the UX. Does that mean I copied something, or that I improved on it? And on top of that, I didn't copy anything — the emulation core is my own. I know App Review has a huge amount of work right now. But why should that affect support this badly? As a paying member of this program for years, this looks like a completely broken process with no transparency at all. People on these forums say that after a design spam rejection your app goes into some different review queue. But even if that's true — why is that my problem? I have no alert about it, no notification of any kind, and no reason to be ignored for months. Let's be honest. Design spam is bad, no question. But it is a rejection like any other. You tell me what's wrong, I fix it, you re-check. Please don't turn "design spam" into a mark that makes developers want to give up and stop trying entirely. App ID: 6790321094 Submission ID: 883d7004-33a3-4fd7-b229-756a15b51cb9
Replies
0
Boosts
1
Views
29
Activity
13h
CloudKit private database: all writes fail with HTTP 500 (empty body), CKErrorDomain 15 / CKInternalErrorDomain 2001, account-scoped, reads unaffected. Began immediately after Apple Account legal name change
Since approximately 03:11 UTC on 2026-08-28, every CloudKit private-database write from my iCloud account fails. The app had been syncing normally for weeks before this moment. Failure signature: Every record save returns HTTP 500 with an empty response body (Server: AppleHttpServer, via icloud-xrail). Client-side error: CKErrorDomain 15 (Server Rejected Request) with underlying CKInternalErrorDomain: 2001. Reads succeed. CKContainer.accountStatus reports available. Authentication is fine. Only writes fail. Reproduces identically via NSPersistentCloudKitContainer mirroring and via a raw CKModifyRecordsOperation probe. Device: iPhone 15 Pro Max, iOS 17.2.1. Development environment, private database. Evidence this is account-scoped server state, not app configuration: It reproduces identically in two containers: the original production container and a freshly created container set up after the failures began. A brand-new container failing the same way rules out container-specific corruption or schema issues. Entitlements, embedded provisioning profile, and App ID iCloud capability have all been verified correct (codesign inspection and App Store Connect API). No code or configuration change coincided with the onset. The failure follows my Apple ID across probes over many hours. Every write 500s, without exception. Correlating event: the legal name on my Apple Account was changed at account.apple.com the same morning, shortly before the failures began. I cannot prove causation, but the timing is exact, and the account-scoped, writes-only signature is consistent with a wedge in the account's server-side state (PCS / user-record layer) introduced by the identity change. I request a check of this account's CloudKit/PCS state. Sample failing request UUIDs (x-apple-request-uuid) for locating these in server logs: 244DA811-E4AA-4771-88F0-7C092EFD8DEF, 2026-08-28 ~09:57 UTC 1FD544D6-6ED2-4181-8976-B4F4C35830D9 E55EFF8F-FC32-48BD-9165-F4EA263F130A Many more available on request. The app logs every attempt. Related reports: this appears closely related to thread 843819 (same week, same signature: private-db writes CKError 15 / HTTP 500, fresh container also affected, Console works), and possibly to the recent cluster of private-database reports in threads 838743, 840248, and 839650. Please correlate rather than triage in isolation. Impact: this blocks shipping a family-sharing feature built on CKShare, the purchase-deciding feature of the app. All development on sync is stopped. I can supply on request: a CloudKit sysdiagnose captured during a failing save (per TN3163), additional request UUIDs with timestamps, and the exact local timeline of the account name change.
Replies
0
Boosts
0
Views
19
Activity
13h
CloudKit Private Database requests fail with CKError 15 / HTTP 500, while Console works
Hi, I’m running into a strange CloudKit issue and I’m trying to figure out whether this could be related to the China mainland iCloud environment, or whether I’m missing something on the client side. I’m testing on macOS with Xcode 26.6, using the CloudKit Development environment and the Private Database. The Apple Account signed in on the Mac is a China mainland account, and CKAccountStatus reports available. The original container is: iCloud.com.hu.sujian With that container: I can create a custom zone in CloudKit Console. The app can save a normal CKRecord to the Private Database default zone. But the app consistently fails when creating a custom CKRecordZone. The error is: CKErrorDomain Code=15 (serverRejectedRequest) Underlying CKInternalErrorDomain Code=2000 I also opened DTS case 21678909 and filed FB24394907. As part of the DTS investigation, I created a completely new CloudKit container: iCloud.com.hu.sujian.dtstest21678909 I then repeated the same tests using the same Apple Account and the same minimal test app. On the new container, both of these app-side operations fail: Saving a CKRecord to the Private Database default zone CKErrorDomain Code=15 (serverRejectedRequest) CKInternalErrorDomain Code=2000 HTTP status: 500 Request UUID: D4B4DC7A-4167-4987-8BB1-4C61E658EDB6 Creating a custom CKRecordZone named SujianLibrary CKErrorDomain Code=15 (serverRejectedRequest) CKInternalErrorDomain Code=2000 HTTP status: 500 Request UUID: 00B4A294-9C63-4DBC-9133-03D969536B73 However, if I open CloudKit Console for that same new container, I can create a custom Private Database zone successfully. I created: DTSConsoleTest21678909 and it shows up normally as: REGULAR_CUSTOM_ZONE The code is very small. The relevant paths are essentially: let container = CKContainer(identifier: containerIdentifier) let database = container.privateCloudDatabase let record = CKRecord(recordType: "DTSWriteTest") record["message"] = "test" as CKRecordValue try await database.save(record) and: let zone = CKRecordZone(zoneName: "SujianLibrary") try await database.save(zone) What confuses me is that CloudKit Console works, while the app receives an HTTP 500 from the CloudKit service. The behavior also changed slightly between the two containers: Original container: default-zone record write from app: works custom-zone creation from app: fails custom-zone creation in Console: works New container: default-zone record write from app: fails custom-zone creation from app: fails custom-zone creation in Console: works FB24394907 contains the full reproduction details and logs. Has anyone seen something similar, especially with a China mainland iCloud account? I also have a small standalone reproduction project if that would be useful. Thanks.
Replies
1
Boosts
0
Views
222
Activity
13h
SwiftUI iOS 26: Root ScrollView jumps during interactive pop when the Tab Bar is hidden
I encountered a SwiftUI navigation issue on iOS 26.3.1 with this structure: TabView NavigationStack(path:) custom root ScrollView The navigation stack hides the system Tab Bar while a destination is presented. When the root ScrollView is near its bottom, an interactive pop briefly exposes the root list at a lower vertical position, then snaps it back when the transition completes. Measured geometry on an iPhone 17 Pro Max simulator: Before navigation: offset 754.67, container height 733, bottom inset 107 During pop: offset 705.67, container height 782, bottom inset 58 After pop: offset 754.67, container height 733, bottom inset 107 The effective Tab Bar occupancy on this device was 49 points. During the transition, the container became 49 points taller and its bottom inset became 49 points smaller, causing SwiftUI to clamp the content offset near the bottom. The following approaches did not prevent the visible intermediate state: Adding more bottom spacing Disabling scroll content offset adjustment in the navigation path transaction Saving and restoring ScrollPosition after the pop .defaultScrollAnchor(.top, for: .sizeChanges) Moving Tab Bar visibility ownership to each destination view; this also produced a noticeable delay before the Tab Bar returned The workaround that has been reliable is: Keep Tab Bar visibility synchronized with whether the tab-owned NavigationStack path is empty. This preserves the normal system animation timing. Measure the Tab Bar's effective occupancy from public geometry: root ScrollView bottom inset window bottom safe-area inset the app's normal trailing scroll margin While navigation depth is greater than zero, preserve that measured amount with a clear safeAreaInset on the root ScrollView. When onScrollGeometryChange reports that the root page's system bottom inset has returned, release the reserved inset in a transaction with animations disabled. With this approach, the offset remained 754.67 throughout push and pop. The Tab Bar also returned at its original system-controlled time. The implementation uses public APIs only. It does not hard-code 49 points, traverse the UITabBar view hierarchy, poll system UI state, or restore an offset after the transition. Has anyone found an Apple-recommended alternative, or observed the same behavior on other iOS 26 versions?
Replies
0
Boosts
0
Views
17
Activity
13h
App Store US Search Indexing Bug: Unique name, global availability enabled, but searchable everywhere except the US App Store (Anyone else?)
Hi everyone, I’m sharing this to see if anyone else has experienced this specific geographic search suppression issue on a newly released app. The Situation: App Name: CrushPov Status: Released a few days ago, "Ready for Sale", global availability including the US is fully enabled. The Core Issue: My primary target market is the US. While the app appears in search results in other regions, searching the exact, unique app name ("CrushPov") in the US App Store yields zero results. It doesn't appear anywhere, even at the very bottom. What works: Direct App Store URLs and iTunes Search API work fine. Users can download it via direct links, but organic US search discovery is completely dead. Apple Search Ads (ASA): Apple Search Ads campaign creation flow cannot find the app in the US storefront either—neither by name search nor by pasting the canonical App Store URL. What I've Checked: Metadata, pricing, and US availability settings are fully configured in App Store Connect. There are no competing apps with this exact name. This is clearly an isolated indexing issue on the US App Store servers. If you've experienced this US-specific ghost-suppression state on a newly released app: Did it eventually resolve itself after a certain period (weeks) without intervention? Has anyone successfully gotten Apple Support to manually re-index a region-specific search drop? Any insights or shared experiences would be greatly appreciated. It's tough to kick off US-focused influencer marketing when the local App Store search completely fails to acknowledge the app exists.
Replies
0
Boosts
0
Views
15
Activity
13h
UNEXPLAINABLE 3 MONTHS TAKING TECHNICAL ISSUE DEV ACCOUNT
Dear Apple Developer Support / Apple Developer Program Team, I am writing to formally escalate an unresolved issue with my Apple Developer Program application. I initially applied for the Apple Developer Program at the beginning of June 2026. My application was subsequently accepted, and I received communication indicating that I should be able to proceed with the remaining steps to activate my Developer Program membership. However, the process has been technically blocked from the beginning. When I follow the link provided by Apple, I am unable to proceed with signing the agreement and completing the required payment. Instead, I remain stuck on the same screen: “Thank you for your submission. We’ll get back to you soon.” I have contacted Apple Support and Developer Support repeatedly about this issue. On several occasions, I have spent approximately 1–1.5 hours waiting to reach a representative. Unfortunately, most of the representatives I have spoken with have been unable to identify or resolve the underlying issue. I have repeatedly been advised to be patient and have been told that the matter appears to be related to an internal Operations department. I fully appreciate that technical issues can occur and that some cases require investigation by another department. However, this matter has now remained unresolved for approximately three months. At one point, after waiting for a significant period without a resolution, I requested that my application be withdrawn so that I could submit a new application and potentially avoid the technical issue. Even getting this request understood and processed took approximately 1.5–2 weeks. I subsequently submitted a new application and, again, the application was accepted. Unfortunately, I am now experiencing essentially the same technical problem and remain unable to complete the enrollment process. This has become extremely concerning because we are not dealing with a normal application delay. We appear to be dealing with a technical or operational issue that prevents an accepted applicant from completing the final enrollment steps, while standard support channels have been unable to resolve or meaningfully explain the situation. I have retained documentation of the entire process, including application confirmations, acceptance communications, screenshots, correspondence and support interactions, and I am able to provide these upon request. Our company is a legitimate new business and our development activities and applications are directly connected to our company website, business email infrastructure and development plans. We have also involved experienced developers who have previously worked with Apple Developer accounts at established international companies, and this situation is highly unusual compared with their previous experience. I want to emphasize that I have been patient and cooperative throughout this process. I have provided the requested information, contacted the appropriate support channels multiple times, followed the instructions given to me, and even restarted the application process when advised. During the phone calls I selected that everything can be recorded so apple should have those conversations. However, after approximately three months, I believe it is reasonable to request that this matter receive attention at a level capable of actually resolving it. I am not looking for preferential treatment. I am simply asking Apple to investigate why an application that has already been accepted cannot proceed through the enrollment process, and to provide a clear explanation and resolution. Please treat this as a formal complaint and escalation request and provide me with a reference/case number for this complaint. I am prepared to provide all supporting documentation immediately. I sincerely hope this matter can now be escalated to someone who has the authority and technical access necessary to investigate and resolve it ASAP. Kind regards,
Replies
0
Boosts
0
Views
36
Activity
13h
MKDirections returns "Directions Not Available" when A and B are outside mainland China (e.g. Tokyo–Osaka)
I use MapKit and MKDirections for driving directions. The error "Directions Not Available" appears when the two points (A and B) are outside mainland China (e.g. Tokyo → Osaka). For routes inside China (e.g. Shanghai → Beijing), the same code works. let req = MKDirections.Request() req.source = MKMapItem(placemark: MKPlacemark(coordinate: origin)) req.destination = MKMapItem(placemark: MKPlacemark(coordinate: destination)) req.transportType = .automobile MKDirections(request: req).calculate { response, error in // Tokyo–Osaka (outside China): "Directions Not Available" // Shanghai–Beijing (inside China): works } Questions: Is MKDirections intended to support only routes within the device’s region (e.g. China)? When A/B are abroad, is "Directions Not Available" expected? Is this documented? For cross-country or overseas routes (e.g. Tokyo–Osaka), what is the recommended approach—third-party routing API + drawing on MapKit? Thanks.
Replies
1
Boosts
1
Views
328
Activity
13h
TestFlight Installation Error: “The requested app is not available or doesn't exist” – Beta Contract Missing
Hello Apple Developer Community, I am experiencing a TestFlight issue with my iOS app and would appreciate any guidance. App Information: App ID: 6801854699 Bundle ID: az.idrak.liseyi App Version: 1.0.9 (14) Platform: iOS Team ID: W24294ZD96 Apple Developer Program membership: Active until December 11, 2026 Free Apps Agreement: Active Paid Apps Agreement: Active Issue: I uploaded build 1.0.9 (14) to App Store Connect using Codemagic. The build processes successfully and appears in the internal testing group. However, when an internal tester opens TestFlight and attempts to install the app, TestFlight displays: “The requested app is not available or doesn't exist.” At the same time, Codemagic reports the following API error: POST betaAppReviewSubmissions returned 422: Beta contract is missing for the app App Store Connect also previously displayed a message saying that I needed to renew my Apple Developer Program membership when attempting to create an external testing group. However, my membership is active until December 11, 2026, and all required agreements are active. Steps to reproduce: Upload build 1.0.9 (14) to App Store Connect using Codemagic. Wait for the build to finish processing. Add/select the build for TestFlight internal testing. Open TestFlight on an iPhone using an internal tester account. Attempt to install the app. TestFlight displays: “The requested app is not available or doesn't exist.” Codemagic reports: “Beta contract is missing for the app.” This issue appears to be related to a backend synchronization or Beta Contract problem. Apple Developer Support has already escalated this case to their technical team under case number 20000139248466. Has anyone experienced the same Beta Contract / TestFlight availability issue, or knows how this can be resolved? Thank you.
Replies
0
Boosts
0
Views
24
Activity
13h
Sign In with Apple - invalid_client
Hi Apple Developer Support, We are implementing Sign in with Apple for our web application hosted on example.com. In the Service ID settings, we have configured the following: Service ID (client_id): com.example.service.local Web Domain: example.com Return URL: https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple We also tested login via the following URL from our web application: https://appleid.apple.com/auth/authorize?response_mode=form_post&response_type=code&client_id=com.example.service.local&scope=name%20email&state=2f9gMY1rTe12-O7Wbnb7KWe504HQ0KWBSHTKHbg9ZEY=&redirect_uri=https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple However, we’re receiving an invalid_client error after submission. Our questions: Is it valid to use an ngrok URL like https://2db2-121-160-153-88.ngrok-free.app/... as the Return URL for development and testing? Does the Web Domain need to match the ngrok domain, or is it enough to register the production domain (e.g., example.com)? Is there any propagation delay or approval process after updating the Return URL in the Service ID? Is the client_id strictly required to match the Service ID exactly? We would greatly appreciate any insights or best practices to help us resolve this issue. Thank you in advance!
Replies
36
Boosts
23
Views
3.2k
Activity
14h
macOS 27 beta: every OS update fails — MobileSoftwareUpdate 1259 "failed to copy firmware identity" (orphaned iSCPreboot volume-group dir) — FB24342236
Every macOS update fails during preflight personalization on my MacBook Pro (Mac15,6, Apple Silicon), currently on 27.0 build 26A5378j. It's failed on every build from beta 5 (26A5406e) through beta 7. Identical failure via Software Update and via startosinstall. It fails LOCALLY, before contacting Apple (gs.apple.com and gdmf.apple.com are both reachable with valid certs). Error (install.log + unified log): reaches PREFLIGHT_PERSONALIZE (~0.15), then aborts MobileSoftwareUpdateErrorDomain Code=1259 "failed to copy firmware identity" "could not obtain device identity information through SFR installer" SUMacControllerErrorPreflightPersonalizeFailed=7723 Root cause I've traced: an orphaned volume-group boot-policy directory in /System/Volumes/iSCPreboot/. ls shows two volume-group UUID dirs — the live one (matches diskutil info /) and an orphan (3D3287DE-...) with no corresponding APFS volume group (diskutil apfs list shows only one live group). Both date to Feb 2024. The preflight can't reconcile the System Recovery boot policy in the orphaned dir. Note: NOT caused by Erase All Content and Settings (unlike the commonly reported case). The orphan predates the beta, so any pre-existing second volume-group boot-policy directory reproduces it. It was harmless for ~2 years; macOS 27's stricter preflight rejects it. Ruled out (no effect): disk space, VPN, DNS, clock, Apple Account, refreshing the beta seed entitlement, reboot, Time Machine, re-downloading the installer, and Recovery reinstall (same 1259). Filed as FB24342236 — no response across beta 5, 6, 7. Questions: Is this a known issue with a planned fix, and in which build? Any supported recovery path that does NOT require a second Mac? (Recovery reinstall fails the same way.) Or is DFU Revive/Restore the only option? Will the public 27.0 release install on this machine, or hit the same preflight?
Replies
0
Boosts
0
Views
26
Activity
14h