I have an app with lots of networking calls that are currently done through URLSession. We would like to implement the new carried constrained entitlements and begin moving data through the ultra constrained network path for core features of our application. I have successfully implemented the NWPathMonitor to identify when the current network path is ultra constrained and I have been consistently on a physical device in a real world environment. I'm aware that we will not be able to use URLSession to do this from other posts in this forum like this one. Because of this problem with URLSession I am attempting to fallback to using NWConnection when the current path is ultra constrained. I have setup a NWConnection with the NWParameters.allowUltraConstrainedPaths set to true. The request works perfectly when connected to wifi or cellular. However, it does not work at all when the current path is ultra constrained. When attempting this request through my NWConnection I receive an error that says: The operation couldn’t be completed. (Network.NWError error 50 - Network is down) Is this expected? I have confirmed my physical device is connecting to carrier provided satellite and I have been able to load data in other ios apps from Apple like the music app while on this carrier constrained connection. If this is not the correct way to move data when the path is ultra constrained what is the correct way?

My entity has a startDate (NSTime) attribute where I use the date and time in my detail display of the entity. And in my list, I need to group my entities by day (YYMMDD) based on the start date; and I want to ensure that it can adapt to the region where the user is currently (e.g. if user travels or migrate, the YYMMDD should be adapted based on the current region). Does Core Data SectionedFetchRequest supports strftime() functions from SQLite (https://sqlite.org/lang_datefunc.html) or what is an effective alternative sectioned fetch in my case?

HealthKit is currently not supported on macOS nor tvOS, despite being supported by visionOS. Support for macOS was last asked about[1] here in 2018. My goal is to display interactive data visualisations over workouts collected in HealthKit on macOS. Will this be possible to do in the near future using HealthKit directly? If not, can I somehow read the information from an iPhone and display it on the mac? Cheers, Rodrigo [1] https://developer.apple.com/forums/thread/94937

Hello, dear Apple engineers. We have recently tried to pair our Android phones and iPhones via BLE SMP, but have encountered a very high probability of pairing failures. Through PacketLogger and Android phone HCI, we have determined that the issue is caused by the iOS side sending an SMP Pairing Failed message during the SMP process. Please help us analyze the reason for this.

General: Forums subtopic: App & System Services > Processes & Concurrency Forums tag: Background Tasks Background Tasks framework documentation UIApplication background tasks documentation ProcessInfo expiring activity documentation Using background tasks documentation for watchOS Performing long-running tasks on iOS and iPadOS documentation WWDC 2020 Session 10063 Background execution demystified — This is critical resource. Watch it! [1] WWDC 2022 Session 10142 Efficiency awaits: Background tasks in SwiftUI iOS Background Execution Limits forums post UIApplication Background Task Notes forums post Testing and Debugging Code Running in the Background forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Sadly the video is currently not available from Apple. I’ve left the link in place just in case it comes back.

Dear Apple App Store Review Team, We are currently developing an application focused on user data asset management, aimed at helping users better protect and manage their personal data. One of the core features of our application is to allow users to access files stored on their mobile devices from other devices within the same local network. At present, our implementation works as follows: once the application is launched, it starts an HTTP service in the background to support access from other devices within the local network. However, we have encountered a technical challenge in the iOS environment: when the application is moved to the background or the device screen is turned off, the system imposes strict limitations on the runtime of background tasks. Our testing has shown that, typically after about 30 seconds, the background HTTP service is suspended by the system, which prevents other devices from continuing to access the files. As developers, we would like to clarify the following: What specific technical steps are required to enable a continuous background HTTP service under iOS? During development, which aspects (e.g., system permission configurations, App Store review guidelines) need to be addressed to support such functionality? What qualifications or requirements (e.g., entitlement requests, compliance documentation) are necessary for an application to provide unrestricted HTTP service in the background? If such behavior is not officially supported, we kindly request that you provide the relevant official guidelines and documentation so that we can fully understand the applicable policies and requirements. Thank you very much for your time and guidance.

We rely on ApplePaySession.applePayCapabilities() to decide whether to show the Apple Pay button. We use two different merchant IDs for non-prod/prod environments, and encountered a change in behavior where this API now returns different results. These merchant IDs are generated from a third-party provider Adyen. However, Adyen has informed us that they are unable to identify the root cause of the issue and advised us to seek assistance directly from Apple Pay support. Timeline Last known working date: 13/08/2025 Issue first noticed: 18/08/2025 Environment Details Apple Pay JS API version 1.latest Browsers Tested: Third party browsers including Chrome/139.0.0.0, Firefox/141.0 Browsers with ApplePaySession built-in (like iOS Chrome, iOS Safari, and macOS Safari) are working fine Framework Stack: Angular v18.1.3 (important) no configuration setup in Apple dev account, merchantId is generated from a third-party provider Adyen. Current Execution Flow: Apple Pay JS API script element is injected <script type="text/javascript" async="" src="https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js"></script> Triggers below to check apple pay readiness, different ${merchantId_credential} is used: await window.ApplePaySession.applePayCapabilities(`${merchantId_credential}`); (**ApplePaySession is a valid object at this point) Observed that different paymentCredentialStatus is returned // nonprod env { "paymentCredentialStatus": "applePayUnsupported" // unexpected } // prod env { "paymentCredentialStatus": "paymentCredentialStatusUnknown" } The same code is executed in each environment and the behaviour was also the same, but has changed since then. Side notes By checking the SDK’s internal code, we saw that in third-party browsers it makes an extra call to the following endpoint. Responses from this call also come back differently depending on the merchantId. When invoking below: curl -X POST \ https://smp-paymentservices.apple.com/paymentservices/v3/checkStatus/merchant/{merchantId} \ -H 'Content-Type: application/json' \ -d '{ "initiative": "web", "initiativeContext": "env_specific_domain" }' Our non-prod environment returns {"registered":false} while using prod's merchantId and domain it returns {"registered":true}. We thought the issue might be domain-related since the environments are on different domains, but so far, no luck. The main questions we're looking to resolve are: Why did the behavior change at a certain point despite no code changes? How should we approach this investigation, and what specific requests should we be making to the Adyen team? Why does the response from the call to https://smp-paymentservices.apple.com/paymentservices/v3/checkStatus/merchant/{merchantId} return different results? Perhaps this could provide a clue regarding the question above? We noticed that canMakePayments() is returning true, so we could consider using that as a workaround. Would it be safe to change the source of truth relying on canMakePayments() for displaying Apple Pay? There is a concern that this issue may also occur in our production environment, so we would appreciate assistance in understanding what is happening and finding a resolution.

Hello, We’re seeing an issue where the Apple Pay button is visible in Safari but not clickable for certain users, while it works normally for others. This happens on our site (https://store-qa2.enphase.com/ ) as well as on other sites for the same affected users. Currently, we display the Apple Pay button based on the following condition: Boolean(window.ApplePaySession) && ApplePaySession.canMakePayments(); For affected users, the button shows up as expected, but it’s not interactive. All users (both affected and unaffected) are on the latest versions of Safari and macOS/iOS. Could someone clarify what additional conditions Safari/Apple Pay requires for the button to be fully functional? And under what circumstances could it be visible but not clickable?

We are unable to add/remove Merchant IDs in App IDs identifier profile, after pressing "Edit" button on "Apple Pay Payment Processing" section, then choosing desired Merchant ID to check/uncheck from the available Merchant IDs, then pressing Continue/Save/Confirm buttons - nothing happens, the "Save" button text briefly changes to "Processing" and then back To "Save" and we still have previously enabled Merchant IDs and the Save button is still in enabled state, any help?

Hello, We are currently developing an application that uses the Host-based Card Emulation (HCE) entitlement to enable corporate access functionality. With this entitlement, we have successfully established HCE communication and can interact with our access control systems to unlock doors. Our question is related to improving the user experience: We would like this access functionality to work without requiring the app to be in the foreground, as this adds friction for users during entry. Specifically, we would like to know: Is it possible for our app to coexist with Apple Wallet as the default contactless app, so that: Our app handles NFC interactions for corporate access (e.g., opening doors). Apple Wallet remains the default for payments. If that coexistence is not possible, and our app is set as the default contactless app, Will the system still need to launch our app into the foreground to complete a transaction (e.g., to emulate the NFC card)? Or is there a way to trigger HCE responses in the background (e.g., using a background process or service extension)? Any guidance on how to configure the app for optimal background access behavior, while maintaining compatibility with Wallet, would be greatly appreciated. Thank you in advance.

Hello, I’m a developer at an IT service provider in the banking sector. In the context of an HCE-based payment solution on iOS, we use the Apple Card Session API to receive and process APDU commands. We are currently facing an issue with a specific payment terminal model (CCV): When using this terminal, the Apple Card Session correctly triggers the readerDetected and readerDeselected events, but does not fire the expected received event, even though APDU commands are clearly being sent at the protocol level. This behavior only occurs with this particular CCV terminal in our implementation – with other terminals and on Android devices, the received event is triggered reliably. The same CCV terminal also works without issues when using Apple Pay or PayPal (which also uses HCE → Card Session), and APDU data is transmitted as expected in those cases. Interestingly, in our implementation, roughly every 10th to 20th transaction with this CCV terminal does trigger the received event and APDU commands are delivered — in those rare cases, the payment proceeds successfully. In the system logs, we sometimes see APDU commands marked as invalid, but this also happens in cases where communication works fine, so we’re not sure whether this is actually related to the missing events. Our questions: Has anyone encountered this behavior before – specifically missing received events despite active communication from the terminal? Are there known limitations or specific requirements for payment terminals so that APDU commands are passed through to the Apple Card Session? Are there any diagnostic tools or logs we could use to better narrow down the root cause? At this point, we are unsure whether the issue lies in terminal compatibility, the Apple Card Session itself, or our implementation. Any insights, experiences, or technical hints would be greatly appreciated. Thanks in advance for your help!

Hi, I'm having this issue that I have have not been able to figure out as I've gone through a checklist and it seems I have everything in place, but im sending my pushToStartTokenUpdates token to a server and im able to test starting a live activity via CURL where it shows my push token going through and even my test payload but after a while I get this issue in my logs where it fails to find a live activity Push notifications are set up, im sending my token to APN and im even able to start live activities locally.

We are working with earphones that support Bluetooth BR/EDR (non-BLE). In our iOS app using CoreBluetooth, BLE peripherals appear during discovery, but this device does not.

Good morning, I have been playing with he new Networking framework released in beta, and i think its amazing how powerful and simple it is. However i have been tackling some issues with it, it seems that the NetworkListener does not allow us to configure a specific endpoint for any of the protocols, UDP, TCP (QUIC, TLS) Is this intended or just not missing features as of the Beta ? I figured out how to use bonjour to get a port (as i am brand new to using Networking on macOS and Swift) I get that the use of this is mainly as a client to connect to servers, but it would make more sense to have a high level abstraction of what already exist, wouldn't it be more intuitive to configure a NetworkEndpoint that contains either a Bonjour Service or an endpoint with configured port that we can then configure on the Listener, instead of doing .service(...) ?

Furuno AP(EW750) is sending EAPOL M1 message, but Iphone16 is not responding with EAPOL M2 message, Hence Iphone16 is unable to connect to Qualcomm based AP with MLO suiteb encryption. Issue impact: All the Iphone16 users cannot connect to WiFi7 AP with MLO suiteb encryption globally. Predominantly, Iphone users tend to connect to more secured wifi networks using WPA3 suiteb encryption, hence many of the iphone users will experience the connectivity issue significantly. Topology: AP Hardware: Furuno WiFi7 AP(EW770) The Furuno WiFi7 AP uses Miami IPQ5332 with waikiki radio QCN9274 (Qualcomm based chipset) AP software: SPF12.2 CSU3 IPhone16 software: (18.3.1 or 18.5 ) I phone16 wifi capabilities: 802.11 b/a/g/n/ac/ax/be Radius server details: Radius server: Laptop running with Ubuntu Radius package: 3.0.26dfsggit20220223.1.00ed0241fa-0ubuntu3.4 Version: 3.0.26 Steps: Power on the Wi-Fi 7 Access Point with the Miami chipset, and flash it with the SPF 12.2 CSU3 image. Enable both 5 GHz and 6 GHz radios on the AP. Enable MLO (Multi-Link Operation) in 6Ghz & 5Ghz, set MLD address different from radio address and configure Suite-B (192-bit) encryption On the Linux laptop, set up the RADIUS server with EAP-TLS authentication method. Once the above steps are completed, take the iPhone 16 and follow the steps below to install the RADIUS client certificates on the device. On the sniffer laptop, switch the Wi-Fi adapter to monitor mode, configure the required channel, and begin packet capture. Check SSID is broadcasting, then connect the iPhone 16 to . Verify if the client (iPhone 16) connects to the SSID using WPA3-Enterprise, MLO, and Suite-B encryption by checking the wireless capture on both the AP and iPhone sides. Support needed from Apple team: We would request Apple team to analyse and enable the IPhone16 users to connect to advanced security WPA3 Suiteb by resolving the issue. Below is our analysis and observation for your reference. As per IEEE, MLD mac address can be set to the same or different from radio address, Iphone16 is not accepting EAPOL M1 message if source address(MLD) is different from radio address. IPhone16 is accepting EAPOL M1 if the source address(MLD) is set to the same as the radio address and responds with M2 message IPhone16 is not accepting EAPOL M1 if source address(MLD) set to different from radio address and fails to respond with M2 message. sysdiagnose.log log-file log-file Please let us know additional logs are required.

In FileProvider framework based app, is it mandatory to make the host-app sandboxed? I think, no, as Google Drive app is non-sandboxed. But when removing sandboxing from my hostApp, even though mount is visible in Finder but extesnion is not being launched and Finder shows a error message saying "MyApp encountered an error. Items may be out of date." And when I add app-sanboxing, then things work fine. Can someone please help how can we remove sandboxing of hostApp and still make it work. Is there any specific entitlement we need to add, or any whitelisting needed for our Developer Team Id?

Hello, I am developing a messaging filtering app (F-Secre) that includes a Message Filter Extension. The extension correctly identifies and filters spam SMS/iMessage. In iOS 18, when a message was filtered into the Junk folder, the Messages app would correctly display a label beneath it indicating it was filtered by our product, e.g., “Junk filtered by F-Secre”. After updating to the iOS 26 beta (26.0 (23A5330a)), the filtering functionality itself still works—messages are correctly moved to the Junk folder. However, the branding attribution ("filtered by F-Secre") is now missing. The message appears in the Junk folder with no indication of which extension filtered it. This is a regression in user experience, as it removes visibility and credit for our app's work and might confuse users about whether the filtering system is active.

For important background information, read Extra-ordinary Networking before reading this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Broadcasts and Multicasts, Hints and Tips I regularly see folks struggle with broadcasts and multicasts on Apple platforms. This post is my attempt to clear up some of the confusion. This post covers both IPv4 and IPv6. There is, however, a key difference. In IPv4, broadcasts and multicasts are distinct concepts. In contrast, IPv6 doesn’t support broadcast as such; rather, it treats broadcasts as a special case of multicasts. IPv6 does have an all nodes multicast address, but it’s rarely used. Before reading this post, I suggest you familiarise yourself with IP addresses in general. A good place to start is The Fount of All Knowledge™. Service Discovery A lot of broadcast and multicast questions come from folks implementing their own service discovery protocol. I generally recommend against doing that, for the reasons outlined in the Service Discovery section of Don’t Try to Get the Device’s IP Address. There are, however, some good reasons to implement a custom service discovery protocol. For example, you might be working with an accessory that only supports this custom protocol [1]. If you must implement your own service discovery protocol, read this post and also read the advice in Don’t Try to Get the Device’s IP Address. IMPORTANT Sometimes I see folks implementing their own version of mDNS. This is almost always a mistake: If you’re using third-party tooling that includes its own mDNS implementation, it’s likely that this tooling allows you to disable that implementation and instead rely on the Bonjour support that’s built-in to all Apple platforms. If you’re doing some weird low-level thing with mDNS or DNS-SD, it’s likely that you can do that with the low-level DNS-SD API. [1] And whose firmware you can’t change! I talk more about this in Working with a Wi-Fi Accessory. API Choice Broadcasts and multicasts typically use UDP [1]. TN3151 Choosing the right networking API describes two recommended UDP APIs: Network framework BSD Sockets Our general advice is to prefer Network framework over BSD Sockets, but UDP broadcasts and multicasts are an exception to that rule. Network framework has very limited UDP broadcast support. And while it’s support for UDP multicasts is less limited, it’s still not sufficient for all UDP applications. In cases where Network framework is not sufficient, BSD Sockets is your only option. [1] It is possible to broadcast and multicast at the Ethernet level, but I almost never see questions about that. UDP Broadcasts in Network Framework Historically I’ve claimed that Network framework was useful for UDP broadcasts is very limited circumstances (for example, in the footnote on this post). I’ve since learnt that this isn’t the case. Or, more accurately, this support is so limited (r. 122924701) as to be useless in practice. For the moment, if you want to work with UDP broadcasts, your only option is BSD Sockets. UDP Multicasts in Network Framework Network framework supports UDP multicast using the NWConnectionGroup class with the NWMulticastGroup group descriptor. This support has limits. The most significant limit is that it doesn’t support broadcasts; it’s for multicasts only. Note This only relevant to IPv4. Remember that IPv6 doesn’t support broadcasts as a separate concept. There are other limitations, but I don’t have a good feel for them. I’ll update this post as I encounter issues. Local Network Privacy Some Apple platforms support local network privacy. This impacts broadcasts and multicasts in two ways: Broadcasts and multicasts require local network access, something that’s typically granted by the user. Broadcasts and multicasts are limited by a managed entitlement (except on macOS). TN3179 Understanding local network privacy has lots of additional info on this topic, including the list of platforms to which it applies. Send, Receive, and Interfaces When you broadcast or multicast, there’s a fundamental asymmetry between send and receive: You can reasonable receive datagrams on all broadcast-capable interfaces. But when you send a datagram, it has to target a specific interface. The sending behaviour is the source of many weird problems. Consider the IPv4 case. If you send a directed broadcast, you can reasonably assume it’ll be routed to the correct interface based on the network prefix. But folks commonly send an all-hosts broadcast (255.255.255.255), and it’s not obvious what happens in that case. Note If you’re unfamiliar with the terms directed broadcast and all-hosts broadcast, see IP address. The exact rules for this are complex, vary by platform, and can change over time. For that reason, it’s best to write your broadcast code to be interface specific. That is: Identify the interfaces on which you want to work. Create a socket per interface. Bind that socket to that interface. Note Use the IP_BOUND_IF (IPv4) or IPV6_BOUND_IF (IPv6) socket options rather than binding to the interface address, because the interface address can change over time. Extra-ordinary Networking has links to other posts which discuss these concepts and the specific APIs in more detail. Miscellaneous Gotchas A common cause of mysterious broadcast and multicast problems is folks who hard code BSD interface names, like en0. Doing that might work for the vast majority of users but then fail in some obscure scenarios. BSD interface names are not considered API and you must not hard code them. Extra-ordinary Networking has links to posts that describe how to enumerate the interface list and identify interfaces of a specific type. Don’t assume that there’ll be only one interface of a given type. This might seem obviously true, but it’s not. For example, our platforms support peer-to-peer Wi-Fi, so each device has multiple Wi-Fi interfaces. When sending a broadcast, don’t forget to enable the SO_BROADCAST socket option. If you’re building a sandboxed app on the Mac, working with UDP requires both the com.apple.security.network.client and com.apple.security.network.server entitlements. Some folks reach for broadcasts or multicasts because they’re sending the same content to multiple devices and they believe that it’ll be faster than unicasts. That’s not true in many cases, especially on Wi-Fi. For more on this, see the Broadcasts section of Wi-Fi Fundamentals. Snippets To send a UDP broadcast: func broadcast(message: Data, to interfaceName: String) throws { let fd = try FileDescriptor.socket(AF_INET, SOCK_DGRAM, 0) defer { try! fd.close() } try fd.setSocketOption(SOL_SOCKET, SO_BROADCAST, 1 as CInt) let interfaceIndex = if_nametoindex(interfaceName) guard interfaceIndex > 0 else { throw … } try fd.setSocketOption(IPPROTO_IP, IP_BOUND_IF, interfaceIndex) try fd.send(data: message, to: ("255.255.255.255", 2222)) } Note These snippet uses the helpers from Calling BSD Sockets from Swift. To receive UDP broadcasts: func receiveBroadcasts(from interfaceName: String) throws { let fd = try FileDescriptor.socket(AF_INET, SOCK_DGRAM, 0) defer { try! fd.close() } let interfaceIndex = if_nametoindex(interfaceName) guard interfaceIndex > 0 else { fatalError() } try fd.setSocketOption(IPPROTO_IP, IP_BOUND_IF, interfaceIndex) try fd.setSocketOption(SOL_SOCKET, SO_REUSEADDR, 1 as CInt) try fd.setSocketOption(SOL_SOCKET, SO_REUSEPORT, 1 as CInt) try fd.bind("0.0.0.0", 2222) while true { let (data, (sender, port)) = try fd.receiveFrom() … } } IMPORTANT This code runs synchronously, which is less than ideal. In a real app you’d run the receive asynchronously, for example, using a Dispatch read source. For an example of how to do that, see this post. If you need similar snippets for multicast, lemme know. I’ve got them lurking on my hard disk somewhere (-: Other Resources Apple’s official documentation for BSD Sockets is in the man pages. See Reading UNIX Manual Pages. Of particular interest are: setsockopt man page ip man page ip6 man page If you’re not familiar with BSD Sockets, I strongly recommend that you consult third-party documentation for it. BSD Sockets is one of those APIs that looks simple but, in reality, is ridiculously complicated. That’s especially true if you’re trying to write code that works on BSD-based platforms, like all of Apple’s platforms, and non-BSD-based platforms, like Linux. I specifically recommend UNIX Network Programming, by Stevens et al, but there are lots of good alternatives. https://unpbook.com Revision History 2025-09-01 Fixed a broken link. 2025-01-16 First posted.

Hi, I am having a ton of issues with the new multicast/network entitlements requirements on MacOS. Basically, since my app didn't request these new entitlements until recently, if the app had been installed without these permissions enabled, it will not pick up the new permissions once they are enabled. The only options I had were to create a new user, and install the app under the new user, which works, but is not a real solution for users. This is really problematic, as there is no way currently to remove or change these network permissions once they are established. Is there a way to fix this? Or some other workarounds I am missing? Thanks Also via the documentation: TN3179: Understanding local network privacy | Apple Developer Documentation "There's no guarantee that it'll actually trigger the alert” And "On macOS there’s no way to reset your program’s Local Network privilege to the undetermined state (FB14944392). One alternative is to run your program in a virtual machine (VM). To retest, restore the VM from a snapshot taken before you installed your program.”

NEAppProxyUDPFlow contains below property: open var localEndpoint: NWEndpoint? { get } Why is localEndpoint not available for NEAppProxyTCPFlow? Is there a way to determine the source port of a flow of type NEAppProxyTCPFlow within the following method of NETransparentProxyProvider? override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool {