Hello,
I am developing with the Nearby Interaction framework using third-party UWB accessories (Murata SR040/SR150).
I observed a difference between U1-based and U2-based iPhones:
iPhone 12 Pro (U1 chip)
NINearbyObject.direction returns valid 3D vector (x, y, z).
Distance and direction both work as expected.
iPhone 15 Pro and iPhone 16 Pro (U2 chip)
NINearbyObject.direction is always nil.
Only distance is returned (around 0.35–0.40 m in my test).
Effectively behaves as "distance-only mode".
Environment:
Hardware: iPhone 12 Pro, iPhone 15 Pro
iOS version: 18.5
Accessory: Murata UWB SR040 / SR150
App: Using NINearbyAccessoryConfiguration with BLE-based discovery
Info.plist includes NSNearbyInteractionUsageDescription
Camera assistance was tested both ON and OFF
Expectation:
I expected the U2 chip to behave consistently with U1, i.e. provide direction vectors when possible.
Instead, on iPhone 15 Pro, direction is always unavailable (nil) while distance is returned correctly.
Questions:
Is this an intentional limitation for U2 chip + third-party accessories?
Is there a new requirement (e.g. certification, firmware update, capability flags) to enable direction on U2 devices?
Could this be related to NIDeviceCapability or the new Extended Distance Measurement (EDM) mode in U2?
Thanks in advance for any clarification.
Delve into the world of built-in app and system services available to developers. Discuss leveraging these services to enhance your app's functionality and user experience.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hi,
I am experiencing an issue where my in-app purchase products cannot be fetched from App Store Connect during sandbox testing, despite all products being properly configured.
ERROR MESSAGE:
When testing on a physical iOS device, I receive the following error:
"Error fetching offerings - The operation couldn't be completed. (RevenueCat.OfferingsManager.Error error 1.) There's a problem with your configuration. None of the products registered in the RevenueCat dashboard could be fetched from App Store Connect (or the StoreKit Configuration file if one is being used)."
All products show status "READY_TO_SUBMIT" with the warning: "This product's status (READY_TO_SUBMIT) requires you to take action in App Store Connect before using it in production purchases."
I have 2 subscriptions and 4 Consumable in-app purchases set up in App Store Connect.
VERIFICATION COMPLETED:
Bundle ID matches exactly in App Store Connect, Xcode project, and RevenueCat dashboard
Product IDs match exactly between App Store Connect, RevenueCat, and application code
Paid Applications Agreement is signed and active (Signed on 12/9 morning, everything shows as active)
All products are in "Ready to Submit" status with complete metadata
All products are properly linked to the app in App Store Connect
Testing on physical iOS device (not simulator) with sandbox account signed in via Settings > Developer section
Products have been in "Ready to Submit" status for 8 hours
I have researched this error and verified the common causes (Paid Agreements, Product ID mismatches, Bundle ID mismatches) are all correctly configured on my end.
QUESTION:
Is this an issue on Apple's end, or are there additional requirements for products in "Ready to Submit" status to be available in sandbox testing? I have been unable to test my in-app purchases despite all configuration appearing correct.
Thank you for your assistance.
Topic:
App & System Services
SubTopic:
StoreKit
I have a watch only app that display an open/close park status and the current temperature with a current condition icon. That's it. On second submission the watch app was rejected due to no WeatherKit attribution. I have a lack of clarity of what's needed. With my single view that display my content I don't want WeatherKit attribution to overwhelm what's being presented to the user. I've tried looking for watch apps in the store that provide attribution and I'm not finding any. Looking for advice on how to meet this requirement without attribution overpowering my content.
I'm trying to test the update process for an app containing an FSKit module that I'm distributing on the Mac App Store. (I'm also distributing the same app directly with Developer ID, but here I'll focus on App Store because that's the behavior I've been looking at first.) To do that I'm using an internal tester group on TestFlight and then testing an update with TestFlight. Below is the behavior I'm seeing on macOS 15.7.2 (24G325).
I've noticed that if an app update is triggered while a disk is mounted using the FSKit extension, the disk is automatically unmounted without warning (FB21287341). That's already undesirable itself in my opinion, but on top of the unmount, there are two other problems:
That unmount doesn't seem to be a "clean" unmount and doesn't call functions like synchronize (FB21287688). Now, in my case, my app only provides read-only access, so that doesn't actually matter much in my case. However, I'd imagine if I were to add write access at some point in the future, this would go from "doesn't matter" to "very bad."
I've seen a few cases where quitting or crashing the FSModule process while a volume is mounted without actually doing a clean unmount causes a lot of "disk-related actions" (for lack of a better term) to freeze (FB21305906). For example, a use of the mount(8) command or trying to mount a disk at all freezes, and opening Disk Utility stalls on a "Loading disks" spinning indicator. This happens until the Mac is rebooted. I did notice this issue once while testing updates via TestFlight a few times.
The same applies if I simply delete the app with Finder instead of updating it.
Is there a way to prevent the extension's process from terminating in this case and/or another workaround I could use without waiting for a macOS update to hopefully change this behavior?
And does observing this kind of behavior with TestFlight's update behavior suggest the same thing could happen on the App Store with its automatic updates? I'm concerned that pushing an update via the App Store will unexpectedly unmount disks or cause the system-wide issues described in FB21305906 at a random time, which is a pretty big disruption for users.
If I have two iOS apps, with bundle ids com.mycompany.A and com.mycompany.B, and they both have the shared group id of group.com.mycompany.B, then they can read/write data to same file (in shared defaults or, for example, a Realm database saved to the same shared group location).
What I have noticed is that if both apps get installed and some data X written to shared defaults (but data which isn't accessed by both apps i.e. if only app A uses this data), then if app A is deleted and reinstalled then X is not deleted in this situation (unless both apps A and B are deleted).
I guess that is to be expected as they both use the same group id and the OS won't clear that area out unless both apps are deleted.
However I think I am seeing a situation where if app A has group.com.mycompany.A as its group and app B has group.com.mycompany.B as its group, then this is still the same situation - data written by app B for doesn't get deleted if only app B is deleted/reinstalled on the phone. It won't get deleted unless both app B and A are deleted from the phone.
This is not what I was expecting.
I need to perform some more checks (its more complex to verify as app A is developed by one company and app B by another), but if this were to be the case would this be unexpected behavior by the OS? Presumably it would be unexpected as the container should be identified by the full group id and not a partial portion of the group id right?
We're developing an Electron app for MacOS App Store. When updating our app through TestFlight, TestFlight prompts "Close This App to Update", and when I click "Continue" our app would be "Terminated" for update.
Now this is where things go wrong. On MacOS 15 our app seems to be gracefully terminating (We attached it with lldb and it shows that our app returns with 0 when we click "Continue") which is fine.
However for MacOS 26 though, it seems that TestFlight just directly SIGKILLs our app (indicated by lldb), which means that all of our app's child processes are left orphaned. Even worse, our app is singleton, which means that when the app relaunches it fails, because the leftover child processes from the previously SIGKILLed session is still alive, and even if we want to kill those orphaned child processes we can't because our app is sandboxed thus cannot kill processes outside of the current sandbox.
We captured output from log stream (app name redacted):
12-02 22:08:16.477036-0800 0x5452 Default 0x5a4a7 677 7 installcoordinationd: [com.apple.installcoordination:daemon] -[IXSCoordinatorProgress setTotalUnitsCompleted:]: Progress for coordinator: [com.our.app/Invalid/[user-defined//Applications/OurApp.app]], Phase: IXCoordinatorProgressPhaseLoading, Percentage: 99.454 123: Attempt to set units completed on finished progress: 214095161 2025-12-02 22:08:16.483056-0800 0x53ba Default 0x5a5c9 167 0 runningboardd: (RunningBoard) [com.apple.runningboard:connection] Received termination request from [osservice<com.apple.installcoordinationd(274)>:677] on <RBSProcessPredicate <RBSProcessBundleIdentifierPredicate "com.our.app">> with context <RBSTerminateContext| explanation:installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N re portType:None maxTerminationResistance:Absolute attrs:[ 2025-12-02 22:08:16.488651-0800 0x53ba Default 0x5a5c9 167 7 runningboardd: (RunningBoard) [com.apple.runningboard:ttl] Acquiring assertion targeting system from originator [osservice<com.apple.installcoordinationd(274)>:677] with description <RBSAssertionDescriptor| "installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N" ID:167-677-1463 target:system attributes:[ 2025-12-02 22:08:16.489353-0800 0x53ba Default 0x5a5c9 167 0 runningboardd: (RunningBoard) [com.apple.runningboard:process] [app<application.com.our.app.485547.485561(501)>:2470] Terminating with context: <RBSTerminateContext| explanation:installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N reportType:None maxTerminationResistance:Absolute attrs:[ 2025-12-02 22:10:23.920869-0800 0x5a5a Default 0x5a4c6 674 14 appstoreagent: [com.apple.appstored:Library] [A95D57D7] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} 2025-12-02 22:10:32.027304-0800 0x5ae5 Default 0x5a4c7 674 14 appstoreagent: [com.apple.appstored:Library] [BEB5F2FD] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} 2025-12-02 22:10:36.542321-0800 0x5b81 Default 0x5a4c8 674 14 appstoreagent: [com.apple.appstored:Library] [185B9DD6] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0}
The line "Terminating with context" seems suspicious. This line is not seen on MacOS 15, only MacOS 26. Is this documented behavior? If so, how can we handle this?
Topic:
App & System Services
SubTopic:
Processes & Concurrency
Tags:
App Store
Mac App Store
TestFlight
Hi everyone,
I have a question regarding the intended privacy limits of the DeviceActivityReportExtension.
According to the documentation and the WWDC21 session "Meet the Screen Time API", this extension was created specifically to prevent the host application from accessing the user's underlying activity data (websites visited, app usage, screen time, etc).
But I have found that my host app is actually able to reconstruct this raw activity data from the activity report. I am able to extract specific visited websites and app usage durations back into the main app.
I reported this to Apple Security (Case ID: OE1100504480881 ), assuming it was a sandbox bypass. However, they closed the ticket stating that this is "expected behavior" and requires no fix.
My question for Screen Time Engineers: Is the documentation incorrect? If my host app is expected to be able to read this data, is there a formal API we should be using instead of extracting it from the report extension?
The current behavior contradicts the privacy limits described in the documentation, so I am confused if I should rely on this data access for my app features or if it will be patched later.
Thanks.
Hello,
I have a problem with a subscription: it is not recognised by my application (under TestFlight); it is as if it did not exist.
I have two subscriptions in the same group, a premium subscription that works perfectly and a basic subscription that is not recognised.
I have checked everything at least twenty times. Its status is ‘Ready to submit’.
I asked GPT 5.1 and Claude AI, but clearly both of their AIs are out of date and are giving me an obsolete procedure with App Store Connect options that don't exist.
App intent has a perform method that is async and can throw an error, but I can't find a way to actually await the result and catch the error if needed.
If I convert this working but non-waiting, non-catching code:
Button("Go", intent: MyIntent())
to this (so I can control awaiting and error handling):
Button("Go") {
Task {
do {
try await MyIntent().perform() // 👈
} catch {
print(error)
}
}
}
It crashes:
AppDependency with key "foo" of type Bar.Type was not initialized prior to access. Dependency values can only be accessed inside of the intent perform flow and within types conforming to _SupportsAppDependencies unless the value of the dependency is manually set prior to access.
Although it is invalid since the first version is working like a charm and dependencies are registered in the @main App init method and it is in the perform flow.
So how can we await the result of the AppIntent and handle the errors if needed in the app? Should I re-invent the Dependency mechanism?
Hello,
I'm using PassKit with to perform Apple Pay payment in a financial application.
Our approach are:
On iOS application, define PKMerchantCapability threeDSecure and credit, perform apple pay experience and get the encrypted response.
On PCI service, receive the encrypted data Payment token, decrypt this data, and use to perform the payment.
The problem is, in MasterCard transaction the eciIndicator is missing.
I want to know if has some rule or problem about it.
Hi everyone,
I'm building a task management app that layers on top of EventKit/Reminders. I'm also moderating /r/AppleReminders.
I see a confusion around the semantics of dates on both the developer side and on the user side.
I'm trying to map the standard productivity mental model to the EKReminder implementation and hitting some walls.
In productivity contexts, a task tends to have three distinct dates:
Start Date: When the task becomes actionable — Don’t alert the user before this date.
Notification: When the device should buzz/ping the user — Meaning that they can get started on the task.
Due Date: Hard deadline — If the system works well, tasks are meant to rarely be past-deadline; productivity systems are about meeting deadlines rather than about missing them.
The EventKit Reality
Here is what I’m seeing in practice, and I’m hoping someone can correct me if I’m wrong:
Field
Description
In Practice (Reminders App)
startDateComponents
Docs say "start date of the task"
Seemingly unused? I can set it via API, but the Reminders app UI ignores it. It doesn't seem to trigger visibility in "Today" or Smart Lists.
dueDateComponents
Docs say "date by which reminder should be completed"
Conflated. Acts as the "Date" you see in the list. It functions as the Start Date (shows in Today), Due Date (turns red tomorrow), AND Notification time (unless early alerts are set).
alarms
Inherited from EKCalendarItem
seems to be used for the actual notifications, including "Early Reminders," but tightly coupled to the due date in the UI.
My Questions:
Is startDateComponents effectively a dead field? Is there any native behavior (Smart List filtering, sorting, visibility) that respects this field, or is it purely for metadata storage for third-party apps?
Smart List Logic: I was hoping to create a Smart List that shows "Actionable" items (i.e., Start Date <= Today). However, the Smart List filters only offer a generic "Date" field, which maps to dueDateComponents. Has anyone successfully filtered by startDateComponents in a native Smart List?
Conflation: Is there any "blessed" way to set a Due Date that is distinct from the Notification time without fighting the system? (e.g. Due Friday, but remind me Wednesday).
Any insight into the intended semantics here would be huge. I'm trying to avoid fighting the framework, but the "One Date to Rule Them All" approach in the Reminders app is making it tricky to support separate Start/Due dates.
Thanks!
LiveActivity using colorScheme to adapt to dark mode in iOS 26 system does not work
The system keeps returning. mark, unable to switch
I have been working on a multi-platform multi-touch HID-standard digitizer clickpad device.
The device uses Bluetooth Low Energy (BLE) as its connectivity transport and advertises HID over GATT. To date, I have the device working successfully on Windows 11 as a multi-touch, gesture-capable click pad with no custom driver or app on Windows.
However, I have been having difficulty getting macOS to recognize and react to it as a HID-standard multi-touch click pad digitizer with either the standard Apple HID driver (AppleUserHIDEventDriver) or with a custom-coded driver extension (DEXT) modeled, based on the DTS stylus example and looking at the IOHIDFamily open source driver(s).
The trackpad works with full-gesture support on Windows 11 and the descriptors seem to be compliant with the R23 Accessory Guidelines document, §15.
With the standard, matching Apple AppleUserHIDEventDriver HID driver, when enumerating using stock-standard HID mouse descriptors, the device works fine on macOS 14.7 "Sonoma" as a relative pointer device with scroll wheel capability (two finger swipe generates a HID scroll report) and a single button.
With the standard, matching Apple AppleUserHIDEventDriver HID driver, when enumerating using stock-standard HID digitizer click/touch pad descriptors (those same descriptors used successfully on Windows 11), the device does nothing. No button, no cursor, no gestures, nothing. Looking at ioreg -filtb, all of the key/value pairs for the driver match look correct.
Because, even with the Apple open source IOHIDFamily drivers noted above, we could get little visibility into what might be going wrong, I wrote a custom DriverKit/HIDDriverKit driver extension (DEXT) (as noted above, based on the DTS HID stylus example and the open source IOHIDEventDriver.
With that custom driver, I can get a single button click from the click pad to work by dispatching button events to dispatchRelativePointerEvent; however, when parsing, processing, and dispatching HID digitizer touch finger (that is, transducer) events via IOUserHIDEventService::dispatchDigitizerTouchEvent, nothing happens.
If I log with:
% sudo log stream --info --debug --predicate '(subsystem == "com.apple.iohid")'
either using the standard AppleUserHIDEventDriver driver or our custom driver, we can see that our input events are tickling the IOHIDNXEventTranslatorSessionFilter HID event filter, so we know HID events are getting from the device into the macOS HID stack. This was further confirmed with the DTS Bluetooth PacketLogger app. Based on these events flowing in and hitting IOHIDNXEventTranslatorSessionFilter, using the standard AppleUserHIDEventDriver driver or our custom driver, clicks or click pad activity will either wake the display or system from sleep and activity will keep the display or system from going to sleep.
In short, whether with the stock driver or our custom driver, HID input reports come in over Bluetooth and get processed successfully; however, nothing happens—no pointer movement or gesture recognition.
STEPS TO REPRODUCE
For the standard AppleUserHIDEventDriver:
Pair the device with macOS 14.7 "Sonoma" using the Bluetooth menu.
Confirm that it is paired / bonded / connected in the Bluetooth menu.
Attempt to click or move one or more fingers on the touchpad surface.
Nothing happens.
For the our custom driver:
Pair the device with macOS 14.7 "Sonoma" using the Bluetooth menu.
Confirm that it is paired / bonded / connected in the Bluetooth menu.
Attempt to click or move one or more fingers on the touchpad surface.
Clicks are correctly registered. With transducer movement, regardless of the number of fingers, nothing happens.
操作步骤:1:调用let eligible = try await AgeRangeService.shared.isEligibleForAgeFeatures,返回YES后,再次调用 let response = try await AgeRangeService.shared.requestAgeRange(ageGates:18, in: viewController)
switch response {
case .declinedSharing:
DispatchQueue.main.async {
completion(.declinedSharing, nil, nil)
}
case .sharing(let swiftRange):
DispatchQueue.main.async {
let model = ARAgeRange(swiftRange: swiftRange)
completion(.sharing, model, nil)
}
[MTAgeRangeService requestEligibility:^(BOOL eligible) {
if (eligible) {
//您应用程序的用户所在的地区,需要执行特定年龄相关义务
[MTAgeRangeService requestAgeRangeWithAgeGates:18 in:[ViewU getCurrentVC] completion:^(enum ARResponseType responseType, ARAgeRange * _Nullable ageRange, NSError * _Nullable error) {
[weakself.ageRangeLoadingView dissmiss];
self->_ageRangeLoadingView = nil;
if (responseType == ARResponseTypeSharing) {
//用户同意并分享了年龄范围
if ([ageRange.lowerBound intValue] >= 18) {
//满18岁可以注册
}else{
//不到18岁不能注册,提示一下
}
}else{
//用户拒绝或者其他未知错误,需要提示
}else{
}
}
}] ;
}else{
}];
I'm facing a problem where notification permissions are working fine in the main app, but failing in the Device Activity Report Extension on iOS 26. This issue wasn’t present in earlier iOS versions. Despite having notification permissions granted in the main app, the extension fails to get authorization.
iOS 26:
"
Before iOS 26:
Topic:
App & System Services
SubTopic:
General
Tags:
Notification Center
User Notifications
Screen Time
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"
Network Interface APIs
Most developers don’t need to interact directly with network interfaces. If you do, read this post for a summary of the APIs available to you.
Before you read this, read Network Interface Concepts.
Interface List
The standard way to get a list of interfaces and their addresses is getifaddrs. To learn more about this API, see its man page.
A network interface has four fundamental attributes:
A set of flags — These are packed into a CUnsignedInt. The flags bits are declared in <net/if.h>, starting with IFF_UP.
An interface type — See Network Interface Type, below.
An interface index — Valid indexes are greater than 0.
A BSD interface name. For example, an Ethernet interface might be called en0. The interface name is shared between multiple network interfaces running over a given hardware interface. For example, IPv4 and IPv6 running over that Ethernet interface will both have the name en0.
WARNING BSD interface names are not considered API. There’s no guarantee, for example, that an iPhone’s Wi-Fi interface is en0.
You can map between the last two using if_indextoname and if_nametoindex. See the if_indextoname man page for details.
An interface may also have address information. If present, this always includes the interface address (ifa_addr) and the network mask (ifa_netmask). In addition:
Broadcast-capable interfaces (IFF_BROADCAST) have a broadcast address (ifa_broadaddr, which is an alias for ifa_dstaddr).
Point-to-point interfaces (IFF_POINTOPOINT) have a destination address (ifa_dstaddr).
Calling getifaddrs from Swift is a bit tricky. For an example of this, see QSocket: Interfaces.
IP Address List
Once you have getifaddrs working, it’s relatively easy to manipulate the results to build a list of just IP addresses, a list of IP addresses for each interface, and so on. QSocket: Interfaces has some Swift snippets that show this.
Interface List Updates
The interface list can change over time. Hardware interfaces can be added and removed, network interfaces come up and go down, and their addresses can change. It’s best to avoid caching information from getifaddrs. If thats unavoidable, use the kNotifySCNetworkChange Darwin notification to update your cache. For information about registering for Darwin notifications, see the notify man page (in section 3).
This notification just tells you that something has changed. It’s up to you to fetch the new interface list and adjust your cache accordingly.
You’ll find that this notification is sometimes posted numerous times in rapid succession. To avoid unnecessary thrashing, debounce it.
While the Darwin notification API is easy to call from Swift, Swift does not import kNotifySCNetworkChange. To fix that, define that value yourself, calling a C function to get the value:
var kNotifySCNetworkChange: UnsafePointer<CChar> {
networkChangeNotifyKey()
}
Here’s what that C function looks like:
extern const char * networkChangeNotifyKey(void) {
return kNotifySCNetworkChange;
}
Network Interface Type
There are two ways to think about a network interface’s type. Historically there were a wide variety of weird and wonderful types of network interfaces. The following code gets this legacy value for a specific BSD interface name:
func legacyTypeForInterfaceNamed(_ name: String) -> UInt8? {
var addrList: UnsafeMutablePointer<ifaddrs>? = nil
let err = getifaddrs(&addrList)
// In theory we could check `errno` here but, honestly, what are gonna
// do with that info?
guard
err >= 0,
let first = addrList
else { return nil }
defer { freeifaddrs(addrList) }
return sequence(first: first, next: { $0.pointee.ifa_next })
.compactMap { addr in
guard
let nameC = addr.pointee.ifa_name,
name == String(cString: nameC),
let sa = addr.pointee.ifa_addr,
sa.pointee.sa_family == AF_LINK,
let data = addr.pointee.ifa_data
else { return nil }
return data.assumingMemoryBound(to: if_data.self).pointee.ifi_type
}
.first
}
The values are defined in <net/if_types.h>, starting with IFT_OTHER.
However, this value is rarely useful because many interfaces ‘look like’ Ethernet and thus have a type of IFT_ETHER.
Network framework has the concept of an interface’s functional type. This is an indication of how the interface fits into the system. There are two ways to get an interface’s functional type:
If you’re using Network framework and have an NWInterface value, get the type property.
If not, call ioctl with a SIOCGIFFUNCTIONALTYPE request. The return values are defined in <net/if.h>, starting with IFRTYPE_FUNCTIONAL_UNKNOWN.
Swift does not import SIOCGIFFUNCTIONALTYPE, so it’s best to write this code in a C:
extern uint32_t functionalTypeForInterfaceNamed(const char * name) {
int fd = socket(AF_INET, SOCK_DGRAM, 0);
if (fd < 0) { return IFRTYPE_FUNCTIONAL_UNKNOWN; }
struct ifreq ifr = {};
strlcpy(ifr.ifr_name, name, sizeof(ifr.ifr_name));
bool success = ioctl(fd, SIOCGIFFUNCTIONALTYPE, &ifr) >= 0;
int junk = close(fd);
assert(junk == 0);
if ( ! success ) { return IFRTYPE_FUNCTIONAL_UNKNOWN; }
return ifr.ifr_ifru.ifru_functional_type;
}
Finally, TN3158 Resolving Xcode 15 device connection issues documents the SIOCGIFDIRECTLINK flag as a specific way to identify the network interfaces uses by Xcode for device connection traffic.
Revision History
2025-12-10 Added info about SIOCGIFDIRECTLINK.
2023-07-19 First posted.
Hi Team,
We have a requirement for device-to-device communication using the Multipeer Connectivity framework without requiring Wi-
Fi connectivity.
Current Status:
Multipeer communication works successfully when Wi-Fi is enabled
Connection fails when using Bluetooth-only (Wi-Fi disabled, in Airplane Mode)
Concern:
We've found forum suggesting that Multipeer Connectivity over Bluetooth-only has been restricted since iOS 11, despite
Apple's documentation stating support for both Wi-Fi and Bluetooth transports.
Request:
Could you please confirm:
Whether Bluetooth-only Multipeer Connectivity is officially supported in current iOS versions( iOS 18.0+)?
If there are specific configurations or entitlements required for Bluetooth-only operation?
Any known limitations or alternative approaches for offline device-to-device communication?
This clarification will help us determine the appropriate implementation strategy for our offline communication
requirements.
Thank you.
Hi there,
I'm trying to work on an architecture where one app exposes an API (Extension Host) that other apps can plugin to. I've been reading all I can from the docs and whatever I can find online. It seemed like iOS26 added the ability to do such a thing (at least in early builds).
Is that the case?
Has the functionality been walked back such that extensions can only be loaded in iOS from within the single app bundle?
My use case is the following:
I'm working on an agent app that desires to have 3rd party developers add functionality (think how MCP servers add functionality to LLMs). The 3rd party plugins would be provided in their own app bundles vetted by the AppStore review team, of course, and would only provide hooks, basically, the main app can use to execute functions or get state.
This is the best thread I found on the topic, and the subtext is that it needs to be in the same bundle. https://developer.apple.com/forums/thread/803896?answerId=865314022#865314022
Let's say for the moment that this isn't possible using ExtensionKit. What's the best way to achieve this? Our current best alternative idea is a hidded WebKit window that runs JS/WASM but that's so hackish.
Please let me know, thanks!
Summary
NetworkConnection<WebSocket> in iOS 26 Network framework throws POSIXErrorCode(rawValue: 22): Invalid argument when receiving WebSocket ping (opcode 9) or pong (opcode 10) control frames. This prevents proper WebSocket keep-alive functionality.
Environment
iOS 26.0 (Simulator)
macOS 26.1
Xcode 26.0
Note: This issue was initially discovered on iOS 26 Simulator. The same behavior was confirmed on macOS 26, suggesting a shared bug in the Network framework. The attached sample code is for macOS for easier reproduction.
Description
When using the new NetworkConnection<WebSocket> API introduced in iOS 26 or macOS 26, the receive() method throws EINVAL error whenever a ping or pong control frame is received from the server.
This is a critical issue because:
WebSocket servers commonly send ping frames to keep connections alive
Clients send ping frames to verify connection health
The receive callback never receives the ping/pong frame - the error occurs before the frame reaches user code
Steps to Reproduce
Create a WebSocket connection to any server that supports ping/pong (e.g., wss://echo.websocket.org):
import Foundation
import Network
// MARK: - WebSocket Ping/Pong EINVAL Bug Reproduction
// This sample demonstrates that NetworkConnection<WebSocket> throws EINVAL
// when receiving ping or pong control frames.
@main
struct WebSocketPingPongBug {
static func main() async {
print("=== WebSocket Ping/Pong EINVAL Bug Reproduction ===\n")
do {
try await testPingPong()
} catch {
print("Test failed with error: \(error)")
}
}
static func testPingPong() async throws {
let host = "echo.websocket.org"
let port: UInt16 = 443
print("Connecting to wss://\(host)...")
let endpoint = NWEndpoint.hostPort(
host: NWEndpoint.Host(host),
port: NWEndpoint.Port(rawValue: port)!
)
try await withNetworkConnection(to: endpoint, using: {
WebSocket {
TLS {
TCP()
}
}
}) { connection in
print("Connected!\n")
// Start receive loop in background
let receiveTask = Task {
var messageCount = 0
while !Task.isCancelled {
do {
let (data, metadata) = try await connection.receive()
messageCount += 1
print("[\(messageCount)] Received frame - opcode: \(metadata.opcode)")
if let text = String(data: data, encoding: .utf8) {
print("[\(messageCount)] Content: \(text)")
} else {
print("[\(messageCount)] Binary data: \(data.count) bytes")
}
} catch let error as NWError {
if case .posix(let code) = error, code == .EINVAL {
print("❌ EINVAL error occurred! (POSIXErrorCode 22: Invalid argument)")
print(" This is the bug - ping/pong frame caused EINVAL")
// Continue to demonstrate workaround
continue
}
print("Receive error: \(error)")
break
} catch {
print("Receive error: \(error)")
break
}
}
}
// Wait for initial message from server
try await Task.sleep(for: .seconds(2))
// Test 1: Send text message (should work)
print("\n--- Test 1: Sending text message ---")
try await connection.send("Hello, WebSocket!")
print("✅ Text message sent")
try await Task.sleep(for: .seconds(1))
// Test 2: Send ping (pong response will cause EINVAL)
print("\n--- Test 2: Sending ping frame ---")
print("Expecting EINVAL when pong is received...")
let pingMetadata = NWProtocolWebSocket.Metadata(opcode: .ping)
try await connection.ping(Data()) {
pingMetadata
}
print("✅ Ping sent, waiting for pong...")
// Wait for pong response
try await Task.sleep(for: .seconds(2))
// Cleanup
receiveTask.cancel()
print("\n=== Test Complete ===")
print("If you saw 'EINVAL error occurred!' above, the bug is reproduced.")
}
}
}
The receive() call fails with error when pong arrives:
❌ EINVAL error occurred! (POSIXErrorCode 22: Invalid argument)
Test Results
Scenario
Result
Send/receive text (opcode 1)
✅ OK
Client sends ping, receives pong
❌ EINVAL on pong receive
Expected Behavior
The receive() method should successfully return ping and pong frames, or at minimum, handle them internally without throwing an error. The autoReplyPing option should allow automatic pong responses without disrupting the receive loop.
Actual Behavior
When a ping or pong control frame is received:
The receive() method throws NWError.posix(.EINVAL)
The frame never reaches user code (no opcode check is possible)
The connection remains valid, but the receive loop is interrupted
Workaround
Catch the EINVAL error and restart the receive loop:
while !Task.isCancelled {
do {
let received = try await connection.receive()
// Process message
} catch let error as NWError {
if case .posix(let code) = error, code == .EINVAL {
// Control frame caused EINVAL, continue receiving
continue
}
throw error
}
}
This workaround allows continued operation but:
Cannot distinguish between ping-related EINVAL and other EINVAL errors
Cannot access the ping/pong frame content
Cannot implement custom ping/pong handling
Impact
WebSocket connections to servers that send periodic pings will experience repeated EINVAL errors
Applications must implement workarounds that may mask other legitimate errors
Additional Information
Packet capture confirms ping/pong frames are correctly transmitted at the network level
The error occurs in the Network framework's internal processing, before reaching user code