We have total control of our local network. It's convenient to plug in 10 to 20 ipads and let them just obtain addresses via DHCP, but if for example we needed to give pre-assign the iPad static IP addresses, we can do that. If we need to put all these devices on some isolated subnetwork with no DHCP server we can do that. (I have no idea what the 192.168/x16 vs 24 distinction is or means but I'm sure we can do that too.) It's our local network. In short, we can do any freakin' thing required on the local network that helps us crack this problem. With that in mind, if you don't mind answering two questions you've raised now: Do you know of any off the shelf VPNs that can be configured in the way you describe? Going back the other direction: I can potentially rewrite libsrt (which is C/C++) to use sockets that only use cellular. I didn't think however that was possible on iOS (and Network was the only place I could do that). If you could point me to sample C/C++ code or the specific APIs from C/C++ that let me open sockets that will only use cellular, I can take a stab at it. My HTTP REST needs are quite modest, and I could probably roll something simple on top of Network to do those very few calls that absolutely have to be over cellular. Given all the above, if no VPNs exist with the required capabilities, if the socket rewrite doesn't pan out, will the App proxy, which can detect if a route is local or not, and simply uses a Network connection of the required type to just relay traffic to/from the original location work?

I said "I could, just maybe, rewrite the low level libsrt library to use sockets provided from Network, where I can force traffic over cellular." Actually, no, I can't. I thought Network could give me the equivalent of a socket, which I could fold back into libsrt, but it doesn't work that way. So at the application level, I cannot do this. The only choice appears to be something outside the app which forces the traffic onto a route through cellular. If that's not an app proxy, what could it be?

There is a DHCP server on the local LAN to assign addresses to devices. The criteria is simple: if my iPad is trying to talk to anything on say 192.168, it should use ethernet. Otherwise, it should use cellular. If an app proxy is the wrong tool for this, then can you suggest any other way to accomplish this? I could, just maybe, rewrite the low level libsrt library to use sockets provided from Network, where I can force traffic over cellular. The problem would be that my HTTP rest requests, which use URLSession, would have no way of being forced over cellular. Is there any library/framework that exists on top of Network that lets me make REST calls? If so, possibly doing all of this completely in app, i.e. forcing certain connections onto cellular while letting others do whatever the OS thinks is best, could be done. The other thing that could work is if the OS had some way of knowing: “yeah, this device is on a LAN. But I know the LAN won’t send traffic out to the general WAN, so any connections that aren’t local can’t try to go the LAN.” But I don’t believe it works that way… tell me if I’m wrong there.

Actually, the document you referred to isn’t so daunting. It’s the PDF about configurations which is overwhelming. That said, there is no place that I know of that documents how to set up the dictionary with NETestpAppMapping nor where it should go (the main app’s info file I assume). If there’s any documentation, or one can spell out exactly how you’re supposed to use an NEAppProxyProviderManager in dev to get going, that’d be great. I tried to create one but the console printed an error message that “must be MDM blah blah.” Presumably that’s because my attempt at providing the app mapping was flawed. I hope. This stuff is all so hard when there’s basically no good documents telling you how to start (without MDM) to even test. thanks again, you’re a life saver.

Assume the target devices are managed and the app is installed by MDM. My question of is an app proxy the right tool is really: Will an app proxy let me split the traffic in the way I envision? I have zero experience in this area. Can you suggest an easier way of getting this done. As always, thanks for your attention. Could you perhaps give a simple explanation of what a minimal configuration file would be, and how, simply for testing in dev, I can install it? I’ve looked at the reference document and it is a bit… daunting. I know what MDM is, I have a vague idea about configurations, and absolutely no experience here.

I made a much simpler project, but have been unable to get it to produce the error, even after running for upwards of 36 hours. I'm seeing if I can reproduce this in my more complex app. There is always the possibility that changes to the DockKit code in later iPhone OS versions have fixed the problem. If I can't my original (complicated) app to error out in a few more days of testing, I'll have to conclude that's what happened. I'll follow up again in a few more days.

Yes, I was using AVCaptureAudioDataOutput. But as I remarked, the problem is not present on two other webcams. I further discovered that the problematic webcam gets back into sync if you just run the capture session for about 5 minutes. There are posts on the web that the Insta360 Link 2 Webcam has known issues with audio/video sync when outputing h264 (but not, apparently, mjpeg). So this appears to really be an issue on Insta360's end. But thanks for the reply.

This turns out to have been specific to the webcam I was using (Insta360 Link 2). That particular webcam delivers out-of-sync video/audio streams, though curiously, if you let the capture session run, within about 5 minutes it usually sorts itself out and the delay is gone. Other webcams don't seem to have this issue. Nothing to see here folks, just keep moving along...

