My App is a rather small menu-bar status-item app with 2 informational windows. It does NOT make use of ANY of the APIs mentioned here: https://developer.apple.com/forums/thread/663874 that are bound to need "Local Network" hence trigger TCC dialog. Yet - on first run of the app, the dialog pops. App is Obj-C, and the only APIs used are Notification-Center (for scheduling local notifications to the user), XPC connections and calls to other (our) apps for gathering that information, plus normal AppKit windowing (Controls, Text-fields, etc.) nothing else. Obviously SOMETHING I do causes the thing - and I know for sure this app DOES NOT NEED access to the local network - only I do not know how to identify the specific API I need to avoid using (or change the way I'm using) Are there any specific system logs to watch for? Is there any official set of APIs that will trigger the dialog? Provided that I cannot avoid this - could this permission be granted via MDM profile payload? Our product comes with

I have been using networking multicast permissions in my Xamarin application for UDP device discovery, and it has been working reliably for years. However, I am now encountering an issue specific to iPadOS 18.1 (potentially also iPadOS 18, though I haven’t tested this). The issue is that my app no longer requests the required network permission on devices running iPadOS 18.1. On the other hand, the app works perfectly on iPhone and iPadOS 17.7 without any problems. Has there been any change in the networking or permissions framework in iPadOS 18.1 that could cause this behavior? I would appreciate any guidance or insights to resolve this issue. Thank you for your assistance!

