Overview

I have been using Swift Playground to build and submit my apps to the appstore for around three years now. Recently I uploaded two of my apps but now when I submit them for approval an error is issued… “Unable to Add for Review”… (see pic attached). I don’t understand it because Playground does not use Xcode as far as I am aware? Can someone advise me what I can do to resolve this? Is it something I have to wait to be fixed by an Apple update?

I’m testing FinanceKit with Apple Cash and noticed that transfers don’t include any counterparty information. Here’s an example transaction I fetched: Transaction( id: 5A96EA49-B7C9-4481-949D-88247210C1D7, accountID: 28D7C0E2-DC2A-4138-B105-BCE5EE00B705, transactionAmount: 30 USD, creditDebitIndicator: .credit, transactionDescription: "Transfer", originalTransactionDescription: "", merchantCategoryCode: nil, merchantName: nil, transactionType: .transfer, status: .booked, transactionDate: 2025-08-19 21:57:54 +0000, postedDate: 2025-08-19 21:57:55 +0000 ) As you can see: transactionDescription is just "Transfer" originalTransactionDescription is empty merchantName is nil No counterparty details are exposed In contrast, the Wallet app clearly shows the other person’s name and avatar for Apple Cash transfers, making it easy to understand who the payment was with. In FinanceKit, there’s no way to distinguish between transfers with different people — every transfer looks identical. Questions Is there a hidden or planned field for Apple Cash counterparty information? Can FinanceKit provide at least minimal metadata (e.g., contact name, initials, or a privacy-preserving identifier)? Is there any workaround today to correlate Apple Cash transfers with contacts? Feature request: Please expose counterparty information for Apple Cash transfers. Even something as simple as a stable identifier or name string would enable developers to build Wallet-quality transaction detail screens. Thanks!

