The production macOS build is showing severe performance problems, while Mac_Dev performs normally. Observed behavior in production Mac build: Issue board scrolling becomes inconsistent or nearly unusable Changing an issue status in detail view is very slow Scrolling the status menu/options can be slow Typing in issue description/notes fields becomes sluggish Dragging issues between milestones/statuses on the board can lag badly Observed behavior in Mac_Dev: Board scrolling is smooth Status changes are immediate Typing in description fields is responsive Drag/drop between milestones works well Important comparison: Mac_Dev appears to run against an isolated local SwiftData store Production Mac app uses the normal CloudKit-backed store Because the same UI is fast in Mac_Dev, this does not look like a pure rendering problem Most likely cause is production store / CloudKit sync churn amplifying existing SwiftUI invalidation and save behavior Current hypothesis: The production app is saving or observing live Issue mutations too aggressively Detail view edits and some quick actions may be causing repeated saves / broad view invalidation Cloud-backed persistence likely makes the problem much worse than the isolated dev store The UI architecture may still need cleanup, but the production data lane is likely a major factor Any help in understanding how best to address this would be helpful.

Hi, We are currently in the process of getting an custom iAP2 device communicating via USB-C. We have been using the 'EADemo' app as a test app to ensure full function before certification. Currently, the device completes the authentication and identification successfully. The device appears within the 'EADemo' app, and we are able to select it and see the available protocol. Selecting the protocol sends the EAStartSession command to the accessory and we ACK it. This is where the issues begin. Attempting to send either a string or hex packet results in nothing being sent. The app does not appear to attempt to send a packet when these are pressed. The 'EADemo' app also does not increment its receive counter when the accessory sends an EA packet, but we do receive the ACK from the device. This indicates the device is receiving the packet, but not processing it in app. Sending the EASessionStatus from the accessory with a status of okay does not change the behavior. Sending the EASessionStatus packet from the accessory with a status of closed results in the device sending an EAStopSession packet. The issue does not appear to be with the accessory or the underlying transport layer. Previous attempts to contact MFi support resulted in them referring me to developer support. Are there any known issues within the 'EADemo' app that we should know about/and or need to fix? Does Apple have any other EA example application? Are there any other publicly avalilbe EA examples that Apple would recommend us trying? Thanks, Mike

