4.3(a) is usually not about your idea. It means App Review matched your binary, metadata or concept to other submissions, and the rejection rarely says which ones. Adding features doesn't change that match, which is why you got the same result. What tends to work: Check where the code came from. If any part of the app started from a template, tutorial or open-source sample that many other apps also used, that's the most common trigger. Rewrite or remove that part, not just the UI. Make the metadata clearly yours: name, subtitle, icon, screenshots and description should not look like other color-identification apps. Lead with what's unique (the colorblindness simulator for family and friends). Ask before resubmitting. Reply in App Review and ask which part of the app or metadata is considered similar, and say it's your own code under a single bundle ID. You can also appeal to the App Review Board with the same explanation and a short screen recording of the simulator feature. Avoid quick resubmissions with small changes. That pattern is what puts accounts at risk. One substantive change with a clear reply, or an appeal, is safer than several quick tries.

That automated price question usually needs two things, not one: the reply and a resubmission. A reply alone often doesn't put the app back in the queue while the status says "Rejected". Open App Review in App Store Connect → the rejected submission. If you see "Resubmit to App Review" (or "Update Review"), use it. Keep the same build; nothing in the binary needs to change. Make the reply short and explicit: "Yes, the intended price for [product ID] is [tier/price] in [currency]. This is correct." If the price really was a mistake, change it in the in-app purchase's pricing first, then reply and resubmit. Check the in-app purchase itself is attached to the version (Version page → In-App Purchases and Subscriptions) and its status is "Waiting for Review", not "Developer Action Needed". First-time IAPs have to go in with the app version. Then one expedite request is reasonable if you have a real date.

Publish usually stays disabled because one of the data types isn't fully answered, even if it looks saved. Things that fix it most often: Open each of the 9 data types and step through all of its questions: the purposes, "linked to the user?" and "used for tracking?". A data type that was added but never had its purposes saved blocks Publish without any warning. The summary page should show all 9 with their purposes listed. Remove one data type and add it back, answering every screen, then check the Publish button again. This sometimes clears a stuck draft. Try another browser or a private window (Safari and Chrome behave differently in App Store Connect), and make sure only one person is editing App Privacy at the same time. Check Users and Access that your account shows the Account Holder/Admin role for this app specifically (not limited app access). If none of that enables Publish, the support case is the right path. Add a screenshot of the full data-type summary, which helps them see it's stuck on their side.

Not resubmitting again is the right call; a new submission would restart the wait. A few things worth checking: Is the Oct 15 submission really tied to the appeal? On the App Review page, open the submission and confirm the build and version match what the Board asked for, and that nothing is listed under "Unresolved Issues". Reply in the original rejection thread, not only a new support case: "Following the App Review Board's Oct 14 message, we resubmitted on Oct 15 (submission ID …). Is anything else needed from us?" That puts the appeal history in front of whoever picks it up. Review notes: dating is one of the categories 4.3(b) names, so the reviewer who opens it needs the difference up front. Put two or three sentences in App Review Information → Notes on what's distinctive ("dates, not DMs": how the flow differs from swipe-and-chat apps), plus the demo account and a link to the screen recording. If there's still nothing after that, the Contact Us form under App Review is the right channel to follow up on an appeal; mention the Board's reply date.

Nobody outside App Review can pre-approve this, but the guideline is fairly clear: 4.3(b) names fortune telling (which astrology falls under) among saturated categories. Some thoughts: Readings anywhere in the app will likely keep it in that bucket. If a reviewer finds personal readings after sign-in, they'll probably classify the app by that feature, even if it's secondary. The cleaner path is the one you suggested: the game as its own app, with no readings, and metadata (name, subtitle, keywords, screenshots) that sells it as a game, not as astrology. The game has to stand on its own. If the astrology theme is just a skin on a common game type, you can trade a 4.3(b) for a 4.3(a). Make the core mechanic something a reviewer won't have seen many times. Account risk: the warning is mostly triggered by a pattern: resubmitting the same rejected concept with small changes, several near-identical apps, or hiding features from review. A genuinely different app, submitted once with clear review notes ("this replaces our rejected astrology app; it contains no readings"), is the opposite of that pattern. Before you build: you can ask App Review directly through Contact Us → App Review, describing the planned app. They won't pre-approve, but replies sometimes tell you whether it would be treated as the same concept.

