“iPhone 16 pro”

[quote='882274022, Davidbaraff2, /thread/820572?answerId=882274022#882274022, /profile/Davidbaraff2'] Do you know of any off the shelf VPNs that can be configured in the way you describe? [/quote] No. But my expertise is in VPN APIs, not VPN products. [quote='882274022, Davidbaraff2, /thread/820572?answerId=882274022#882274022, /profile/Davidbaraff2'] If you could point me [at code to] open sockets that will only use cellular [/quote] To start you off: Extra-ordinary Networking > Network Interface Techniques > Binding to an Interface explains how to bind a socket to a specific interface. Extra-ordinary Networking > Network Interface APIs > Network Interface Type explains how to identify the WWAN interface. [quote='882274022, Davidbaraff2, /thread/820572?answerId=882274022#882274022, /profile/Davidbaraff2'] We have total control of our local network. [/quote] So what happens if you don’t deploy a DHCP server on that network? I would expect that you’ll still be able to communicate with your iPads us

The 3 in that error is KERN_NO_SPACE, which is a pretty clear indication that the system memory allocator asked for address space and the kernel refused to give it. However, given all the constraints you’ve described, it’s not at all clear why that would be. Weirdly, the code that traps this way is not on the main branch of the Darwin open source, but I found a copy in the rel/libmalloc-792 branch [1]. Now, I don’t have time today to study that code in depth, but I figured you’d find it interesting (-: AFAICT it tries to allocate address space by using mach_vm_map to map MEMORY_OBJECT_NULL, specifying a start that’s after 16 GiB, such that it fits within 64 GiB, with a randomly applied offset. That random bit probably explains why this shows up so infrequently. It’s hard to say why this is failing. You might be able to learn more by running vmmap against the dying process. It’d also be interested to know what address was passed to mach_vm_map (with reference to the source, that’s the ptr_addr value),

only restart iPhone can solve the problem

⏺ That's it. The fix is: Removed ASSETCATALOG_COMPILER_LAUNCHIMAGE_NAME = LaunchImage from both Debug and Release build settings Added UILaunchStoryboardName = LaunchScreen to Info.plist Without a proper launch storyboard, UIKit falls back to a legacy compatibility mode that computes wrong screen dimensions on iPhone Air — causing the fractional tab bar height and the infinite layout loop. The LaunchScreen.storyboard already existed in the project but was never referenced.

You can also kill it by sudo pkill -9 remotepairingd If you encounter an instance where you actually find this necessary, please file a Feedback Assistant Report which includes a devicectl diagnose (and separate mac / phone / watch sysdiagnoses if they're not all collected by it). There are no known issues for which this step should be necessary, so if there are issues, we want to know about them. make sure NOT to un-pair your device If you un-pair or you accidentally tap the button to not trust, the only way to get the prompt to appear again is by physically re-connecting the phone. watch is ON throughout the connecting process Yes, and it needs to remain unlocked throughout the DDI mounting process as well. If the device locks before the DDI mounting completes, you will need to re-attempt mounting the DDI. --Jeremy jeremyhu at apple dot com

Thank you @Tomato and @DTS Engineer ! The purpose of my app is to provide a notification mechanism when there are drastic air quality changes. To accomplish this, I have an async function that makes a GET request to an air quality sensor (using UrlSession), decode the payload, and then do comparisons with previous readings. If the readings have changed drastically, an UNMutableNotificationContent() is scheduled. Currently, my async function is called from within a repeating scheduled timer so that I can poll my sensor every minute: Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in timerVal -= 1 if timerVal == 0 { timerVal = startVal getAQI() } } This all works just fine (including when the app is in the background) ONLY when I run the app from Build and Run in Xcode on my dev iPhone as the destination. I've left the app running this way for hours in the background and with the phone locked and it works great! However, when I try to run the app purely from the app shortcut on

First off, to clarify the purpose of this forum and my role at Apple, this forum is specifically to support engineers building products for our platform, not consumer-level support. I'm responding here because I hope the information will be helpful to you and to other engineers working on our hardware. However, I can't comment on if or when this will be fixed, nor am I the right person to try and pass feedback through. Secondly, on the feedback side, I'd appreciate you filling a bug on this and then posting the bug number back here so I can ensure it gets to the correct team. That's the best way to get this feedback to the relevant engineering team. In any case, I can't provide you with a direct solution, but I can confirm that this is basically what's going on: From what I am reading, it appears to be that the M4 Pro has 3 display lanes, and when I plug the first Studio Display XDR, it is using 2 lanes. More specifically, the kernel logic that assigns display pipes to monitors is not particularly so