I’m working on an iOS Network Extension where a NEPacketTunnelProviderconfigures a local HTTP/HTTPS proxy usingNEPacketTunnelNetworkSettings.proxySettings. Per NEProxySettings.exceptionList docs: If the destination host name of an HTTP connection matches one of these patterns then the proxy settings will not be used for the connection. However, I’m seeing two distinct issues: Issue A (exception bypass not working): HTTPS traffic to a host that matches exceptionList still reaches the proxy. Issue B (domain-scoped proxy not applied): When matchDomains is set to match a specific domain (example: ["googlevideo.com"]), I still observe its traffic in some apps is not proxied. If I remove the domain from matchDomains, the same traffic is proxied. Environment OS: iOS (reproduced with 26.4 and other versions) Devices: Reproduced with several iPhones (likely iPads as well) Xcode: 26.3 Extension: NEPacketTunnelProvider Minimal Repro (code) This is the minimal configuration. Toggle between CONFIG A / CONFIG B to reproduce each issue. import NetworkExtension final class PacketTunnelProvider: NEPacketTunnelProvider { override func startTunnel( options: [String : NSObject]? = nil, completionHandler: @escaping (Error?) -> Void ) { let proxyPort = 12345 // proxy listening port let settings = NEPacketTunnelNetworkSettings(tunnelRemoteAddress: "8.8.8.8") let proxySettings = NEProxySettings() proxySettings.httpEnabled = true proxySettings.httpsEnabled = true proxySettings.httpServer = NEProxyServer(address: "1.2.3.4", port: proxyPort) // proxy listening address proxySettings.httpsServer = NEProxyServer(address: "1.2.3.4", port: proxyPort) // proxy listening address // CONFIG A: proxy all domains, but exclude some domains // proxySettings.matchDomains can be set to match all domains // proxySettings.exceptionList = ["*.cdninstagram.com", "cdninstagram.com"] // CONFIG B: proxy only a specific domain // proxySettings.matchDomains = ["googlevideo.com"] settings.proxySettings = proxySettings setTunnelNetworkSettings(settings) { error in completionHandler(error) } } } Repro steps Issue A (exceptionList bypass not working) Enable the VPN configuration and start the tunnel with CONFIG A (exceptionList = ["*.cdninstagram.com", "cdninstagram.com"]). Open the Instagram app to trigger HTTPS connections to *.cdninstagram.com Inspect proxy logs: cdninstagram.com traffic is still received by the proxy. Safari comparison: If I access URLs that trigger the same *.cdninstagram.com hosts from Safari, it can behave as expected. When the traffic is triggered from the Instagram app, the excluded host still reaches the proxy as CONNECT, which is unexpected. Issue B (matchDomains not applied for YouTube traffic) Start the tunnel with CONFIG B (matchDomains = ["googlevideo.com"]). Open the YouTube app and start playing a video (traffic typically targets *.googlevideo.com). Inspect proxy logs: googlevideo.com traffic is not received by the proxy. Remove the host from matchDomains and observe that googlevideo.com traffic is received by the proxy. Safari comparison: If I access a googlevideo.com host from Safari while matchDomains = ["googlevideo.com"], it behaves as expected (proxied). In contrast, the YouTube app’s googlevideo.com traffic is not proxied unless I match all domains. Expected Issue A Connections to *.cdninstagram.com in the Instagram app should not use the proxy and should not reach the local proxy server. Issue B With matchDomains = ["googlevideo.com"], traffic to *.googlevideo.com (YouTube video traffic) should be proxied and therefore reach the local proxy. Actual Issue A The local proxy still receives the request as: CONNECT scontent-mad1-1.cdninstagram.com:443 HTTP/1.1 So the bypass does not happen. Issue B With matchDomains = ["googlevideo.com"], I still observe googlevideo.com traffic in the YouTube app that is not delivered to the proxy. When all traffic is proxied, the same traffic is delivered to the proxy.

I’m trying to submit the first release of my iOS app together with the app’s first consumable in-app purchases, and I’m stuck in what looks like an App Store Connect state issue. My app was already rejected by App Review because the in-app purchases did not appear inside the app when the reviewer opened the paywall. Current setup: First app release Current app version page: iOS App Version 1.0.2 Current attached build: 5 App has never been released before 4 consumable IAPs: com.glowup.credits.100 com.glowup.credits.500 com.glowup.credits.1000 com.glowup.credits.2500 What I see in App Store Connect: All 4 IAPs show Waiting for Review On the iOS App Version 1.0.2 page, the In-App Purchases and Subscriptions section does not appear at all Because of that, I cannot explicitly select or attach the IAPs from the version page What I’ve already done: Uploaded a new build and attached build 5 to version 1.0.2 Removed my local StoreKit configuration file so the app now uses live App Store / StoreKit only Confirmed RevenueCat is configured correctly and sees the offering/packages RevenueCat logs show the products exist remotely, but StoreKit cannot fetch any live products and returns an “offerings empty / none of the products could be fetched” type error RevenueCat also reports the products are still in WAITING_FOR_REVIEW My questions: If the IAPs already show Waiting for Review, are they automatically linked to the current app submission? Is it expected that the In-App Purchases and Subscriptions section can disappear from the app version page in this state? For a first-release app that was already rejected, is attaching a new build and clicking Update Review enough, or is there another step required to associate the IAPs with the resubmission? Has anyone seen App Review reject an app for missing IAPs while the IAPs were still pending review and not yet fetchable from StoreKit? Any guidance from someone who has dealt with this exact first-release + first-IAP submission flow would help a lot.

Development environment: Xcode 26.4, macOS 26.3.1 Run-time configuration: iOS 18.7.6 and higher We have an application running on supervised devices, with an MDM profile typically deployed via jamf. The profile enables a Content Filter, with the two flags "Socket Filter" and "Browser Filter" set to true. On the device side, we implement the content filter as a network extension via: a class FilterDataProvider extending NEFilterDataProvider, a class FilterControlProvider extending NEFilerControlProvider. For the record, the FilterDataProvider overrides the handle*() methods to allow all traffic; the handleNewFlow() simply reports the new connection to FilterControlProvider for analysis. Problem: some customers reported that after a reboot of their device, they would not get access to the internet for up to 60s/90s. We have not been able to reproduce the problem on our own devices. What we see is that, even with our app uninstalled, without any Content Filter, it takes roughly 20s to 25s for a device to have internet access, so we can probably consider this 20s delay as a baseline. But would you be aware of a reason that would explain the delay observed by these customers? More details: We have conducted some tests on our devices, with extended logging. In particular: we have added an internet probe in the app that is triggered when the app starts up: it will try to connect to apple.com every 2s and report success or failure, we also have a network monitor (nw_path_monitor_set_update_handler) that reacts to network stack status updates and logs the said status. A typical boot up sequence shows the following: the boot time is 7:59:05, the app starts up at 7:59:30 (manually launched when the device is ready), the probe fails and keeps failing, the content filter is initialized/started up 7:59:53 and is ready at 7:59:55, the network monitor shows that the network stack is connected (status = nw_path_status_satisfied) right after that, and the probe succeeds in connecting 2s later. In other words, internet is available about 50s after boot time, 25s after app startup (i.e. after the device is actually ready). For some customers, this 25s delay can go up to 60/90s.

I am working on a large-scale e-commerce application and we are trying to solve a specific issue regarding push notifications and user experience. We have a use case where we need to send a standard push notification to the user, but under certain local conditions on the device, we want to intercept that notification via a Notification Service Extension and suppress/drop it so it does not alert the user. We understand that the com.apple.developer.usernotifications.filtering entitlement allows a Notification Service Extension to drop notifications. However, looking at the entitlement request form, the categories seem strictly limited to: End-to-end encrypted messaging Earthquake warnings Education/learning platforms Enterprise healthcare apps My questions for the community and Apple staff: Is it possible for an e-commerce or retail app to be approved for this entitlement if we have a highly specific, valid use case that improves user experience. If this entitlement is strictly off-limits for our domain, what is the Apple-recommended architecture to achieve this? Thank you in advance for any insights or guidance!

Hello team, I have implemented sample project for URL Filtering as well as setup PIR server at backend but currently I am facing a major issue, If PIR server is re started then the app shows error code 9 every time until. and unless I disconnect and connect it back to internet

Hi everyone, I’m currently reviewing the app transfer criteria in Apple’s official documentation and came across the following statement: “Mac apps that have used the sandbox environment and share the Application Group Container Directory with other Mac apps can't be transferred.” We are planning to add Widget support to our iOS app before initiating an app transfer. As part of this, the app would likely: Enable App Sandbox Use App Groups to share data between the main app and the Widget Given this, I have a couple of questions: Although the documentation explicitly mentions Mac apps, would the same restriction for app transfer apply to iOS apps that use App Groups (e.g., for Widgets)? If iOS apps are not subject to this restriction, will the Widget extension and its associated App Group data transfer correctly along with the main app during the transfer process? We want to make sure we don’t introduce any blockers before proceeding with the transfer. Any clarification or related experience would be greatly appreciated. Thanks in advance!

I am facing an intermittent problem where iPhones are failing to pair/connect with Xcode under Xcode -> Windows -> Devices and Simulators. This happens when more than one web content filters are present, for instance, I have my web content filter (FilterSockets true, FilterGrade Firewall) and there is also Sentinel One web content filter with same configuration. Note: We are not blocking any flow from remoted / remotepairingd / core device service / MDRemoteServiceSupport etc processes. But they do get paused and resumed at times for our internal traffic verification logic. So, we are trying to understand what impact our content filter may be having on this iPhone Pairing?? If we stop either one of the filters the problem goes away. I have tracked the network traffic to the phone, and it seems to be using a ethernet interface (en5/en10) over the USB-C cable. I can see endpoints like this: localEndpoint = fe80::7:afff:fea1:edb8%en5.54442 remoteEndpoint = fe80::7:afff:fea1:ed47%en5.49813 I also see remoted process has the below ports open : sudo lsof -nP -iTCP -iUDP | grep remoted remoted 376 root 4u IPv6 0xce4a89bddba37bce 0t0 TCP [fe80:15::7:afff:fea1:edb8]:57395->[fe80:15::7:afff:fea1:ed47]:58783 (ESTABLISHED) remoted 376 root 6u IPv6 0xf20811f6922613c7 0t0 TCP [fe80:15::7:afff:fea1:edb8]:57396 (LISTEN) remoted 376 root 7u IPv6 0x2c393a52251fcc56 0t0 TCP [fe80:15::7:afff:fea1:edb8]:57397 (LISTEN) remoted 376 root 8u IPv6 0xcb9c311b0ec1d6a0 0t0 TCP [fd6e:8a96:a57d::2]:57398 (LISTEN) remoted 376 root 9u IPv6 0xc582859e0623fe4e 0t0 TCP [fd6e:8a96:a57d::2]:57399 (LISTEN) remoted 376 root 10u IPv6 0x2f7d9cee24a44c5b 0t0 TCP [fd6e:8a96:a57d::2]:57400->[fd6e:8a96:a57d::1]:60448 (ESTABLISHED) remoted 376 root 11u IPv6 0xbdb7003643659de 0t0 TCP [fd07:2e7e:2a83::2]:57419 (LISTEN) remoted 376 root 12u IPv6 0x569a5b649ff8f957 0t0 TCP [fd07:2e7e:2a83::2]:57420 (LISTEN) remoted 376 root 13u IPv6 0xa034657978a7da29 0t0 TCP [fd07:2e7e:2a83::2]:57421->[fd07:2e7e:2a83::1]:61729 (ESTABLISHED) But due to the dynamic nature of port and IPs used we are not able to decide on an effective early bypass NEFilterRule. We don't want to use a very broad bypass criteria like all link local IPs etc. Any help will be greatly appreciated.

Are there some requirements to use Notification Content Extensions other than including the target to my iOS app? I have done it, configured it to match a certain category of notifications, but my custom interface doesn’t show up. is there anything I need to configure on my main app? Is that anything that should be changed there, such as disabking its botifications handling? is there any requirement concerning the payload? I tried to disable time sensitive and content-available notifications, but it didn’t help.

I'm experiencing an issue where the App Group shared container appears to be recreated (with a new creation date) during an app update, resulting in complete loss of locally stored data. Background My app uses UserDefaults, Realm, Core Data, and CloudKit, with all local data stored in the App Group container (FileManager.containerURL(forSecurityApplicationGroupIdentifier:)). The app has been available since 2016 and has a stable user base. Starting last year, I began receiving occasional reports from users saying all their data in the app had disappeared. To investigate, I added diagnostic logging that detects when an existing user's data appears to have been reset — specifically by checking the App Group container's file system creation date, and the existence and values of expected files. What the diagnostics revealed When the issue occurs, I observe the following: The App Group container has a recent creation date, far newer than the user's first launch date The Core Data store file's creation date is also immediately after the App Group container's recreation date I write the same values to both standard UserDefaults and the App Group version (UserDefaults(suiteName:)). Only the App Group version is reset — the standard side retains historical data The standard side still holds firstLaunchDate, initialVersion, and launchCount, confirming this is not a fresh install Here is a sample diagnostic log from an affected user: appGroupContainerCreationDate: 2026-03-30T18:44:10Z firstLaunchDate: 2025/01/05 4:00 initialVersion: 10.8.0 currentAppVersion: 10.14.14 previousVersion: 10.10.0 launchCount: 44 availableStorageMB: 46646 The container creation date (2026-03-30) is clearly inconsistent with the user's first launch date (2025-01-05) and launch count (44). The container creation date is obtained with the following code: let appGroupURL = FileManager.default.containerURL( forSecurityApplicationGroupIdentifier: "group.xxx.xxx" )! let attributes = try? FileManager.default.attributesOfItem(atPath: appGroupURL.path) let containerCreationDate = attributes?[.creationDate] as? Date Scale and pattern Reports began increasing in late November last year Over 85% of affected cases are on iOS 26 Most affected devices have plenty of available storage (46GB+ in the example above) This is likely occurring during a normal app update (not a fresh install or device restore) Ruled-out hypotheses Not a fresh install — firstLaunchDate, initialVersion, and launchCount are preserved in standard UserDefaults Not a storage issue — affected users typically have tens of GBs of free space, making it unlikely that iOS purged the data due to low storage Not an app-side code change — the App Group identifier and entitlements have not been changed Not triggered by silent notifications, background tasks, or widget activity — these processes do write to the App Group container, but the recreation does not appear to occur immediately after any of these operations Questions Has anyone else observed App Group containers being recreated (new creation date, empty contents) during a standard app update? Is there a known iOS behavior or bug that could cause this, particularly on iOS 26? Are there any recommended mitigations? Any insight would be greatly appreciated. This is a data loss issue affecting real users, and I'd like to understand whether this is an iOS-level problem or something I should be handling differently on my end.

Hi everyone, I’m currently developing an iOS app using React Native and implementing consumable In-App Purchases (IAP). I'm facing an issue where getProducts returns an empty array without any error messages when testing on a TestFlight build. I have already completed the following setup: Agreements, Tax, and Banking: All forms are signed and the status is "Active" in App Store Connect. Product Configuration: The Consumable product is created in App Store Connect with the status "Ready to Submit". App Store Connect Integration: The product is correctly linked under the "In-App Purchases and Subscriptions" section of the App version. Xcode Capability: The "In-App Purchase" capability has been added to the project. Implementation: The Product ID in my React Native code (using react-native-iap) matches the ID in App Store Connect exactly. Despite these steps, the product list remains empty. Are there any hidden requirements or specific configurations for TestFlight that I might have missed? Any guidance would be greatly appreciated. Thanks!

I'm encountering a null pointer dereference crash pointing to the internals of CFNetwork library code on iOS. I'm spawning URLSessionTasks at a decently fast rate (~1-5 per second), with the goal being to generate application layer network traffic. I can reliably encounter this crash pointing to NetConnection::dequeue right after a new task has been spawned and had the resume method called. I suspect that this is perhaps a race condition or some delegate/session object lifecycle bug. The crash appears to be more easily reproduced with a higher rate of spawning URLSessionTasks. I've included the JSON crash file, the lldb stack trace, and the source code of my URLSession(Task) usage. urlsession_stuff_stacktrace.txt urlsession_stuff_source.txt urlsession_crash_report.txt

I have a FetchDescriptor that uses starts(with:) which works fine in debug builds but crashes in TestFlight and archive. For background information I'm using iCloud and model inheritance where the property being used in fetch descriptor is defined on the superclass, the fetch descriptor is for the subclass. Implementation: static func fetchDescriptor(nameStartingWith prefix: String) -> FetchDescriptor<ColorAsset> { let predicate = #Predicate<ColorAsset> { asset in asset.name.starts(with: prefix) } return FetchDescriptor<ColorAsset>(predicate: predicate) } @Model public class Asset: Identifiable { // MARK: - Properties var name: String = "" .... } @available(macOS 26.0, *) @Model public class ColorAsset: Asset { ... }

Just wondering if anyone ran into this issue. I use NetFSMountURLSync for my application with which I allow the user to use a custom path as a mount point (instead of "/Volumes"). This has worked just fine for at least a decade now, but ... since the Tahoe 26.4 "update" mounting to a custom path only generates errors. Note: Mounting to "/Volumes" works correctly (mountpoint = NIL). Since I'm unaware of any changes; is this a bug introduced by Tahoe 26.4, or should I be using a different function to mount a network share?

I'm building a freediving app for Apple Watch Ultra using the shallow depth entitlement (com.apple.developer.submerged-shallow-depth-and-pressure). My app uses WKExtendedRuntimeSession with the underwater-depth background mode, and it works correctly — the session starts, Water Lock activates automatically, and Crown hold water ejection ends the session as expected. However, the app does not appear in Settings > General > Auto-Launch > When Submerged on the watch. Other third-party apps (including one that hasn't been updated in ~2 years and presumably only has the shallow entitlement) do appear in this list. My configuration: WKBackgroundModes: ["underwater-depth", "workout-processing"] WKSupportsAutomaticDepthLaunch: true (Boolean, in watch app Info.plist) Entitlement verified in both the signed binary and provisioning profile watchOS 26.3, Apple Watch Ultra 2 Tested with: development build, TestFlight, and direct Xcode deploy. Watch restarted after each. The app does not appear in any case. The documentation at https://developer.apple.com/documentation/coremotion/accessing-submersion-data states: "Adding the underwater-depth Background Mode capability also adds your app to the list of apps that the system can autolaunch when the wearer submerges the watch." Does auto-depth-launch require the full depth entitlement (com.apple.developer.submerged-depth-and-pressure), or should the shallow entitlement be sufficient? Is there an additional step required for the app to appear in the When Submerged list? Any guidance appreciated.

Hello. Our application performs encoding and decoding of large json files which sometimes may take up to 1,5GB of RAM memory. We understand that this may be a problem for devices with low RAM memory (3GB). But before iOS 26.4 we didn't have much occurrences (3 for the last 90 days). Starting from iOS 26.4 it started to crash a lot. Can the reason be that iOS 26.4 occupies more RAM memory so there is less memory left for our app? Or maybe starting from iOS 26.4 there is less RAM memory allocated per app? The crash message is Fatal error: failed to allocate 392 bytes of memory with alignment 8

Inquiry) Inquiry Regarding USB Network Connectivity Between an iPad (Wi‑Fi Model) and an Embedded Linux Device An embedded device (OS: Linux) is connected to an iPad (Wi‑Fi model) using a USB‑C cable. The ipheth driver is installed on the embedded device, and the iPad is recognized correctly. A web server is running on the embedded device. To launch a browser on the iPad and access the web server running on the embedded device via a USB network connection. Based on our verification, the iPad is not assigned an IP address, and therefore communication with the web server on the embedded device is not possible. We would appreciate it if you could provide guidance on the following questions. We would like to assign an IP address to the iPad (Wi‑Fi Model) so that it can communicate with the embedded device over a USB network connection. Is there a way to achieve this through the standard settings on the iPad? If this cannot be achieved through settings alone, are there any existing applications that provide this functionality? If no such application currently exists, is it technically possible to develop an application that enables this capability on iPadOS? Information) The USB‑C port on the embedded device is fixed in HOST mode. The embedded device operates as the USB host, and the iPad operates as a USB device. When a cellular model iPad is connected and “Personal Hotspot” is enabled, an IP address is assigned via DHCP, and we have confirmed that the web server can be accessed from the iPad’s browser. We are investigating whether a similar solution is possible with a Wi‑Fi model iPad.

DJI's DNG files display abnormally in the Apple Photos app on iOS devices, with dark areas showing as very black, but the same files appear normal in Photoshop. I'm curious about what causes this issue.

We probably triggered a bug within Rosetta: https://github.com/docker/desktop-feedback/issues/230