Your 3.1.3(e) reasoning sounds right: payments for in-person tours belong outside IAP, and a free guide-side tool with no digital purchases shouldn't need IAP at all. A few things that help this kind of submission move: Make sure the answers are attached to the current submission. Because a new build went in with the answers, check on the App Review page that the six answers appear in the thread for this submission (c4d547f4…), not only on the earlier one. If they don't, paste them again there. Put a short version in App Review Information → Notes: "Free business tool for licensed tour guides. No IAP, no paid digital content. Travelers pay for in-person tours in our separate consumer app (Guidalia, Apple ID …), per 3.1.3(e)." Plus a demo guide account that already has a tour and a booking request, so the reviewer can see the whole flow without setting anything up. Expedite: you've already requested one; repeat requests don't help much. When you follow up, mention the Nov 23 date and what happens on it. Don't add another build unless something's actually wrong; it resets the wait.

Sorry, that's a rough spot. While you wait, a few things can shorten it or reduce the damage: Check whether the crash can be stopped from your side. A crash 15–20 seconds after launch on an app that didn't change is often triggered by something remote: an API response, a feature flag, a third-party SDK's config or an expired certificate/key. If you can find it in the crash logs (Xcode Organizer or your crash reporter), a server-side or config fix can bring the current version back today, without waiting for review. Keep the fix submission binary-only. You mentioned two metadata rejections; make sure this submission doesn't carry new screenshots or description changes that could trigger a third. If it does, revert the metadata to the last approved version and say so in the notes. Expedite wording: "Version 9.1 fixes a crash on launch affecting all users of the live version 9.0 since Oct 29 (crash log attached). The submission contains no metadata changes." Attaching a crash log or a short screen recording of the crash helps. Contact Us → App Review → request a phone call is available in many regions and sometimes moves faster than case replies. Once this is through, consider phased release for future updates so a bad build can be paused.

The Oct 9 withdraw-and-resubmit is the likely reason the clock restarted: a new build makes it a new submission, and earlier replies don't carry over. Things worth checking before contacting them again: App Review page: open the submission (not just the version) and look for an "Unresolved Issues" or "Developer Action Needed" state. A metadata rejection sometimes leaves a message there that the version page doesn't show. The 1.1 keyword everywhere: subtitle, keywords, promotional text, in-app purchase display names, and screenshots in every localization. If it's still in one place, they can sit on it. Put the history in App Review Information → Notes: "Oct 2 rejected under 1.1 for keyword X; removed from all localizations on Oct 3; build 61 adds bug fixes only." Whoever picks it up then sees it without the old thread. Don't withdraw again. One expedite request that cites a concrete user impact (a bug in 2.0.0 that 2.0.1 fixes) tends to get further than "please review". If you ship regularly, consider phased releases so you can pause a bad update without needing a fast review.

A metadata-only 2.3.7 doesn't need a new binary, but a reply on its own often doesn't put the submission back in the queue. What usually works: Open App Review in App Store Connect → the rejected submission. If you see "Resubmit to App Review" (or "Update Review" / "Submit for Review" on the version page), that's the step that moves it; the reply just explains the change. Keep the same build. The locked 6.9" and 6.5" sets: that usually means those sets are still tied to the rejected submission, or they're showing Apple's scaled versions of another size. Check whether each says "Using 6.9" display" or similar. If the 6.5" set is just scaled from 6.9", fixing 6.9" fixes both. If none of them will unlock, App Review → Contact Us → "App Review" lets you ask them to unlock the metadata; mention the screenshot by position. Check every place the old wording can hide: all iPhone and iPad sizes, every localization's screenshots, App Previews, and the promotional text. One leftover screenshot is enough for a second 2.3.7. Don't add a new build to the submission just to "nudge" it. That makes it a new submission and resets the wait. One short reply once it's resubmitted is enough: "Removed the screenshot showing pricing/'free' wording from all device sizes and localizations. No binary change."