During development, before things eventually go live, if the associated server for a message filter extension has a self signed SSL then if/how can test iPhones be configured such that the OS will connect to the server when they are performing a message filter query request?

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" Don’t Try to Get the Device’s IP Address I regularly see questions like: How do I find the IP address of the device? How do I find the IP address of the Wi-Fi interface? How do I identify the Wi-Fi interface? I also see a lot of really bad answers to these questions. That’s understandable, because the questions themselves don’t make sense. Networking on Apple platforms is complicated and many of the things that are ‘obviously’ true are, in fact, not true at all. For example: There’s no single IP address that represents the device, or an interface. A device can have 0 or more interfaces, each of which can have 0 or more IP addresses, each of which can be IPv4 and IPv6. A device can have multiple interfaces of a given type. It’s common for iPhones to have multiple WWAN interfaces, for example. It’s not possible to give a simple answer to any of these questions, because the correct answer depends on the context. Why do you need this particular information? What are you planning to do with it? This post describes the scenarios I most commonly encounter, with my advice on how to handle each scenario. IMPORTANT BSD interface names, like en0, are not considered API. There’s no guarantee, for example, that an iPhone’s Wi-Fi interface is en0. If you write code that relies on a hard-coded interface name, it will fail in some situations. Service Discovery Some folks want to identify the Wi-Fi interface so that they can run a custom service discovery protocol over it. Before you do that, I strongly recommend that you look at Bonjour. This has a bunch of advantages: It’s an industry standard [1]. It’s going to be more efficient on the ‘wire’. You don’t have to implement it yourself, you can just call an API [2]. For information about the APIs available, see TN3151 Choosing the right networking API. If you must implement your own service discovery protocol, don’t think in terms of finding the Wi-Fi interface. Rather, write your code to work with all Wi-Fi interfaces, or perhaps even all Ethernet-like interfaces. That’s what Apple’s Bonjour implementation does, and it means that things will work in odd situations [3]. To find all Wi-Fi interfaces, get the interface list and filter it for ones with the Wi-Fi functional type. To find all broadcast-capable interfaces, get the interface list and filter it for interfaces with the IFF_BROADCAST flag set. If the service you’re trying to discover only supports IPv4, filter out any IPv6-only interfaces. For advice on how to do this, see Interface List and Network Interface Type in Network Interface APIs. When working with multiple interfaces, it’s generally a good idea to create a socket per interface and then bind that socket to the interface. That ensures that, when you send a packet, it’ll definitely go out the interface you expect. For more information on how to implement broadcasts correctly, see Broadcasts and Multicasts, Hints and Tips. [1] Bonjour is an Apple term for: RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses RFC 6762 Multicast DNS RFC 6763 DNS-Based Service Discovery [2] That’s true even on non-Apple platforms. It’s even true on most embedded platforms. If you’re talking to a Wi-Fi accessory, see Working with a Wi-Fi Accessory. [3] Even if the service you’re trying to discover can only be found on Wi-Fi, it’s possible for a user to have their iPhone on an Ethernet that’s bridged to a Wi-Fi. Why on earth would they do that? Well, security, of course. Some organisations forbid their staff from using Wi-Fi. Logging and Diagnostics Some folks want to log the IP address of the Wi-Fi interface, or the WWAN, or both for diagnostic purposes. This is quite feasible, with the only caveat being there may be multiple interfaces of each type. To find all interfaces of a particular type, get the interface list and filter it for interfaces with that functional type. See Interface List and Network Interface Type in Network Interface APIs. Interface for an Outgoing Connection There are situations where you need to get the interface used by a particular connection. A classic example of that is FTP. When you set up a transfer in FTP, you start with a control connection to the FTP server. You then open a listener and send its IP address and port to the FTP server over your control connection. What IP address should you use? There’s an easy answer here: Use the local IP address for the control connection. That’s the one that the server is most likely to be able to connect to. To get the local address of a connection: In Network framework, first get the currentPath property and then get its localEndpoint property. In BSD Sockets, use getsockname. See its man page for details. Now, this isn’t a particularly realistic example. Most folks don’t use FTP these days [1] but, even if they do, they use FTP passive mode, which avoids the need for this technique. However, this sort of thing still does come up in practice. I recently encountered two different variants of the same problem: One developer was implementing VoIP software and needed to pass the devices IP address to their VoIP stack. The best IP address to use was the local IP address of their control connection to the VoIP server. A different developer was upgrading the firmware of an accessory. They do this by starting a server within their app and sending a command to the accessory to download the firmware from that server. Again, the best IP address to use is the local address of the control connection. [1] See the discussion in TN3151 Choosing the right networking API. Listening for Connections If you’re listening for incoming network connections, you don’t need to bind to a specific address. Rather, listen on all local addresses. In Network framework, this is the default for NWListener. In BSD Sockets, set the address to INADDR_ANY (IPv4) or in6addr_any (IPv6). If you only want to listen on a specific interface, don’t try to bind to that interface’s IP address. If you do that, things will go wrong if the interface’s IP address changes. Rather, bind to the interface itself: In Network framework, set either the requiredInterfaceType property or the requiredInterface property on the NWParameters you use to create your NWListener. In BSD Sockets, set the IP_BOUND_IF (IPv4) or IPV6_BOUND_IF (IPv6) socket option. How do you work out what interface to use? The standard technique is to get the interface list and filter it for interfaces with the desired functional type. See Interface List and Network Interface Type in Network Interface APIs. Remember that their may be multiple interfaces of a given type. If you’re using BSD Sockets, where you can only bind to a single interface, you’ll need to create multiple listeners, one for each interface. Listener UI Some apps have an embedded network server and they want to populate a UI with information on how to connect to that server. This is a surprisingly tricky task to do correctly. For the details, see Showing Connection Information for a Local Server. Outgoing Connections In some situations you might want to force an outgoing connection to run over a specific interface. There are four common cases here: Set the local address of a connection [1]. Force a connection to run over a specific interface. Force a connection to run over a type of interface. Force a connection to run over an interface with specific characteristics. For example, you want to download some large resource without exhausting the user’s cellular data allowance. The last case should be the most common — see the Constraints section of Network Interface Techniques — but all four are useful in specific circumstances. The following sections explain how to tackle these tasks in the most common networking APIs. [1] This implicitly forces the connection to use the interface with that address. For an explanation as to why, see the discussion of scoped routing in Network Interface Techniques. Network Framework Network framework has good support for all of these cases. Set one or more of the following properties on the NWParameters object you use to create your NWConnection: requiredLocalEndpoint property requiredInterface property prohibitedInterfaces property requiredInterfaceType property prohibitedInterfaceTypes property prohibitConstrainedPaths property prohibitExpensivePaths property Foundation URL Loading System URLSession has fewer options than Network framework but they work in a similar way: Set one or more of the following properties on the URLSessionConfiguration object you use to create your session: allowsCellularAccess property allowsConstrainedNetworkAccess property allowsExpensiveNetworkAccess property Note While these session configuration properties are also available on URLRequest, it’s better to configure this on the session. There’s no option that forces a connection to run over a specific interface. In most cases you don’t need this — it’s better to use the allowsConstrainedNetworkAccess and allowsExpensiveNetworkAccess properties — but there are some situations where that’s necessary. For advice on this front, see Running an HTTP Request over WWAN. BSD Sockets BSD Sockets has very few options in this space. One thing that’s easy and obvious is setting the local address of a connection: Do that by passing the address to bind. Alternatively, to force a connection to run over a specific interface, set the IP_BOUND_IF (IPv4) or IPV6_BOUND_IF (IPv6) socket options. Revision History 2025-01-21 Added a link to Broadcasts and Multicasts, Hints and Tips. Made other minor editorial changes. 2023-07-18 First posted.

