That sounds frustrating, especially with several unrelated apps receiving the same questions together. Since the four reviews are still open, I’d keep each reply attached to its own Resolution Center conversation and ask whether the reviewer needs a specific demo or clarification for that app. A short screen recording showing the core workflow, plus a concise explanation of what is built in common versus what is unique, may be easier for them to assess than sending source code unsolicited. For the 4.3(a) decision, the public forum can’t see the comparison or tell you which app triggered it. In the existing rejection thread, ask App Review to clarify the specific similarity they want you to address, and explain the concrete differences in the binary, metadata, audience, and user workflow. Keep the reply factual and avoid changing or resubmitting more apps until you get direction, so you don’t create another review cycle without knowing what to fix.

For a membership termination under 3.2(f), the reinstatement decision has to come from Apple’s account review team, so the public forum can’t see the case or estimate a timeline. Since Support already said it was forwarded to the senior team, I’d keep everything on that same case and ask for a status check and whether they need any specific additional information. A concise timeline and any requested evidence are easier to review than opening another case. I’d also avoid creating another developer account or reposting private case details publicly while the appeal is pending. If the team gives you a next step, follow that through the private support channel so it stays attached to the appeal.

I wouldn’t remove one platform version just because the two submissions were flagged together. In the Resolution Center, explain that these are the macOS and iOS versions of the same product and point out the platform-specific differences reviewers can verify, such as controls, interface and supported features. Include the app IDs, version/build numbers and separate screenshots or a short recording for each platform. If the rejection doesn’t say what made the submissions look duplicative, ask App Review to identify the specific concern before changing the bundle setup. That gives you a clearer path than deleting a platform submission based on a guess about how the automated check works.

If the app still shows “Unable to Continue” after Support’s checklist, this probably needs someone at Developer Support to check the enrollment record or the specific account restriction. I don’t know of a public workaround that bypasses that message, so I’d avoid starting another enrollment attempt or creating more cases. Reply to the existing case with the exact error screenshot, confirmation that you completed each checklist item, and the dates of your last follow-ups. Ask them to confirm whether the enrollment is blocked on any verification step and whether you can continue through the web enrollment flow. Keep account details and documents in the private case. The Apple Developer Support page has the current contact options for your region.

That message usually means the enrollment flow has hit a limit and Apple needs to review it. I’d stop retrying for now, since another attempt probably won’t remove the block. Pick one of your existing support cases and reply there with a screenshot of the message, when it first appeared, your country, and whether you’re enrolling as an individual or an organization. Include the Enrollment ID if you have one. Keep your Apple Account email and any identity or payment documents in the private support case, not in this public thread. Apple’s enrollment guide explains how to follow up with Developer Support.

Because the listing still appears for “haniva app” and in the Search API, it sounds like the app is available and the exact-query result is the part that changed. I’d avoid changing the app name while Apple is looking into it. In the existing support case, send the storefront, exact search term, date and a recording of the results on apps.apple.com, then ask whether the “haniva” spelling correction can be reviewed. Keeping the cases and FB number linked should help avoid splitting the history across separate reports.

Since you replied and resubmitted on October 10, the app is back in the review queue from that submission date. Accepting the agreement on October 15 was still important, but it doesn’t itself move a submission out of Waiting for Review. I’d check that build 4 is still the selected build and that there are no new Resolution Center messages or agreement banners in App Store Connect. If everything is clear, follow up in the existing support case with the October 10 resubmission date and submission ID, rather than creating another submission just to change the queue date.

One practical thing to try on the next submission: put a short, direct answer to each of the four questions in the App Review Notes, using the same wording as the questionnaire, and point to the exact page in the app where the related controls can be tested. Keep the PDF as supporting detail, since reviewers may not use an attachment as a substitute for the answers in the notes. For the two current submissions, I’d reply in the Resolution Center with the answers again in the message itself and ask which specific answer was missing or unclear. That gives the reviewer the information in the active review conversation and gives you a record to reference with Developer Support. I wouldn’t assume from the outside that the notes or attachment were not visible.

Since payment was completed 26 days ago, this is well past Apple's published 24-hour point for contacting support if you haven't received membership confirmation. The enrollment guide says to sign in with the Apple Account used to enroll and include your Enrollment ID in the support request. Send the order number and invoice only through the private support case, not here. One detail worth checking: if this is an individual enrollment paid by credit card, Apple says the card must be your own; using someone else's card can delay enrollment and lead to an ID check. If that's not the issue, ask Developer Support to confirm whether the payment is linked to the Enrollment ID and whether any verification step is still pending. Guide: https://developer.apple.com/help/account/membership/program-enrollment/

