Awaiting a reply in Resolution Center — Guideline 4.3(a) on an app we built ourselves

Question

Created 3w

Replies 2

Boosts 0

Participants 3

Hello,

I apologise for posting here. I know this forum is not a support channel, and I would not have posted if I had another way to reach App Review.

Apple ID: 6759336435 Submission ID: 59a73f4a-e83b-4fa4-96dc-4c4b6a0ebcc4 Version reviewed: 1.0 (3) In review since: August 10, 2026 Rejection received: August 20, 2026

Our first submission was rejected under Guideline 4.3(a), on the basis that the app shares a similar binary, metadata or concept with apps previously submitted by a terminated Apple Developer Program account.

We have no connection to any terminated developer account. RocketIO is not related to any other app, including the other apps on our own account. It is a separate product that we have been designing and writing for several years, on a different technical foundation: 114,817 lines of Dart across 139 files in Flutter, plus the Swift we wrote for the iOS tunnel host and the Network Extension, 187 tests, and 32 fully translated languages.

We believe the binary match is a false positive. RocketIO statically links a publicly available open-source proxy core, as every app in this category does. That core is the largest part of the compiled binary, so any two apps linking the same open-source library will share a large amount of identical compiled code no matter how different their own source is — exactly as apps linking OpenVPN or WireGuard do. We cannot remove it, because it is the reason the app exists.

RocketIO is also a bring-your-own-configuration client rather than a VPN service. It ships with an empty server list and does nothing until the user supplies a configuration for infrastructure they already own. We operate no servers, sell no subscriptions and carry no traffic. Among the protocols we have implemented are several that very few clients support on any platform, including DNSTT (DNS tunnelling), AnyTLS, ShadowQUIC, Mieru and Juicity, some of them added only recently.

We replied in Resolution Center with all of this in detail, and asked which app or account the similarity was matched against, so that we could respond to the specific finding rather than guess. We are still waiting for a response.

We have deliberately not resubmitted. We did not want to place another submission in the queue while this conversation is open, and we did not want to send back something that could reasonably be read as unchanged.

We have been waiting since August 10, and we will be honest that it has been a difficult wait. We put years of work into this app and we have users who are looking forward to it, and at the moment we cannot tell them anything, because we do not know what specifically we are being asked to change.

Could someone from App Review please reply to us there? We are glad to provide our source repository and its full commit history, to take a call at any time convenient to you in English, and to demonstrate the app live.

Thank you for your time.

Answer 1

VictorSolano OP

3w

The strongest sentence in your post is currently the weakest evidence: "that core is the largest part of the compiled binary". You can turn that from a belief into a number, and a number is much harder to set aside than an explanation.

For a Flutter iOS build the compiled code splits into three pieces you can size independently:

Runner (your Swift, including the tunnel host and the Network Extension)
Flutter.framework, plus your Dart AOT snapshot inside App.framework
the statically linked proxy core

Build with a link map (Other Linker Flags: -map $(TARGET_TEMP_DIR)/link.map), then total the __TEXT,__text bytes per object file and group them by the static archive they came from. size -m -x on each Mach-O in the .app, plus the framework sizes, gets you most of the way there on its own. What you want at the end is one sentence of the form: N% of the executable's code section comes from <core>, M% is Dart snapshot, and the remainder is code we wrote.

If you also pin the vendored core to a specific public commit and say so, the claim stops being "we did not copy anyone" and becomes "the bytes that match are upstream commit <sha> of <public repo>, which every client in this category links identically, and here is the share of the binary they account for". That is a claim a reviewer can check without taking your word for anything, and it is aimed at the actual signal, which is a binary match rather than authorship. Your offer of the repository and commit history proves you wrote your code; it does not address why two binaries look alike, and those are different questions.

Two smaller things. The 187 tests and 32 languages are real work but they are not responsive to a binary-similarity finding, so I would keep the reply narrow. And the empty-server-list, bring-your-own-configuration point is worth stating as an observable fact about the reviewed build — what the app does on first launch with no configuration supplied — rather than as a description of your business model.

Asking which app or account the similarity was matched against is the right question and I would keep it as the only question. I had twelve updates come back under 4.3(a) in one batch two nights ago on the generic body, and I asked essentially the same thing after measuring my own side first: 1030 Swift files across the twelve apps, zero byte-identical pairs. The measurement did not win an argument, but it did stop me from rewriting code that was never the problem, and it made the reply short.

Write-up of that measurement, if any of it transfers: https://thechosenvictor.com/blog/twelve-apps-rejected-guideline-4-3a-spam

Answer 2

GetResubmit OP

2w

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.