This problem has been solved here: https://developer.apple.com/forums/thread/849096?answerId=911825022#911825022

@dazboj Man! Thanks! It solved the issue on my side. To fix it: I removed the group Deleted old SDK using xcrun simctl runtime list + xcrun simctl runtime delete <id> Rebooted system Installed the new SDK via Xcode The reboot step was crucial. This is the same problem as in my thread: https://developer.apple.com/forums/thread/853154 Also, I think it's worth mentioning what is the impact of deleting daemon group. Based on AI: The daemon group (GID 1) is a system group used by background processes (daemons). A regular user normally shouldn’t be a member. If your account ended up there, it could be because of: a manual change (e.g. following a tutorial or running a script), software that modified group memberships during installation, an attempt to work around file permission problems. After removal, your account loses the access that membership provided, namely access to files and directories whose group is set to daemon with group permissions enabled. This restores the standard, more secure state. Is it safe? Usually yes, if your account isn’t supposed to be in that group. Still: The command requires sudo, so make sure you understand where it came from. Replace <your_username> with your actual username (you can check it with whoami). Logging out and back in is usually needed for the change to fully take effect.

@grinmax have you resolved this issue with support?

This requirement is insane, so basically Apple blocks selling your app if you ever used that entitlement O_O. Completely insane! How come there is no workaround/process to do that?!

Well, that's why I asked you, because Feedback Assistant is an abyss, nobody investigates bugs reported there - I know it from experience because I've reported 68 bugs over the 6 years and only 7 bugs have been fixed / a workaround has been provided. Reporting bugs there is pointless. This particular bug has been reported in 2024 and I still didn't get any response. I also reported another one in 2025 - also without any reply. It's a critical bug because it affects users when they use the native keyboard for typing, providing suggestions in an undesired language, and there is no workaround. I even created DTS ticket to ask about this bug and I only got a generic reply. The level of support provided for developers paying for a developer account is unacceptable.

8 days until iPhone Duo release and we still don't have a stable SDK available...

Unfortunately, it won't be fixed, I reported many bugs over the years and they fix nothing, this is how things work at Apple. The Feedback Assistant app is just an abyss where you send bugs and they get discarded and forgotten unless you report something that affects all apps in the App Store. Things like custom keyboards are not their concern. I also reported a very similar bug with a laggy keyboard launch and visible resizing: FB20622442 - one year ago, no answer, no fix.

Thank you! Having you here, could you please also take a look at: FB13954760? I've been waiting for over 2 years for the fix for this critical keyboard-related bug. It's still reproducible.

If your keyboard spans both screens, the hinge acts as an "unsafe" area in the middle of your view. You can always change that. As I mentioned, reserved area doesn't work either. So you can't detect it and you can't adjust to it. If needsInputModeSwitchKey was returning false or behaving unpredictably, it's often because the view hierarchy hasn't fully resolved No, it's a bug, already confirmed: https://developer.apple.com/forums/thread/849736 The regression where the text field loses focus and the keyboard dismisses usually happens if the extension crashes, takes too long to layout, or manually resigns first responder during a bounds change. The key to keeping the keyboard alive rather than tearing down and rebuilding your views. It's a bug, it happens also when using the native keyboard + Safari app. I would be very interested to see a focused sample showing how you handle each item and see how you hit those issues you have described. Everything has already been reported (besides the focus issue) with sample projects: FB25073949 FB24883137 FB24979367 FB24785360

I'm also experiencing issues with my macOS app being stuck "In Review." I'm not sure how long it would remain in this status if I hadn't canceled it. It takes so long that I managed to prepare a new version in the meantime, but now I've uploaded the final changes, and the app has been "In Review" since yesterday. We'll see how long it is going to stay in this status... During all those "In Review" periods, I noticed in the analytics that no one has opened the app, so its status changes, but there is no one there actually reviewing it...

But guys, no worries, they won't fix it, so it's better to just adjust the keyboard to this behavior. I've reported multiple keyboard bugs over the last few years - none of them has been fixed. And some are quite critical. My favorite one is that iOS installs additional language based on your keyboard bundle id. So if it starts for example with "pl.*" it will install Polish 🤦‍♂️ - reported 2 years ago, not fixed yet. And there is no workaround because you can't just change bundle id. Also, please note that reserved areas / hinge detection doesn't work in keyboard extensions either.

I'm aware of that. My point is that the keyboard layout on iPhone Duo has been changed (between beta 1 and rc 1) and instead of showing the globe button alone on the side, it shows it as a normal button. Maybe it's intended but it doesn't seem so. If this were an intentional change, needsInputModeSwitchKey would return true, so that custom keyboard could show their own globe button, but the SDK still returns false. This strongly indicates a bug: either the system should present the globe button, or needsInputModeSwitchKey should return true. I've already reported it: FB25073949

However, it looks like you filed a bug? May I ask the reason if you see the property has been deprecated? I filled the bug before I figured out what's the root cause as you can clearly see by the order of posts. Nevertheless, the deprecation doesn't mean that random things in the app should break, so the SDK bug remains valid.

I've found the bug! It turns out that accessing UIScreen.main here breaks accent color in the app 🤯! I know UIScreen.main is deprecated, but I was using it as a fallback and since the window wasn't initialized yet, the fallback triggered causing this issue...

Inconsistency on iOS: Messages: new message -> leading edge App Store: event -> trailing edge Calendar: tap on event -> leading edge Weather: tap on day -> leading edge Photos: tap on your avatar -> trailing edge Find: tap on a device -> trailing edge Measure: tap on a list - top-left corner -> trailing edge TV: tap "more" on a description -> trailing edge Mail: swipe left and select "more" -> trailing edge