A pending termination citing both Section 3.2(f) and Guideline 5.6.2 is broader than an ordinary request for an identity document. Apple may be investigating whether the legal entity, account holder, application owner, service operator and information presented to customers are consistent and verifiable. Since you submitted the appeal within the stated deadline, preserve proof of submission: the confirmation screen or email, exact timestamp, Apple ID, Team ID and the complete text of your appeal. Six days without a decision does not necessarily mean that the appeal was not received. I would not submit duplicate appeals or change any account details while the investigation is pending. Instead, contact Developer Support under case 102979575702 and ask them to confirm that the appeal was received and provide a secure channel for your supporting documents. Do not post identity, tax, banking or company records publicly. Prepare one indexed evidence package covering the following: The exact legal name, address and registration number of RAYAAUSTIN LLC. Evidence that the Account Holder is authorized to represent and legally bind the company. Consistency between the company’s D‑U‑N‑S record, IRS records, bank account and App Store Connect information. Consistency between the App Store developer name, support website, privacy policy, domain registration and customer-support email. Ownership of the LightXtreme name, icon, source code, backend and VPN infrastructure. Every employee, contractor or development agency that had access to the source code, certificates or App Store Connect account. Any previous developer account, transferred application, purchased codebase, white-label component, related company or shared technical infrastructure. The identity of the company that actually operates the VPN servers, processes subscriptions and handles user data. For every item, state the name currently shown, the person or company that controls it, the supporting document and any discrepancy you discovered. This provides the same clarity as a table without requiring one. Because this is a VPN application, include a separate section confirming that the account is enrolled as an organization, the app uses NEVPNManager, users receive a clear data-use disclosure before purchasing or using the VPN, and the privacy policy identifies the actual VPN operator and describes all data flows. Also confirm that VPN-derived user data is not sold, used or disclosed to third parties and identify any territorial VPN licences that may be required. Do not state only that all documents match. Compare every field carefully. A trading name instead of the LLC name, an individually owned domain, a different company named in the privacy policy, a contractor-controlled backend or a reused VPN codebase may all be relevant. I would send Apple this focused follow-up: “We submitted our termination appeal on [date and time] regarding Team ID [ID] and Apple ID [ID]. Please confirm that it was received and remains under review. We understand that the cited provisions may concern consistency between our legal entity, Account Holder, application ownership, customer-facing identity and VPN service operations. We have prepared an indexed verification package covering company registration, Account Holder authority, D‑U‑N‑S, tax and banking records, domain and privacy-policy ownership, source-code provenance, contractors, backend and VPN infrastructure, and all potentially related developer accounts. Because these records contain sensitive information, please provide the secure channel through which the team handling the appeal wants them submitted. If possible, please also identify the category of the outstanding concern: legal-entity information, Account Holder authority, application or source-code ownership, related-account association, customer-facing identity, or VPN service operation. This will allow us to address the issue precisely.” If you discover a genuine inconsistency, disclose it directly, explain how it occurred and provide a dated correction plan. If no inconsistency exists, present the documents as a factual rebuttal rather than making a generic promise to improve. Do not create another developer account, transfer the application, replace the Bundle ID or ask another company to resubmit it. Those actions could reinforce the identity or account-association concern.

One detail may be worth addressing in your appeal: the reviewer tested on an iPad, and without a climbing video in Photos the app opens to a screen that can look like a generic camera tool. That may make the app’s specific purpose harder to recognize, though it does not establish why Apple applied 4.3(a). I’d make the review path unmistakable: include a sample climbing video in the review instructions, list the exact steps to import it, show the HealthKit overlay and climber-tracking workflow, and explain what the optional gimbal and Watch companion add. Also confirm that the submitted iPhone build was tested in the iPad environment used for review. Ask App Review to clarify whether the concern is 4.3(a), meaning multiple Bundle IDs for the same app, or 4.3(b), meaning the app is indistinguishable from existing apps. Those are different issues and need different evidence. Since you’ve already filed an appeal, I’d wait for that review and avoid another speculative submission.