Hi everyone, I’m the developer of one sec, an app used by a large number of users globally to reduce time spent on social media and to build healthier digital habits. Because of this, we rely heavily on Apple’s Screen Time / DeviceActivity / FamilyControls, ManagedSettings APIs – and unfortunately, we’re seeing increasingly severe issues in production that directly impact hundreds of thousands of real iOS users. During the past years, we have been busy filing dozens of feedback requests for different Screen Time issues – and there has been no response from Apple at all. Developer Relations might be able to "confirm" that the bugs are present and that they ended up with the right team – but they are never addressed, neither are workarounds provided. Instead, the situation gets worse and worse. iOS 26 introduced a series of heavy regressions (which have been reported via Apple’s official bug report tool "Feedback Assistant" on iOS 26 beta 1 in June 2025 – and have not been addressed 10 Months later). This is very frustrating for us as developers, but also for our end-users who run into these issues every day. In the end this impacts our ability to build an amazing product and hurts revenue (which affects both us and Apple). 1. DeviceActivity thresholds are not firing at all This affects both: our app’s usage of the API and Apple’s own Screen Time limits Radars: FB22304617, FB20526837, FB15491936, FB12195437, FB15663329, FB18198691, FB18289475, FB19827144 2. Screen Time usage data is clearly corrupted Websites showing hundreds of hours per week Up to ~20 hours per day of usage reported for a single domain Radars: FB22304617, FB17777429, FB18464235 3. DeviceActivity thresholds reaching threshold immediately Newly introduced with iOS 26 Reported on iOS 26 beta 1 in June No response so far / no workaround DeviceActivity calls didReachThreshold immediately after creating the DeviceActivityEvent – instead of waiting till the defined threshold is actually reached. Radars: FB13696022, FB18351583, FB21320644, FB18927456, FB18061981 4. Randomly Randomizing ApplicationTokens From time to time, and without consistency, Screen Time suddenly provides new, random, unknown tokens to my app in the ShieldConfigurationDataSource and ShieldActionDelegate. This has been reported on many times before here on the dev forms, many many years back already: https://forums.developer.apple.com/forums/thread/756440 https://forums.developer.apple.com/forums/thread/758325 https://forums.developer.apple.com/forums/thread/758325?answerId=793267022#793267022 Radars: FB14082790 and FB18764644 5. Moving Tokens from one ManagedSettingsStore to Another Removing an ApplicationToken from one SettingsStore and then adding it to another while the target app remains in foreground leads to the re-use of the ShieldConfiguration. Which can be wrong in many scenarios. It is not possible to request a re-request of the ShieldConfiguration in that scenario. Radar: FB14237883 6. Unable to Open Parent App (one sec) from Shield Many times, when a target app is blocked by a shield, the user wants to perform some action (e.g. to unlock more time for the target app via an intervention). That means, that somehow I have to forward the user from a ShieldActionDelegate back into my target app. Unfortunately, there’s no API for that. Many apps on the App Store rely on private API to achieve that, but that’s too risky for a popular app like one sec. Radar: FB15079668 7. Unable to Open Target App from an ApplicationToken When a user has completed an intervention within one sec, and they indend to to continue to the target app, there is no way that one sec can open the target app just from the token alone. Sure, there are URL schemes, but that means the user has to manually assign URL schemes to each ApplicationToken. That is not a very user friendly process (and in many cases impossible, because not every app registers URL schemes). It would be better if there was a way that my app could open a target app directly from an ApplicationToken, e.g. via an AppIntent that can be run on a button press. This way, the selected apps would remain fully private while still offering advanced functionality: struct OpenTargetAppIntent: AppIntent, OpenAppFromApplicationTokenIntent { func perform() { return .result(openAppFromApplicationToken: applicationToken) } } Radar: FB15500695 Summary Thanks a lot for taking the time to read my feedback. If you have any questions, please feel free to reach out to me any time. I’m always happy to provide more details, logs, and steps to reproduce in my radars / feedback requests or in-person in Cupertino. It would be extremely helpful if someone from the Screen Time / DeviceActivity engineering team could: Take a look at the listed radars. Work on bug fixes and be transparent about when fixes will be shipped. Provide workarounds in the meantime. We genuinely want to build great, reliable experiences on top of Screen Time – but in its current state, it’s becoming very difficult to depend on. – Frederik

Hi everyone, I’m running into an issue with my app submission. It has been stuck in Waiting for Review for over a month now, and there has been no progress at all. I’ve already contacted support twice, but unfortunately haven’t received any response. Has anyone experienced something similar? Are there any ways to speed up the review process or escalate the situation? I’d really appreciate any advice or shared experiences. Thanks in advance!

Hello, my Apple Developer Program enrollment has been pending for 5 days - I am not able to reach support cause the don't answer phone. I have completed all steps and payment - have my invoice. . Could you help somehow?

I want to address the missing or incomplete DirectX calls from D3DMetal and Game Porting Toolkit 3. These missing calls have in part caused issue with our porting process and we are reconsidering. Missing or Incomplete Calls DXGI_FEATURE_PRESENT_ALLOW_TEARING — IDXGIFactory5::CheckFeatureSupport — this calls has to do with how VSync is handled and some modern games require it to initialize. Currently D3DMetal return 0 maybe by design but most likely because it’s not integrated. Adding a stub that returns 1 can fix this. I’m my use case I simply Noped the check and forced it to continue. D3D12_FEATURE_D3D12_OPTIONS2.DepthBoundsTestSupported — this call is also not present. Which causes games to not initialize rendering. Thankfully this was fixed by once again skipping the check. But this is essential for water rendering. This could be one reason currently water is not rendering in our game. IDXGIOutput6::GetDesc1().ColorSpace — returns DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 (SDR) on external HDR compatible displays. We were able to fix this by forcing HDR to be enabled. It should return HDR support. These calls may exist but they need to be updated to return the correct values. Specifically for depth bound test you can reference MoltenVK which sets it up on top of Metal since it’s not a native feature. The water issue could be also an issue with how the shaders are compiled. But I’m unable to check because of the closed source nature of GPTK and its debuggers. What is a better way we can debug our game to see why the water isn’t rendering. Does D3DMetal have some debug options or something similar? Feedback Number FB22330617 - Missing DirectX Calls for Tearing and Depth Bound Test in D3DMetal and GPTK 3 We hope these issues are resolved quickly because we were thinking of a simultaneous release with our Windows version, but we can't ship with such large bugs.

