Hello, it seems Multipeer Connectivity is deprecated. We are looking to connect multiple Vision Pros together that are in the same physical space but in unknown network setups (That might block P2P communication and Multicasting). We are building an app with unity and already have networking solution that we are looking to extend to work with something like multipeer connectivty? Am I reading the docs right that "Apple peer-to-wifi" is the replacement. And that by using the "includePeerToPeer" property this will work. Would it be possible in this way that the Vision Pros discover and communicate with each other even if not connected to an AP?

I have an iOS app that now cannot connet to websocket servers when building with new SDKs. The app that i have deployed in appstore can connect to the existing websocket servers we use but when i build the same code with the new SDKs (Nex XCode) the app connects to the websocket server and then disconnect right after that so no messages are received and no messages are sent. What has changed and what do i need to change in the app? Or do i need to change somehing else somewhere else?

We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced. iOS → iOS 26 Networking → URLSession / Network.framework

libquic.dylib crashes with a null/invalid buffer access in nw_protocol_data_access_buffer during QUIC connection path migration on iOS 26. App code is not in the stack — this is entirely within Apple system libraries. We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced.

Actual Result: After showPicker(for:), the system AccessorySetupUI RemoteAlert brings up a remote keyboard. User taps are dispatched to AccessorySetupUI’s UIRemoteKeyboardWindow instead of the picker content window. App-side endEditing(true) / resignFirstResponder cannot dismiss it because the keyboard belongs to the system AccessorySetupUI remote scene. Key Evidence: 19:51:54.066: App window snapshot before showPicker has no UITextEffectsWindow. 19:51:54.009968: ASAccessorySession ### showPickerWithDisplayItems 19:51:54.013299: AccessorySetupUI showPickerWithOverrideBundleID 19:51:54.051591: AccessorySetupUI reports remote keyboard onscreen, frame {{0, 623}, {440, 333}} 19:51:54.095643: display layout shows com.apple.AccessorySetupUI foreground and com.osmo.tech obscured. 19:51:56.207/19:51:56.305: touch events are sent to and logged as KeyboardTouch touch down/up. Questions for Apple: Is AccessorySetupKit picker expected to show a keyboard when no text input is focused? Is it a system bug that UIRemoteKeyboardWindow covers/intercepts the “Find Accessories” action? Is there any public API for a third-party app to dismiss the keyboard inside AccessorySetupUI RemoteAlert? If this is expected behavior, what is the recommended workaround or required picker/display item configuration?

