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 third case with the same signature, plus one piece of evidence I haven't seen in this thread yet. Same app structure as the original post: main app plus three Screen Time extensions — DeviceActivityMonitor, ShieldAction, ShieldConfiguration. Timeline: 2026-07-11 — build 1.0.0 (1) submitted. Cleared automated analysis, reached human review, and was rejected 2026-07-13 on guidelines 3.1.2(c), 5.6 and 2.3.2. No Screen Time or Family Controls issue was raised. 2026-07-27 — build 1.0.0 (3) uploaded. Zero entitlement or code-signing changes from build 1 (verified by diff). 2026-08-01 — rejected by automated pre-review analysis: "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." The evidence I'd suggest others check: instead of verifying with codesign locally, look at App Store Connect's own record. Under TestFlight > iOS Builds > [your build] > Build Metadata > Store Information there is an Entitlements section listing the entitlements Apple parsed out of the binary it received. For our rejected build it shows: Recess.app/Recess — com.apple.developer.family-controls: true Recess.app/PlugIns/ShieldConfiguration.appex/ShieldConfiguration — com.apple.developer.family-controls: true Recess.app/PlugIns/DeviceActivityMonitor.appex/DeviceActivityMonitor — com.apple.developer.family-controls: true Recess.app/PlugIns/ShieldAction.appex/ShieldAction — com.apple.developer.family-controls: true Binary State: Validated. So App Store Connect's own record of the received binary lists the entitlement on all four executables, while the automated analysis says the app was not submitted with the entitlement. Both statements come from the same system. Also confirmed on our side: Family Controls (Distribution) is enabled on all four App IDs, and forcing a fresh provisioning profile mint on 2026-08-01 produced four new App Store profiles — app plus all three extensions — every one containing com.apple.developer.family-controls, with a successful App Store export.
3h
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 third case with the same signature, plus one piece of evidence I haven't seen in this thread yet. Same app structure as the original post: main app plus three Screen Time extensions — DeviceActivityMonitor, ShieldAction, ShieldConfiguration. Timeline: 2026-07-11 — build 1.0.0 (1) submitted. Cleared automated analysis, reached human review, and was rejected 2026-07-13 on guidelines 3.1.2(c), 5.6 and 2.3.2. No Screen Time or Family Controls issue was raised. 2026-07-27 — build 1.0.0 (3) uploaded. Zero entitlement or code-signing changes from build 1 (verified by diff). 2026-08-01 — rejected by automated pre-review analysis: "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." The evidence I'd suggest others check: instead of verifying with codesign locally, look at App Store Connect's own record. Under TestFlight > iOS Builds > [your build] > Build Metadata > Store Information there is an Entitlements section listing the entitlements Apple parsed out of the binary it received. For our rejected build it shows: Recess.app/Recess — com.apple.developer.family-controls: true Recess.app/PlugIns/ShieldConfiguration.appex/ShieldConfiguration — com.apple.developer.family-controls: true Recess.app/PlugIns/DeviceActivityMonitor.appex/DeviceActivityMonitor — com.apple.developer.family-controls: true Recess.app/PlugIns/ShieldAction.appex/ShieldAction — com.apple.developer.family-controls: true Binary State: Validated. So App Store Connect's own record of the received binary lists the entitlement on all four executables, while the automated analysis says the app was not submitted with the entitlement. Both statements come from the same system. Also confirmed on our side: Family Controls (Distribution) is enabled on all four App IDs, and forcing a fresh provisioning profile mint on 2026-08-01 produced four new App Store profiles — app plus all three extensions — every one containing com.apple.developer.family-controls, with a successful App Store export.
Replies
Boosts
Views
Activity
3h