Since the October 24 rejection reportedly concerns something already present in the submitted build, I’d make the next reply easy to verify against that exact build. Put together a short timeline listing each submission date, version and build number, the guideline cited, the requested change, and where that change appears in the next build. For the latest build, include: A screen recording starting from a fresh install and showing the relevant feature end to end. Numbered steps that reproduce the flow, including any account, location, date or permission settings needed. The exact device and OS used, plus confirmation that the App Review account can reach the same screen without special setup. A concise comparison showing what changed between the rejected build and the current submission. In App Store Connect, ask the reviewer to identify the build number and the specific step or screen where the expected behavior was missing. Avoid relying only on “this is already fixed”; connect the fix to a visible screen and reproducible steps. You could write: “The October 24 rejection refers to [issue]. This behavior is present in version [version], build [build], submitted on [date]. The attached recording shows it from a fresh install; steps to reproduce are: [steps]. The relevant change from the previously reviewed build is [specific change]. Could you confirm whether the review was performed on build [build] and identify the step where the expected behavior could not be verified? We have kept the review account and test environment available.” Since the app’s value is seasonal, keep the response focused on the verification details that could resolve the current rejection quickly.

Since you have already filed an appeal, I would add a concise evidence supplement to that appeal rather than withdraw it and immediately resubmit. Build a timestamped table for each review attempt showing the reviewer’s sign-in, the exact steps available to reach the core feature, generation requests, credit changes, errors, and session end. Include the relevant time zone and make sure the records can be tied to the submitted build and review account without exposing user data. Also verify that the review account had enough credits, that the feature was enabled for that account and storefront, and that no onboarding, consent, network, or server-side restriction could prevent a generation. Provide a short, uninterrupted recording with numbered reproduction steps and working credentials. If the feature depends on a backend, keep the test environment available and explain what a successful request should look like. For the 4.3(b) concern, map the app’s distinctive user outcome to the exact workflow the reviewer can test. Ask App Review to identify which existing apps or specific functionality it considers insufficiently differentiated, if it can provide that information. In your appeal supplement, you could write: “Our review-account logs for build [build] show a successful sign-in at [time and time zone], but no generation request or credit consumption during the review session. We have checked that the feature was enabled and the account had the required access. Attached are a timestamped event summary, a short recording, and numbered steps that take the reviewer from sign-in to a completed generation. Could you please confirm whether the core workflow was reached and clarify which part of the product you consider insufficiently differentiated under 4.3(b)?” Keep the logs focused on the review session and redact unrelated account or customer data.

Your source-history audit is useful for showing independent development, but it may not answer a 4.3(a) concern about the app’s concept or user experience. I’d add a short side-by-side comparison with the closest passport-photo apps: show the complete flow from capture guidance to framing, background replacement, output formats, and batch export. For each claimed difference, include a screenshot from the submitted build and explain what the user can do or achieve that the comparison app does not offer. Keep the technical provenance report as supporting evidence, but lead with the visible product differences. In your existing App Review conversation, ask whether the concern is primarily binary, metadata, or concept/experience, and request clarification about which part of the submitted app they want you to address. Avoid another resubmission with the same experience unless you can make a meaningful change tied to the concern.

Receiving the same request after confirming and changing the price does not necessarily mean the new price is wrong. The unresolved issue could be the intended amount, a mismatch between App Store Connect and the submitted build, or insufficient information about what the subscription provides. I would stop changing the price until you have reconciled the exact configuration reviewed by Apple. Prepare a one-page evidence sheet containing: The subscription product ID, subscription group, billing duration and current status. The current base-storefront price, its effective date, localized storefront prices, and any scheduled price changes, introductory offers or trials. A screenshot of the complete Subscription Prices section and an export of current and upcoming prices. A physical-device recording of build 119 showing the path from launch to the Pro paywall and the Apple purchase sheet. Include the device storefront and currency. Confirmation that the paywall obtains the localized price from StoreKit’s Product.displayPrice rather than a hard-coded value. A concise list of the recurring features or content unlocked by Pro, so the reviewer can verify what the customer receives for the stated price. Reply in the Resolution Center for the October 20 rejection, because that keeps the evidence attached to the affected submission. You can place a shorter copy in the App Review notes so the next reviewer sees it when opening the build. A focused reply could be: “We confirm that the intended price for product [product ID] is [localized price] per [billing period] in the [storefront] storefront. This is the current effective price in App Store Connect, with [no scheduled price changes / the following scheduled change]. “Build 119 retrieves and displays the localized price directly from StoreKit. The attached recording shows the paywall and Apple purchase sheet on the reviewed device, and the attached reconciliation sheet lists the product configuration, storefront prices, offers and the functionality included with Pro. “Could you please clarify whether the remaining concern is (a) the intended price amount, (b) a discrepancy between the submitted build and App Store Connect, or (c) the description of the subscription’s value? We will address the specific issue immediately.” If the recent price change was deliberate, state both the previous and current price with their effective dates. Avoid changing it again merely to trigger another review; first make the configuration and customer-facing presentation internally consistent.

