The wording change from “other developers” to “you or other developers” may be meaningful, but I would not treat it as proof by itself. The practical next step is to make your appeal evidence separate three possible issues: binary similarity, metadata similarity, and concept/category similarity. Your code-overlap numbers are useful, but for 4.3(a) I would also include evidence App Review can evaluate quickly: a table of all five affected apps, their Bundle IDs, App IDs, categories, core user flows and monetization; screenshots or a short video showing the document-parser feature immediately visible in Real Cost, not hidden behind purchase or onboarding; a comparison against the closest loan/debt apps, focused on user outcome rather than implementation; the exact build numbers and metadata versions that were rejected; a statement that there are no shared templates, contractors, SDKs, backends, assets or metadata patterns beyond ordinary SwiftUI scaffolding. In Resolution Center or a formal appeal, I would ask Apple to identify which of the three areas is driving the rejection: binary, metadata, or concept. If they believe the apps are similar to your own submissions, ask whether the concern is portfolio-level duplication rather than this specific app’s implementation. I would avoid another resubmission until that evidence package is ready. Repeated binary changes without knowing which similarity signal Apple is using can make the review history harder to reason about.

Since your App Review Board appeal is already pending, I would not submit another build yet. Guideline 4.3(a) specifically concerns multiple Bundle IDs for the same app. Because this is an update to the same live Bundle ID, ask the Board to clarify whether the match involves another app record, an embedded component, your developer-account history, or an unrelated binary. Provide a compact comparison between the approved 1.8.9 archive and rejected 1.8.10: the Git diff and release notes, every Bundle ID in the app and its extensions, embedded frameworks and SDK versions, signing team, entitlements and dependency lockfiles, confirmation that no other app under the account shares the product, assets or code. Then ask Apple to compare 1.8.10 directly with the approved 1.8.9 build and identify the additional Bundle ID or associated app that triggered 4.3(a). Previous approvals do not guarantee approval of an update, but if the only product change is the feedback field and the bundle/dependency inventory is unchanged, that is much stronger evidence than another general explanation or speculative code change.

Since the App Review Board appeal is already pending, I would stop resubmitting new builds for now. Another speculative change may create a new review cycle without clarifying what Apple is actually detecting. Prepare a review-state inventory for the exact appealed build: every remote configuration value, feature flag, server response, account role, usage limit, update check, region-dependent branch, deep link and relationship to the old app record. Attach a clean-install recording using the review credentials, together with timestamped server logs showing what the app received during that flow. In the appeal, separate verified facts from assumptions. State that the two identified behaviors were removed, document how you verified their absence, and ask Apple to identify the exact screen or runtime behavior at issue—or confirm whether the concern relates to the app binary, developer account or previous App Store Connect record. The previous record and rapid resubmissions may be relevant, but there is no way to establish that from the generic rejection alone. The strongest next step is one complete, reproducible evidence package rather than another binary change.

Because Apple explicitly lists dating apps as an established category under 4.3(b), the key question is probably not whether your BaZi engine is original, but whether the submitted app delivers a visibly different user experience from the first few minutes of use. I would stop resubmitting the same build. Prepare a short comparison showing how Kindred differs from the closest dating apps in onboarding, profile creation, match generation, compatibility explanations, synastry analysis and the actions available after a match. Support each difference with annotated screenshots or a brief video from the exact submitted build. Make sure the BaZi experience is central and immediately visible, rather than appearing as an additional scoring layer behind a conventional dating flow. In Resolution Center, ask Apple to clarify whether the concern is category saturation under 4.3(b) or a binary/metadata association under 4.3(a), because those require different remedies. Since the appeal was already upheld, Android downloads and development effort are unlikely to change the outcome by themselves. The next submission should demonstrate meaningful product and UX differentiation, not simply provide another general explanation of why the matching algorithm is unique.

I would not submit another speculative build. Your strongest case is to separate the shared open-source component from the product you actually created. Prepare one compact evidence package containing: The exact submitted build and Git commit. The dependency lockfile, version, license and hash of the shared proxy core. A binary/module map distinguishing that core from your own app code. A comparison of your UI, configuration model, supported protocols, workflows and business model against the closest alternatives. A clear ownership and account-history statement. In Resolution Center, ask whether the concern is the binary, metadata or overall concept. Then submit one focused App Review Board appeal addressing that specific distinction. Explain that identical compiled sections are expected when unrelated apps statically link the same open-source library, while the surrounding implementation and user experience are independently developed. Don’t publish your full repository. Offer relevant source excerpts, dependency evidence and a secure live demonstration instead.