One more thing to check besides where the answers are placed: the 1.3 questions are often triggered by what's in the binary, not by the notes. If any third-party analytics, ads or attribution SDK is linked (Firebase Analytics, AdMob, Unity Ads, Facebook SDK, even if unused), review asks these questions, and "none" in your answers then contradicts the build. Check Package.resolved / Podfile.lock, remove anything you don't use, and make sure your App Privacy labels say the same as your answers. Also make sure purchases and external links sit behind a parental gate. Paste the four answers into the Resolution Center reply itself, since attached PDFs aren't always opened.

Your own guess is probably right: an earlier TestFlight build of the same app under a different developer account can look to review like the same app from another developer, and resubmitting unchanged won't change that. In the Resolution Center, give the facts: the other account's team name/ID, that it was an internal TestFlight-only build that was never released, who owns that account, and that this account is now the only publisher. Offer to remove the app record from the other account (or do it and confirm). Then wait for their reply before submitting again. If it's rejected again after that explanation, appeal to the App Review Board with the same facts.

Adding to Pokpong's reply: 4.2.6 is the guideline about apps created from commercialized templates or app-generation services. Five unrelated apps from one individual account, reviewed close together, can look to review like generator output, and then 4.3 follows. In the answers to the nine questions, state plainly that no template or app-generation service was used, describe your stack and who wrote the code, and say how each app is maintained. For Cookie Hide, put what's different from the approved Safari cookie-banner blockers in the first two lines of the review notes (the TCF consent receipts and the public 100-site test page are strong points). When you resume, submit one app at a time and wait for a decision before the next.

Since the rejection says "with apps submitted by other developers", your code history probably isn't what triggered it. Provenance evidence helps when the match is to your own apps or a shared template. Here, review is most likely matching the concept and metadata to the many existing passport/ID-photo apps, and most of the features you list (on-device background removal, auto-framing, multiple formats) are things the top apps in that category also advertise. What usually moves a 4.3(a) in a crowded category: Pick the one workflow nobody else has (for example: one source photo → every format in one batch, with country-specific head-size checks) and lead with it in the name, subtitle, first three screenshots and the first lines of the description. In the review notes, compare the app to 2–3 named apps in one short paragraph: "Unlike X and Y, Canvasz…". Attach a 30–60 second screen recording of that workflow. In the Resolution Center, ask directly whether the concern is the concept or the metadata. If you still think the concept judgment is wrong after that, the App Review Board appeal is the formal route.

One thing that may help frame the appeal: "Section 3.2" in these notices refers to the Apple Developer Program License Agreement (usually 3.2(f), dishonest or fraudulent acts), and 5.6 is the Developer Code of Conduct. So Apple sees this as an account-conduct issue rather than a functionality bug, which is why it was a removal rather than a normal rejection, and why the technical fix on its own probably won't reverse it. What tends to help an appeal like this: Look for anything that could look like manipulation from Apple's side: incentivised or bulk reviews, paid install campaigns or a promo vendor, a review-prompt or rewards SDK, an ad network with suspicious traffic, unusual refund patterns, or a link to another account (shared Mac, team member, payment details). In the appeal, say what you checked, what you removed or changed and when, and attach evidence (vendor invoices, analytics showing organic installs). Keep the technical fix as a separate, short point at the end, not the main argument. While the appeal is pending, don't upload new builds or set up a new account to republish. Apple tends to treat that as evasion, and it can make things worse.

Taking your questions in order: Separate step? Usually yes, in two parts. A removal through App Store Notices is lifted on Apple's legal side, not by App Review, so the "removed from sale" banner stays until App Store Notices closes it internally. That's normally a separate action from them confirming the dispute is resolved. Also open Pricing and Availability in App Store Connect and check that your countries/regions are still selected. After a removal they are sometimes cleared, and the app stays off sale even once the hold is lifted. Is the removal blocking 1.0.5? Quite possibly. An app with an open removal flag often sits in Waiting for Review until the flag is cleared. Don't cancel and resubmit, as that only resets your place in the queue. Better channel: besides replying in the App Store Notices thread with APP265997, open a case via developer.apple.com/contact → App Store Connect / "Removal of app". Ask specifically for the removed-from-sale status to be lifted following the other party's Oct 5 confirmation, and attach that confirmation. Once the banner is gone, you can also request an expedited review for 1.0.5.