Overview

I'm using Product.products(for:) to get my auto-renewable subscription on watchOS: let products = try await Product.products(for: [<##Identifier##>]) However, it doesn't return any value, and doesn't throw errors. The console shows an error: Could not parse product: missingValue(for: [StoreKit.ProductResponse.Key.billingPlanType], expected: StoreKit.BackingValue) Is this a bug or I did't configure something well? This product has been approved by App Review.

My app review has been stuck. The app includes IAP. When displaying purchases, it first needs to retrieve the price list. This price list is hosted on Apple's servers. Retrieving it is handled by the SDK. Possibly due to the sandbox environment, the price list is very difficult to obtain right when Apple's California office starts work. But at other times, it's very fast. Apple's reviewers have never been able to see the prices. I suggested they change their test time to noon or afternoon, but they still couldn't see the prices. This suggests that the network environment used by Apple's review team has poor connectivity to Apple's own sandbox servers. When I received the review start notification, I tested it myself, and it worked perfectly — the price list loaded quickly. I recorded a video and took screenshots to show the reviewers. But they are still testing within their own network environment, so they couldn't see the price list. I suggested they switch to an open network environment for testing, such as cellular mobile data or a coffee shop Wi-Fi. But that doesn't seem to have helped. They still say they cannot retrieve the prices. This has been going on for a week. They test once a day, and I resubmit once a day. I don't understand why they won't test just once in an open network environment — that would allow them to see the price list load quickly, and would also prove that Apple's SDK and sandbox are functional. If the app works fine in the user environment, then there is no problem. If there's an issue in their test environment, it's a network environment issue. Our code has no problem — I can see that it retrieves the price list and purchases work normally. Every day I can only resubmit without uploading a new version. But I can't keep this up forever. I think maybe a supervisor or someone in charge needs to look into this. Our app is com.ayi9.phone.

I have two lines through Verizon wireless, my main line for the account was acting like a dead eSIM every time it is on it kills my data completely even on the second phone line unable to send a receive phone calls, send a receive text messages, retrieve voicemails, or use data in any capacity from that line. I have completely deleted and reinstalled and reactivated eSIM for that line a handful of times in the last week/week and a half & it is the main account line being rendered completely unusabl.

I've been struggling to get consistent UI and UX behaviour of SwiftUI Views inside NSToolbarItems and was wondering if there is an official way to use them. I've now revisited this issue in macOS 27 and continue to see some idiosyncrasies. In the attached screenshot, you can see that the highlight area on mouse down between to the two buttons is different. This is the easiest example I've come up with that shows SwiftUI Views exhibiting different behaviour than AppKit Views. Two questions: Is an NSHostingView a valid and supported view type for NSToolbarItem.view? If so, are there any rules that govern how the SwiftUI view should be configured? (ex: frame, sizing options, supported SwiftUI Views, preferred "root view" types, etc?) Sample code that created the two NSToolbarItem buttons in the screenshot. macOS 27 ZY21R0CMGL (Public Beta 1) Xcode 27.0 beta Minimum Deployment target: 27.0 // Left-Top SwiftUI Button (Clipped Highlighting) let item = NSToolbarItem(itemIdentifier: itemIdentifier) let rootView = Button { } label: { Image(systemName: "sidebar.trailing") } item.view = NSHostingView(rootView: rootView) // ... snip .. // Right-Bottom AppKit Button (Correct Highlighting) let item = NSToolbarItem(itemIdentifier: itemIdentifier) item.image = NSImage(systemSymbolName: "sidebar.trailing", accessibilityDescription: nil) Both screenshots are taken on mouse down.

So I know apple store connect are strict in term of your app screenshots, you cannot insert some promotional video and you cannot insert any screenshot that does not come from an iphone or official simulator. But I saw earleir someone's app with a screenshot that was like "MOCK" type, it has some 2 sentence description on top and below them the actual screenshot (on a phone simulation mockup lets say). This got me thinking that apple store connect actually tolerate images that are not PURE screenshots? You can actually take screenshots insert them to mockup and then insert that image in app store connect? How to do that and more importantly what to do to make sure it is done in a way apple store connect accepts it? What others things can be done, or best practices?

