İOS 26 beta battery %1

Starting in iOS 26.4, PushKit has introduced a new didReceiveIncomingVoIPPushWithPayload delegate, making it explicit whether or not an app is required to report a call for any given push. The new delegate passes in a PKVoIPPushMetadata object which includes a mustReport property. We have not documented the exact criteria that will cause a mustReport to return false, but those criteria currently include: The app being in the foreground at the point the push is received. The app being on an active call at the point the push is received. The system determines that delivery delays have made the call old enough that it may no longer be viable. When mustReport is false, apps should call the PushKit completion handler (as they previously have) but are otherwise not required to take any other action. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I'm developing a turn-based Messages game extension and experiencing a persistent issue on iPad where tapping on message bubbles does not reliably trigger lifecycle callbacks after the extension has been used once. The Problem: On iPad, after a player: Opens the extension by tapping a game message Takes their turn (plays a card) Sends the updated game state as a new message Extension collapses When the opponent sends their response and the player taps on the new message bubble, the extension often does not open. The didSelect(_:conversation:) method is not called. The user must refresh the conversation by scrolling away and back or reopening the Messages App before tapping works again. This works perfectly on iPhone - every tap on a message bubble reliably triggers didSelect and opens the extension. What I've Tried: I've implemented every lifecycle method and workaround I could find: swiftoverride func willBecomeActive(with conversation: MSConversation) { super.willBecomeActive(with: conversation) if let mess

I'm facing an issue with Xcode Cloud. Every branch I push to my GitLab repository is not appearing as selectable when I try to create a build with my workflow. Additionally, if I try to update the workflow from Xcode, it crashes every time I save the changes. Any help would be appreciated. Translated Report (Full Report Below) ------------------------------------- Process: Xcode [32110] Path: /Applications/Xcode.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 26.2 (24553) Build Info: IDEApplication-24553000000000000~2 (17C52) Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.apple.dt.Xcode [58945] User ID: 501 Date/Time: 2026-02-19 13:11:54.9987 -0600 Launch Time: 2026-02-19 13:03:37.7725 -0600 Hardware Model: Mac16,5 OS Version: macOS 26.2 (25C56) Release Type: User Crash Reporter Key: 61D7E2DA-E724-EFE2-6A01-25079BFCA2D1 Incident Identifier: B3D4A277-7CB5-4696-A00F-057929659F41 Sleep/Wake UUID: 2D4F6C41-716C-4B47-8D40-27FD2D74A8AE Time Awake Sin

Hi everyone, I'm currently experiencing an unusually long time for my app to be reviewed. I'm curious to know if other people are experiencing the same problem, since I don't remember it ever taking this long for a submission to be reviewed. I first submitted my app for review on February 9th, and resubmitted it on February 16th (one week later), requesting an expedited review. On the 18th, I contacted support (2 days ago). I still haven't had any changes to my submission, and haven't heard from support either. A client of mine has had their submissions reviewed as usual. I'm not sure if there's a specific issue with mine that's causing the delay. I haven't found any phone numbers I can call, and I'm quite anxious about this because we are trying to fix a critical bug, and all our campaigns are on hold until we fix this. Has anyone experienced this before? How did you get it resolved? Any help is greatly appreciated 😊

Hi, we are setting up Apple Pay on our website which sells only digital goods. We don't collect a shipping address because we aren't shipping anything. We want to use the user's billing address in order to show them the total amount (including sales tax) before they authorize the purchase. However, it seems that the billing address isn't always provided by Apple Pay before the payment is authorized. With Apple Pay, what is the recommended way of acquiring the user's billing address before they authorize the purchase? -- More details about our setup: We are using the Apple Pay JS API. In createPaymentRequest, we specify requiredBillingContactFields: ['postalAddress'], but per the docs, the address is provided after the user authorizes the transaction. That is too late for us because we want to show the sales tax before the user authorizes the purchase. We have attempted to work around this by getting the billing contact details in session.onpaymentmethodselected. For example: session.onpaymentmethodselected =

My application provides a unique feature for MacOS 26+ users, while keeping legacy for other versions (12.4+). So I aim to provide two help books localized package, depending on MacOS' version of the running computer. I designed two help bundles, with their own Info.plist files (identifiers, default filename…) and I've made multiple checks to verify that all their settings are correct and different when needed. As an app's info.plist can deal only with one Help Book, my application delegate registers both in applicationDidFinishLaunching: using: [[NSHelpManager sharedHelpManager] registerBooksInBundle:[NSBundle mainBundle]]; In Interface Builder, the help menu item is connected to the application delegate's showHelp: method to set the correct help package. The code in this method is: if (@available(macOS 26.0,*)){ helpbook = @fr.myapp.updated.help; } else { helpbook = @fr.myapp.legacy.help; } [[NSHelpManager sharedHelpManager] openHelpAnchor:@index inBook:helpbook]; The problem is that despi

The scenario is, in a macOS app (primarly), main thread needs to wait for some time for a certain 'event'. When that event occurs, the main thread is signaled, it gets unblocked and moves on. An example is, during shutdown, a special thread known as shutdown thread waits for all other worker threads to return (thread join operation). When all threads have returned, the shutdown thread signals the main thread, which was waiting on a timer, to continue with the shutdown flow. If shutdown thread signals the main thread before the later's timer expires, it means all threads have returned. If main thread's timer expires first, it means some threads have failed to join (probably stuck in infinite loop due to bug, disk I/O etc.). This post is to understand how main thread can wait for some time for the shutdown thread. There are two ways: a) dispatch_semaphore_t b) pthread conditional variable (pthread_cond_t) and mutex (pthread_mutex_t). Expanding a bit on option (b) using conditional variable and mutex: // This me