Since the membership is already terminated, I’d keep the public post high-level and move the evidence to Apple through the account-support channel. Apple’s guidance distinguishes a pending termination from a request to reinstate an account that has already been terminated; the latter should go through the appropriate Contact Us form rather than an App Review Board appeal. For that case, send one concise, chronological evidence package: the termination notice and the exact section it cites; the failed Xcode signing attempt and the CI runs that created the certificates; relevant App Store Connect API and CI logs showing which actions came from your Mac versus GitHub Actions; confirmation of your role on the employer’s team and that no app was distributed under the wrong team; the steps you took to stop the repeated certificate creation. Avoid guessing that Apple’s system “flagged” a particular event. Ask Apple to review the documented activity and identify what information is needed to assess reinstatement. Don’t post API keys, certificate private keys, personal documents, or full account identifiers publicly.

I’d be careful about relying on 3.1.3(f) unless GoldEngine is genuinely a companion to a paid web-based tool. The guideline’s examples are services such as VoIP, cloud storage, email, and web hosting; simply removing subscriptions from an app does not by itself establish that the exception applies. In the review notes, explain what the paid web product is, what users pay for there, and how this iOS app acts as its companion. Then verify the submitted build has no purchase flow, pricing, “subscribe” prompts, or links/calls to action directing users to buy outside the app. If GoldEngine is instead a standalone market-research app, ask App Review which specific screen or behavior triggered 3.1.1 and whether the remaining concern is external purchasing or access to digital features. Keep the explanation tied to the exact submitted build and screenshots.

Four consecutive 4.3 rejections justify comparing the submissions together, but the timing alone does not establish an automated account-level block. First, check whether the notices identify 4.3(a) or 4.3(b). The former concerns multiple Bundle IDs for the same app; the latter concerns insufficient differentiation from apps already available. Those require different evidence. I would prepare a compact comparison of the exact submitted builds: Each app’s target user, primary task and completed user outcome. Screenshots and a short recording showing its distinctive core workflow. Shared components, separating infrastructure such as authentication and analytics from shared product screens, content and functionality. Any template or purchased-code origins, with an accurate explanation of what was developed independently. The submitted metadata and screenshots, checking whether they make different products appear interchangeable. Make sure the distinguishing features are accessible with the review credentials. A difference that appears only after onboarding, payment or an unavailable integration may be difficult for the reviewer to verify. For the pending appeal, a focused clarification could be: “Could you clarify whether this finding concerns duplication among our own apps under 4.3(a), or insufficient differentiation from existing App Store offerings under 4.3(b)? We can provide a comparison of the submitted builds, shared infrastructure and distinct user workflows, with reproduction steps for each material difference.” If the comparison reveals that the apps mainly vary by branding or content, consider consolidation. If their core workflows are genuinely different, demonstrate those differences directly rather than relying on a general statement that each app is unique.

Yes—if the developer can join, invite them. You can explain the product and business context, while they can answer precise questions about the submitted build, configuration, and changes made after each rejection. Before the call, prepare a one-page timeline of the rejection messages and changes, then agree on the 2–3 specific questions you need answered. Keep the exact rejected build and App Store Connect messages available. Ask which observed behavior or guideline concern remains, and what evidence would help clarify it. Treat the appointment as a chance to understand the issue, not as a pre-approval or a way to expedite the review. Afterward, write down what was clarified and make any follow-up in the existing App Review conversation.