Hello, We are currently working on a zero-configuration networking compliant device thru avahi-daemon (for mDNS/DNS-SD handling) and avahi-autoipd (for link-local address configuration). Our test environment setup is: Device Under Test (DUT): Debian 9 Linux avahi-daemon: v0.6.32 avahi-autoipd: v0.6.32 Test Bed: Macmini with macOS Sequoia 15.0 Bonjour Conformance Test v1.5.4 Router: NEC Aterm WR8370N Devices are connected via LAN SRV PROBING/ANNOUNCEMENTS BASIC test failure was encountered in BCT during Multicast-DNS test suite execution. Please see the logs below: ERROR 2025-01-15 19:36:35.792930+0900: Cache flush bit is set in the SRV probes NOTICE 2025-01-15 19:36:35.792946+0900: DEVICE-sERvICE-32\._uSCaNs\._tcp\.lOcaL\.._uscAnS._tCP.loCAL., SEND_CONFLICT_WIN -> SEND_CONFLICT_WIN FAILED (SRV PROBING/ANNOUNCEMENTS BASIC) START (SRV PROBING/ANNOUNCEMENTS) DEBUG_2 2025-01-15 19:36:35.792979+0900: received packet (1137 bytes) DEBUG_2 2025-01-15 19:36:35.792999+0900: srv_cf_probe WARNING 2025-01-15 19:36:35.793022+0900: SRV Probing/Announcements Failed: See runtime output for PROBING and WINNING SIMULTANEOUS PROBE for details. FAILED (SRV PROBING/ANNOUNCEMENTS) We would like to know what causes the above test to fail, is it related to avahi or a an inccorect mDNS service handling wherein the cache flush bit was incorrectly set? Thank you.

I have an idea for a game where the Apple TV app acts as the host and discovers nearby iOS apps that can join the game. Each iOS app needs to be able to have the user draw, tap, etc and have all the events be delivered in real time to the Apple TV where the effects will be rendered immediately (imagine a co-op game played in your lounge room where guests user their own devices to control aspects of the UI on the shared Apple TV screen) MPC is discontinued and DeviceDiscoveryUI is limited to only a single iOS device so I’m trying to figure out the best way to do the P2P networking. Reading/watching videos suggests that using GKMatchMaker and friends seems like it might suffer from latency problems (because everything has to go via Game Centre - or does it?) plus I’m not sure how I’d deal with the fact that the owner of the Apple TV is likely to signed into the same game centre id on both the Apple TV and their own devices to which would mean they wouldnt be able to play because the host can’t invite “themselves” on another device (or can it?) Soooo… I’m looking for suggestions on how best to move forward. I’ve read https://developer.apple.com/documentation/technotes/tn3151-choosing-the-right-networking-api which is very useful but there’s no clear suggestion that would work. Using the Network for the real time messaging seems doable but dealing with discovery / invites seems like a massive pain that I’d prefer to use built-in libraries if possible. Any suggestions would be gladly received. Thanks a lot

We’ve been dealing with local network permission issues on macOS 15. Although 15.1 brought some improvement, users are now reporting similar problems again on 15.2. Our setup: A “launcher” app (installed from a web package, not sandboxed) uses NSTask to launch our main macOS app. This macOS app connects to an iOS app via the local network. We expect a local network permission prompt to appear when the new app launches, but for many users, it never does. In cases where it worked on an earlier macOS version, there’s no entry in System Settings > Privacy & Security > Local Network, so they can’t toggle anything. Oddly, if we run the macOS app directly in 15.2, local network access works, yet the privacy entry is still sometimes missing. We haven’t found a clear way to troubleshoot this within the current API. Has anyone experienced a similar issue, or have suggestions on how to debug and resolve this? Thanks in advance!

