İOS 26 beta battery %1

[quote='864098022, Pasjonsfrukt, /thread/803580?answerId=864098022#864098022, /profile/Pasjonsfrukt'] Sorry for the late response! [/quote] No worries. I have plenty of other things to do (-: [quote='864098022, Pasjonsfrukt, /thread/803580?answerId=864098022#864098022, /profile/Pasjonsfrukt'] We have not seen the issue when we connect to the AP through Settings > Wi-Fi. [/quote] OK. The reason I asked is that here on the Apple Developer Forums our primary focus is on APIs. If you were able to reproduce the problem in Settings then that’d eliminate any possibility that your iOS code is incorrect. Without being able to reproduce it in Settings, it’s possible that this is a bug in your app (you occasionally pass in the wrong Wi-Fi details) or in the Network Extension layer that you’re calling (as opposed to the core Wi-FI layer that does all the heavy lifting here). However, the actual error you’re seeing here, failed to association error 1, is a strong indication of an issue in the core Wi-

Hmmm, this is the second question I’ve seen about SAML-based SSO in the past week. Are you working on the same product as francisaugustomedeiros over in SAML with SSO extension triggering twice? Or is this just a coincidence? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I pasted a concrete example of calling Swift from C++ in your other thread. Admittedly, this was calling a class not a struct, but it seems like a reasonable place to start. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='805580021, hoppedevz, /thread/805580, /profile/hoppedevz'] Is there any way to retrieve the memory pressure percentage using native libraries? [/quote] Be careful here. In any non-trivial VM-based OS, free memory isn’t a useful statistic. I talk about this in On Free Memory. In most cases you want to respond to memory pressure notifications. You can get those via Dispatch; see the makeMemoryPressureSource(eventMask:queue:) function. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It’s working but only when I redeem it through the sandbox account management in the developer settings. If I try to redeem it via my app I get a message saying I need iOS 16.3 or later, when I’m clearly on iOS 26. Clear Purchase History is also not working. Even after reinstalling my app it still fetches the redeemed purchase.

This seems like something that the NE team is going to have to investigate. [quote='805679021, davidsansom, /thread/805679, /profile/davidsansom'] I have raised a FB ticket, FB20866080. [/quote] Thanks. That’s the best path forward here. My only other suggestion is that you add a ‘first light’ log point to your sysex and to your NE filter provider, as explained in Debugging a Network Extension Provider. That’ll tell you whether the sysex started and, if it did, when the NE filter provider started within that. If your code isn’t started at all in these failure cases, that’s more evidence that this is an issue on the OS side of things. Note The advantage of using the system for these ‘first light’ log points is that these log entries end up in the sysdiagnose log. You can then point to them, or the absence of them, in the sysdiagnose log that you attached to your bug. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='805736021, iwp, /thread/805736, /profile/iwp'] Wi-Fi raw socket [/quote] Please clarify what you mean by “Wi-Fi raw socket”. What API are you actually calling? [quote='805736021, iwp, /thread/805736, /profile/iwp'] Wi-Fi module itself is reset. [/quote] And what do you mean by this? Does it involve doing something on the iOS device? Or is this “Wi-Fi module” part of something you’ve created, like a Wi-Fi based accessory? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

There are two supported ways to package an ES client: A system extension embedded in an app installed in Applications A launchd daemon In the system extension case, you install your sysex using System Extensions framework. That framework was designed to be use by a GUI app in response to user actions. Trying to hide that process from the user doesn’t end well. If you’re not happy with that constraint it’s fine to package your ES client as a launchd daemon, and then install it via an installer package, using SMAppService, or any other privilege escalation path that takes your fance. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I want to start by being clear about terminology. An XPC service is a bundled executable with the .xpc extension. For third-party developers, we only support XPC services that are bundled within the app [1]. You can’t install them elsewhere on the system. It seems like you’re creating a launchd agent which vends a named XPC endpoint via the MachServices property. I think this distinction is relevant here. The responsibility constraint doc specifically mention an “XPC service”, and I think it means what it says, meaning that responsibility constraints don’t apply to launchd daemons and agents. If you’re looking to constrain what process can connect to your named XPC endpoint, check out the Validating Signature Of XPC Process link in XPC Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Well, the story here is a little muddled, because XPC services can be embedded in a framework. The system makes a lot o

I’m not aware of any Xcode 26-specific problem with this API. I’ve also not see any feedback about problems with this API in recent OS releases. I suspect that your code has some other issue that just happens to cause this failure. My advice is that you isolate the problematic code into a small test project. It should either work there, or present you with an easier debugging task. To get you started you can crib my code from Getting WIFI SSID. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Ed addressed your specific question, but I want to address about the big picture… It seems like your goal is to downgrade an iOS device from a newer version of iOS to an older version. There’s no supported way to do that [1] on iOS or any of its ‘child’ platforms [2]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] The only exception being during the beta cycle of a new OS, where it’s possible to erase and device and install the most recent non-beta OS. [2] It is possible to do this with macOS.

NWConnection isn’t really set up to deal with UDP broadcasts. My advice, sadly, is that you use BSD Sockets for this. BSD Sockets is a much harder API to use correctly. I have lots of hints and tips in Broadcasts and Multicasts, Hints and Tips. The most critical point is that, when working with broadcasts and multicasts, you should target a specific interface. If you try to send a broadcast without specifying the interface, it’s hard to predict which interface it’ll be sent over. [quote='805719021, Tetsuya_0, /thread/805719, /profile/Tetsuya_0'] I suspect this may be a regression bug in the iPadOS 26 security sandbox [/quote] Well, it’s certainly a regression, but I doubt it’s in the sandbox. Usually the sandbox causes things to fail with EPERM. You are feel to file a bug about NWConnection, but I’m concerned that it’ll struggle to get traction given the state of broadcast support in Network framework. If you need a fix for this in the short-to-medium term, I recommend that you switch to BSD Sockets.