Hi everyone and @Apple Developer Support, I'm hoping someone from Apple can help escalate this, as first-level support has not been able to resolve it for over 10 days. I renewed my Apple Developer Program membership (Organization) and paid in full by card on 10 June 2026. The payment was completed and I have the official Apple invoices. However, my membership was never properly activated. The clearest sign something is wrong: my account now shows a Renewal date of January 11, 2026 — a date that is already in the past — even though I paid on 10 June 2026. My previous membership had expired on January 10, 2025. It looks like my payment was applied to the old, already-lapsed period instead of starting a new term. Since I paid on 10 June 2026, my membership should be active from 10 June 2026 to 10 June 2027. On a phone call on 15 June 2026, Apple confirmed the payment was received but had not been correctly linked to my account, and that they could not fix it on the call. My emails (cases 102912847689 and 102917255312) have gone unanswered beyond automated replies. What I have verified: Two-factor authentication is enabled The payment was made for and invoiced to my Developer account / company I have not made any duplicate payments (and I will not pay twice) Details: Program: Apple Developer Program (Organization) Team ID: UQK3368F79 Web Order: W1785567985 / Apple order AEY1626756 Invoice: BB84180706 (09.06.2026) Region: Hungary Could someone from the Apple team please review and manually link web order W1785567985 to my account and activate the membership for the correct term (10 June 2026 – 10 June 2027)? If you're experiencing the same issue, please Boost this post and share your case below — support seems to be more active here in the forums. Thank you!

Hello App Review team, I am an individual developer and I appear to be experiencing a systemic, account-level delay rather than a normal queue wait. My current app "Color Grading App - Gradee" (Apple ID 6778543702) has been in "Waiting for Review" since June 10 - about 10 days - and has not yet entered review. This is a recurring pattern on my account: previous apps also stayed in "Waiting for Review" for an unusually long time (weeks to months) before review even began, regardless of the app's content. Because every submission on this account is affected the same way, I am concerned my account may be under a review hold or flag. Could someone please: Confirm whether my Apple Developer account is under any review hold, enhanced review, or flag. Let me know if anything is required from my side to resolve it. I have open support cases (102914638162, 102918134058) but have not yet received a response. I am not trying to flood support - I just want to understand what is happening so I can fix it. There is also time sensitivity: a marketing video for this app has gone viral and many users are actively searching for it right now. Thank you very much for your help.

The owner of the app has cancer & every moment is counting as the situation is getting worse by the hour. It may sound weird, but as you guys know, cancer patients have a lot of requests; he wants to see his app live. I sent the app for review 2 days ago, but it's still in "waiting for review". I will appreciate it if any Apple staff watch this post, will be grateful & begging to review this amazing app faster & make it live. please!

