Hi, I'm a new Apple Developer Program enrollee (1 week in) shipping a Mac app via Developer ID + notarytool. Hardened runtime enabled, properly timestamped, all embedded Mach-O signed inside-out. 10 submissions are stuck "In Progress" - the oldest from 2026-06-07 (60+ hours ago). One Invalid verdict came back on 2026-06-08 for a real signing issue (unsigned PyQt5 framework binaries) which I've since fixed; the 10 newer submissions should pass cleanly. Apple's system status page has shown Developer ID Notary Service as green ("Operational") this entire time. This appears to be a queue issue specific to my account, not a service-wide outage. xcrun notarytool history: createdDate: 2026-06-09T16:26:37Z id: 4c928b64... status: In Progress (17h) createdDate: 2026-06-09T16:25:26Z id: 74e9feed... status: In Progress (17h) createdDate: 2026-06-08T21:13:31Z id: 8b246574... status: In Progress (37h) createdDate: 2026-06-08T20:59:37Z id: 4a529617... status: In Progress (37h) createdDate: 2026-06-08T18:49:33Z id: ff43d591... status: In Progress (39h) createdDate: 2026-06-08T18:46:27Z id: 60579d8d... status: In Progress (39h) createdDate: 2026-06-08T18:36:02Z id: a82fd14b... status: In Progress (39h) createdDate: 2026-06-08T18:22:45Z id: 4514a5cb... status: In Progress (39h) createdDate: 2026-06-07T21:20:09Z id: 700c8413... status: In Progress (60h) createdDate: 2026-06-07T20:18:08Z id: 2ea83c6c... status: In Progress (60h) xcrun notarytool info on each returns "status: In Progress" with no processedDate set. I understand new submitters can get held for extended in-depth analysis on first submissions, but 60+ hours is past any documented expectation for that. Could a DTS engineer please look at the backend logs and either release the queue or tell me what's specifically blocking these submissions? Thanks!

This is the first notarisation activity on a newly enrolled Developer Program account. Every submission has been stuck "In Progress" with no terminal status and no log available. Oldest stuck request: UUID: bfb5a0e3-31a2-4dcd-a1c6-2f26ce6e62dd Created: 2026-05-29T13:43:22Z Team ID: ZH3S4VZT33 It has now been more than 7 days. I understand first-time submissions can be held for in-depth analysis, which is why I waited a full week before posting. Evidence this is account/team-level rather than specific to one app: A second submission the same day (e42fb5f4-8fc7-4eec-9eef-9764e756b444) and a separate throwaway probe app submitted 2026-06-01 (0333a989-3a9f-44b1-98e6-69f9ee4028e4) are all stuck "In Progress" too. xcrun notarytool log <id> returns "Submission log is not yet available" for all of them. No rejection email at the Apple ID address. Apple System Status shows Developer ID Notary Service as Available. Could someone from the notary service team check the queue for Team ID ZH3S4VZT33 and advise whether these are in the in-depth-analysis path? Happy to provide codesign output or additional UUIDs.

Hello Team, We are currently implementing a digital membership solution across our gym facilities, allowing members to add their access cards to Apple Wallet. In this regard, we would like to request enablement of NFC capability for Wallet passes associated with our Apple Developer account. Our setup includes NFC-enabled access control hardware integrated with our gym management system, and NFC support is required to issue and utilize digital membership cards. At present, we only have a standard Pass Type ID Certificate in our developer account. However, we understand that NFC-enabled Wallet passes require a Pass Type ID Certificate with NFC capability. We would appreciate your guidance on how we can enable or obtain a Pass Type ID Certificate with NFC support in our Apple Developer account. Looking forward to your support.

Seeing my notarizations getting stuck. This is becoming a blocker for releasing. What's strange is that earlier versions of the same app (very similar) passed notarization very quickly. Any advice or recourse?

My app includes the main program, Finder extension, and launcher helper. Which identifier should I choose when generating a provisioning profile?

Hi, I have Identifiers that's used maybe in old Xcode projects long time ago that never been uploaded for Apple to approve and yet when trying to remove I get an error message below, any suggested fixes ? " The App ID 'xyz.xyz.xyz' appears to be in use by the App Store, so it can not be removed at this time. "

