> Given that kext development is still supported (although highly discouraged), won’t they have to support the same level of kernel debugging as usual?
They just need to support loading kernel extensions. As watchOS has shown, developers will figure out a way to get their thing working on your device even if your make debugging extremely painful. (Apple's current silicon prevents debugging entirely because the kernel is prevented from being patched in hardware.)
They're two separate groups. Group one, the grandfathered one, is "legitimate" software that was simply published to the store prior to the mandatory sandboxing requirement–those can still get updates and remain unsandboxed. The second group is the list that I posted here, that have special status in the dynamic linker (can interpose functions) and through that can (probably don't, but "can" on a technical level by exploiting flaws in how Apple does sandboxing) bypass the sandbox.
They just need to support loading kernel extensions. As watchOS has shown, developers will figure out a way to get their thing working on your device even if your make debugging extremely painful. (Apple's current silicon prevents debugging entirely because the kernel is prevented from being patched in hardware.)
> Can you name any of these apps?
Sure. If your app's bundle ID matches one of
dyld interposing is enabled for your app even if it comes from the App Store, opening the door for subverting the mechanism for applying the sandbox.