Summary On an M2 Max (macOS 26.5.1, 25F80), WindowServer intermittently stops checking in with the userspace watchdog ("hung 40/80 seconds since last successful checkin") and the machine resets. The part I'm asking about: since ~2026-06-17 the wedge no longer ends in a normal panic-reboot — it escalates to recoveryOS and forces a full Mac reactivation (local password + iCloud). Four times in 55 hours. The most recent was captured live and fired on a machine that was idle, memory-clean (1.2 GB free, flat swap, no Jetsam), with the underlying IOKit power-assertion count plateaued — so this is not resource exhaustion at the moment of the wedge. It reproduces under a heavy third-party workload (an Electron app's per-session process fan-out, tracked separately by the vendor). I'm not asking Apple to fix that app — I'm asking about the OS behaviors that turn "an app uses a lot over many hours" into "the owner is locked out pending iCloud reactivation." Apple-side vs app-side (so this isn't dismissed as a third-party issue) Apple's — and these should hold regardless of any app, because no userspace workload should be able to cause them: A userspace WindowServer watchdog timeout escalating to a firmware/recoveryOS reset that invalidates the boot policy and demands iCloud reactivation. On disk, the four 06-18→06-20 events have the WindowServer watchdog .spin/.ips but no panic-full and no ResetCounter — they did not take the normal panic-reboot path. The watchdog resetting the whole machine instead of restarting the wedged compositor ("WindowServer has not exited since first loaded"). WindowServer/SkyLight degrading cumulatively under sustained use so the wedge fires even when the machine is currently idle and memory-clean (below). IOKit never reclaiming RootDomainUserClient (IOPMrootDomain) registrations — they accumulate unbounded and clear only on reboot, and the dominant holders are Apple's own daemons (apsd, WebThumbnailExtension), not the app. App-side (separate tracker): unbounded per-session MCP process fan-out + an Electron footprint + a held NoIdleSleep assertion forcing sustained display-on operation. That controls how fast you reach the degraded state; the OS controls whether reaching it is a graceful degrade or an owner-lockout. Event 4 shows the OS failure with no resource exhaustion present at all. System MacBook Pro 14" (Mac14,5), M2 Max (T6020), 38-core GPU, 32 GB — a high-end, fully capable machine I had essentially never needed to reboot before this; it now forces a reactivation roughly once per day of use. macOS 26.5.1 (25F80), kernel xnu-12377.121.6~2 (Darwin 25.5.0). FileVault on, no third-party kexts, 161 GB free disk. Same kernel build as 25F71 — the update didn't change it. Signature userspace watchdog timeout: no successful checkins from WindowServer (0 induced crashes) in 120 seconds WindowServer has not exited since first loaded service: logd / opendirectoryd / configd — last checkin: 0 seconds ago service: WindowServer — last checkin: 120 seconds ago Panicked task ... watchdogd; KEXT backtrace: AppleARMWatchdogTimer -> AppleARMPlatform Compressor Info: NN% (OK) ... 0 swapfiles <-- memory-clean Only WindowServer is stuck; logd/opendirectoryd/configd check in normally. Pre-reset spindumps show ws_main_thread off-CPU ~59 s, wedged in SkyLight → QuartzCore CA::Transaction::commit / CALayer render-commit. Two spindumps per event (the 40 s/80 s checkpoints before the 120 s reset). Timeline & the escalation point (verifiable on disk by panic-full/ResetCounter presence) Normal panic-reboots (panic-full + ResetCounter written): 06-15 22:24 (~6.2 h uptime), 06-16 11:39 (~13.2 h), plus 06-14 / 06-15 16:07 / 06-16 20:08. Latest panic-full on disk = 06-16 20:08. Escalated to recoveryOS reactivation (NO panic-full, NO ResetCounter): # When WindowServer uptime at wedge state R1 06-18 01:23 ~27.6 h (99,278 s) R2 06-18 19:53 ~18.4 h (66,201 s) + Jetsam pressure R3 06-19 15:30 ~19.2 h (68,991 s) R4 06-20 08:19 ~16.7 h (60,180 s) idle, 1.2 GB free, leak plateaued 583 Uptime = WindowServer-process uptime from the .ips "M checkins since K seconds ago" field (the coarse uptime JSON field — 99000/66000/69000/60000 — corroborates). Time-to-wedge is not a fixed interval — it ranges ~6–28 h and scales inversely with GPU/compositor load; the invariant is sustained use, not a clock value. After 06-16 there are zero panic-full and zero ResetCounter on disk — the fingerprint of the recoveryOS escalation. Decisive evidence — R4, captured live A monitor sampling every 2.5 min when WindowServer wedged (08:19, 16.7 h): 08:14 iopm=581 free=1833MB swap=3732MB load=2.88 08:19 iopm=583 free=1192MB swap=3724MB load=3.03 <-- watchdog spindump written Idle (load ~3), 1.2 GB free, flat swap, no Jetsam, the IOKit power-assertion count plateaued at 583. Nothing to exhaust — it still wedged and escalated to reactivation. The trigger is cumulative WindowServer/SkyLight state, not the resource level. The leak (an aggravator) RootDomainUserClient/IOPMrootDomain clients climb without bound (baseline ~120 → 583–923 here). Dominant holders are Apple daemons (live ioreg walk 2 min pre-panic: apsd 228/596, then Safari/WindowServer/powerd/loginwindow). Killing the top creating process does not reclaim them (ioclasscount 526→526) — kernel-orphaned, reboot-only. Per R4 the leak is an aggravator, not the threshold (583 wedged; 923 had not earlier). Ruled out Hardware (survived 25F71→25F80, same kernel; peripheral + driver removal); memory exhaustion (R4 and others memory-clean); a fixed clock (load-dependent, 6–28 h); an iopm threshold (R4 plateaued at 583). Questions for Apple engineering Why does a userspace WindowServer watchdog timeout escalate to recoveryOS + forced reactivation (boot-policy re-verification) instead of a normal panic-reboot? What invalidates LocalPolicy / triggers Activation-Lock re-verification on this path? What in WindowServer/SkyLight degrades cumulatively over sustained use so a render-commit can't complete within the watchdog window even on an idle, memory-clean machine? Can the watchdog restart the wedged WindowServer ("has not exited since first loaded") instead of resetting the whole machine into a reactivation lockout? Can IOKit lifecycle-bound RootDomainUserClient (IOPMrootDomain) registrations so they don't accumulate unreclaimable? Dominant creators are Apple daemons (apsd, WebThumbnailExtension). Apple Feedback FB22947849 has the per-event spindumps, .ips, the live monitor log, and a sysdiagnose. I'd most appreciate a pointer on #1 — the reactivation escalation is what turns a recoverable crash into a repeated owner-lockout.

So I am adding Catalyst support to my iOS app. I went through and updated my code and Build Settings to add Catalyst support. I can build for any iOS build or macOS build. I went into App Store Connect and then added a macOS build. I am not able to do a single build and archive that uploads a build for both macOS and iOS. I can do a build and archive for "Any iOS Device (arm64)" and it shows up in the iOS test flight. I can do a build and archive for "Any Mac (Mac Catalyst, arm64, x86_64) and it shows in the macOS test flight. Maybe I'm making a bad assumption ( I could not find any documentation on it) but I assumed Catalyst was a single build and archive that showed up in BOTH macOS and iOS sections. The build settings seem to imply the build is good for a single build and archive process. I want this to be a universal app and my assumption doing it that way would keep everything in sync when you push to the App Store. You can already download the app through the App Store but it is a version of the iPad app. I was hoping to make it more native and available in the Mac App Store without the iPhone/iPad app option. Am I making bad assumptions? Will I just have to do two Build and Archives for every build? I just want to make sure I'm doing this correctly and the best way.

Hello, My app has been in “Waiting for Review” status since May 28. App ID: 1471317275 The app was transferred to my developer account about two months ago. Since the transfer, previous reviews were completed without any issue, and I have not received any message in the Resolution Center or any indication that something is wrong with this submission. I am not sure if the app transfer could have affected the review queue, but the current submission has now been waiting for an unusually long time. Could someone from Apple please advise what I should do in this situation? Should I continue waiting, contact App Review Support directly, or resubmit the build? Thank you for your help.

Hello, I'm an individual developera. My enrollment has been stuck in "Pending" for over one week and I'd be grateful for help. Timeline Enrolled in first in 05.06. After several emails with no reply and no ivoice I withdrawn my enrollement. Enrolled in the Apple Developer Program (individual) on 15.06 again Payment was charged successfully and I received the official invoice from Apple on 17.06. Since then the account has stayed in "Pending." The symptom My account still shows "Purchase your membership / Complete your purchase." When I open the Apple Developer app it says "Enrollment through the Apple Developer app is not available for this Apple Account" and sends me to the website, which then asks me to pay again. I have deliberately not paid a second time, to avoid creating duplicate charges. This looks like a backend synchronization issue: the payment is recorded on Apple's side and the invoice was issued, but it was never linked to my enrollment. I have already opened a support case and followed up several times, but have not received a substantive response. Erollment ID: 55R7MCH5YH

We are experiencing an issue with our iOS application (MotoDealz) distributed through TestFlight. App Details: App Name: MotoDealz Version: 1.4.36 Builds: 48 and 49 Issue: The application installs successfully through TestFlight, but when launched on a physical iOS device it displays only a blank white screen and does not proceed further. Observations: The same build works correctly in the iOS Simulator. Build processing completed successfully in App Store Connect. No crash dialog or error message is displayed. The issue is consistently reproducible after reinstalling the TestFlight build. The application remains on a white screen indefinitely. Environment: Distribution Method: TestFlight Physical Device: iPhone Simulator: Working as expected Has anyone encountered a similar issue where the app works correctly in the simulator but shows only a white screen in TestFlight builds on physical devices? Any guidance regarding diagnostics, device logs, release-build configuration, or TestFlight-specific troubleshooting would be greatly appreciated. Thank you.

A sandboxed Mac app with correct CloudKit entitlements fails to connect to com.apple.cloudd (the CloudKit daemon) when distributed via TestFlight (Mac Team Store Provisioning Profile). The identical binary works correctly when launched from Xcode (Mac Team Provisioning Profile also present). All entitlements are correctly embedded and the App ID is properly configured in Apple Developer Portal. Environment macOS 26.5.1 (25F80) Xcode 26.5 (17F42) SwiftData with NSPersistentCloudKitContainer / ModelConfiguration(cloudKitDatabase: .private(...)) Steps to Reproduce Create a sandboxed Mac app using SwiftData with CloudKit sync Enable iCloud + CloudKit in Signing & Capabilities Archive and distribute to TestFlight (Mac Team Store Provisioning Profile) Install via TestFlight on macOS 26 and launch Check Console for kernel sandbox messages Expected Result CloudKit connects to com.apple.cloudd and syncs data, matching behavior of the iOS version using the same container. Actual Result Console shows repeated kernel sandbox denials followed by CloudKit setup failure: kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.cloudd kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.duetactivityscheduler CheatSheet Mac CoreData+CloudKit: Failed to set up CloudKit integration for store Error Domain=CKErrorDomain Code=6 "Error connecting to CloudKit daemon." Key Diagnostic Finding When launched from Xcode, taskgated-helper validates both the Mac Team Store Provisioning Profile AND the Mac Team Provisioning Profile, and CloudKit succeeds: cloudd: TCC approved access for container containerID=iCloud.com.michaelendres.CheatSheet:Production When launched from TestFlight, only the Mac Team Store Provisioning Profile is present, and the sandbox denies com.apple.cloudd despite identical entitlements in the binary: codesign -d --entitlements shows: com.apple.developer.icloud-services: [CloudKit] com.apple.developer.icloud-container-identifiers: [iCloud.com.michaelendres.CheatSheet] com.apple.developer.icloud-container-environment: Production com.apple.security.app-sandbox: true Conclusion The Mac Team Store Provisioning Profile on macOS 26 does not appear to grant the sandbox exception for mach-lookup com.apple.cloudd, while the Mac Team Provisioning Profile (development) does. This prevents any Mac App Store / TestFlight app using CloudKit from syncing on macOS 26.

My app says ready for distribution. What are my next steps? App store version release is locked with a time but every time that passes it just changes the time. I can not change it to manual and there is no launch button that I can find.

I was using Times New Roman and trying to use superscript numbers, but found out that Times New Roman only has superscript numbers 0, 1, 2, 3, ¹ (like so) and since I'm writing out transcriptions of pinyin, I also need superscript 4, 5, 6, 7. When I do that, the font changes to Lucida Grande automatically. I would like to change the default unicode font/alt font from Lucida Grande to EB Garamond (downloaded from Google) since it more closely resembles Times New Roman and unfortunately, I need to keep the font as close to Times New Roman as possible. Is there a way to change the default the computer chooses to when Times New Roman/alt font fails unicode? Alternatively, is there a font that looks exactly like Times New Roman that has the superscript numbers 0-9? 2022 laptop, M2, Tahoe 26.6.1 Move post at will if need be.

Rejected under Guideline 4.2 - a native crypto wallet + Web3 browser flagged as "just a web browser." Looking for guidance. I'd appreciate the community's and Apple engineers' read on a 4.2 (Minimum Functionality) rejection, because I believe the guideline was misapplied and I want to resolve it correctly. WHAT THE APP IS Everything Black is a native iOS app (SwiftUI, iOS 18+) built to platform Black-owned businesses, history, culture, and content, and to preserve it in one place. There is nothing else like it on the App Store. It combines a community hub, a Web3 layer, and an on-device crypto wallet. Native non-custodial wallet (GuapcoinX / GUAP token). This is core, and none of it is possible on the web. A 12-word recovery phrase is generated on the device with native BIP-39 / BIP-32 key derivation. The private key is stored in the iOS Keychain, so it never leaves the device or touches a server. Every transaction is gated by Face ID via the native LocalAuthentication framework. Transactions are signed on-device (secp256k1) and broadcast to the GuapcoinX network. Web3 and blockchain domains. The app registers and resolves on-chain domain names, .guap and .hbcu, and routes to them. These are real blockchain writes initiated and signed by the user. To my knowledge this is the only iOS browser that resolves these domains natively. Native AI assistant. A native SwiftUI chat that returns tailored Black-owned business recommendations from a ZIP code. Native directory and Discover. A native SwiftUI feed and search over a directory of Black-owned businesses, news, podcasts, wikis, resources, and a community board, preserving Black culture and content in a single app. A browser tab is included so users can open community and Web3 sites and reach their .guap and .hbcu domains. It is one tab among several, not the substance of the app. THE REJECTION Guideline 4.2, Design, Minimum Functionality. The app provides a limited user experience as it is not sufficiently different from a web browsing experience. Including features such as push notifications, Core Location, or sharing do not provide a robust enough experience to be appropriate for the App Store. (Screenshot of the rejection attached.) WHY I THINK 4.2 DOESN'T FIT The rejection says the experience is not sufficiently different from a web browsing experience. But the core of the app is a native crypto wallet doing on-device key generation, Keychain storage, biometric-gated signing, and on-chain transactions, capabilities a website physically cannot provide. The App Store hosts many approved apps that pair an in-app browser with a native wallet and an AI assistant, which is exactly the combination here. I suspect the native functionality was missed because the app opens on the Home and browser tab, so the reviewer may not have reached the Wallet and Assistant tabs. MY QUESTIONS First, for those who've cleared a 4.2 on an app with a genuine native wallet: did a Resolution Center reply work, or did you have to change the app or metadata? Second, is it worth changing the default launch tab to a native screen such as the Wallet, so the native functionality is the first thing a reviewer sees? Third, is there any guidance from Apple on how an in-app browser should be positioned so it isn't read as the whole app? Thanks in advance. G u i

Hello App Review team, My external TestFlight build has been in "Waiting for Review" for Beta App Review for about 2 days (~46 hours) with no status change. App: GlazingTime Version: 1.1.0 (build 13) This is the first external-testing (Beta App Review) submission of this build. I've checked and there are no "Missing Compliance" or action-required flags on the build — export compliance is set (ITSAppUsesNonExemptEncryption = false) — so as far as I can tell nothing is pending on my side. Could you let me know if anything is holding it up, or check on its place in the queue? Happy to provide any additional details. Thank you.

When a user uses the "Add Name" feature on an unknown number in their Call Logs, the name appears under "Other Known Contacts" in the native iOS Contacts app. The Problem: CNContactStore completely ignores these contacts during a standard fetch/enumeration. When user gives limited permission they can search for that contact and select it, but it won't be visible in my App as it's not technically a contact. Is CNContactStore intentionally blocked from reading "Other Known Contacts" for privacy reasons or are there any future plans to expose API so that third party apps can access it?

I am using CI/CD method to build my apps, i dont have xcode simulator, so I cannot produce 13'' screenshots And I have an ipad that is NOT 13'' what can I do? I am locked out from releasing on ipads?