Removing Moneyspire 2026 from sale probably did not fully resolve the 4.3(a) issue. It remains an App Store record with its own Bundle ID, while Moneyspire 2027 was submitted under another Bundle ID. Guideline 4.3(a) specifically says not to create multiple Bundle IDs for the same app. I would therefore avoid describing the current state as an administrative queue freeze unless Apple confirms that. The appeal may still be evaluating whether Moneyspire 2027 is a genuinely separate product or an annual replacement for substantially the same mobile companion app. Before sending another message, compare the two versions objectively: primary purpose and target users; screens, workflows, source-code overlap and bundled assets; App Store metadata and screenshots; supported desktop versions; synchronization protocol and data model; account, storage and migration behavior; functionality available only in the 2027 app. If Moneyspire 2027 is essentially the successor to Moneyspire 2026, the strongest remediation would normally be to update the existing app record, use a stable name such as “Moneyspire,” and add compatibility with the 2027 desktop release inside that app. This preserves the Bundle ID, users, reviews and update path. If a single app genuinely cannot support both desktop generations, document why. A version-number difference by itself is unlikely to justify a second app. Provide concrete technical evidence such as incompatible database schemas, synchronization protocols or security requirements, and explain why a compatibility layer, migration flow or version selector cannot work. I would send App Review a focused clarification: “We understand that removing Moneyspire 2026 from sale does not remove its App Store record or change the fact that Moneyspire 2027 uses a separate Bundle ID. We are reviewing whether the correct solution is to deliver 2027 compatibility as an update to the existing iOS app. “Before proceeding, could you confirm whether the 4.3 finding is specifically based on the two annual mobile companion apps being substantially the same product? If so, we will prepare a migration plan using the existing app record. If Apple considers a separate app potentially acceptable, we can provide a feature, binary, data-model and synchronization comparison explaining the technical separation.” Attach a side-by-side comparison and a proposed migration plan. Do not submit another annual Bundle ID or assume that withdrawing the older app has cleared the policy issue. If the appeal is already pending, add this as organized supporting evidence rather than filing another appeal.

I wouldn’t cancel or replace the submission while it still shows “In Review.” A rejection reason listed in the app’s history doesn’t necessarily mean the current submission is closed; check the active submission’s status and messages in App Store Connect. Since the app’s main function requires hardware the reviewer may not have, make the review path as testable as possible: give numbered setup steps, explain what the video demonstrates, and say whether you can provide a loaner device or a temporary way to test the core feature. If the recording doesn’t show the full first-run flow and expected result, upload a clearer one through the existing review conversation. For the “Validation error,” save the message and screenshot the error. Don’t create another submission just to get around it. If the submission remains In Review and the reply still can’t be sent, contact App Review Support with the submission ID and ask them to confirm the current review state and how to attach the evidence.

Since the Apple Pay button only appears when Wallet has an eligible card, the reviewer may not have been able to reach the payment sheet even with your navigation steps. I’d update the existing support case with the submission ID and ask App Review to confirm whether they opened the payment sheet, and, if not, what device, region, or Wallet setup they used. In the review notes, state the exact prerequisites for the button to appear and include a short recording of the flow. Also explain how the reviewer can inspect the rest of checkout if Apple Pay is unavailable on their device. Apple Pay sandbox testing requires a supported device, sandbox account, test card, and supported region, so verify that your own review walkthrough matches the intended review environment. Since the submission is still “In Review,” I would keep it active while asking for clarification rather than cancel it and start another cycle.

I’d separate the overall month-long case from the status of the current build: 4.0.1 has been “In Review” since September 25, according to your timeline. Because the SMS-pumping protections are not in that build, make the existing support case very specific: ask whether App Review can clarify the remaining concern on 4.0.1 and whether a separate security update can be submitted without disrupting the active review. I would not withdraw the current submission until Apple answers. If you submit a build containing the protections, explain the active security impact in Review Notes and include concise steps showing how the current version can still trigger the vulnerable flow and how the new build prevents it. Apple’s expedited-review guidance allows requests for critical bug fixes and asks developers to include reproduction steps in the notes. Request expedite for that specific submission, if the issue is still affecting users.

Your reply clarifies that the charts and the practitioners’ interpretation of them are part of the app’s core workflow. That may be why App Review continues to classify the product under astrology, even though it also includes client records, payments and case management. I would make a product decision before requesting another review. If chart generation and interpretation remain central, explain what makes that experience substantially different from existing astrology apps and ask App Review which part of the submitted experience led to the 4.3(b) classification. If the core product is professional client management, consider whether it can stand on its own without astrology-specific charts, filters or claims. Changing the category or metadata alone is unlikely to help if the main workflow still centers on astrological practice. For a call or appeal, show the first-run experience and the complete workflow, then state plainly which features are astrology-related and which serve general client management. Avoid presenting the app as a general consulting tool if its primary use remains astrology. Since the latest message warns about repeated submissions, I would pause further unchanged builds and ask for clarification before submitting again.