In https://developer.apple.com/forums/thread/128705?answerId=405119022#405119022, it is said that But if it’s holding up connections that match the on demand rules, that’s the correct behaviour. So if there was an on demand rule to connect for all domains (Connect rule without any matching criteria), all traffic would be held up while in the connecting state. The problem is that a customer can have SSO configured so that auth happens outside of the vpn app. So sequence would be Connect for all domains on demand rule triggers vpn connection VPN, in order to connect, tries auth through a broker app. VPN is in connecting state and blocks broker app traffic and so auth cannot complete and it cannot connect. I tried adding an on demand rule for EvaluateConnection and never connect for the auth domains. However, that caused the vpn to never be triggered to connect. Is it possible to support the scenario of an on demand rule to connect for all domains while having a vpn connection dependent on auth done in a separate app? Do you have any recommendations?

Dear Apple Developer Support Team, I hope this email finds you well. I am writing to inquire about the status of my application for the Hotspot Helper Request entitlement. I submitted the request on January 16, 2025, but I have not received any updates regarding its review status.

I am writing an app using Microsoft's MAUI platform. I am posting this here because that team wants me to make an xcode project to help determine an issue I am having. My MAUI app sends a broadcast packet on a UDP socket using address 255.255.255.255. This worked fine in iOS version 17.x. After upgrading my phone to iOS 18.x it stopped working. The error I get is "no route to host". The exact same code works fine on MacOS. It does not work on iPadOs 18. My question here is 3 fold: Did something specific change between iOS 17 and 18 that would cause a 'no route to host' error when sending a UDP broadcast packet? Can someone provide sample code to show me how to do this type of broadcast using Swift in Xcode for iOS? I read an article that said my app would need the com.apple.developer.networking.multicast entitlement in order to use boradcast functionality. This was introduced in iOS 14. Why did my app work fine in iOS 17 then? Is this what changed? Did this requirement use to be optional and is now required? I did get this entitlement from Apple and applied it to my provisioning profile and my app gave the same "no route to host" error. Why?

We are trying to connect an accessory to the home's Wi-Fi network and we want to pass that name from the app to the accessory. Passing via Bluetooth. Is there and API available on iOS to list the networks that the phone can see?

Hi, I’m urgently seeking assistance with an issue in my app development. The app allows users to control which domains are routed through my relay servers (six server URLs). However, I’ve encountered a problem: When a single relay configuration (for a single server URL) contains more than 70 domains, only one configuration can be active at a time. If I manually activate another relay configuration (for another server URL), the previously activated one automatically deactivates. Is there a way to overcome this limitation? Also, is there a maximum amount of domains that can exist across the per-app relays? I’m referencing the Apple documentation here: https://developer.apple.com/documentation/networkextension/relays Any guidance or insights into resolving this issue would be greatly appreciated! Thank you in advance :)

Hi All, I am trying to write an NWProtocolFramerImplementation that will run after Websockets. I would like to achieve two goals with this Handle the application-layer authentication handshake in-protocol so my external application code can ignore it Automatically send pings periodically so my application can ignore keepalive I am running into trouble because the NWProtocolWebsocket protocol parses websocket metadata into NWMessage's and I don't see how to handle this at the NWProtocolFramerImplementation level Here's what I have (see comments for questions) class CoolProtocol: NWProtocolFramerImplementation { static let label = "Cool" private var tempStatusCode: Int? required init(framer: NWProtocolFramer.Instance) {} static let definition = NWProtocolFramer.Definition(implementation: CoolProtocol.self) func start(framer: NWProtocolFramer.Instance) -> NWProtocolFramer.StartResult { return .willMarkReady } func wakeup(framer: NWProtocolFramer.Instance) { } func stop(framer: NWProtocolFramer.Instance) -> Bool { return true } func cleanup(framer: NWProtocolFramer.Instance) { } func handleOutput(framer: NWProtocolFramer.Instance, message: NWProtocolFramer.Message, messageLength: Int, isComplete: Bool) { // How to write a "Message" onto the next protocol handler. I don't want to just write plain data. // How to tell the websocket protocol framer that it's a ping/pong/text/binary... } func handleInput(framer: NWProtocolFramer.Instance) -> Int { // How to handle getting the input from websockets in a message format? I don't want to just get "Data" I would like to know if that data is // a ping, pong, text, binary, ... } } If I implementing this protocol at the application layer, here's how I would send websocket messages class Client { ... func send(string: String) async throws { guard let data = string.data(using: .utf8) else { return } let metadata = NWProtocolWebSocket.Metadata(opcode: .text) let context = NWConnection.ContentContext( identifier: "textContext", metadata: [metadata] ) self.connection.send( content: data, contentContext: context, isComplete: true, completion: .contentProcessed({ [weak self] error in ... }) ) } } You see at the application layer I have access to this context object and can access NWProtocolMetadata on the input and output side, but in NWProtocolFramer.Instance I only see final func writeOutput(data: Data) which doesn't seem to include context anywhere. Is this possible? If not how would you recommend I handle this? I know I could re-write the entire Websocket protocol framer, but it feels like I shouldn't have to if framers are supposed to be able to stack.

