İOS 26 beta battery %1

Thanks again for reporting the issue. It seems that the issue is impacting the community, but I haven't seen any feedback report ID posted here. Do folks have any feedback report yet? If not, would you mind to file one and share your report ID here? I understand that filing an actionable feedback report takes time, but that will help. I am trying to capture the issue, and yet, my current configuration, Xcode 26.2 (17C52) + iPhone 17 Pro with iOS 26.3 (23D127) + Apple Watch series 10 with watchOS 26.3 (23S620), does work for me. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks for your post as it seems very well written explaining the issue with the code in the end, but following your code as you just looking at a subscription is difficult to understand what is the cause of the issue. I’m not an expert in subscriptions but I wonder looking at your code if could be a Swift's concurrency issue as you are not setting the for await result in Transaction.updates ? I think the problem may b3e that your current handler, though running on @MainActor, processes transactions sequentially within that single loop. If processing takes even a few milliseconds, new updates can arrive and pile up behind the currently processing one, potentially leading to them being handled more than once if logic isn't airtight? I do believe by encapsulating your logic within an actor and using a set for deduplication, you create a predictable and thread-safe environment for handling StoreKit's asynchronous transaction updates, effectively solving the duplicate problem you've encountered. Somethin

Just to share a bit more color, the error happens when Core Data + CloudKit schedules a new export task when another one is still in progress. In this situation, the scheduling will fail, and the system will drop the new task. In Core Data + CloudKit, however, I don't think this is an issue, because NSPersistentCloudKitContainer will schedule another export task next time when it detects something yet to export, which can happen some time after it detects that a previous export task failed, or that a new change on the Core Data store was made, and so the data should eventually be exported. You should be able to observe the behavior by capturing and analyzing a sysdiagnose. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I’m experiencing something very similar. I paid the £79 enrollment fee three days ago (17th Feb) and received both the receipt and payment confirmation email. However, there is no visible indication in my account that the enrollment is under review or in progress — the portal does not show any status update. Because of this lack of status information, I mistakenly initiated a second enrollment, assuming the first one had not gone through. I later withdrew the second application and immediately received a confirmation email for that withdrawal. However, I never received any confirmation that my original enrollment is being processed — only the payment receipt. This is currently blocking my app release, as I’m ready to publish and have already launched on the Play Store. Has anyone found a reliable way to get clarity on enrollment status or escalate this? Any guidance would be greatly appreciated.

I imagine this is working as intended, not a bug. It’s the top of the keyboard. The documentation for UIInputView states The UIInputView class is designed to match the appearance of the standard system keyboard when used as an input view with a responder. You should avoid applying a background to the input view (blue in this example) to avoid covering up the system effects. This is how a “proper” input view + input accessory view looks on iOS 26:

It is not fixed on macOS 26.4 beta or Xcode 26.4 beta. I believe I have found a workaround however: Set this value in Terminal and then restart Xcode and run Update to latest package versions. defaults write com.apple.dt.Xcode IDEPackageSupportUseBuiltinSCM 1 I have verified this works for me with Xcode 26.3 and 26.4 on macOS 26.4 beta after previously having the issue above.

[quote='876733022, disinghal, /thread/811887?answerId=876733022#876733022, /profile/disinghal'] URL Session is calling a public endpoint. [/quote] Right, but you’ve set up your on-demand rules to say that everything generates demand. It’d be interesting to see what happens if you configure your on-demand rules to only generate demand what you load a URL that’s behind the VPN. I suspect it’ll work consistently, but if you find that’s not the case then that’d be an interesting datapoint. [quote='876733022, disinghal, /thread/811887?answerId=876733022#876733022, /profile/disinghal'] It happens intermittently. [/quote] Fair enough. But that doesn’t really contradict the position I explained above. You’ve set yourself up for failure and that you only fail in some cases. That’s a win, right? (-: Seriously though, I don’t think I’m going to be able to help you further here. You are clearly exploring the limits of what’s possible. If you want to make the case that this should work, I recommend that you do that direct