For the past couple of days having a problem with Xcode 26.4. When I try to upload an archive to App Store Connect, it gets stuck on "Uploading". I see the progress bar about 70% full, and a "Preparing to upload xxxx.ipa" label below. Letting it sit overnight, restarting Xcode, machine, etc. and the same result. Anybody else seeing?

FoundationModels framework, macOS Tahoe 26.4.1, MacBook Air M4. Loading a LoRA adapter via SystemLanguageModel.Adapter(fileURL:) leaks ~100MB of APFS disk space per invocation. The space is permanently consumed at the APFS block level with no corresponding file. Calls without an adapter show zero space loss. Running ~300 adapter calls in a benchmark loop leaked ~30GB and nearly filled a 500GB drive. The total unrecoverable phantom space is now ~239GB (461GB allocated on Data volume, 222GB visible to du). Reproduction: Build a CLI tool that loads a .fmadapter and runs one generation Measure before/after with df and du: Before: df free = 9.1 GB, du -smx /System/Volumes/Data = 227,519 MB After: df free = 9.0 GB, du -smx /System/Volumes/Data = 227,529 MB df delta: ~100 MB consumed du delta: +10 MB (background system activity) Phantom: ~90 MB -- no corresponding file anywhere on disk Without --adapter (same code, same model): zero space change du was run with sudo -x. Files modified during the call were checked with sudo find -mmin -10 -- only Spotlight DBs, diagnostics logs, and a 7MB InferenceProviderService vocab cache. Nothing accounts for the ~90MB loss. fs_usage shows TGOnDeviceInferenceProviderService writing hundreds of APFS metadata blocks (RdMeta on /dev/disk3) per adapter call. Recovery Mode diagnostics: fsck_apfs -o -y -s: no overallocations, bitmap consistent (118.6M blocks counted = spaceman allocated) fsck_apfs -o -y -T -s: B-tree repair found nothing fsck_apfs -o -y -T -F -s: "error: container keybag (39003576+1): failed to get keybag data: Inappropriate file type or format. Encryption key structures are invalid." No fsck_apfs flag combination reclaims the space. The leaked blocks are validly allocated in the APFS bitmap and referenced in the extent tree, but not associated with any file visible to du, find, stat, or lsof. Has anyone else observed space loss when using SystemLanguageModel.Adapter? If I am missing something obvious, I would love to know.

Environment: Xcode 26.3 RC macOS 26.3 (25D125) (Apple Silicon / arm64) Setup: Xcode > Settings > Intelligence > Claude Agent: Signed In (account status shows "Signed In") Model: Default Steps to reproduce: Open a new chat in Xcode's Coding Assistant Select "Claude Agent" from the agent dropdown (instead of "Claude Sonnet 4.5") Send any message (e.g. "HI") Expected result: Claude Agent responds normally. Actual result: The message is sent but immediately returns the error: "Your request couldn't be completed." 🚩I have an active Claude Code subscription with remaining usage. Running claude in Terminal works perfectly, confirming the subscription and quota are valid.

We are seeing an issue after updating iPads to iPadOS 26.4 where cellular service is lost until network settings are reset. Environment: Devices managed via Apple Business Manager and Microsoft Intune Carrier: Verizon Confirmed affected devices: iPad (9th generation) eSIM Behavior: After update, device shows no cellular service No prompt to re-activate or re-add the cellular plan The plan appears to still be present on the device Workaround observed: Resetting Network Settings restores service Notes: This does not appear to be a provisioning issue (no need to re-add eSIM) Behavior suggests the cellular/eSIM state may not be initializing correctly after update Toggling Cellular or Airplane mode has not yet been tested for service restoration. We have not yet confirmed whether devices using a physical SIM are affected Still gathering data on scope across additional iPad models Additional observation: We have not observed this behavior on iPhones (e.g., iPhone 16 on iOS 26.4 with LTE remains unaffected) Has anyone else observed similar behavior on iPadOS 26.4, particularly on managed devices or eSIM configurations?

