Hi, Our team already has the Family Controls (Distribution) entitlement approved for the main app and existing Screen Time extensions. We recently added a new Shield Configuration extension to show a custom on-device shield UI using ManagedSettingsUI. It is only used for UI rendering and does not collect or send any user data. However, the entitlement does not seem to be applied to this new extension yet, and we are blocked from proceeding with builds. We have already contacted support but haven’t received an update yet. Case ID: 102881099623 It’s been days without any update, and this has become really stressful for our team since we’re completely blocked at the final step after months of work on this app. Could someone please help to apply/sync the Family Controls distribution entitlement or guide us on the next steps? Happy to share app details privately if needed. Thanks.

Dear Apple Developer Support, We are experiencing an issue where our properly signed, notarized, and stapled PKG installer is being blocked by Gatekeeper on macOS Sequoia (15.3), despite passing all notarization checks. Team ID: 3888L7DV3P Organization: SKY GATE TECHNOLOGYS K.K. Certificate: Developer ID Installer: SKY GATE TECHNOLOGYS K.K. (3888L7DV3P) Issue Details: Our PKG installer is signed with "Developer ID Installer" certificate, notarized (status: Accepted, issues: null), and stapled successfully. pkgutil --check-signature confirms: "signed by a developer certificate issued by Apple for distribution" and "Notarization: trusted by the Apple notary service" xcrun stapler validate confirms: "The validate action worked!" However, spctl --assess --type install returns "rejected" with assessment:verdict = false and assessment:remote = true The system log shows: meetsDeveloperIDLegacyAllowedPolicy = 0 When users download and open the PKG (even from within a notarized DMG), Gatekeeper displays: "Apple could not verify [app] is free of malware" Notably, our .app bundles signed with "Developer ID Application" (same Team ID) pass Gatekeeper without issues. Only PKG installers are affected. Our software is a legitimate enterprise security product (VPN/Zero Trust client) distributed to corporate customers. Could you please: Investigate why our Team ID's PKG installers are being rejected by Gatekeeper's online assessment despite valid notarization Advise on any steps we can take to resolve the meetsDeveloperIDLegacyAllowedPolicy = 0 status for our Team ID Confirm whether there is a trust establishment process for new Developer ID Installer certificates with the Gatekeeper service Thank you for your assistance. Best regards, Riku Ogura Skygate Technologies K.K.