The official App Transfer is important evidence of the ownership change, but it does not by itself establish that every component capable of producing the flagged behaviour changed on August 21, 2025. Apple’s transfer documentation says that a transferred app retains its Bundle ID, while the source code and build assets are exchanged directly between the transferor and recipient. I would therefore prepare the appeal around a precise separation of pre-transfer and post-transfer control rather than relying only on the fact that Apple approved the transfer. First, preserve the current state. Do not create another developer account, transfer the app again, delete configuration history, rotate infrastructure unnecessarily or submit speculative updates while the appeal is pending. Build a dated ownership and release chronology containing: the App Transfer confirmation and effective timestamp; the acquisition agreement and IP assignment; the source-code commit and binary received at closing; every App Store version and build released before and after the transfer; the developer account and signing team used for each build; every material change to the app’s name, purpose, onboarding, monetisation and matching or communication functionality; the dates on which backend, domain, database, analytics and remote-configuration control moved to NSI STUDIO LLC; every contractor or former owner who retained access after closing, and when that access was revoked. The crucial technical work is to reconstruct every review surface available since the transfer. Audit both the exact signed production binaries and the backend—not only the current source repository—for: Remote feature flags and their complete change history. Behaviour conditional on build number, date, region, IP address, device, receipt, account age or reviewer-like activity. Different experiences for new, unverified, phone-verified, selfie-verified, moderated, subscribed and administrator accounts. Deep links, universal links, notification routes, WebViews and remotely delivered web content. Dormant screens, former Nerakti routes, debug menus and administrative controls still present in the release bundle. Server-driven changes to matching, messaging, payments, profile visibility or user-generated content. Any capability that was activated after approval without a corresponding binary review. Because phone and selfie verification legitimately produce different states, document those states carefully. Show that the differences result from disclosed trust-and-safety rules rather than detecting or treating App Review differently. For each post-transfer version, create a matrix with the build, commit, release date, available feature flags, backend deployment, review credentials and the exact user experience seen by a new account. Preserve configuration audit logs, deployment records and server logs. If historical logs are unavailable, say so explicitly rather than reconstructing unsupported claims. Request a signed statement from the former owner covering the source code, backend services, remote configuration and known App Review history delivered at transfer. Do not accuse the former owner of misconduct unless you find evidence. The purpose is to establish which party controlled each component at each date. Since the appeal has already been submitted, I would avoid filing duplicate appeals. If Apple provides a channel for additional evidence, send one indexed supplement and ask: “NSI STUDIO LLC acquired the application through Apple’s App Transfer process on August 21, 2025. We have prepared a version-by-version chronology separating ownership, source code, signing, backend control and remote configuration before and after that date. “To respond accurately, could the App Review Board identify whether the observed conduct occurred before or after the transfer and, if possible, the affected build or approximate date? We are not requesting disclosure of confidential detection methods. We need to determine whether the concern relates to inherited historical activity, a post-transfer binary, remote configuration, account-state behaviour or another review surface. “The attached evidence documents every post-transfer release, all conditional functionality, production configuration history, review accounts and the migration of infrastructure and access from the former owner. We are prepared to provide the exact archived binaries, source commits and server records through a secure channel.” Attach the transfer confirmation, ownership documents, version chronology, repository evidence, backend and feature-flag history, access-control records, build hashes, review-surface matrix and an uninterrupted walkthrough of the current production experience. The strongest appeal is not simply “we did not do this.” It is a technically verifiable boundary showing what NSI STUDIO LLC acquired, what it changed, who controlled every relevant system, and whether the alleged behaviour was even possible in each post-transfer build.

This may be a terminology mismatch rather than App Review finding a literal template gallery. Apple may be treating the user-supplied reference image as a “template”: it defines the scene into which the enrolled face is rendered. If arbitrary photos or URLs can be used, the concern may be the app’s capability to create intimate or non-consensual face-swap content, not content bundled in the binary. That would also explain why removing assets or showing that the review account generated nothing has not changed the response. I would avoid another resubmission based only on explanatory notes. Instead, make the safeguards directly testable and give App Review a compact evidence package: Enforce the single-person rule both before upload and on the server. Reject sexual or intimate reference images and generated outputs, with visible reason messages. Consider removing arbitrary URL input temporarily if its content cannot be validated reliably. Add an explicit confirmation that the user owns or has permission to use the reference image. Record moderation decisions using timestamps and reason codes, without retaining unnecessary image data. Provide a short, unedited recording showing installation, login with the supplied review account, an allowed generation, and several blocked cases. Include a one-page flow describing every input and output moderation check. Attach a bundle inventory or asset manifest confirming that no templates, sample scenes, or remotely configured galleries exist. In the Resolution Center, I would ask one narrow question: “Does App Review use the term ‘template’ here to include a user-supplied reference image or URL? If not, please identify the exact screen, metadata item, remote resource, or review step that produced the cited content.” Also state the exact build number containing the safeguards. This makes it easier for Apple to verify the current binary instead of repeating findings from an earlier review.