I’m developing a share extension for iOS 26 with Xcode 26. When the extension’s sheet appears, it always shows a full white background, even though iOS 26 introduces a new “Liquid Glass” effect for partial sheets. Expected: The sheet background should use the iOS 26 glassmorphism effect as seen in full apps. Actual behavior: Custom sheets in my app get the glass effect, but the native system sheet in the share extension always opens as plain white. Steps to reproduce: Create a share extension using UIKit Present any UIViewController as the main view Set modalPresentationStyle = .pageSheet (or leave as default) Observe solid white background, not glassmorphism Sample code: swift override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear preferredContentSize = CGSize(width: UIScreen.main.bounds.width, height: 300) } Troubleshooting attempted: Tried adding UIVisualEffectView with system blur/materials Removed all custom backgrounds Set modalPresentationStyle explicitly Questions: Is it possible to enable or force the Liquid Glass effect in share extensions on iOS 26? Is this a limitation by design or a potential bug? Any workaround to make extension sheet backgrounds match system glass appearance?

Hi, I’m requesting the Family Controls distribution capability for my app and its extensions. The main app bundle ID was approved within 1 day. However, I later realized the associated extensions (Shield Configuration, Device Activity Monitor, Device Activity Report) also require separate approval. I submitted those extension requests 4 days ago, and they are still in "Submitted" with no updates. This is currently blocking me from proceeding with TestFlight/App Store submission, since the extensions require the approved capability. Is this delay expected for extension bundle IDs? Thanks for your help.

I click in App Store Connect to view my app but there is a dns error. Tried Brave and Safari but have the same result. I just did update my Mac to Tahoe 26.4 . This site can’t be reached olympus-int.itunes.apple.com’s DNS address could not be found. Diagnosing the problem. DNS_PROBE_POSSIBLE

[Also submitted as FB20756013] A popoverTip does not display for toolbar menu buttons in iOS 26.1 (23B5073a). The same code displays tips correctly in iOS 18.6. The issue occurs both in the simulator and on a physical device. Repro Steps Build and run the Sample Code below on iOS 26.1. Observe that the popoverTip does not display. Repeat on iOS 18.6 to confirm expected behavior. Expected popoverTips should appear when attached to a toolbar menu button, as they do in iOS 18.6. Actual No tip is displayed on iOS 26.1. System Info macOS 15.7.1 (24G231) Xcode 26.1 beta 3 (17B5045g) iOS 26.1 (23B5073a) Screenshot Screenshot showing two simulators side by side—iOS 18.6 on the left (tip displayed) and iOS 26.1 on the right (no tip displayed). Sample code import SwiftUI import TipKit struct PopoverTip: Tip { var title: Text { Text("Menu Tip") } var message: Text? { Text("This tip displays on iOS 18.6, but NOT on iOS 26.1.") } } struct ContentView: View { var tip = PopoverTip() var body: some View { NavigationStack { Text("`popoverTip` doesn't display on iOS 26.1 but does in iOS 18.6") .padding() .toolbar { ToolbarItem(placement: .topBarTrailing) { Menu { Button("Dismiss", role: .cancel) { } Button("Do Nothing") { } } label: { Label("More", systemImage: "ellipsis") } .popoverTip(tip) } } .navigationTitle("Popover Tip Issue") .navigationBarTitleDisplayMode(.inline) } } }