Hi, I'm building a wellness app called that helps users manage their phone usage based on their consumption, using the Screen Time API. I need the Family Controls (Distribution) entitlement to ship it. I've already submitted multiple requests across all my bundle IDs, but due to the lack of confirmation feedback after each submission, I may have submitted more than needed. Regardless, the oldest request submitted was on April 22nd (exactly 2 weeks ago), without any reply or change. Is this normal ? Also, I came across a forum post (https://developer.apple.com/forums/thread/821964?answerId=885672022#885672022) suggesting that the entitlement is now scoped at the team level rather than per bundle ID, and that I should resubmit a single request. I want to do the right thing here but I'm not sure whether to resubmit or wait and I don't want to make the situation worse than it already is. We're about a month away from our launch date and this is the last remaining blocker for both TestFlight and App Store submission. Any guidance on next steps, or help prioritizing this, would mean a lot. Thanks so much,

Problem My ARM64 macOS application is being immediately killed with SIGKILL when launched. No crash report is generated, and the process terminates instantly. Environment macOS Version: 15.x (Sequoia) Architecture: ARM64 (Apple Silicon) Certificate: Mac Developer certificate (development signing) App Type: Native ARM64 application with embedded Java runtime Symptoms ./MacOS/myapp Immediately returns: zsh: killed ./MacOS/myapp Investigation Results System Logs Show Security Policy Rejection kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 92850, /path/to/myapp syspolicyd: (Security) MacOS error: -67062 Error Code Analysis Error -67062 = errSecCSReqFailed (Code signature requirement failed) This is a Gatekeeper enforcement issue, not a code signing problem 3. Code Signature is Valid codesign -dvvv myapp Shows valid signature with Mac Developer certificate Authority=Mac Developer: Name (TEAMID) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA What We Tried (That Didn't Help) ✅ Removed hardened runtime flag from Java components ✅ Added JIT entitlements (com.apple.security.cs.allow-jit) ✅ Verified Mach-O structure is correct ✅ Confirmed all libraries are ARM64 ✅ Re-signed with proper entitlements None of these fixed the issue because the problem is Gatekeeper policy enforcement. Question How can I allow this development-signed ARM64 app to run on macOS 15 without full notarization? I've tried: Removing quarantine attributes Various code signing approaches Different entitlements But Gatekeeper still blocks it with error -67062. Is there a way to add a security exception for development builds, or do I need to use a Developer ID certificate even for internal testing? Additional Context This is for internal development/testing. The app works fine when properly notarized, but we need a way to test development builds without going through the full notarization process each time. Any suggestions would be greatly appreciated!

Our team already has Family Controls (Distribution) entitlement approved for the main app and existing Screen Time extensions. We recently added a new Shield Configuration extension to show a custom on-device shield UI using ManagedSettingsUI. It is only used for UI rendering and does not collect or send any user data. However, the entitlement does not seem to be applied to this new extension yet, and we are blocked from proceeding with builds. We have already contacted support but haven’t received an update yet. Case ID: 102881099623 Could someone please help to apply/sync for the Family Controls distribution entitlement or guide us on the next steps? Happy to share app details privately if needed. Thanks.

I'm posting this so other devs hitting error 7000 know they're not alone, and so this gets some visibility outside the support ticket black hole. Timeline: End of February 2026: first notarization attempts. All rejected with status code 7000 March 1st: first support case opened Today, beginning of May: still blocked. Still error 7000 Four cases: 102833704616, 102836645198, 102842517951, 102865000390. Different advisors each time. I've uploaded my government ID twice. When I ask for a status, the answer is "I'll get back to you when I have news." Then silence. My setup is fine. Team ID is Y564MF82K8. App is signed with Developer ID Application, hardened runtime, secure timestamp, no get-task-allow, deep verify clean. Apple rejects the submission before inspecting the binary. The block is on Apple's side. Somebody needs to push a button but they cannot agree who needs to push it, so they just pass it from one department to another. The "correct escalation path" doesn't work. Quinn (Apple DTS engineer) keeps saying on this forum that error 7000 is administrative and the path is Developer Program Support (https://developer.apple.com/forums/thread/118465?answerId=379585022#379585022). I followed that path four times. The cases just sit there. Threads on this forum about error 7000 go back to 2019. Six years. Devs report cases stuck for weeks, months, with the same scripted responses. Apple knows. Apple does nothing. I'm a solo dev and I want to do a proper launch of my SaaS on all major desktop platforms. I paid the $99. I built the app. I signed every agreement. I cannot launch on macOS because Apple's departments cannot agree on who needs to push a button. If anyone here has actually unblocked error 7000, please share what worked. The official path obviously doesn't.

Hi all — looking for diagnosis help, posting publicly in case other devs hit the same issue. Symptom Every notarytool submission for the past 32 days returns: statusCode: 7000 statusSummary: "Team is not yet configured for notarization. Please contact Developer Programs Support..." Account state (all healthy as far as I can tell) Team ID: P6V2783F8M Membership: Active, Individual, paid Free Apps Agreement: Active Paid Apps Agreement: Active (signed Jan 4, 2026) W-8BEN tax form: Active Bank account: Active Developer ID Application certificate: valid, used for signing Bundle ID: dev.tinyclaw.desktop (registered) App is correctly signed codesign -dvvv shows: Authority=Developer ID Application: Yang Yang (P6V2783F8M) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Apr 11, 2026 Hardened runtime + secure timestamp both enabled. spctl --assess passes locally. Submissions (all rejected with 7000) 5a903f08-bd17-4d59-ac63-12e191e2bb5a 49b670da-0f79-4814-809a-f675791f15c3 febfb37a-b445-4d03-b7c4-bf573304f219 9013e185-10e2-42d4-91c1-3378083266eb bfc64627-5eb6-402c-ac25-e79648d2c251 (latest, 2026-05-02) Different builds, different versions (0.5.22-beta.7 → 0.5.27), different DMGs. Same 7000 every time. Credentials revalidated with a fresh app-specific password — same result. DTS Case 102855668616 open since Apr 2 — 4+ weeks of template responses, no engineering progress. Question Has anyone seen 7000 persist this long after a clean Individual enrollment? Is there a specific team-side flag that has to be flipped server-side, that DTS L1 can't see or escalate? Any suggestion on which DTS topic forces escalation to the notarization service team specifically? Happy to share more diagnostic output. Thanks.

Hi all, I enrolled in the Apple Developer Program on April 29 and immediately started notarizing my Electron-based macOS app. All submissions are stuck "In Progress" for 24–67 hours, with no Accepted or Invalid verdict. Team ID: VKFQG6Q29S Account: Individual, newly enrolled 2026-04-29 Submissions stuck (all "In Progress"): 2142f524-4c36-4452-a25d-2260d3b7010d (created 2026-04-30, ~50h) 6237312a-ae36-4a98-8ffe-37193c150a69 (created 2026-04-30, ~54h) 5184f493-f574-4f34-a536-8184bf4ce4eb (created 2026-04-29, ~64h) c108ed9f-1908-4c47-9b32-c55d34da99c7 (created 2026-04-29, ~67h) e1502fcd-dad6-402d-a0aa-550a1907ee46 (created 2026-05-01, fresh — submitted via App Store Connect API key as a control) What I have verified: Developer ID Application certificate is valid and trusted (security find-identity -v -p codesigning shows it) Inside-out signing: every Mach-O binary signed individually with hardened runtime, secure timestamp, entitlements; Helper apps and frameworks sealed top-level AFTER inner binaries; parent .app sealed last; DMG container codesigned codesign --verify --deep --strict --verbose=2 /path/to/app → "valid on disk" and "satisfies its Designated Requirement" I tried both auth methods: App-Specific Password (notarytool keychain profile A) and App Store Connect API Key (Team Key, Developer role, validated successfully). Both produce the same "In Progress" stall. Three earlier submissions returned "Invalid" within minutes with concrete errors (missing entitlements on shm-bridge .dylib, broken parent seal etc.), which I fixed. After the fixes, every submission gets stuck "In Progress" with no terminal status. I opened a Code Signing support case (102882655678) on April 30, no response yet. Has anyone else experienced extended "In Progress" hold on a freshly enrolled Developer ID? Is there a known first-submission review queue, and what's the typical SLA? Any way to escalate or is waiting the only path? Thank you.

I submitted a Family Controls Distribution entitlement request on 4/22 for my app Prof Blob. I received the confirmation page after submitting, but I have not received any approval, rejection, or status update. We are currently blocked from moving forward with our production release submission due to this entitlement. Details: Request ID: Y2L55S3W34 Team ID: 5AXHQ5ZF3G App: Prof Blob Bundle ID: com.spammusubi.blob-screen-time Related extension bundle IDs: com.spammusubi.blob-screen-time.BlobActivityReportExtension com.spammusubi.blob-screen-time.DeviceActivityMonitorExtension com.spammusubi.blob-screen-time.ShieldActionExtension com.spammusubi.blob-screen-time.ShieldConfigurationExtension Purpose: Individual device management for focus and productivity. Prof Blob is a digital wellbeing / screen time management app that uses Apple’s Screen Time APIs to let users select distracting apps and require a short math-based cognitive gate before opening them. The app uses FamilyControls, DeviceActivity, and ManagedSettings. Development builds are working, but the Family Controls Distribution entitlement is required for production builds, TestFlight validation, and App Store submission. Is there a way to expedite this request or confirm that it is still in review? I would be happy to provide any additional information needed to move the request forward.

I submitted a Family Controls Distribution entitlement request on April 21, 2026 for my app Dopfast. I also resubmitted on April 29, 2026. I received the confirmation page both times but have not received any approval, rejection, or status update. I contacted Developer Support (Case #102879238806) and was told the request is handled by another team and they cannot check the status. Details: Team ID: HSJ6KB4WEZ App: Dopfast (digital wellbeing / screen time management) Bundle ID: com.dopfast Purpose: #2 — individual device management for focus and productivity (personal screen time tracking and app blocking) This entitlement is the only remaining blocker for our App Store submission. The app is fully built and ready to ship. Has anyone experienced similar delays recently? Is there a recommended way to expedite this request?

I am experiencing an issue with Apple Development certificate creation in Xcode for my organization account. Account details: Organization: Jtecx LLC Team ID: 8V397ULNY4 Issue: When I attempt to create a new Apple Development certificate in Xcode under the Jtecx LLC (8V397ULNY4) team, the certificate is consistently generated under a different team: Apple Development: Joseph Salmond (67P4AAZ5TA) This appears to be my personal team, not the organization team. Impact: Because of this mismatch: Provisioning profiles created under 8V397ULNY4 cannot find a matching signing certificate Xcode shows “Signing Certificate: None” Xcode reports that the provisioning profile does not include the signing certificate I am unable to run or test the app on physical devices due to signing failures Troubleshooting performed: Deleted all Apple Development certificates from Keychain Access Revoked existing Apple Development certificates in the Apple Developer Portal Created a new Certificate Signing Request (CSR) using Keychain Access Generated a new Apple Development certificate through the Apple Developer portal Downloaded and installed the certificate into Keychain Attempted certificate creation via Xcode (Settings → Accounts → Manage Certificates → + → Apple Development) Verified installed identities using Terminal (security find-identity) Confirmed that only the following development identity is being created: Apple Development: Joseph Salmond (67P4AAZ5TA) Deleted this identity and repeated the process multiple times Recreated provisioning profiles after generating new certificates Downloaded and installed new provisioning profiles Attempted both manual signing and “Automatically manage signing” in Xcode Revoked certificates directly from Xcode and allowed Xcode to regenerate them Confirmed that Apple Distribution certificates are correctly issued under 8V397ULNY4 Despite all of the above steps, every new Apple Development certificate continues to be created under Team ID 67P4AAZ5TA instead of 8V397ULNY4. Expected behavior: When creating an Apple Development certificate while the Jtecx LLC (8V397ULNY4) team is selected, the certificate should be issued under that same team: Apple Development: Joseph Salmond (8V397ULNY4) Requested fix: Please investigate and correct the team association so that: Apple Development certificates are generated under the correct team (8V397ULNY4) is properly associated with the Jtecx LLC developer team for certificate issuance Xcode correctly creates and uses development certificates for the organization team Additional notes: Apple Distribution certificates are working correctly under 8V397ULNY4 Only Apple Development certificates are affected This issue is blocking local development and testing on physical devices Thank you.

I have a macOS app (a background daemon) that I distribute outside the App Store as a .pkg installer. My build process is: Build the app (xcodebuild archive) Sign the app with Developer ID Application Package it with pkgbuild, signed with Developer ID Installer Notarize with notarytool Staple with stapler This works perfectly on my local machine using custom build_pkg.sh. I'm trying to automate this in Xcode Cloud using a ci_post_xcodebuild.sh script so a new build is triggered whenever I push to git repository. The problem is: • security find​-identity shows 0 valid identities in the post-build script environment • The archived app has Signature​=adhoc (no Developer ID signing) • pkgbuild can't sign the .pkg without a Developer ID Installer certificate • Notarization rejects everything because nothing is signed with Developer ID My question: Is there any way to make Developer ID certificates available in Xcode Cloud's post-build scripts? Or is Xcode Cloud only designed for App Store distribution, and I need to use a different CI (like GitHub Actions) for Developer ID / notarized .pkg workflows? Are there other ways to trigger creation of notarized pkg files whenever I push to GitHub?

My app's notarization progress is stuck. ID: aa61b008-a329-4e31-bb23-648029510e36 Forum mod DTS Engineer gives "copy-paste" answers to every user who has this problem.

A signed DriverKit extension fails OSSystemExtensionRequest activation on macOS 26.4.1. The user-facing error is OSSystemExtensionErrorDomain code 4 ("Extension not found in App bundle") — but the dext is in the bundle, the identifier matches, and sysextd confirms it received the request: sysextd: [com.apple.sx:XPC] client activation request for com.arqitekta.bluefield.rshim.driver sysextd: attempting to realize extension with identifier com.arqitekta.bluefield.rshim.driver …and then nothing further. systemextensionsctl list reports 0 extensions. Question: Which log subsystem/category surfaces the kernel-side reason that sysextd aborts after "attempting to realize"? com.apple.sx only shows the request was accepted; whatever vetoes the realize step isn't in that subsystem (or isn't at info/debug level). Is there a separate predicate for the kernelmanagerd / dext-loading path I should be capturing? Environment: macOS 26.4.1 (25E253), Apple Silicon Mac Studio Xcode 26.2 (17C52), DriverKit SDK 25.2 SIP disabled, systemextensionsctl developer on Apple Developer Program, signed "Apple Development: …" DriverKit entitlement request 264CFJJU36 approved; profile includes com.apple.developer.driverkit, allow-any-userclient-access, transport.pci Already verified: Dext at Contents/Library/SystemExtensions/RshimDriver.dext CFBundleIdentifier matches the request, CFBundlePackageType=DEXT codesign --verify --deep --strict passes on app + dext embedded.provisionprofile parses, contains the expected entitlements Three IOKitPersonalities (BF2 / BF2-alt / BF3) using Apple's placeholder IOPCIPrimaryMatch Installer app entitled with com.apple.developer.system-extension.install only spctl -a -vv on the dext reports "rejected" — expected for development signing, should be bypassed under developer mode Minimal repro: https://github.com/jfabienke/bluefield-macos-toolkit/tree/dev-stub-entitlements/rshim-dext — build.sh produces the failing app dext. Captured artefacts (build output, embedded profile dump, signing report, repro shell script) under rshim-dext/dts-artifacts/. Looking for either (a) the right log show predicate to find the actual refusal reason, or (b) an environmental requirement on macOS 26 I'm missing.

I have 2 Notarisation stuck for nearly 24 hours oth submission UUIDs: b78aa323-9993-40fd-a510-4fff5e989e8f and 952714cb-3a59-4caa-9343-674ca7dd86d4 Team ID 6A754AWMJB This is a Developer ID distribution (not App Store)

Dear Apple Support, sometimes we observe exit code 68 in stapling via xcrun stapler staple <pkg_file.pkg> The notarization went fine but then stapling does not work. The output for the last ast failed launch looks like Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={_kCFStreamErrorCodeKey=-2102, NSUnderlyingError=0x60000363c7b0 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <4F2E1620-9251-4525-91E7-C5F3E3681CD0>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <4F2E1620-9251-4525-91E7-C5F3E3681CD0>.<1>" NSLocalizedDescription=The request timed out., NSErrorFailingURLStringKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, NSErrorFailingURLKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, _kCFStreamErrorDomainKey=4} CloudKit's response is inconsistent with expections: (null) As per manual of stapler and sysexit(3) the exit code means EX_NOHOST (68) The host specified did not exist. This is used in mail addresses or network requests. Make a retry sense or is there any other things which is not set correctly at that time? What is your suggestion to avoid this failure and stabilizing our automation of notarization? Best ergards, Stefan

Hi all, I'm submitting a Developer ID-signed, hardened-runtime app for notarization. Every submission returns: "statusCode: 7000 statusSummary: Team is not yet configured for notarization. Please contact Developer Programs Support..." Team ID: V67NRZ84A2. Apple Developer membership is active, Developer ID Application certificate is valid, signing/verification all clean. Already opened a support case last week via the recommended path. The "contact page" on the developer site said Apple usually responds within 2 business days.... Has anyone hit this and gotten it resolved? How long did it take, and was there a more effective channel than the standard support form? I've seen people on Reddit claim they've actually been able to call a Developer phone line, but I haven't seen a valid phone number anywhere. I appreciate your response!

Hello, I have been hitting status code 7000 on every notarization submission since April 21, 2026. The notable detail: earlier submissions on April 18 and April 20 from the same team were Accepted normally. Whatever flag flipped between April 20 and April 21 is on the notary side, because nothing changed on my end. Team details Team ID: ZS76A62WJ4 Organization: KENOPA LTD (UK private limited company) Role: Account Holder Apple Developer Program: Active until April 17, 2027 Apple Developer Program License Agreement: accepted April 16, 2026 Paid Apps Agreement, Free Apps Agreement: both Active in App Store Connect W-8BEN-E and banking: Active Certificate Type: Developer ID Application Identity: "Developer ID Application: KENOPA LTD (ZS76A62WJ4)" Valid through 2027-02-01, full chain trusted App details Platform: macOS (native AppKit, Objective-C, no Electron) Hardened runtime: enabled Code signing passes verify and strict checks Sandbox: not used (Developer ID distribution outside the App Store) Submission history (Team ID ZS76A62WJ4) Accepted submissions: 2026-04-18 10:00 UTC 39856e43-... 2026-04-18 10:03 UTC 3edf2f4f-... 2026-04-18 10:25 UTC 858c52e7-... 2026-04-20 17:17 UTC 4766f3ce-... 2026-04-21 03:58 UTC 9eed3336-... 2026-04-21 05:44 UTC b759941f-... Then everything since flips to Rejected with code 7000: 2026-04-21 19:10 UTC bedc99ad-... 2026-04-21 20:24 UTC 4dbb55f0-... 2026-04-22 07:36 UTC 50e1420e-... 2026-04-24 04:11 UTC 7e4adf81-... 2026-04-25 04:31 UTC 4c0367ea-... 2026-04-25 08:02 UTC a3ce5f56-... (still In Progress at the time of posting) I can paste the full submission IDs in a follow-up if helpful. Sample notary log The body of every Rejected log is the same: status: Rejected statusCode: 7000 statusSummary: "Team is not yet configured for notarization. Please contact Developer Programs Support..." Submissions all upload successfully, sit "In Progress" for hours-to-days, then flip to Rejected with this code. What I have verified All four agreements (Apple Developer Program License, Apple Developer Agreement, Paid Apps, Free Apps) are accepted and Active. Re-checked under the Account Holder login on both portals. Banking and W-8BEN-E are Active. Developer ID Application, Apple Distribution, and Apple Development certificates are all valid and the private keys import cleanly. App Store Connect API key works (notarytool history returns the full list with no auth errors). Same codesign invocation, same notarytool submit flags, same hardened runtime entitlements that worked on April 18-20 still produce the rejection on April 21+. Existing support channels Opened a support ticket via the developer contact form under "Development and Technical / Other Development or Technical Questions" (the exact path the error message specifies). Also emailed Developer Programs separately. Question Has anyone with the same "was working, then suddenly 7000 with no other change" pattern had it resolved? I am aware that DTS engineers have stated on this forum that they cannot escalate this. I am trying to get a sense of: Typical resolution time once a Developer Programs case is open (reports range from days to two-plus months). Whether anyone has found a particular wording of the support request that gets routed faster. Whether the Account Holder doing anything specific in the portal (re-accepting an agreement, toggling something in Membership, etc.) ever cleared this for someone. Thanks.

Hi, I’m requesting investigation of two CtxVault notarization submissions that have remained "In Progress" well past 24 hours. Team ID: DCY4ZS6CS6 App / archive: CtxVault.zip Platform: macOS direct distribution Pending submissions: e2f25e8c-8bf6-44e6-8e60-24b22467b7e6 — created 2026-04-22T12:50:04.988Z — still In Progress 1f41ff2d-cf61-4509-beba-3389f4496ba7 — created 2026-04-22T12:40:23.167Z — still In Progress Context: This is a new Developer ID release path for a personal team. Earlier submissions were Invalid due to unsigned nested Mach-O files inside a bundled Python runtime. That issue was corrected before the two pending submissions above. The current app is signed with Developer ID Application, hardened runtime, and secure timestamps. Local validation passes: codesign --verify --deep --strict spctl assessment on the signed app notarytool accepts the upload and returns submission IDs, but the submissions do not complete and no log is yet available. Earlier invalid submission for context: b4e665a0-98eb-4b92-b44c-58a0a2c6122e Could someone from Apple please confirm whether this team is stuck in queue or under extended review, and whether any team-side provisioning or backend action is needed? I am intentionally not creating more duplicate submissions while these corrected jobs remain pending. Thanks.

Hi, I have an approved com.apple.developer.family-controls entitlement for my main app bundle (com.maxflame.prove-it) and submitted a request on April 18, 2026 to extend it to an embedded extension: com.maxflame.prove-it.DeviceActivityMonitorExtension Request ID: 65CKJZ7DQ4 — status still shows "Submitted" with no further response. The extension uses DeviceActivity callbacks and needs to decode FamilyActivitySelection, which requires the entitlement on the extension bundle as well. In my experience, Family Controls entitlement approvals for the main app bundle have come through within 24 hours. It's now been 5 days with no response for this extension request, which seems unusual. Has anyone else gone through this for extension bundle IDs? Did you need to submit a separate request per bundle, or did Apple extend the approval to your extensions automatically once the main app was approved? And has anyone else experienced longer wait times specifically for extension bundles? Any guidance appreciated.