With multiple replacement builds submitted since Oct 16, I'd first check App Store Connect's App Review page and identify exactly which submission/version/build is currently active. Include that ID and the older submission IDs in one follow-up to the existing support case, and ask whether any review information or account requirement is missing for the active one. That gives Support a clear timeline to investigate; the public forum can't see the queue or tell whether there is an account-side issue. I'd avoid sending another replacement solely to try to advance review. Submit a new build only if you have a specific fix to make, and include complete review notes, test credentials if needed, and steps to reach the affected features. Apple's status guide: https://developer.apple.com/help/app-review/after-submitting-for-review/review-status/ and review information guide: https://developer.apple.com/app-store/review/

One detail that may help frame the delay: the current submission ID is the Oct 13 resubmission, so its “Waiting for Review” time starts from then. The earlier review work and the Oct 5 submission that was removed don't carry over to this queue position. Since the current status is still Waiting for Review, check that the Resolution Center has no new request and that all review notes/demo details are attached to the Oct 13 submission. You already have an expedite request and support case, so update that case with the Nov 2 event date and the current submission ID rather than opening more cases or cancelling this version. Apple describes the status and expedite process here: https://developer.apple.com/help/app-review/after-submitting-for-review/review-status/ and https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review/ I’d also prepare a fallback for the event in case review doesn’t finish before Nov 2, since Apple doesn’t promise a specific completion time.

The approval email and “Review Completed” / “Approved” submission are good evidence that the review decision was approval, but the version page showing “In Review” is a conflicting App Store Connect state. Because the scheduled launch time of 03:00 UTC has now passed, update your existing support case with the current status and say the release is still blocked. Include the submission ID, app ID, version/build, the exact error, and screenshots of both pages. Ask App Store Connect Support to reconcile the version status and release controls. I would not withdraw or resubmit an approved version while Support is checking it. If the version later changes to “Pending Developer Release,” the account holder, admin, or app manager can use “Release This Version.” If it shows “Processing for Distribution,” Apple says it can take up to 24 hours to appear. Release status guide: https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option/ and contact support: https://developer.apple.com/help/app-store-connect/

The “Waiting for Review” label means Apple has received the submission but review hasn't started yet. A verified trader status is one requirement, but it doesn't tell us whether a specific submission has entered the review queue or whether anything else is holding it. The forum can't see your account or escalate that case. One thing to check in the App Review section is whether the seven IAPs are part of the same submission as version 1.12.1, or are separate submissions. If they were submitted together, Apple notes that all items in a submission need to be accepted for the submission to complete. Keep the current submission in place and reply on case 102998404388 with the app version, build, submission date, and screenshots of the current status. Apple's status guide is here: https://developer.apple.com/help/app-store-connect/reference/app-information/app-and-submission-statuses/ and the submission workflow is here: https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/overview-of-submitting-for-review/

TestFlight external testing isn't instant because the first build you add to an external tester group has to go through TestFlight App Review. Apple says that review is required for the first build; later builds may not need a full review. Internal testing is a separate option for up to 100 App Store Connect users, so if you only need teammates to try it, you can add them as internal testers instead. Check TestFlight > Builds for the exact status. “Waiting for Review” means it was submitted and needs approval before external testing; “Ready to Submit” means it still needs to be sent for review. Apple explains the flow here: https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview/ and the statuses here: https://developer.apple.com/help/app-store-connect/reference/app-build-statuses/

Thanks for putting together such a detailed repro. One possible workaround to try in the shipping hierarchy is to move the fullScreenCover(item:) modifier and the selected-photo state above the page-style TabView, so the presentation is owned by a stable parent instead of a tab that can be replaced during a diff. Your repro already suggests that placing the cover outside the TabView avoids the failure. Apple's API describes the item binding as the source of truth for the presentation: https://developer.apple.com/documentation/swiftui/view/fullscreencover(item:ondismiss:content:) The .id(...) and stable ZStack changes you tested look like useful targeted workarounds for the two separate identity changes. I'd keep the regression test around each trigger and file the minimal reproducer with Feedback Assistant, including the crash logs across OS versions. I wouldn't treat the UIKit assertion as proof of a documented SwiftUI contract, but the deterministic repro and crash volume should make a strong bug report.