I am developing an App using the Networking framework, which can be either a Socket Server or a Socket Client, such that 2 devices can communicate remotely. For the most part I have it working, except: I am not sure of the best way to determine the IP Address for the Socket Server in order to allow the Client app to connect. I am currently using either of Cloud Functions, or lookup webpages (such as ipify.org) and even reading the IP addresses locally from within the device (this returns many, but not all of them connect successfully). These options seem to work if the Socket Server app is connected to the internet with an IPv6 address, but I find that when the Socket Server app is connected with an IPv4 address, the Client app never successfully connects. How should I: a) force the Socket Server app to have/use an IPV6 address at all times? or b) allow the Client app to connect successfully via an IPv4 address? And is there a simple way to know what IP Address the Socket Server is listening from?

Hi, I would like to confirm whether the matchDomains property in NERelayManager operates strictly at the Application Layer. Specifically, it seems that adding IPv4 addresses or IPv4 CIDR blocks to the matchDomains list does not work, as the relay manager appears unable to match them. For example, I tried adding the following IPv4 patterns to the matchDomains list: 11.22.33.44 11.22.. 11.22.* However, these IPv4 addresses or patterns are not routed through my Relay server. Additionally, I have observed that when using only the excludedDomains property, the desired IPv4 traffic is correctly routed to the relay server as expected. My question is: Can IPv4 addresses or IPv4 CIDR ranges work with matchDomains? If not, is there an alternative approach to enable IPv4 matching while matchDomains is active?