Don’t cancel or create another submission unless App Review explicitly requires a new binary. That would restart the queue and make the history harder to follow. Prepare one consolidated timeline containing every submission ID, reviewer question, your exact answer, the date and the resulting status. Add it to the existing App Store Connect conversation and ask App Review to identify the single unresolved requirement, if any. Reverify the demo account, backend availability, region-dependent behavior and any feature flags, then state that these were tested against the submitted build. If no requirement remains open, keep the current submission active and update the existing support case with that timeline and the submission ID rather than opening more cases.

First check the submission’s exact status. If App Review only requested pricing confirmation and did not reject the current build or request a change, do not withdraw it or upload another binary. Send one concise follow-up confirming the exact price, currency/price tier and territories, and state that the submitted metadata is final. If the status is still “Rejected,” however, replying alone may not return it to the queue—you must use the available resubmit/update-review action with the current build. If there is no unresolved action in App Store Connect and nothing changes after several business days, open an App Review status case and include the submission ID, the time of the reviewer’s question and your reply. Withdrawing now would restart the process.

Don’t resubmit the same build with only a general explanation. First determine whether Apple’s concern is the binary, metadata, account history, or the product concept itself. Audit the exact submitted IPA and store listing for shared frameworks, templates, assets, naming patterns, screenshots, keywords, bundle history and backend behavior. Include apps previously submitted by your account and anything produced by the same contractor. Then prepare a short differentiation matrix comparing your game’s core mechanics, progression, interface, original assets, content ownership and target audience with the titles Apple may be associating it with. Attach annotated screenshots and a brief video showing those differences in the submitted build. Ask App Review to identify whether the similarity concerns the binary, metadata or concept. An App Review Appointment can help if you bring this evidence and specific questions, but it will not replace visible differentiation. Appeal if your evidence demonstrates mistaken identity or ownership. If the core experience is genuinely too similar, make meaningful product and metadata changes before resubmitting instead of repeatedly uploading minor variations.

One important detail: Apple changed the IAP submission workflow on July 15, so the missing “In-App Purchases and Subscriptions” section on the app version page may no longer indicate a stuck IAP. Try opening Monetization → In-App Purchases, selecting the IAP, and clicking Add for Review. Add it to the existing draft submission that contains the rejected app version. Then check App Review → Draft Submissions and confirm that both the app version and the IAP are listed before submitting. Apple’s current instructions describe this workflow here: https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase/ If Add for Review is unavailable, the IAP cannot be added to the draft, or the app version cannot be selected, then your conclusion is likely correct: the submission state is stuck server-side. In that case, keep the support ticket open and send screenshots, the app version ID, IAP product ID, and draft submission ID, asking Apple to reset or unlock the submission state. I would not upload another binary solely for this issue.

arm64 itself is expected here—Apple’s documentation says it should be included for 64-bit apps and embedded bundles. I would not keep trying to remove or override it. The next step is to inspect the exported IPA from the exact submitted archive, not only the main app’s plist. Check UIRequiredDeviceCapabilities, UIDeviceFamily, MinimumOSVersion and supported architectures in every embedded extension and framework. A conflicting value in any nested bundle can produce an installation failure that App Review reports against the app generally. Also test that exact build through TestFlight on a physical compatible iPad after deleting any previous installation; a simulator install does not fully reproduce App Store installation validation. If every bundle contains only compatible values, reply without another speculative binary change. Attach the plist output for all bundles, identify the submitted build number and request the exact bundle identifier and installation error that failed on Apple’s device. Since arm64 is valid for the stated review device, the rejection may be using a generic template for a different packaging or installation problem.

This sounds primarily like an ownership and metadata-verification issue, so changing the binary is unlikely to help. Provide App Review with a compact evidence package: the Google Play listing, matching developer/company identity, package ownership, original publication date, source repository history and any trademark or business documentation. Explicitly state whether “Pet Shop Owner Simulator 3D” is your own title, a previous title, or wording that only appears in metadata. Then audit every metadata field, screenshot and icon for the exact disputed phrase. Remove unnecessary references to the Android title, but do not rename the product blindly until Apple identifies the conflicting third-party app. Ask them for the App Store URL or developer name they believe you are copying. If the ownership evidence is ignored again, file a single appeal focused on mistaken identity under 4.1(a). Disclosure: I’m affiliated with Resubmit AI; https://getresubmit.com can help turn the rejection and ownership evidence into a structured reviewer response.