Just saw your response. (Side note: finally realized I have to turn on “email me about responses” to get notified when someone replies. Hopefully that works in the future.) I am absolutely interested in engaging with you on this, however, it will take some doing to distill this down to something I can send you. Even if I do so, it will likely take some time for me to run a workable example long enough to generate the bug, since as I indicated, I need to run the app for hours (sometimes days) before it shows up. I assume you all have access to the same hardware (Insta360 Flow Pro 2) in case I succeed at this? So, anyway, I’ll get back to you, but it may take some time before I can generate all that you’ve asked for. Separately, I’ve shown this to Insta360’s enterprise SDK group, and they are (hopefully) working on it as well. If they make any progress, I’ll let you know.

Are there any DockKit engineers at Apple even reading these posts?

Oh, here's one clue related to the first issue: when you turn the accessory on, you sometimes get a popup "Instaflow 360 detected" and if you tap on it, launches the Insta360 app (which fixes the issue). Somehow the Instaflow 360 app has some specialness associated with this hardware device, such that the app is advertised in this state. How is that accomplished? Let's have a fair playing field here! :) You know you're in the correct state when the Instaflow 360 does the cute "nod its head at you" gesture, but like I said, it shouldn't be necessary to run their app to get back to this state after powering/unpowering the dock accessory.

Here's my own personal track() routine, since dockkit's track() doesn't meet my needs: var errorIsLarge = false func track(rectangles: [CGRect], fov: Double) async { guard !rectangles.isEmpty else { await setVelocity(pitch: 0, yaw: 0, roll: 0) return } let r = rectangles.reduce(CGRect.null) { $0.union($1) } let xOffset = 2 * (r.midX - 0.5) var thetaOffset = xOffset * fov print("Tracking: \(thetaOffset.asDegrees) degrees off, midX = \(r.midX)") if abs(thetaOffset) > (3.0).asRadians { print("Error is large set true") errorIsLarge = true } if abs(thetaOffset) < (3.0).asRadians { if !errorIsLarge { thetaOffset = 0 } } if abs(thetaOffset) < (1.0).asRadians { errorIsLarge = false print("error is large is FALSE") thetaOffset = 0 } print("Setting velocity to \(-thetaOffset * 3)") await setVelocity(pitch: 0, yaw: -thetaOffset * 3, roll: 0) What are we doing here? Whenever we get more than 3 degrees off target, that's enough error to try to correct it. If our error is less than 3 degrees, and we're not in a "large error state", ignore the error. We want smooth tracking. We leave being in a "large" error state when we reduce the error to less than 1 degree. We set the velocity to the opposite of 3 X thetaOffset, where thetaOffset is how far off target we are, noting that as I said above, at times we want to tolerate small errors. The idea is that if you get close enough, stop trying to micro-correct. In my case, I'm taking all my observation rectangles, unioning them, and taking the center. However you make observations, at the end of the day, you're going to get some absolute theta error, and that's what you deal with. Note: I'm not trying to pitch up or down (or, god forbid, roll!) the camera. Just yaw (i.e. rotate around the vertical axis).

For a little while I tried to pass rectangles to dockAccessory.track(), but then I gave up. For whatever reason, it didn't seem to work so well. Instead, I measure how far the center of my rectangle is from being centered in the image (in angular units), and then call setVelocity (in the "yaw" axis) with a speed that is proportional to this distance. (If you get the sign wrong, you'll figure it out... quickly.) I observed this gave me much smoother results than letting the camera do its own tracking. I also tried to directly call setOrientation() to make the camera turn to what I think should be the exact amount, but that works poorly. Using the error of how far the center of the rectangle is from the image center, as a measure of how fast to rotate the camera, gives much smoother results. Note: be very careful that if you don't call this routine very frequently, that you have a safeguard in place to countermand the last "setVelocity" call. Because if you don't, and the last thing you tell the camera is "rotate that way with speed X", and you never say anything again, your camera will just spin and spin and spin...

I'll let you know. I had actually given up hope that this would work, because I see lots of posts about people getting popups saying "You don't appear to be connected to the internet" which makes it seem like if you do hotspot to an accessory, in most cases that's your current wifi connection, and you're going to get that message. But, if in fact, that's only for accessories that "lie" about their capabilities, maybe it's not entirely hopeless. I guess I'll do the experiment and see what transpires.

I seemed to have asked about the same requirement just yesterday: "The camera's Wi-Fi does not have internet access; it is purely for file transfers (e.g., photos/videos) between the camera and the iOS app and to command camera to do certain actions. The iOS device should still use mobile data for internet access while connected to the camera's Wi-Fi. The mobile data will be used to upload files to the cloud, as I have a large data plan available for internet use." Please, if you do figure this out, let me know? (email: davidbaraff @ icloud.com )