“We are unable to process your request”

Thank you for your post. The App Store team does not monitor the forums, and I believe you set your app as “Made for Kids” for the first time when you deployed the app. Since your app is already live, the “Made for Kids” flag and the “Kids” category are often locked to prevent developers from changing an app’s target audience without parental consent. This will be a significant privacy issue as you can see. To resolve a locked metadata field like that, you need to contact App Store Connect Support, not App Review. Visit the Apple Developer Contact Us page. The representative can file an internal ticket directly to the App Store Connect engineering team to manually unstick the metadata field on your account if appropriate. Now, depending on your app and the people affected by that change, the engineering team will decide whether to make that change. I’m not in that team now I know their process. Once App Store Connect Support unlocks the field and you successfully uncheck “Made for Kids,” you can subm

Hi, @Dominik_2 I'm a little late here but I'm having the same issue. Did you ever figure this out? I can't even get a 2019 Mac Pro to properly activate LOM and a 2023 Mac mini which gives me the same Address Already In Use error. Here's all my testing and info. Apple are you there??? Infrastructure: • Mac mini 2023 (M2, 10Gb Ethernet, MacMini.local, macOS 15.x Sequoia 15.7.4) — MicroMDM v1.13.1 • Mac Pro 2019 (MacPro7,1, Intel T2, MacPro.local, macOS 15.x Sequoia 15.7.5, T2 firmware 23P3120) • Both supervised via Automated Device Enrollment (DEP) through Apple Business Manager • Both enrolled: IsSupervised = 1, APNs working on both • Both are Controllers and Clients LOM Current State: Mac mini (Apple Silicon M2): • LOM profile installed ✓ • lom0 interface active ✓ • Port 55555 listening on * ✓ • LOMDeviceServerColsolidated path (Apple Silicon) ✓ • com.apple.AppleLOM.XPC active=1 ✓ • com.apple.AppleLOM.Watchdog active=1 ✓ • Mac Pro CAN reach mini's lom0 port 55555 — TCP connection established ✓ • BUT connectio

You can formally request new API functionality, like an animated map layer of wind data, through Feedback Assistant.

Regarding fclonefileat API, my expectations are actually met in macOS 26.4 now - I do expect that the Kernel is capable of rejecting invalid calls of clonefile API and does fail the operation. It is tricky to predict the future as there might be new regular file types that might not be clonable/will become clonable, so I always delegate the file clonability decision to the Kernel. So, stepping back for a moment, my larger advice here in terms of future proofing would actually be to avoid the direct call to clonefile and instead call copyfile. While kernel panic'ing is a relatively extreme failure, clonefile is a low-level syscall, and I'd fully expect that there can/are/will be edge cases where clonefile fails and copyfile does not. The difference here is a matter of API role - clonefile is only designed to do the specific task of sending a specific request to the VFS system, while copyfile() is designed around the broader job. If you specifically want to fail in any case where a file can't be cloned

is the issue fixed and may i know the root cause? Thank you This particular issue was determined to be an accessory failure, caused by the developer reducing the CHIP_IM_MAX_REPORTS_IN_FLIGHT constant from it's default value of 4 to 2. The difference between the working and failing cases where then caused by small differences pairing implementation, which then altered the report timing. I don't know why they original reduced that constant but, in general, altering this sort of constant in a hardware implementation is something I would recommend against. Part of the reason reference platforms exists is that, in practice, it's very difficult for platform and accessory implementors to create products the perfectly interoperate. Theoretically that's addressed by increasingly detailed specifications but anyone who's spent significant time reading a hardware specification knows that increased detail isn't necessarily all that helpful. Reference platforms help smooth out that process by providing a standard

Certification: The accessory is currently in an early development state, so we have not opted for MFi certification yet. We are using development identifiers/chips for testing the iAP2 protocol. OK. Since the accessory is in early development and uncertified, I'd recommend going through the MFi support process, the details of which are in the Developer Technical Support section of the MFi Licensing Handbook, which you can find in the MFi portal. They can discuss all of the hardware details, as well as work with out engineering team(s) if there is an issue on our end. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

...and Quinn's answer is... but I'm going to run this by Quinn to see what he thinks. ...no idea. If you have a moment, please file a bug on this and post the bug number back here. As part of the bug, please reproduce the issue, noting the times you: Initially install the driver First load (when logging fails) Unload Second load (when logging succeeds) Unload Third load (when logging succeeds) ...then collect a sysdiagnose and upload it to the bug. As you go through that process, try to go relatively slowly, pausing between each step, and then wait a minute or two before triggering the sysdiagnose. That helps disperse the logging data over time, which makes it easier to understand follow the process. __ Kevin Elliott DST Engineer, CoreOS/Hardware

How are you getting the icon otherwise? It's not quite otherwise. Normally I just use NSWorkspace.shared.icon(forFile:). But folders require special logic. If the folder name has a . prefix, then I call NSWorkspace.shared.icon(for: .folder). I'm not sure why. Probably should have commented that. But if the folder doesn't have a . prefix, I use the standard NSWorkspace.shared.icon(forFile:). Then, I check to see if I need to do more. I the URL has the com.apple.icon.folder#S extended attribute, I try QLThumbnailGenerator. QLThumbnailGenerator is async anyway, so it really always requires the two-step process.

Hi, We are also affected by this TestFlight issue. The build is visible for internal testing, but when testers tap Install, TestFlight says: “The requested app is not available or doesn't exist.” We already checked the usual things and even tried creating a brand new app record, but the exact same problem still happens. It looks like many developers have run into this before. If anyone has a confirmed solution, please help share it. Was it: an Apple/TestFlight backend issue? an account/app distribution state issue? something Apple Support had to manually fix? Any real experience would be greatly appreciated.

after speaking on the phone, a support guy manually kicked off the email that gave me a link to https://developer.apple.com/contact/file-upload/upload/select to upload my ID, which I think was the missing step in the process. dunno if it'll work after that or not, but