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.