A login timeout that only happens during review usually points to a difference in the review environment, not necessarily a random App Review issue. Before uploading another build, test the exact submitted build from a clean install on an external network, using the same production backend and review account. Check that the account is active and not blocked by region, IP, rate limits, MFA, email verification, or an expired session. Also verify the full login flow over IPv6/NAT64 and inspect TLS/ATS and DNS behavior. Correlate server and authentication logs with the review attempt if you have a timestamp. Then send App Review a short numbered login path and ask which step timed out and at what approximate time. That should help distinguish a client networking failure from an account or backend issue.

Six identical rejections and the wording you received suggest that Apple is objecting to the software-only BAC estimate itself, not to the absence of another disclaimer. Guideline 1.4 does not need to list every prohibited measurement individually. Section 1.4.1 allows Apple to reject health measurements when the claimed accuracy or methodology cannot be validated. In your case, App Review has now stated explicitly that a blood-alcohol estimate without associated measurement hardware is not considered appropriate. TestFlight approval is useful evidence that the build was accessible and functional, but I would not treat it as a substantive approval of the product for App Store distribution. I would pause further unchanged submissions and choose between two materially different product paths. Path 1: Keep BAC by using actual measurement hardware If BAC is essential, integrate a supported breathalyser rather than estimating concentration solely from self-reported drinks. The review package should identify: the exact hardware model and manufacturer; how the app receives the measurement; calibration and accuracy information; supported operating conditions and known limitations; any applicable regulatory or laboratory documentation; whether the device is commercially available to every user who can access the BAC feature. The app should distinguish clearly between a device measurement and any historical drink log. Do not infer that a user is safe to drive, and do not calculate a “safe driving time.” Path 2: Convert Abvy into a drink journal If you do not want a hardware dependency, remove every output that represents or implies a physiological measurement. That includes: BAC percentages or ranges; “alcohol in your system” graphs; predicted sobriety times; countdowns to being under a legal limit; impairment or driving-readiness labels; notifications implying that the user is now sober; BAC terminology in the name, subtitle, keywords, screenshots and website. Tracking beverages, alcohol units or standard drinks is materially different from estimating blood concentration, but the interface should not gamify consumption or establish drinking targets. A disclaimer attached to the same BAC calculation is unlikely to change the result because the potentially harmful output remains available. For the pending appeal, I would ask one narrow question: “We understand that App Review considers a software-only BAC estimate inappropriate under Guideline 1.4, regardless of disclaimers. Before preparing another build, could the App Review Board confirm whether compliance requires removing every estimated BAC, physiological alcohol-level and sobriety-time output, or whether Apple would consider such functionality when it is based on readings from documented external measurement hardware?” If the appeal is unsuccessful, do not submit the same calculator with different wording. Prepare a change matrix showing each rejected output, where it was removed from the binary and metadata, and what non-physiological journaling function replaced it. Attach a continuous video of the exact submitted build and updated screenshots. Existing BAC apps are not reliable precedent. They may have hardware integrations, different documentation, older review histories or functionality that Apple has not evaluated under the same circumstances. The strongest next step is therefore a product decision, not a seventh explanation: either provide a real measurement source or stop presenting an estimated physiological BAC value.

The rejection does not necessarily mean that passkey-only authentication is prohibited. It means the reviewer could not obtain complete access, and the request for a username and password may be a generic response. First, reproduce the onboarding flow using the processed TestFlight build on a clean device, a different Apple ID and an external network. Check the production logs and verify: the associated-domain file and relying-party ID are available publicly; passkey registration reaches the production backend; no invitation, email verification, region restriction or pre-existing account is required; a newly created reviewer account immediately receives enough sample data and permissions to test every feature. Update Beta App Review Information with numbered steps beginning at a clean installation. State explicitly that the app has no password authentication and that the reviewer should create a new passkey. Attach a short recording of the exact TestFlight build completing this flow and ask Apple for the failing screen or approximate timestamp so you can match it to your logs. If fresh passkey registration cannot reliably provide a complete review environment, add an explicit, fully disclosed demonstration mode containing representative data. Do not embed a passkey, private key or hidden authentication bypass in the binary. The demo path should be visible to App Review, isolated from real user accounts and documented in the review notes. I would update the instructions and evidence before uploading another build unless your logs identify a client-side or associated-domain defect.

