Post

Replies

Boosts

Views

Activity

Reply to Version 1.0.0 stuck in "Waiting for Review" for ~2 weeks after an automated Guideline 2.5.1 message about the Family Controls entitlement
Adding a fourth report, with one data point I have not seen in this thread yet: a before and after comparison on the same developer account. Team ID: 2W6DRV27P7 App being rejected: bible.screentime.control, submitted August 2026. Two separate builds, same automated message both times: "An automated analysis indicates the app uses one or more Screen Time APIs but the app has not been submitted with the Family Controls entitlement." What we verified: codesign -d --entitlements, all four executables main app family-controls = true DeviceActivityMonitor.appex family-controls = true ShieldAction.appex family-controls = true ShieldConfiguration.appex family-controls = true All four signed Apple Distribution, App Store profiles embedded, get-task-allow = false. otool -L across every Mach-O in the bundle: only those four link FamilyControls, ManagedSettings, ManagedSettingsUI or DeviceActivity. No third party SDK touches a Screen Time API. Family Controls (Distribution) Assigned on all four identifiers. Provisioning Support: Development, Ad hoc, App Store Connect. No app-and-website-usage entitlement, no DeviceActivityReport extension, no FamilyActivityData. The comparison I think matters: We have an earlier app on the same account, pushup.screentime.control, with the same three extension types, the same entitlement layout and the same signing setup. It was submitted in March 2026, cleared review with no Screen Time objection, and is live on the App Store. The new app is architecturally the same and was submitted in August. It gets auto-rejected every time. We diffed the two Xcode projects setting by setting. Everything touching entitlements is identical: the entitlements files, CODE_SIGN_ENTITLEMENTS on all four targets, signing style, team, and the NSExtensionPointIdentifier values. The only differences are unrelated (deployment target, device family, GENERATE_INFOPLIST_FILE). So on one account, the same configuration passed in March and fails in August. That matches tgirgash's report, where build 1 cleared the automated analysis on July 11 and build 3 with zero signing changes was rejected on August 1. Has anyone had this resolved yet, by support or otherwise? The support cases and expedite requests earlier in this thread appear to have gone unanswered.
Aug ’26
Reply to Version 1.0.0 stuck in "Waiting for Review" for ~2 weeks after an automated Guideline 2.5.1 message about the Family Controls entitlement
Adding a fourth report, with one data point I have not seen in this thread yet: a before and after comparison on the same developer account. Team ID: 2W6DRV27P7 App being rejected: bible.screentime.control, submitted August 2026. Two separate builds, same automated message both times: "An automated analysis indicates the app uses one or more Screen Time APIs but the app has not been submitted with the Family Controls entitlement." What we verified: codesign -d --entitlements, all four executables main app family-controls = true DeviceActivityMonitor.appex family-controls = true ShieldAction.appex family-controls = true ShieldConfiguration.appex family-controls = true All four signed Apple Distribution, App Store profiles embedded, get-task-allow = false. otool -L across every Mach-O in the bundle: only those four link FamilyControls, ManagedSettings, ManagedSettingsUI or DeviceActivity. No third party SDK touches a Screen Time API. Family Controls (Distribution) Assigned on all four identifiers. Provisioning Support: Development, Ad hoc, App Store Connect. No app-and-website-usage entitlement, no DeviceActivityReport extension, no FamilyActivityData. The comparison I think matters: We have an earlier app on the same account, pushup.screentime.control, with the same three extension types, the same entitlement layout and the same signing setup. It was submitted in March 2026, cleared review with no Screen Time objection, and is live on the App Store. The new app is architecturally the same and was submitted in August. It gets auto-rejected every time. We diffed the two Xcode projects setting by setting. Everything touching entitlements is identical: the entitlements files, CODE_SIGN_ENTITLEMENTS on all four targets, signing style, team, and the NSExtensionPointIdentifier values. The only differences are unrelated (deployment target, device family, GENERATE_INFOPLIST_FILE). So on one account, the same configuration passed in March and fails in August. That matches tgirgash's report, where build 1 cleared the automated analysis on July 11 and build 3 with zero signing changes was rejected on August 1. Has anyone had this resolved yet, by support or otherwise? The support cases and expedite requests earlier in this thread appear to have gone unanswered.
Replies
Boosts
Views
Activity
Aug ’26