We're seeing some new and odd behavior where our NEPacketTunnelProvider instance is receiving a stopTunnelWithReason:completionHandler: call with reason NEProviderStopReasonInternalError. Can anyone shed some light into how to diagnose this situation? Here are some basic details: Our PacketTunnel has been in use for years and we only started seeing this issue recently. We're able to reproduce this behavior with some light browsing. The documentation provides no insight on why/when this might occur. Can anyone shed some light into how to diagnose this situation? Things we’ve tried so far: We grabbed a sysdiagnose and looked through the logs: a. Right before the stopTunnel, we see log items referring to a "nesessionmanager" (PID 2038) getting killed. Presumably, this is due to hitting a highwater threshold. (See sysdiagnose items listing below) b. Thinking these were due to memory pressure, we added logging of available/used memory. c. We confirmed that the PacketTunnel was only using 11,808.73 KB. d. Since, there is plenty of memory available the PacketTunnel was not killed for using too much memeory. We wondered if this could be due to our UI's usage of objects like: NETunnelProviderManager and NETunnelProviderSession a. We ran an experiment where we swiped closed the UI to ensure these manager/session objects are not used. b. Without the UI, we still saw the random stopTunnel with NEProviderStopReasonInternalError. We wondered if our routes were the problem, but they seem correct. a. See the NEPacketTunnelNetworkSettings listing below LISTING: From the system_logs.logarchive, the nesessionmanager log items: 2025-01-23 15:07:59.176146 -0800 0x278 memorystatus com.apple.xnu memorystatus: killing process 2038 [nesessionmanager] in high band ? (140) - memorystatus_available_pages: 18932 default kernel 2025-01-23 15:07:59.179641 -0800 0x278 memorystatus com.apple.xnu memorystatus: killing_highwater_process pid 2038 [nesessionmanager] (highwater 140) 7056KB - memorystatus_available_pages: 19161 compressor_size:69593 default kernel 2025-01-23 15:07:59.179888 -0800 0x278 memorystatus com.apple.xnu memorystatus: failed to kill a process and no memory was reclaimed default kernel 2025-01-23 15:07:59.185695 -0800 1 0x45e0c user/501/com.apple.nesessionmanager [2038] exited with exit reason (namespace: 1 code: 0x2) - JETSAM_REASON_MEMORY_HIGHWATER, ran for 266329ms default launchd 2025-01-23 15:07:59.231188 -0800 31 0x45bf2 com.apple.networkextension nesessionmanager(2038) exited default UserEventAgent 2025-01-23 15:07:59.253371 -0800 31 0x45bf2 com.apple.networkextension nesessionmanager exited with active sessions, re-launching nesessionmanager to clear agent status default UserEventAgent LISTING: From the system_logs.logarchive, the stopTunnel from PID 2046 2025-01-23 15:07:59.201581 -0800 SamplePacketTunnel [Extension com.REDACTED.PacketTunnel]: Calling stopTunnelWithReason because: None 2025-01-23 15:08:20.783112 -0800 SamplePacketTunnel 2025-01-23 15:08:20,786 2046 ERROR REDACTED (285805) - Exiting after waiting for stopTunnelWithReason LISTING: routes from NEPacketTunnelNetworkSettings { tunnelRemoteAddress = fd12:3456:789a:1::1 DNSSettings = { protocol = cleartext server = ( 2606:4700:4700::1234, 2606:4700:4700::2345, ) matchDomains = ( , ) matchDomainsNoSearch = NO } IPv6Settings = { configMethod = manual addresses = ( fd12:3456:789a:1::1, ) networkPrefixLengths = ( 64, ) includedRoutes = ( { destinationAddress = 2606:4700:4700::2345 destinationNetworkPrefixLength = 128 }, { destinationAddress = 2606:4700:4700::1234 destinationNetworkPrefixLength = 128 }, ) excludedRoutes = ( { destinationAddress = REDACTED destinationNetworkPrefixLength = 128 }, { destinationAddress = REDACTED destinationNetworkPrefixLength = 128 }, ) } MTU = 3072 } Thanks for taking a look, any help or suggestions would be greatly appreciated

I am unable to apply for Multicast Entitlement at https://developer.apple.com/contact/request/networking-multicast The reason for this is unclear. I have paid for a developer account and believe I'm up to date with all agreements.

Hi all, I’m developing a watchOS app that uses a WebSocket API to process voice audio. However, I keep encountering this error when trying to establish the connection: nw_endpoint_flow_failed_with_error [C1 <server URL>:443 failed parent-flow (unsatisfied (Path was denied by NECP policy), interface: ipsec2, ipv4, ipv6, proxy)] already failing, returning I’ve read Technical Note TN3135, which outlines an exception for audio streaming apps. My app is an audio streaming app, and I’ve already added background audio mode to the app’s capabilities. However, I’m not sure what else is required to meet the exception described in TN3135. Questions How do I meet the exception outlined in TN3135 for WebSocket audio streaming on watchOS? Does NECP enforce additional restrictions even with background audio enabled, and how can I address this? Any guidance or examples of implementing WebSocket audio streaming on watchOS would be greatly appreciated. Thanks!

In our iOS networking related app for the app store (with network extension using packet tunnel provider), we are supposed to read the list of nameservers for the network. We use res_ninit function. This function returns only 3 items (but in reality the network has more dns servers. In my case 5. Some ipv4 and some ipv6) Looking at the header file at iOS 18.2 -> user/include/resolve.h, it shows that the __res_state struct has a maximum limit of 3 for the nsaddr_list array. It seems that the reason the res_ninit function returns only 3 values is because of this. For our code to work correctly, it needs to know all the dns servers, but we only get partial results. Is there any other api that can get us all the dns servers ?

I added a Content Filter to my app, and when running it in Xcode (Debug/Release), I get the expected permission prompt: "Would like to filter network content (Allow / Don't Allow)". However, when I install the app via TestFlight, this prompt doesn’t appear at all, and the feature doesn’t work. Is there a special configuration required for TestFlight? Has anyone encountered this issue before? Thanks!