Hoping this might peak someones interest regarding proxy authorisation handling specifically during a device's SetupAssistant phase. Our problem in this instance relies with the AuthBroker's handling of proxy authorisation challenges. With Apple's devices proxy auth is handled through AuthBroker which will make subsequent calls to GSS/ keychain if applicable to handle proxy Auth with CFNetwork. Whilst this process functions quite well in the large part it's functionality around prompt suppression causes issues during the setupAssistant phase. To avoid prompt fatigue AuthBroker Agent has a flag for a given proxy authorisation host (combination of host + port) that's responsible for reporting if a system prompt has been raised in the past. If it has AuthBroker will suppress prompting for the active session. This creates a problem with SetupAssistant in that AuthBroker agent is not allowed to raise system prompts in this state. As a result it instaed triggers a default not now handling: default 2026-04-27 20:34:43.565424 -0700 AuthBrokerAgent [0x100a7ee60] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[119].0x100a7ee60 default 2026-04-27 20:34:43.565608 -0700 AuthBrokerAgent [0x100a80350] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[158].0x100a80350 default 2026-04-27 20:34:43.565924 -0700 AuthBrokerAgent Fetching proxy credential for query <private> default 2026-04-27 20:34:43.566135 -0700 AuthBrokerAgent Request <private> 0x65a873860 default 2026-04-27 20:34:43.567245 -0700 AuthBrokerAgent Not internal release, disabling SIRL default 2026-04-27 20:34:43.576369 -0700 AuthBrokerAgent CFNetwork Diagnostics [3:1] 20:34:43.575 { CopyDefaultCredential: (null) Store: shared credential storage 0x100a7d320, session 0xad7010040, persistent 0x100a7d3e0 Space: https://someproxy.example.com:3128/, NTLM (Hash 774a6617a1f9d1ae) Result: null } [3:1] default 2026-04-27 20:34:43.576451 -0700 AuthBrokerAgent Prompting user 0x65a873860 default 2026-04-27 20:34:43.578299 -0700 AuthBrokerAgent Cache loaded with 6300 pre-cached in CacheData and 69 items in CacheExtra. default 2026-04-27 20:34:43.606794 -0700 AuthBrokerAgent User selected alternate response, won't prompt again 0x65a873860 default 2026-04-27 20:34:43.606820 -0700 AuthBrokerAgent Not sending a credential 0x65a873860 default 2026-04-27 20:34:43.606829 -0700 AuthBrokerAgent Fetching proxy credential complete result (null) This flows onto Authbroker requests executed after setupAssistant and prevents the device from prompting until an effective restart: default 2026-04-28 13:37:46.710956 +1000 Setup Buddy exiting... default 2026-04-28 13:38:06.658658 +1000 AuthBrokerAgent [0xad6864000] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[278].0xad6864000 default 2026-04-28 13:38:06.659238 +1000 AuthBrokerAgent Fetching proxy credential for query <private> default 2026-04-28 13:38:06.661957 +1000 AuthBrokerAgent Request <private> 0xa4eccc760 default 2026-04-28 13:38:06.662597 +1000 AuthBrokerAgent SecSecurityClientGet new thread! default 2026-04-28 13:38:06.813050 +1000 AuthBrokerAgent CFNetwork Diagnostics [3:7] 13:38:06.809 { CopyDefaultCredential: (null) Store: shared credential storage 0x100a7d320, session 0xad7010040, persistent 0x100a7d3e0 Space: https://someproxy.example.com:3128/, NTLM (Hash 774a6617a1f9d1ae) Result: null } [3:7] default 2026-04-28 13:38:06.813088 +1000 AuthBrokerAgent Will not prompt since user previously dismissed prompt 0xa4eccc760 default 2026-04-28 13:38:06.813091 +1000 AuthBrokerAgent Not sending a credential 0xa4eccc760 default 2026-04-28 13:38:06.814867 +1000 AuthBrokerAgent Fetching proxy credential complete result (null) Is there any chance to get this handling updated so that SetupAssistant reset AuthBroker's prompting state on conclusion to allow for system prompt exposure to the user without requiring a device restart.

We are implementing a Network Extension that uses NETransparentProxyProvider. For browser TCP flows we terminate in the extension and re‑originate traffic with NWConnection. Per documentation, we set NWParameters.preferNoProxies = true on that NWConnection so it should not use the system HTTP/HTTPS proxy configuration, including PAC‑selected explicit proxies. Observation: With System Settings → Network → Proxies → Automatic proxy configuration pointing at a PAC file that returns something like PROXY 127.0.0.1:8888 for relevant traffic, we still see our NWConnection traffic show up at the local explicit proxy as a normal CONNECT host:443 tunnel. That suggests PAC / explicit proxy selection is still being applied to sockets we believed were opted out via preferNoProxies. This is affecting interoperability: the browser may evaluate PAC with a hostname (e.g. a site configured as DIRECT), while a separate NWConnection may be evaluated in a context where the logical host is an IPv4 literal, so the same PAC script can return PROXY for what the user thinks is the “same” destination. We had expected preferNoProxies to remove the second leg from PAC/proxy entirely. Expected: NWConnection with preferNoProxies == true should connect without opening an explicit CONNECT session to the PAC‑configured proxy (unless there is documented behavior that NE‑originated traffic is intentionally exempt from this flag). Actual: Traffic from the NWConnection path still reaches the explicit proxy (we can log CONNECT … on a minimal local proxy). Environment: macOS Tahoe 26.5 (25F71), Network Extension / App Proxy provider, PAC served over local http, Safari as client. Questions: Is preferNoProxies guaranteed to bypass PAC‑selected explicit proxies for NWConnection from Network Extension processes, or are there known exceptions (e.g. certain interfaces, MDM, networkserviceproxy, etc.)? If this is by design, what is the supported way for an NE to open an outbound TCP connection that must not inherit system PAC/proxy?

wifip2pd leaks file descriptors during repeated Wi-Fi Aware NDP cycles → EMFILE → Wi-Fi Aware permanently broken Summary Under repeated Wi-Fi Aware (NAN) datapath connect/teardown cycles, wifip2pd leaks file descriptors until it hits the per-process limit (EMFILE, "Too many open files"). After that, wifip2pd can no longer create the socket needed to configure the nan0 interface, so updating the nan0 IPv6 link-local address fails with Apple80211Error Bad file descriptor. From the app's side, the NDP datapath is established but the NetworkConnection never gets a local IPv6 address and stays stuck in .preparing. The condition does not self-heal and is not cleared by restarting the app — only a reboot (or wifip2pd restart) recovers Wi-Fi Aware. Configuration iPhone 16 Pro Max, iOS 26.5 Network framework (new Swift NetworkConnection / NetworkBrowser Wi-Fi Aware API) System component: wifip2pd Where the problem is The leak and the failure are entirely inside wifip2pd (the per-process descriptor table fills up). The chain is: fd leak in wifip2pd → EMFILE ("Too many open files", errno 24) → socket() fails → cannot set nan0 IPv6 link-local address (Apple80211 ioctl on invalid fd → EBADF) → app NWConnection NWPath = satisfied but localEndpoint = nil → NetworkConnection stuck in .preparing, times out Abnormal console logs (the evidence) The smoking-gun lines from the unified log / Console (process wifip2pd): wifip2pd <Error> Failed to create socket: Too many open files wifip2pd <Error> Failed to update nan0 IPv6 address to [fe80::30c1:22ff:fe97:fefb] (from [fe80::e8a0:9bff:fe25:4d5c]) because <Apple80211Error Bad file descriptor> wifip2pd <Error> nw_path_shared_necp_fd necp_open failed [24: Too many open files] # errno 24 = EMFILE wifip2pd(Network) <Error> File descriptor is bad, could not create socket Counts over one ~11.5-minute failing capture: wifip2pd "Too many open files": 45 occurrences (a healthy capture has 0). nan0 IPv6 address update: 2 success / 13 fail (the 2 successes are before exhaustion; everything after fails with "Bad file descriptor"). Healthy device, for contrast — the IPv6 update succeeds on every NAN MAC rotation, and the app connection then works: wifip2pd Successfully updated nan0 IPv6 address to [fe80::f4c4:14ff:fe28:784a] # → app NWPath: status=satisfied, local=fe80::f4c4:14ff:fe28:784a%nan0 → NetworkConnection .ready Two facts that localize the bug: The leak is in wifip2pd, not the app. wifip2pd is one persistent daemon (constant pid) whose fd count only grows; the client app was restarted multiple times during the test and that did not release the descriptors. All "Too many open files" lines are emitted by wifip2pd. The NDP datapath itself still succeeds — only socket/interface-address configuration fails: kernel nan0: handleDataPathEstablished: NAN-DP Data path ESTABLISHED ... encrypt 1, EstDPs 1 wifip2pd #### Data Confirmed With Peer: ... port: 9004 Application-layer symptom (developer-facing) The same client code works before exhaustion and fails after: Before: NetworkConnection<UDP> reaches .ready; NWPath.localEndpoint = fe80::…%nan0. After: NetworkConnection<UDP> stays .preparing; every onPathUpdate reports status=satisfied, interfaces=["nan0"], local=nil; it times out and retries forever. The decisive developer-visible signal is NWPath.status == .satisfied together with localEndpoint == nil on nan0. Correlating timestamps confirms the contradiction: the console shows Data Confirmed With Peer ... port 9004 ~9–10 s before the app's NetworkConnection gives up, while the matching nan0 IPv6 update fails with "Bad file descriptor". The datapath is up at L2, but the connection is unusable because no local address was ever assigned. Steps to Reproduce Pair an iPhone with a Wi-Fi Aware peer that publishes a datapath service (_media-sync._udp, paired device, NCS-SK-CCM-128). Repeatedly establish and tear down the NDP datapath. In our case the peer device repeatedly powers off/on; each cycle forces a fresh browse + re-pair + NDP establish (the peer's NAN MAC is randomized each boot). Loop this; wifip2pd is never restarted, so the leak accumulates (failure appeared by ~the 9th iteration). Expected vs Actual Expected: wifip2pd releases the descriptors of each completed/torn-down browse/subscribe/datapath session; fd count stays bounded; nan0 IPv6 updates keep succeeding; NetworkConnection reaches .ready. Actual: wifip2pd fd count grows until EMFILE; nan0 IPv6 update then fails permanently; NetworkConnection is stuck .preparing for the rest of the wifip2pd process lifetime. Impact Any app using Wi-Fi Aware NDP datapaths under frequent connect/teardown eventually loses all Wi-Fi Aware connectivity. The failure is sticky for the wifip2pd lifetime and is invisible to / unrecoverable by the client app. Workaround Reboot the device (resets wifip2pd). The client can only slow the leak (fewer reconnects, prompt release of NetworkConnection), not prevent it, since the descriptors leak inside wifip2pd. To confirm / fix A sysdiagnose captured during the reproduction should show wifip2pd's open-fd count growing monotonically per connect/teardown cycle (which descriptor type leaks per browse/subscribe/datapath). Repro signature to grep in the logs: wifip2pd emitting Failed to create socket: Too many open files, necp_open failed [24: Too many open files], and Failed to update nan0 IPv6 address ... Apple80211Error Bad file descriptor.

We are currently investigating a serious issue related to Wi-Fi Aware and AccessorySetupKit. We found that some devices which originally supported Wi-Fi Aware may suddenly report that Wi-Fi Aware is not supported. After this happens, calling the following API fails: ASAccessorySession.showPicker(for:completionHandler:) API documentation: https://developer.apple.com/documentation/accessorysetupkit/asaccessorysession/showpicker(for:completionhandler:) The error returned is: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable.” Related logs: error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." 21:27:33.116061+0800 deviceaccessd Activating DASession: CID 0x7FC70001, BundleID xxxx, PID 542, WiFiAwareSupported: no 2026-05-26 21:27:33.118<103>21:27:33.118[E][WiFiAware::WA]@"":[ASK] showPicker callback error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." UserInfo={ NSDebugDescription=Current device is not Wi-Fi Aware capable., cuErrorMsg=Current device is not Wi-Fi Aware capable., NSLocalizedFailureReason=Current device is not Wi-Fi Aware capable. } Device information: Device: iPhone 16 Pro OS Version: 26.5 The device was previously able to use Wi-Fi Aware successfully. However, after the issue occurs, the system reports: WiFiAwareSupported: no The only known way to recover so far is to erase all content and settings / factory reset the device. This is not an acceptable workaround for end users and may cause a severe user experience issue. We would like to ask for your help with the following questions: Under what conditions would an iPhone that supports Wi-Fi Aware suddenly be reported as not Wi-Fi Aware capable? Is WiFiAwareSupported: no determined by hardware capability, system configuration, region setting, privacy/security policy, entitlement state, or some cached system state? Is there any known issue in AccessorySetupKit or Wi-Fi Aware on iOS 26.5 that could cause this behavior? Is there a way to recover the Wi-Fi Aware capability without requiring a factory reset? Are there any additional logs, sysdiagnose profiles, or diagnostic commands you recommend us to collect when this issue occurs? This issue is critical for us because users who encounter it will no longer be able to proceed with accessory setup, even though their device should support Wi-Fi Aware. Please let us know if you need a sysdiagnose, sample project, full device logs, or additional reproduction information. We would appreciate any guidance on the root cause and possible workaround.

As shown in the image, Apple's Wi-Fi Aware framework mentions support for Mac 26.0+

I'm working on developing a transparent proxy provider extension, and I am trying to figure out how to handle a change in configuration that would result in a different verdict from handleNewFlow() Consider the following scenario: The proxy provider is started with configuration A, and a bunch of packet flows get a verdict of NO from handleNewFlow(). These flows are now handled by the system and get routed out to the internet normally. Some application changes the protocolConfiguration property to configuration B, and the proxy provider detects this change via KVO. This new configuration changes the verdict that would have been returned from handleNewFlow() to YES, requiring that traffic to be handled by the transparent proxy provider instead of the system. These flows should be closed (eg: by calling closeReadWithError()) but the proxy provider has no record of them because we previously returned NO Is there a way that a transparent proxy provider can get the operating system to close the currently open flows so that they can be re-evaluated by handleNewFlow() and directed into the transparent proxy instead?

Hello Apple Developer Forums, We are evaluating AccessorySetupKit for onboarding a custom Wi-Fi smart-home accessory. Our main goal is to achieve password-less Wi-Fi provisioning, meaning the user would not need to manually type a Wi-Fi password or setup/pairing code during onboarding. We would like to understand whether ASK currently supports, or is intended to support: Secure Wi-Fi credential provisioning through system APIs Fully system-mediated onboarding flows Provisioning for headless/no-display accessories More specifically: Can password-less Wi-Fi provisioning be implemented using only public ASK APIs? Is a pairing/setup code always required? Or are developers still expected to use temporary AP mode and custom credential transfer flows? We are trying to determine the recommended onboarding architecture for future products. Thank you.

Context Our enterprise application is offline-first for iOS and iPadOS, designed to work completely offline, storing a very large local database (DB) and many attached files (images and videos) locally. Users create and update entities on the device.1 When connectivity is available, the app performs a bidirectional sync: local changes (including multi-gigabyte files) are uploaded, and thousands of DB updates are pulled down and applied locally. The Challenge: Foreground Requirement The complete sync process often requires 10 to 20 minutes to finish. Users expect their devices to proactively sync when online, even if it takes this long. Our fundamental problem is that, at present, users must keep the app in the foreground to complete the task. We have confirmed that on iOS, the system aggressively terminates the app process, typically after 30 seconds of being sent to the background. We currently advise users with large projects to keep the app in the foreground and connected to power.2 Existing Mitigation and Technical Details We have implemented several best practices to optimize transfers and manage device resources: We use battery checks before initiating large transfers, with a low battery threshold (around 15%) to pause actions if the device will enter a danger zone.2 Our upload mechanism uses HTTP Range Requests to implement a resumable single-stream approach for maximum throughput, ensuring that if a connection drops mid-transfer (even at 1.2 GB of a 2.5 GB file), we only re-transfer the remaining bytes, rather than losing all progress. This addresses network resilience and speed but not the OS background limitation.3 The Core Issue The various background options provided by iOS and iPadOS do not appear deterministic enough to reliably handle the immediate, extended data synchronization (uploading GB files and pulling down substantial DB changes) that we require. We are seeking a solution where a user-initiated task engages in background work almost immediately, reliably continuing for 10–20+ minutes after the user leaves the app or locks the screen, allowing for more "natural" device usage. Our Question for Apple Engineering Given the high volume of data transfer and the need for deterministic, extended background execution, what is Apple's current recommended, official approach for an enterprise app that requires prolonged background syncs—specifically, how can we architect this on iOS/iPadOS to reliably continue the upload and download of large data sets and database updates after the app moves out of the foreground?

Hello, I'm currently developing a NAC agent and, based on my research so far, it seems macOS does not allow the use of a custom 802.1X supplicant. Is there any roadmap or indication that Apple may support third-party/custom 802.1X supplicants in future macOS releases? I'd appreciate any clarification or insight on this topic.

Hi, Has the get-task-allow development bypass for NEFilterDataProvider been intentionally removed or changed in iOS 26? Previous DTS guidance in thread/31109 confirmed this bypass existed. I note that WWDC 2025 Session 234 states "iOS system-wide content filter is supported on supervised devices only" without mentioning it. My production deployment is supervised MDM devices — I am purely asking about the development testing path, which is not working for me on iOS 26.4.2. All I get is NEConfigurationErrorDomain Code=10 "permission denied" before my app code even runs. Thank you!

Hello, I'm developing a gambling blocker app that uses NEFilterDataProvider. My app was approved on the App Store, but the core feature doesn't work for end users. I have the content-filter-provider entitlement. Issue 1 — saveToPreferences() fails in distribution builds In dev builds (Xcode direct install), NEFilterManager.saveToPreferences() works fine — iOS shows a permission dialog and the filter is registered. In distribution builds (TestFlight/App Store), it fails immediately: NEFilterErrorDomain code 5 — Operation not permitted Console log from nehelper: "Creating a content filter configuration is only allowed through profile in production version" Issue 2 — .mobileconfig profile requires MDM Following the Console hint, I tried a .mobileconfig profile with com.apple.webcontent-filter payload (ContentFilterUUID, FilterType: Plugin, PluginBundleID). On an unsupervised consumer iPhone (iOS 18.5), installation fails: Profile Installation Failed — MDM required Question: What is the correct mechanism to activate a NEFilterDataProvider on a consumer (non-MDM) iPhone in a distribution build? Is there a specific entitlement or approval process I'm missing? (DTS Case-ID: 20087732)

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

I need to programmatically configure TLSv1.3 control parameters like cipher suites, Named Groups Signature Scheme I can see in the apple development documentation, there is a option to configure cipher suites but no way to configure Named Groups and Signature Scheme. Does anyone know a way to configure "Named Groups" & "Signature Schemes" also ? or If it is not possible in iOS then also Do we have anywhere written in documentation (evidence) ?

In my basement I have a couple of raspberry PIs that are collecting sensor data. They cannot send the data to any server because there is no signal in the basement. So my idea was to develop an app that would host a web server so that I can take my phone, go into the basement and enable the hotspot so that the raspberrys can connect to my phones Wifi and send their sensor data via API calls to the web server that is running on the phone. I have read about Vapor but somehow that feels like overkill for this problem. Do you guys have any recommendations how to solve this problem or better ideas than running a web server on the iPhone (and no, extending the wifi signal into the basement is not an option here)?