On the Certificates, Identifiers and Profiles section of the Account section of developer.apple.com, if you manually configure the Capabilities of an App Identifier, there are icons with no tooltips. Does anyone know what they mean? (I'm particularly interested in the two different icons shown in my screenshot, with the same name)

I've read Quinn's response on thread 827096 about Developer ID notarization submissions held for "in-depth analysis" on new teams. That guidance fits the general shape of what I'm seeing, but I'm posting a separate thread because (a) my situation does not involve an app transfer — these are the first-ever notarizations under a newly activated team, and (b) I've passed the "usually clears in a day or two" expectation and want to ask a few specific questions that thread didn't cover. Setup macOS app distributed outside the App Store Rust universal binary (aarch64-apple-darwin + x86_64-apple-darwin, merged via lipo) Binary signed with Developer ID Application, hardened runtime (--options runtime) and Secure Timestamp (--timestamp) .pkg built via pkgbuild + productsign with Developer ID Installer Team was activated 2026-05-29 — these are our first notarizations under the account, no prior submission history Submissions Submission A — submitted 2026-05-29T19:18:02Z, currently 100+ hours In Progress Submission B — submitted 2026-06-01, currently 30+ hours In Progress, identical polling behavior (Submission IDs available to DTS on request — happy to share via DM or via the Apple Developer Support case we have open on the same issue.) I submitted B specifically to test whether A was a one-off stuck queue entry. Both stalling identically rules that out and points at a team-level condition rather than a per-submission issue. xcrun notarytool log returns Submission log is not yet available or submissionId does not exist for both — same as the OP's experience on 827096. Local verification — every check in TN2206 passes $ pkgutil --check-signature .pkg Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2026-05-29 19:15:36 +0000 Certificate Chain: Developer ID Installer: () Developer ID Certification Authority Apple Root CA $ codesign --verify --strict --verbose=2 valid on disk satisfies its Designated Requirement $ codesign --display --verbose=4 | grep -E '^(Authority|Timestamp|Runtime|TeamIdentifier)=' Authority=Developer ID Application: () Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=May 29, 2026 at 12:13:40 PM TeamIdentifier= Runtime Version=26.5.0 xcrun notarytool history returns successfully and lists both submissions, so authentication and connectivity to the notary service are healthy. Developer System Status has shown the Developer ID Notary Service as "Available" throughout. Questions for DTS (Quinn or whoever picks this up) Quinn's 827096 reply describes "in-depth analysis" for new teams clearing in a day or two. Is there a known long-tail beyond that window, and is there anything a team can do to flag itself as ready for processing rather than waiting passively? Does resubmitting (as I did with submission B) extend, restart, or sit independently from the review of submission A? Is the review-completion clock driven by the team's activation date, the first submission, or the cumulative submission history? In other words, does each new submission help the team's signal, or does the system wait for the first to fully clear before evaluating subsequent ones? If we hit the 1-week mark Quinn referenced as the escalation tripwire without resolution, what's the recommended channel — a follow-up reply here, a new thread, Feedback Assistant, or another route? We also have an open Apple Developer Support case on this, currently silent for 4 days. Working that channel in parallel. Thanks in advance for any guidance — and thanks to Quinn for the public visibility he's given this pattern on 827096; it's the most useful documentation on it I've been able to find.

I've tried to add the "Pass Type Identifiers" entitlement manually in .entitlements, but it will not archive and shows the error: Entitlement com.apple.developer.pass-type-identifiers not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. It works correctly for the App (parent of ), but without it the App Clip can't see any passes. The documentation says this should be possible: Note In iOS 17 and later, App Clips can use the Wallet capability. For more information on functionality that’s available to App Clips, see Choosing the right functionality for your App Clip. It is not visible in the portal either. Is this an entitlement that I need to specifically request, and if so, how would I go about doing so? Thanks! Wes

Hi Apple Developer Support, I am writing to escalate an urgent unresolved request regarding our app BetterUs (Team ID: TK8M23SECQ, Bundle ID: com.dalesidebottom.betterus). Timeline of attempts: ~1 May 2026 — Submitted FamilyControls Distribution entitlement request via the official form at developer.apple.com/contact/request/family-controls-distribution for bundle IDs com.dalesidebottom.betterus.shield and com.dalesidebottom.betterus.report. No confirmation number received, no response. ~20 May 2026 — Raised support case 102892887667 via developer.apple.com/contact. Received acknowledgement from Eugene. ~21 May 2026 — Replied with all requested information (date of submission, business need, bundle IDs). Today — Still no approval and no further response. It has now been over 3 weeks since the original request. What I need: The FamilyControls Distribution entitlement is already approved on my account for: com.dalesidebottom.betterus ✅ com.dalesidebottom.betterus.monitor ✅ I simply need it extended to these two sub-extensions of the same app: com.dalesidebottom.betterus.shield (Shield Configuration extension) com.dalesidebottom.betterus.report (DeviceActivity Report extension) These are not new use cases — they are part of the same approved parental screen time app. Without this, BetterUs cannot be submitted to the App Store at all. I have active testers waiting and this delay is significantly impacting our launch. I would greatly appreciate urgent attention on this matter. Thank you, Dale Sidebottom

This issue keeps cropping up on the forums and so I decided to write up a single post with all the details. If you have questions or comments: If you were referred here from an existing thread, reply on that thread. If not, feel free to start a new thread. Use whatever topic and subtopic is appropriate for your question, but also add the Entitlements tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Determining if an entitlement is real In recent months there’s been a spate of forums threads involving ‘hallucinated’ entitlements. This typically pans out as follows: The developer, or an agent working on behalf of the developer, changes their .entitlements file to claim an entitlement that’s not real. That is, the entitlement key is a value that is not, and never has been, supported in any way. Xcode’s code signing machinery tries to find or create a provisioning profile to authorise this claim. That’s impossible, because the entitlement isn’t a real entitlement. Xcode reports this as a code signing error. The developer misinterprets that error [1] in one of two ways: As a generic Xcode code signing failure, and so they start a forums thread asking about how to fix that problem. As an indication that the entitlement is managed — that is, requires authorisation from Apple to use — and so they start a forums thread asking how to request such authorisation. The fundamental problem is step 1. Once you start claiming entitlements that aren’t real, you’re on a path to confusion. Note If you’re curious about how provisioning profiles authorise entitlement claims, read TN3125 Inside Code Signing: Provisioning Profiles. There are a couple of ways to check whether an entitlement is real. My preferred option is to create a new test project and use Xcode’s Signing & Capabilities editor to add the corresponding capability to it. Then look at what Xcode did. You might find that Xcode claimed a different entitlement, or added an Info.plist key, or did nothing at all. IMPORTANT If you can’t find the correct capability in the Signing & Capabilities editor, it’s likely that this feature is available to all apps, that is, it’s not gated by an entitlement or anything else. Another thing you can do is search the documentation. The vast majority of real entitlements are documented in Bundle Resources > Entitlements. IMPORTANT When you search for documentation, focus on the Apple documentation. If, for example, you search the Apple Developer Forums, you might be mislead by other folks who are similarly confused. If you find that you’re mistakenly trying to claim a hallucinated entitlement, the fix is trivial: Remove it from your .entitlements file so that your app starts to build again. Then add the capability using Xcode’s Signing & Capabilities editor. This will do the right thing. If you continue to have problems, feel free to ask for help here on the forums. See the top of this post for advice on how to do that. [1] Xcode 26.2, currently being seeded as Release Candidate, is much better about this (r. 155327166). Give it a whirl! Commonly Hallucinated Entitlements This section lists some of the more commonly hallucinated entitlements: com.apple.developer.push-notifications — The correct entitlement is aps-environment (com.apple.developer.aps-environment on macOS), documented here. There’s also the remote-notification value in the UIBackgroundModes property. com.apple.developer.in-app-purchase — There’s no entitlement for in-app purchase. Rather, in-app purchase is available to all apps with an explicit App ID (as opposed to a wildcard App ID). com.apple.InAppPurchase — Likewise. com.apple.developer.storekit — Likewise. com.apple.developer.in-app-purchase.non-consumable — Likewise. com.apple.developer.in-app-purchase.subscription — Likewise. com.apple.developer.app-groups — The correct entitlement is com.apple.security.application-groups, documented here. And if you’re working on the Mac, see App Groups: macOS vs iOS: Working Towards Harmony. com.apple.developer.background-modes — Background modes are controlled by the UIBackgroundModes key in your Info.plist, documented here. UIBackgroundModes — See the previous point. com.apple.developer.voip-push-notification — There’s no entitlement for this. VoIP is gated by the voip value in the UIBackgroundModes property. com.apple.developer.family-controls.user-authorization — The correct entitlement is com.apple.developer.family-controls, documented here. IMPORTANT As explained in the docs, this entitlement is available to all developers during development but you must request authorisation for distribution. com.apple.developer.device-activity — The DeviceActivity framework has the same restrictions as Family Controls. com.apple.developer.managed-settings — If you’re trying to use the ManagedSettings framework, that has the same restrictions as Family Controls. If you’re trying to use the ManagedApp framework, that’s not gated by an entitlement. com.apple.developer.callkit.call-directory — There’s no entitlement for the Call Directory app extension feature. com.apple.developer.nearby-interaction — There’s no entitlement for the Nearby interaction framework. com.apple.developer.secure-enclave — On iOS and its child platforms, there’s no entitlement required to use the Secure Enclave. For macOS specifically, any program that has access to the data protection keychain also has access to the Secure Enclave [1]. See TN3137 On Mac keychain APIs and implementations for more about the data protection keychain. com.apple.developer.networking.configuration — If you’re trying to configure the Wi-Fi network on iOS, the correct entitlement is com.apple.developer.networking.HotspotConfiguration, documented here. com.apple.developer.musickit — There is no MusicKit capability. Rather, enable MusicKit via the App Services column in the App ID editor, accessible from Developer > Certificates, Identifiers, and Profiles > Identifiers. These app services are tied to your App ID on the server side, meaning that they have no presence in your code signature. com.apple.developer.shazamkit — There is no ShazamKit capability. Like MusicKit, this is an app service. com.apple.mail.extension — Creating an app extension based on the MailKit framework does not require any specific entitlement. com.apple.security.accessibility — There’s no entitlement that gates access to the Accessibility APIs on macOS. Rather, this is controlled by the user in System Settings > Privacy & Security. Note that sandboxed apps can’t use these APIs. See the Review functionality that is incompatible with App Sandbox section of Protecting user data with App Sandbox. com.apple.developer.adservices — Using the AdServices framework does not require any specific entitlement. com.apple.security.device.audio-input-monitoring — The com.apple.security.device.microphone entitlement is what restricts microphone access on macOS. [1] While technically these are different features, they are closely associated and it turns out that, if you have access to the data protection keychain, you also have access to the SE. Revision History 2026-05-28 Added com.apple.security.device.audio-input-monitoring to the common hallucinations list (Kevin) 2026-04-23 Added com.apple.developer.shazamkit to the common hallucinations list. Added a little more info about app services. 2025-12-09 Updated the Xcode footnote to mention the improvements in Xcode 26.2rc. 2025-11-03 Added com.apple.developer.adservices to the common hallucinations list. 2025-10-30 Added com.apple.security.accessibility to the common hallucinations list. 2025-10-22 Added com.apple.mail.extension to the common hallucinations list. Also added two new in-app purchase hallucinations. 2025-09-26 Added com.apple.developer.musickit to the common hallucinations list. 2025-09-22 Added com.apple.developer.storekit to the common hallucinations list. 2025-09-05 Added com.apple.developer.device-activity to the common hallucinations list. 2025-09-02 First posted.

Ive spent nearly one month to develop my first app, and now its done. but i am stuck with getting Family Controls Distribution entitlement. i`ve request that one month and half ago. but still get no response. I tried connect the apple developer support、send post on Forum、send code-level support on appstoreconnect. All completely disappeared into a black hole. I understand that you may be facing a significant backlog, waiting for nearly two months without any response or update regarding the Family Controls Distribution entitlement is extremely difficult for me to understand. I genuinely cannot understand why Apple’s review process is operating with such low efficiency.

Every notarization submission from my team is being rejected by the notary service with this message: statusCode: 7000 statusSummary: "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions." 23 submissions in the past few days all returned this same rejection. Before submissions started returning Rejected, they would sit at "In Progress" indefinitely (sometimes for days), which I initially mistook for the in-depth-analysis slow-lane. Once Apple's queue cleared the backlog, every one of them surfaced as statusCode 7000. Ruled out on my side: Apple Developer Program membership is active License Agreement signed (days before the submissions) Code signing is valid (Developer ID Application chain), hardened runtime enabled, secure timestamp present ASC API key successfully submits and queries (the issue is in server-side processing/policy, not auth) Tested with both a minimal binary and a full app, same rejection Team ID: XSN9V8JZ75 Reference submission ID (the small isolated test): ba67edaf-c3d9-44dd-9974-5fc1811e0f72

These have been stuck in progress for a long time. Usually this process is fairly quick for this app: id: 92caae7f-1796-4928-bb35-72f5f2667786 id: 3645e93f-a8ac-4826-8a4a-690f980dde8e id: 3645e93f-a8ac-4826-8a4a-690f980dde8e What can be done, it is holding back deployments :(

I made a small 20MB .pkg installer for some Logic Pro Drum Machine Designer patches so the user doesn't have to manually place the files by hand. Tried to notarize 3 times, all attempts have been stuck "in progress" since yesterday and can't seem to get any log files that might explain where things are getting stuck. Are the duplicate submissions causing this and if so is there a way to de-duplicate? My first time doing this so when notarization was hanging on the first attempt I thought I had done something incorrectly. Not sure how to troubleshoot this and would appreciate any guidance.

Adding application ID to .pkg file seemed to work Original My modified version I created a .pkg file which installed to Applications folder and the app worked fine, but when I uploaded the app with transporter I got the message 'executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true'

Hello Apple Developer Support Team, This is my first app submission. I submitted my app on 18 May 2026, and since then all notarization submissions have remained in “In Progress” for an unusually long period without completing. Environment macOS 26.2 Notarization tool: xcrun notarytool submit Team ID: HRZ4D6R846 Developer ID signing identity is valid and correctly detected Timeline Issue started on 18 May 2026 Multiple submissions have remained in “In Progress” for 24–72+ hours Current count: 3+ submissions stuck in progress Checks already completed Verified the Developer ID Application certificate is valid and properly installed. Verified app signatures using: codesign -vvv --deep --strict Checked Apple Developer System Status, which currently shows all services as operational Re-submitted using fresh builds and credentials, but the behavior remains unchanged Could you please confirm whether there is any known notarization processing issue on Apple’s side during this period, and advise on the following: How to unblock the currently stuck submissions Whether the “In Progress” submissions should be cancelled and re-submitted Thank you for your assistance. Best regards, Rishikesh Galande

Team ID: C5S6LNK274 Issue Description: Starting from 2026-05-21 06:31:24 UTC, all my notarization submissions have been stuck in "In Progress" status for over 4 hours. Yesterday (2026-05-20) and all days before that, submissions completed successfully with status "Accepted". Today's submission history shows a clear queue blockage pattern: First stuck task: 94e73c5d-9c54-4ad2-9a63-f1f158aa6647 (created at 06:31:24) Total stuck tasks so far: 20 (all with status "In Progress") The 20 stuck tasks span from 06:31:24 to 10:05:02 UTC No tasks after 06:31 have completed Here is the stuck queue: createdDate: 2026-05-21T10:05:02.525Z id: 03055f30-afc3-42ca-ab42-25cfffa7aef3 status: In Progress createdDate: 2026-05-21T10:04:56.904Z id: 4f9daed0-a911-43db-aa00-74ba27cf6d69 status: In Progress createdDate: 2026-05-21T09:41:15.173Z id: 80e0677c-f9ce-4eb6-94d8-435ca6b0c05f status: In Progress createdDate: 2026-05-21T09:41:09.030Z id: 564c5cc5-6a1e-4ac7-8c87-e15c6a7e8a98 status: In Progress createdDate: 2026-05-21T09:39:01.267Z id: 0531d545-20f9-44eb-87b5-b6a0074f6efb status: In Progress createdDate: 2026-05-21T09:38:46.491Z id: dc67c99e-f7ee-4d50-8771-399ff77598f9 status: In Progress createdDate: 2026-05-21T09:26:12.019Z id: 65105788-6e03-4d18-a21d-e3229007f9d5 status: In Progress createdDate: 2026-05-21T09:26:02.085Z id: 508da919-d7e2-4357-af40-c66255f7765f status: In Progress createdDate: 2026-05-21T09:11:58.772Z id: b6cdbe19-22a2-4667-8104-86bd9ef476d5 status: In Progress createdDate: 2026-05-21T09:11:53.703Z id: e27c10ee-0cfa-4528-971e-a2582041ff83 status: In Progress createdDate: 2026-05-21T08:51:08.738Z id: 3defc9fe-57ed-4343-a312-45fb3aec3d9e status: In Progress createdDate: 2026-05-21T08:51:08.526Z id: a46c5740-c908-4744-a404-c6a79ce06883 status: In Progress createdDate: 2026-05-21T08:37:20.380Z id: fc5364be-0944-4e43-b277-12917db7c1c0 status: In Progress createdDate: 2026-05-21T08:37:16.382Z id: cf78e06d-105f-4fcf-bdd0-f67875ec8349 status: In Progress createdDate: 2026-05-21T08:04:48.709Z id: 7ffc08ca-52a8-48f8-8196-93faa65b7bce status: In Progress createdDate: 2026-05-21T08:04:34.254Z id: 087d0c51-eef1-4af7-85fd-52b4809c46f1 status: In Progress createdDate: 2026-05-21T07:31:57.221Z id: f9d2a9f8-ddbf-48d6-b3fc-95df8e442239 status: In Progress createdDate: 2026-05-21T07:31:51.103Z id: 7a1da2ed-8e39-40cd-a155-b23abab4aed9 status: In Progress createdDate: 2026-05-21T06:31:24.535Z id: 94e73c5d-9c54-4ad2-9a63-f1f158aa6647 status: In Progress createdDate: 2026-05-21T06:31:21.188Z id: b443dceb-c92e-47b4-8458-057e9304b60e status: In Progress Key observations: This is NOT a new developer account - submissions from yesterday and all prior days completed successfully No changes to the app bundle between yesterday (working) and today (stuck) All stuck submissions are for the same file (VV AI.zip) No error messages - just permanently "In Progress" What I've tried: Waited 4+ hours Stopped all new submissions (no retries after 10:05 UTC) Request: Could someone from Apple DTS please check the server-side queue status for Team ID: C5S6LNK274 Specifically, please check if the first stuck task (94e73c5d-9c54-4ad2-9a63-f1f158aa6647) has encountered an internal error that is blocking the entire submission queue. Thank you.

Hi Apple DTS, FivePrayer is a live App Store app and we are blocked by Family Controls (Distribution) after an app transfer. Bundle ID: com.fiveprayer.app Current team: FivePrayer LLC Previous team: Gansoft Inc. App Store: https://apps.apple.com/us/app/fiveprayer/id6755536905 This same app previously had Family Controls (Distribution) approved under Gansoft Inc. After the transfer to FivePrayer LLC, the capability did not carry over, so we had to request it again. It has now been pending for almost one month, and we cannot ship critical updates because Family Controls is a core dependency of the app. Is there a way to re-associate the previously approved entitlement with the transferred App ID, or route this to the correct Managed Capabilities / Entitlements team? Thank you.

Hello, Between April 20 and April 25 of this year, I submitted a request for the Family Controls Distribution entitlement through the following page: https://developer.apple.com/contact/request/family-controls-distribution After submitting the request, I clearly saw the message: “Thank you for your submission. We’ll review your request and contact you soon with a status update.” However, I have not received any further update or feedback since then. Afterward, I contacted Apple multiple times. Unfortunately, the responses I received consistently indicated that the relevant teams were unable to check the status or progress of the entitlement request, and no clear timeline or follow-up commitment was provided. Eventually, I was informed via email that the issue had already been escalated to the operations team for handling. However, many more days have now passed without any progress or update. At this point, it has been nearly one month since I submitted the entitlement request, yet I still have not received any result, status update, or meaningful feedback. I genuinely do not understand why the tracking and communication process for this entitlement request is so unclear and slow. I would sincerely appreciate it if the relevant team could provide a clear update regarding the current status of my request and the expected next steps. Thank you.