Your evidence is thorough, but it appears to prove a different proposition from the one App Review is asking about. The radio-browser.info licence can authorize use of the directory data and API. It does not necessarily authorize your app to provide access to each broadcaster’s audio stream, station name, logo, metadata or programming. Likewise, these facts demonstrate technical accessibility, not permission: the stream URL is public and unauthenticated; the broadcaster hosts the stream itself; the server returns icy-pub: 1; the station can edit or remove its directory entry; you respond quickly to takedown requests. A publicly reachable stream is not automatically licensed for inclusion in a third-party commercial directory application. The broadcaster is also the exact party from whom Apple may expect authorization. A takedown process mitigates complaints after publication but does not establish permission before distribution. I would therefore separate the evidence into three rights layers: Directory rights — permission to use the radio-browser.info database and API. Service-integration rights — permission to build a third-party application around that directory or discovery service. Content rights — authorization from each broadcaster, network or appropriately authorized aggregator to expose its stream, branding and metadata through your app. Your current exhibits appear strong on the first layer but may not establish the third. Before another submission, I would choose one of these paths: A. Launch with a curated licensed catalog Obtain written authorization from a manageable initial group of stations. Each letter should identify: your legal entity and app name; the station and stream URLs covered; permission to make the stream discoverable and playable in the app; permission to display the station name, logo and metadata; applicable territories and duration; confirmation that the broadcaster controls or has the necessary rights to the stream. B. Use a commercial catalog provider Contract with a provider whose terms expressly allow third-party consumer apps to search and play the covered stations. The agreement should authorize your company and use case, not merely provide API access. C. Remove the catalog and provide a user-configured player Let users enter and manage their own stream URLs without supplying a browsable directory. This materially changes the role of the app, although Apple may still review how third-party content is accessed. For the review package, create a station-level rights matrix with columns for the station, legal operator, stream URL, authorization document, branding permission, territories and expiration date. Do the same separately for podcasts; Podcast Index’s API terms may not by themselves establish rights to every podcast’s audio and artwork. I would also ask App Review a narrower question: “We understand that permission to use directory metadata may be distinct from authorization to make individual audio streams available through the app. Could you confirm whether the outstanding concern is (1) authorization from radio-browser.info and Podcast Index as third-party services under Guideline 5.2.2, (2) authorization from each broadcaster or podcast publisher for the underlying streams under Guideline 5.2.3, or both?” Do not lead the next response with the fact that the streams are publicly accessible. Instead, show a clear chain of authorization from the rights-controlling entity to your developer company. If obtaining station-level or aggregator authorization is not commercially feasible, another unchanged appeal is unlikely to succeed. The realistic product change is either a small licensed catalog or a user-configured player without a supplied third-party directory.

Since the reviewer still could not access the app after you added the demo account, I would treat this as an environment or account-state problem rather than upload another build immediately. Test the exact Beta App Review credentials from a clean installation and a network outside your development environment. Verify that: the account is already activated and does not require email verification, MFA, an invitation, or acceptance of updated terms; it is not restricted by region, IP address, device count, rate limits, or an expired session; all four sections contain persistent sample data and use the same permissions as intended; the production backend used by the submitted build is available without VPN or internal configuration; the guest path and the demo-account path are both described separately in Beta App Review Information. Attach a short recording starting from a clean install, plus timestamped authentication and API logs for a successful login using that exact account. Then ask Apple to provide the failing screen, timestamp, or step so you can correlate it with the server logs. Because this is TestFlight review, I would first update the Beta App Review instructions and evidence and wait for the requested clarification. A new binary is only useful if you identify an actual client-side defect.

The unrelated rejections are worth documenting, but they do not by themselves prove that your account has been flagged. I would make the next appeal easy to audit instead of arguing about the cause. Prepare two separate evidence packages: For the sports games, create a matrix of Bundle IDs, gameplay loops, rules, progression, assets, metadata, monetization, and target audiences. Explain why these need to be separate apps rather than variations inside one app. For each unrelated app, provide a one-page comparison showing whether its binary, dependencies, assets, metadata, backend, contractors, and product purpose overlap with any of the sports titles. Include every submission date, build number, rejection date, and the exact rejection wording. Then ask the App Review Board to identify whether the concern is similarity among your own apps, similarity to third-party apps, shared code or metadata, or a broader portfolio pattern. Since multiple appeals are already pending, I would avoid further speculative resubmissions. Ask for the portfolio chronology to be reviewed together, while still requesting an app-specific finding for each rejection.

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.