[Submitted as FB21961572] When navigating from a tile in a scrolling LazyVGrid to a child view using .navigationTransition(.zoom) and then returning, the source tile can lag behind the rest of the grid if scrolling starts immediately after returning. The lag becomes more pronounced as tile content gets more complex; in this simplified sample, it can seem subtle, but in production-style tiles (as used in both of my apps), it is clearly visible and noticeable. This may be related to another issue I recently filed: Source item disappears after swipe-back with .navigationTransition(.zoom) CONFIGURATION Platform: iOS Simulator and physical device Navigation APIs: matchedTransitionSource + navigationTransition(.zoom) Container: ScrollView + LazyVGrid Sample project: ZoomTransition (DisappearingTile).zip REPRO STEPS Create a new iOS project and replace ContentView with the code below. Run the app in sim or physical device Tap any tile in the scrolling grid to navigate to the child view. Return to the grid (back button or edge swipe). Immediately scroll the grid. Watch the tile that was just opened. EXPECTED All tiles should move together as one coherent scrolling grid, with no per-item lag or desynchronization. ACTUAL The tile that was just opened appears to trail behind neighboring tiles for a short time during immediate scrolling after returning. MINIMAL CODE SAMPLE import SwiftUI struct ContentView: View { @Namespace private var namespace private let tileCount = 40 private let columns = [GridItem(.adaptive(minimum: 110), spacing: 12)] var body: some View { NavigationStack { ScrollView { LazyVGrid(columns: columns, spacing: 12) { ForEach(0..<tileCount, id: \.self) { index in NavigationLink(value: index) { RoundedRectangle(cornerRadius: 16) .fill(color(for: index)) .frame(height: 110) .overlay(alignment: .bottomLeading) { Text("\(index + 1)") .font(.headline) .foregroundStyle(.white) .padding(10) } .matchedTransitionSource(id: index, in: namespace) } .buttonStyle(.plain) } } .padding(16) } .navigationTitle("Zoom Transition Grid") .navigationSubtitle("Open tile, go back, then scroll immediately") .navigationDestination(for: Int.self) { index in Rectangle() .fill(color(for: index)) .ignoresSafeArea() .navigationTransition(.zoom(sourceID: index, in: namespace)) } } } private func color(for index: Int) -> Color { let hue = Double(index % 20) / 20.0 return Color(hue: hue, saturation: 0.8, brightness: 0.9) } } SCREEN RECORDING

iOS 26.4系统上，我们发现三个问题： 1.调用了finishTransaction接口，但是在App重新启动后，[SKPaymentQueue defaultQueue].transactions仍然会有这笔订单。 2.支付完成后，[[NSBundle mainBundle] appStoreReceiptURL]]，拿到的票据解析出来里面的商品是空的，需要延迟2秒钟左右在调用[[NSBundle mainBundle] appStoreReceiptURL]]才能获取有效票据。 3.支付完成后，如果用户没有点击最后弹出的确认弹框，等待5秒钟，系统会自己回调 - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions; 代理方法。正常应该是用户点击了最后弹出的确认弹框，在回调- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions;方法。 我们在苹果开发者论坛上面找到其他开发者反馈的类似问题，链接如下： https://developer.apple.com/forums/thread/817700 https://developer.apple.com/forums/thread/792437?answerId=849557022#849557022 https://developer.apple.com/forums/thread/817834 https://developer.apple.com/forums/thread/817706 https://developer.apple.com/forums/thread/818586 我们有大量用户升级到了26.4系统，这对于我们造成了巨大的困扰，我们需要你们的帮助，感谢！

Hey! I am new to the apple developer enrolment program and it seemed alright to me when I started to fill all of the spaces, but when it lead to the paying process I started to have an issue. The issue is that I fill the spaces to pay, but I never receive the email for actually the bill, so I do not pay and receive the enrol. How do I fix it?

We are observing a regression in iOS 26.4 related to AppIntents, specifically AppEntity + EntityQuery. When using a single AppIntent with a parameter backed by AppEntity and EntityQuery, the query correctly returns multiple entities (e.g. ~50 items). However, in the Shortcuts app UI, only a single item is displayed. This behavior differs from iOS 26.3 and earlier, where all returned entities are correctly displayed in the selection list. This issue significantly impacts dynamic configuration use cases where AppEntity is used to represent server-driven or runtime-generated options.(The screenshots below illustrate the difference in shortcut presentation between iOS 26.4 and earlier versions.)

Description Enterprise users are experiencing VPN resource access failures after upgrading to macOS Tahoe. Investigation indicates that configd (specifically IPMonitor) is incorrectly re-ranking network interfaces after a connectivity failure with probe server. This results in DNS queries routing through the physical network adapter (en0) instead of the VPN virtual adapter, even while the tunnel is active. This behaviour is not seen in previous macOS versions. Steps to Reproduce: Connect to an enterprise VPN (e.g., Ivanti Secure Access). Trigger a transient network condition where the Apple probe server is unreachable. For example make the DNS server down for 30 sec. Observe the system routing DNS queries for internal resources to the physical adapter. Expected Results The: VPN virtual interface should maintain its primary rank for enterprise DNS queries regardless of the physical adapter's probe status. Actual Results: IPMonitor detects an UplinkIssue, deprioritizes the VPN interface, and elevates the physical adapter to a higher priority rank. Technical Root Cause & Logs: The system logs show IPMonitor identifying an issue and modifying the interface priority at 16:03:54: IPMonitor Detection: The process identifies an inability to reach the Apple probe server and marks en0 with an advisory: Log snippet 2026-01-06 16:03:53.956399+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] configd[594] SetInterfaceAdvisory(en0) = UplinkIssue (2) reason='unable to reach probe server' Interface Re-ranking: Immediately following, IPMonitor recalculates the rank, placing the physical service ID at a higher priority (lower numerical rank) than the VPN service ID (net.pulsesecure...): Log snippet 2026-01-06 16:03:53.967935+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 0. en0 serviceID=50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 addr=192.168.0.128 rank=0x200000d 2026-01-06 16:03:53.967947+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 1. en0 serviceID=net.pulsesecure.pulse.nc.main addr=192.168.0.128 rank=0x2ffffff 3.Physical adapter Is selected as Primary Interface: 2026-01-06 16:03:53.968145+0100 localhost configd[594]: [com.apple.SystemConfiguration:IPMonitor] 50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 is the new primary IPv4 configd[594]: 50CD9266-B097-4664-BFE6-7BAFCC5E9DC0 is the new primary DNS Packet Trace Evidence Wireshark confirms that DNS queries for enterprise-specific DNS servers are being originated from the physical IP (192.168.0.128) instead of the virtual adapter: Time: 16:03:54.084 Source: 192.168.0.128 (Physical Adapter) Destination: 172.29.155.115 (Internal VPN DNS Server) Result: Connectivity Failure (Queries sent outside the tunnel)

We have an VoiP application, our application can be configured to amplify the PCM samples before feeding it to the Player to achieve volume gain at the receiver. In order to support this, We follow as below. If User has configured this Gain Settings within application, Application applies the amplification for the samples to introduce the gain. Application will also set the AVAudioSessionCategory to AVAudioSessionCategoryPlayback Provided the User has chosen the output to Speaker. This settings was working for us but we see there is a difference in behaviour w.r.t Volume Level System Settings between OS 26.3.1 and OS 26.4 When user has chosen earpiece as Output, then we will set the AVAudioSessionCategory to AVAudioSessionCategoryPlayAndRecord. User would have set the volume level to minimum. When user will change the output to Speaker, then we will set the AVAudioSessionCategory to AVAudioSessionCategoryPlayback. The expectation is, the volume level should be of AVAudioSessionCategoryPlayback what was set earlier instead we are seeing the volume level stays as minimum which was set to AVAudioSessionCategoryPlayAndRecord Could you please explain about this inconsistency w.r.t Volume level.