---
type: reference
title: "CAMDOM — App Store Review Saga"
description: "Complete chronology of Apple App Store and Google Play review challenges: NFC suppression, privacy policy, Bluetooth purpose strings, entitlements, video requirements, 3-week waits."
tags: [camdom, app-store, apple-review, google-play, nfc, privacy, store-submission, post-mortem]
timestamp: "2026-07-20"
---

# CAMDOM — App Store Review Saga

The story of getting CAMDOM approved on Apple App Store and Google Play is a case study in platform gatekeeping, technical improvisation, and team resilience. From the first submission on August 15, 2024 to the AltStore PAL pivot in December 2024, the team fought through 15+ Apple review cycles, NFC suppression dead-ends, CodePush rejections, stale feedback loops, and a 3-week black hole of silence. Android, by contrast, was approved in days.

This document reconstructs the complete timeline from the team's internal WhatsApp chats.

---

## 1. The Submission Timeline

| Date | Version | Store | Action | Result | Next Step |
|---|---|---|---|---|---|
| Aug 15, 2024 | 2.19 | Apple / Google | First submission for review | Submitted | Wait for feedback |
| Aug 16, 2024 | 2.19 | Apple | Review feedback | **REJECTED** — Guideline 2.5.4 | Remove `external-accessory` from Info.plist |
| Aug 17, 2024 | 2.19 | Apple / Google | Resubmitted after plist fix | Submitted | Wait; Android build breaks, fixed same day |
| Aug 18, 2024 | — | Apple | Review feedback | **CONDITIONAL** — Needs video, account deletion, NFC explanation | Record video, implement delete account |
| Aug 20, 2024 | 2.34 | Apple / Google | Resubmitted with video + screenshots | Submitted | NFC/Apple Pay issue surfaces |
| Aug 21, 2024 | 2.35 | Apple | Resubmitted | Submitted | Still pending NFC decision |
| Aug 22, 2024 | 2.35 | Apple | Review feedback | **CONDITIONAL** — NFC video still needed + Bluetooth purpose string too vague | Fix Bluetooth string, decide on NFC |
| Aug 23, 2024 | 2.38 | Apple / Google | "Final" version submitted | Submitted | NFC removed, Bluetooth string updated |
| Aug 24, 2024 | 2.38 | Apple | Review feedback | **STILL ASKING ABOUT NFC** (stale feedback loop) | Open thread with Apple |
| Aug 26, 2024 | — | Google | Rejection | **REJECTED** — Family policy | Rate app 10+ |
| Aug 26, 2024 | — | Google | Resubmitted with rating fix | **APPROVED** | Android live in production |
| Aug 27–Sep 1 | — | Apple | In review | **SILENCE** (no response) | Wait |
| Sep 2, 2024 | 3.2.0 | Apple | Cancelled previous, submitted new version | Submitted | Cancelled due to 2-week delay |
| Sep 2, 2024 | 3.3.0 | Apple / Google | "Final" version submitted | Submitted | — |
| Sep 3, 2024 | 3.3.0 | Apple | In review | **IN REVIEW** | — |
| Sep 8, 2024 | — | Apple | Push notification entitlement confusion | Still in review | Decision: don't touch, risk too high |
| Sep 13, 2024 | 3.03 | Apple | Review feedback | **REJECTED** — Code downloading + education category | Remove CodePush |
| Sep 13, 2024 | 3.22 | Apple | Build without CodePush + login fix | Submitted | Apple schedules call |
| Sep 13, 2024 | 3.25 | Apple | Removed all CodePush references | Submitted | — |
| Sep 14, 2024 | 3.26 | Apple | Resubmitted to reset review queue | Submitted | — |
| Sep 14, 2024 | 3.27 | Apple | Removed APM + Expo Updates entirely | Submitted | — |
| Sep 14, 2024 | 3.29 | Apple | Final clean build submitted | Submitted | Awaiting appeal response |
| Sep 16, 2024 | 3.30 | Apple | After phone call from Apple | Submitted | — |
| Sep 16, 2024 | 3.30 | Apple | Review feedback | **REJECTED** — Still claims code downloading | Regenerated iOS project, cleaned Expo plists |
| Sep 16, 2024 | 3.31 | Apple | Resubmitted after project regeneration | Submitted | — |
| Sep 20, 2024 | 3.33 | Apple | App description document submitted | In review | — |
| Sep 20–Oct 1 | 3.33 | Apple | Metadata stuck in review limbo | **LIMBO** | Metadata error on screenshots |
| Oct 11, 2024 | — | Apple | Original app **REJECTED** (final) | **REJECTED** | Publish as entirely new app |
| Oct 12, 2024 | New App | Apple | New app submitted to review | Submitted | — |
| Oct 16, 2024 | — | Apple | In review | **IN REVIEW** | — |
| Oct 18–21 | — | Apple | Multiple rejections + calls | Ongoing rejection cycle | Explore AltStore PAL for EU |
| Nov 28–Dec 4 | — | AltStore PAL | Notarization + token setup | Apple notarization **APPROVED** | Configure AltStore source |
| Dec 12, 2024 | — | AltStore PAL | App listed on AltStore PAL source | **LIVE** (EU only) | AltStore PAL installation issues reported |
| Dec 13, 2024 | — | AltStore PAL | Testing | Partially working; AltStore PAL UX rough | Explore direct distribution |

---

## 2. Apple Review — The Never-Ending Story

### Guideline 2.5.4 — External Accessory (Aug 16)

The very first Apple rejection came one day after submission. Apple cited **Guideline 2.5.4 - Performance - Software Requirements**:

> "The app declares support for `external-accessory` in the `UIBackgroundModes` key in your Info.plist file but does not declare any external accessory protocols supported by the app. The external accessory background mode is intended for apps that communicate with hardware accessories through the External Accessory framework."

**What happened:** The Info.plist had `external-accessory` as a background mode. CAMDOM uses BLE (Core Bluetooth), not the External Accessory framework. These are completely different iOS APIs — BLE is peer-to-peer communication; External Accessory is for MFi-certified hardware peripherals. The plist entry was either a default from the React Native template or a misconfiguration.

**Victor's fix:** Removed the `external-accessory` value from `UIBackgroundModes` in Info.plist. The app only needs `bluetooth-central` and `bluetooth-peripheral` background modes.

**Lesson:** Apple's automated review tools flag Info.plist declarations that don't match declared protocols. Even if the app works fine, a mismatched plist entry triggers an automatic rejection.

### NFC / Apple Pay Issue (Aug 18–24)

This issue consumed nearly a week of engineering time and was never truly "solved" — it was abandoned.

**The technical problem:** CAMDOM's core mechanic requires two phones to be in close physical proximity (BLE range). When two iPhones are brought together for pairing, iOS detects the NFC field from the other device and triggers the Apple Pay Contactless Payment popup. This happens at the OS level — no app code invokes it. The result: users trying to pair their phones for consent protection are interrupted by an Apple Pay payment sheet.

**Alefita's research (Aug 18):** Alef discovered the `com.apple.developer.passkit.pass-presentation-suppression` entitlement, which allows an app to suppress Apple Pay popups while the app is active. She asked Victor to add it to the provisioning profile.

**The entitlement discovery:**
- Alef: "sera que vc consegue add esse entitlement na provision profile? `com.apple.developer.passkit.pass-presentation-suppression`"
- Alef: "pra desativar o NFC enquanto o app ta ativo, pq o app tem que ficar perto e isso ta chamando o apple pay"

**Victor's investigation:** When Victor tried to add the entitlement, he discovered it is NOT available to all developers. It requires direct contact with Apple to request access. The entitlement exists in Apple's documentation but is restricted.

- Victor: "Acho que podemos solicitar pra Apple e tals, nao sei quanto tempo demora"
- Alef: "ve se vc consegue add, pq parece que tem que entrar em contato direto com a apple"

**Felipe's escalating concern:**
- Felipe: "Eu so acho estranho por que... Tá tudo rodando em Bluetooth e ai o NFC liga do nada... deve ter alguma config para nao chamar"
- Felipe: "A experiencia é MUITO zuada com ta ligado"

**The decision (Aug 21):** After Victor attempted to request the entitlement from Apple with no response, the team decided to remove NFC entirely.

- Alef: "no caso o nfc na Apple a gente pode tirar e sera que se a gente falar no review que mandou um email pedindo o entitlements pra desativar o nfc eles aceleram?"
- Alef: "So coloquei o nfc pra tentar desativar o Apple Pay, mas n funcionou, vou tirar aqui que é melhor"
- Felipe: "Melhor tirar"
- Alef: "Ss, nem ta servindo pra nada msm"

**The stale feedback loop (Aug 22-24):** Even after NFC was removed from the codebase, Apple continued requesting an NFC demo video. Apple was reviewing against cached feedback from a previous submission — the version that still had NFC. This is a known Apple review phenomenon: feedback from one submission can persist into the next review cycle if the reviewer doesn't update their notes.

- Victor (Aug 22): "Eles ainda reclamaram do problema do NFC"
- Victor (Aug 22): Apple feedback: "Specifically, we need a demo video that shows all the NFC functionality in the app, including the app interacting with NFC tags."
- Victor (Aug 24): "Estou realmente confuso com isso"
- Alef (Aug 24): "A gente tirou nfc e nao tem nada que use, vou revisar se tem alguma lib que eu instalei e esqueci de tirar"

After Alef confirmed zero NFC references remained in the codebase, Victor opened a thread directly with Apple. The issue was eventually resolved when the next review cycle started fresh — but it cost 3+ days.

### Privacy Policy (Aug 21–30)

Apple required a privacy policy that explicitly explained CAMDOM's data practices. The initial submission didn't have a dedicated privacy page.

**The fix:** Victor created `https://www.pay4brain.com/privacy_camdom` — a standalone privacy policy page hosted on the PAY4BRAIN corporate domain. The page explained:
- What data CAMDOM collects (consent metadata, no audio/video)
- Why Bluetooth is needed (device-to-device pairing for consent protection)
- How user data is handled
- Account deletion process

This was published August 30 and referenced in all subsequent Apple review submissions.

### Bluetooth Purpose String (Aug 22)

Apple rejected the Bluetooth usage description as insufficiently specific. Apple's exact feedback (Guideline 5.1.1):

> "One or more purpose strings in the app do not sufficiently explain the use of protected resources."
>
> "Update the Bluetooth purpose string to explain how the app will use the requested information and provide an example of how the data will be used."
>
> Examples of unclear strings: "App would like to access your Contacts", "App needs microphone access"

**The problem:** The original Bluetooth purpose string was generic — something like "App needs Bluetooth." Apple requires each permission request to explain *why* the app needs that capability and *how* it will be used.

**The fix:** Alef updated the `NSBluetoothAlwaysUsageDescription` and `NSBluetoothPeripheralUsageDescription` keys in Info.plist to explicitly explain that CAMDOM uses Bluetooth to establish a peer-to-peer connection between two devices for digital consent protection.

- Alef (Aug 23): "Ajustei a plist falando que é pra se conectar com outros devices usando o Camdom"

### Education Category Confusion (Sep 13)

When Apple finally responded after the 3-week wait, one of their complaints was confusing:

- Felipe: "Mensionaran educacao"
- Victor: "Ele ta chamando app de educacional, mas nao tem nenhum lugar falando disso, nenhum texto"

**What likely happened:** Apple may have miscategorized the app or interpreted the app's description/keywords as educational content. CAMDOM is a consent protection tool — Apple's reviewer may have conflated "consent education" with "educational app," which triggers different review guidelines.

**Victor's appeal (Sep 14):** In the appeal, Victor explicitly stated:

> "The application does not fulfill any educational purposes, it's a marketing entertainment application and should not be placed as educational content."
>
> "The application does not download, compile or execute any code or script, it is not a runtime or development educational tool, nor compiler application."

### CodePush / Expo Updates (Sep 13–16)

This became the most persistent and frustrating rejection reason. Apple accused CAMDOM of "downloading code" — a serious violation of their guidelines.

**The reality:** CAMDOM used Expo's OTA (Over-The-Air) update mechanism via CodePush to push JavaScript bundle updates without going through App Store review. This is explicitly allowed under Apple's guidelines for React Native / Expo apps — it updates the JS bundle, not native code.

**Apple's accusation:**
- Victor: "Eles estao reclamando que o app esta fazendo download de codigo"

**The team's response:**
- Felipe: "E o Codepush, ne? Tem que tirar isso"
- Victor: "Só que tem uma secao da Apple sobre isso. E permitido"

**But Apple was not convinced.** Despite the team's appeals and citations of Apple's own guidelines, the reviewer maintained that the app was downloading executable code. The team tried progressively cleaner builds:

1. **3.21.0**: CodePush removed entirely
2. **3.22.0**: CodePush removed + login crash fixed
3. **3.25.0**: All CodePush references removed from build
4. **3.26.0**: Submitted to reset review queue
5. **3.27.0**: Expo Updates AND APM (Application Performance Monitoring) removed
6. **3.29.0**: Final clean build

**Alefita's APM theory (Sep 14):**
- Alef: "Será que o apm ta dando problema? Pq se parar pra pensar como um apm funciona, ele injeta codigo no nosso codigo pra fazer a inspecao. Eu era maintainer do datadog na epoca do RD e lembro de ter visto no codigo do apm ele baixando um bundle pra injetar no app."

After removing Expo Updates, APM, and all network-calling libraries, Apple *still* rejected the app on Sep 16 claiming code was being downloaded. Alef then regenerated the entire iOS project from scratch:

- Alef: "Re gerei o projeto aqui do lado do iOS e tem uns plist novo relacionado ao expo deixando claro que o expo update ta desativado mesmo sendo parte do framework na ta nem instalado e configurado"

**Apple's phone call (Sep 16):** Apple called Victor directly to discuss the rejection. After the call, Apple moved the app to review status — but rejected it again hours later with the same "downloading code" complaint.

### The 3-Week Wait (Sep 3–13)

The period from September 3 to September 13 was a complete blackout. Apple had the app in review but provided zero feedback.

**Contributing factors:**
- iOS 18 launch was September 16 — Apple's review teams were likely preparing for the event
- Multiple app submissions were in the queue
- The previous version had been in review for 2 weeks before being cancelled

**Team morale during the wait:**
- Felipe (Sep 3): "Oremos" (Let us pray)
- Victor (Sep 3): "A ultima q enviei ficou 2 semanas"
- Felipe (Sep 1): "Acho que nao, pq esta em review. Se mandar de novo, vou ter que cancelar esse envio pra mandar outro"
- Victor (Sep 1): "Apple que ta chato, nao aprovou, mas tbm nao reprova. Ta la em revisao ainda"

**The critical decision (Sep 2):** Victor cancelled the version that had been in review for 2 weeks and submitted the newer 3.2.0. This was risky — cancelling resets the review queue — but the team judged that the original submission was stuck.

- Victor: "Acho que vou cancelar essa da Apple"

### Push Notification Entitlement (Sep 8)

Apple kept requesting push notification entitlement even though CAMDOM does not use push notifications.

- Alef: "acho que talvez a falta do entitlement de push deve ta jogando a gente pra uma fila de baixa prioridade, ajusta pra gente, ja tinha feito antes mas voltou"
- Victor: "Nao tem mais no profile dizendo que usamos push. Nao tenho ideia do pq que ainda esta pedindo."
- Victor: "A Apple ja teria rejeitado igual ela faz quando falta alguma string. Tenho receio de adicionar o entitlement, da submeter e ela reprovar."
- Felipe: "Melhor esperar entao. OREMOS"

**Decision:** The team chose NOT to add the push notification entitlement, fearing it might trigger a new rejection. The app was already in review for 5+ days at this point, and cancelling would reset the clock. They waited it out.

### The Final Rejection and New App (Oct 11)

After weeks of cycles, appeals, and phone calls, the original CAMDOM app was formally rejected. The team made the painful decision to publish as an entirely new app on the App Store.

- Victor (Oct 11): "Vamos publicar um novo app pois esse foi reprovado"

The new app was submitted Oct 12, but Apple continued to delay and reject. By late October, the team began exploring AltStore PAL as an alternative distribution channel for their EU-based client (Billy Boy / Innocean Berlin).

---

## 3. Google Play — Faster but Not Smooth

### Family Policy Rejection (Aug 26)

Google Play rejected CAMDOM's first production submission due to family policy compliance. The app needed a content rating adjustment.

- Victor (Aug 26): "A Google reprovou por uma questao da family policy, estou vendo o que vamos precisar ajustar pra nao deixar o app com rated muito alto"

**The fix:** Victor adjusted the content rating questionnaire responses, resulting in a **10+** rating. This is a quick fix — just re-answering Google's content survey.

- Victor (Aug 26): "Ajustado. Rated ficou 10+. Mas e isso"

**Resolution time:** Same day. Google Play was approved and live in production by August 26.

### Migration from AppCenter to Google Play Internal Test

Originally, CAMDOM used Microsoft AppCenter for internal testing distribution (both iOS and Android). The Android builds were distributed via `https://install.appcenter.ms/users/victor-pay4brain.com.br/apps/camdom-internal-test/`.

**The switch:** When Google Play's Internal Test track became available, Victor migrated Android distribution there. This was cleaner — testers install directly from the Play Store, no sideloading required.

- Victor (Aug 18): "O internal test do Android liberou aqui, acho que nao vamos precisar do app center mais"
- Victor (Aug 20): "Agora ta no internal test playstore"

AppCenter was kept as a fallback for Android and as the primary distribution for iOS TestFlight alternatives.

---

## 4. The NFC Deep Dive

The NFC issue is worth a standalone section because it consumed engineering time across a full week and illustrates a fundamental iOS platform limitation.

### The Problem

CAMDOM requires two phones to be physically close for BLE pairing. On iOS 17.4+, when two iPhones are in proximity, the OS can trigger the Apple Pay Contactless Payment sheet via the device's NFC reader. This is an OS-level behavior — no app code invokes it. The result: users pairing phones for consent protection are interrupted by an Apple Pay popup asking for payment authentication.

Felipe captured the user experience problem clearly: "A experiencia e MUITO zuada com ta ligado."

### Research: PassKit Suppression Entitlement

Alefita researched the problem and found the `com.apple.developer.passkit.pass-presentation-suppression` entitlement. This is Apple's official mechanism for apps to suppress Apple Pay popups while the app is active.

**Technical details:**
- The entitlement is declared in the app's entitlements file (`<key>com.apple.developer.passkit.pass-presentation-suppression</key><true/>`)
- When present, the app can call `PKPassLibrary.suppressAutomaticPassPresentation()` to prevent Apple Pay from triggering
- Requires iOS 17.4+ (which matched the target devices)

**The catch:** This entitlement is NOT available to all Apple Developer Program members. It requires a direct request to Apple. Most developers never need it — it's designed for transit apps, payment terminals, and similar use cases.

### Apple Developer Forum Research

Alefita found relevant discussion on Apple Developer Forums about this entitlement. The 2018-era articles about Apple Pay suppression were the primary reference. The consensus: you must contact Apple directly, explain your use case, and wait for them to grant the entitlement to your developer account.

### Victor's Provisioning Profile Attempts

Victor attempted to add the entitlement to the provisioning profile:

- Alef (Aug 18): "sera que vc consegue add esse entitlement na provision profile?"
- Victor (Aug 18): "Tenho q ver como fazer isso"
- Victor (Aug 18): "Acho que podemos solicitar pra Apple e tals, nao sei quanto tempo demora"

When Victor investigated, the entitlement was not available in the standard provisioning profile options — confirming it requires Apple's explicit grant.

### Felipe's Escalating Pressure

Felipe pushed hard to resolve this because the client was already testing and the Apple Pay popup was breaking the user experience:

- Felipe (Aug 18): "Mas o cliente ta dizendo que com isso nao rola. Que precisamos resolver"
- Felipe (Aug 18): "E realmente. A experiencia e MUITO zuada com ta ligado"
- Felipe (Aug 18): "Mas ainda com a questao do NFC"

### Decision Framework

The team considered two approaches:
1. **Try to suppress:** Request the entitlement from Apple, wait for approval, implement PKPassLibrary suppression
2. **Remove entirely:** Strip NFC from the app, accept that proximity-triggered Apple Pay popups may still occur on some devices

Given that Apple had not responded to the entitlement request and the review timeline was already slipping, the team chose option 2.

- Alef (Aug 21): "Só coloquei o nfc pra tentar desativar o Apple Pay, mas n funcionou, vou tirar aqui que é melhor"
- Victor (Aug 21): "do NFC vamos tirar por hora, eles ainda nao responderam"

### The Stale Review Problem

After NFC was completely removed from the codebase, Apple's review team continued asking for an NFC demonstration video. This was feedback from a previous review cycle that persisted into the current one — Apple reviewers sometimes don't clear old notes when a new build arrives.

- Victor (Aug 22): "Eles ainda reclamaram do problema do NFC. Nao entendi ainda isso"
- Apple feedback (Aug 22): "Specifically, we need a demo video that shows all the NFC functionality in the app, including the app interacting with NFC tags."

This required Victor to open a direct communication thread with Apple to explain that NFC had been removed and that the feedback was stale. Resolution took an additional 2-3 days.

---

## 5. The Video Requirement

### What Apple Wanted

Apple required a step-by-step demonstration video showing the app in use on a physical iOS device. They wanted to understand the BLE pairing flow — something that cannot be reproduced by Apple's reviewers since it requires two physical phones.

**Apple's feedback (Aug 18):** The app needed a video showing how two devices connect and interact.

### The Nubank Reference

Victor pointed to Nubank's App Store listing as the model format — annotated screenshots showing step-by-step functionality:

- Victor: `https://apps.apple.com/br/app/nubank-conta-cartao-e-mais/id814456780?l=en-GB`
- Victor: "Passo a passo desse jeito ai bonitinho"

### Language Debate

There was a brief debate about whether screenshots and video needed to be in English, German, or both:

- Victor: "Tem q ser nas duas linguas ta. Ingles e alemao"
- Felipe: "Faz so em ingles"
- Victor: "Ai temos q tirar o alemao das lojas"
- Felipe: "Faz so em ingles. Pode?"
- Victor: "Bora ver. Se eles reclamarem, fazemos em alemao tbm"

**Decision:** English only. German was removed from store metadata.

### Who Recorded and What Was Shown

Alefita recorded the demonstration videos using two physical iPhones showing the full pairing flow:

- Alef (Aug 15): "tem que ver nos ppt pra enviar um que tenha 2 iPhones se conectando, so consigo gravar aqui iPhone e Android, ideal seria nem citar suporte a Android no review da Apple"
- Alef (Aug 19): Recorded the video with iPhone-to-iPhone BLE connection (noted: "so a iluminacao que ficou meio amarelada pq fim de tarde aqui na sala")
- Alef (Aug 21): Also recorded edge-case scenarios that the client's testers had found

The video showed:
1. Two iPhones opening CAMDOM
2. Onboarding / account creation
3. BLE pairing initiation
4. Successful connection
5. Consent protection flow activation

### Submission Format

Victor submitted the video via App Store Connect's "App Review Information" section, along with annotated screenshots in Nubank-style step-by-step format (1242x2688 and 1242x2208 for iOS; 1290x2796 for Android).

---

## 6. Store Review as a Risk Factor

### Timeline Slippage

The original plan was to have both stores approved by mid-August 2024. Reality:

- **Google Play:** Approved Aug 26 (11 days from first submission)
- **Apple App Store:** Never approved on the original app. After 2+ months of review cycles, the app was formally rejected Oct 11.

### Client Confidence Erosion

The Apple delays directly impacted the client relationship. Felipe bore the brunt of managing expectations:

- Felipe (Sep 18): "Ontem bati boca feio com o cliente... Falei mil vezes que a Apple nao nos da um prazo exato. E que ele teria que aguardar e e isso... Estamos TODOS no mesmo barco."
- Felipe (Sep 19): "Vou falar com o cliente amanha. expliquei que nao temos como dar um prazo, por que a apple nao da prazo para isso. Android ta liberado em prod e e isso."
- Felipe (Sep 19, quoted by Victor): "Nao compartilhem" (regarding internal discussions about the situation)

### Version Accumulation

The review period saw massive version accumulation. The app went from **2.17** (pre-submission) to **3.33.0** during the Apple review period — a jump of over a dozen minor versions. Each version addressed review feedback, fixed bugs found during testing, or removed features Apple objected to.

Key version milestones during review:
- 2.19 → 2.38: First review cycle (NFC, Bluetooth, privacy policy)
- 3.0 → 3.3: "Final" version (but never final)
- 3.21 → 3.29: CodePush removal cycle
- 3.30 → 3.33: Post-appeal builds

### The "Release Dance"

The pattern repeated throughout:
1. Alef builds a version
2. Victor submits to stores
3. Apple provides feedback (days to weeks later)
4. Alef fixes the issue
5. Victor resubmits
6. Return to step 3

This loop ran at least **15 times** for Apple. Google Play required only 2 submissions.

### Felipe's Containment Strategy

Felipe developed a strategy for managing Apple's detailed questions:

- Felipe: "Nao entra muito em detalhes, se tentarem diz que essa parte ta comigo"
- Felipe: "Melhor nao subir ela para Android. Vamos testar so IOS e se estiver ok"
- Felipe (Oct 1): "Apple silicone bla bla bla" (describing the new app's Apple Silicon requirement text)

The philosophy: give Apple the minimum required information. Over-explaining creates more questions.

---

## 7. Lessons Learned

### Apple Review is Unpredictable

- First rejection: 1 day
- Longest silent review period: 10 days (Sep 3–13)
- Total review period for original app: 57 days (Aug 15 – Oct 11)
- Multiple builds submitted in the same day (Sep 13–14 had 5+ submissions)

### NFC on iOS is Uncontrollable Without Special Entitlements

The `com.apple.developer.passkit.pass-presentation-suppression` entitlement is not available to standard developer accounts. Apps that need to suppress Apple Pay popups (transit, venue, proximity-based) must request it directly from Apple. There is no programmatic workaround at the app level.

### Privacy Policy Must Be Explicit About Bluetooth Usage

Apple requires the Bluetooth purpose string to explain not just that the app uses Bluetooth, but *what for* and *how*. "App needs Bluetooth" is automatically rejected. The string must describe the specific use case (e.g., "CAMDOM uses Bluetooth to establish a secure peer-to-peer connection between two devices for digital consent protection").

### Stale Feedback Loops

Apple reviewers can carry forward feedback from previous builds. Even after removing a feature entirely, the team was asked to demo it. The only resolution is direct communication with the review team to flag the stale feedback.

### Push Notification Entitlement Confusion

Apple repeatedly asked for push notification entitlement even though the app doesn't use push notifications. The team chose not to add it (risking a new rejection) rather than modify the provisioning profile mid-review. This was the correct call — adding an unused entitlement could have triggered a new compliance review.

### CodePush / OTA Updates Are Allowed But Provocative

Apple's guidelines permit JavaScript bundle updates via OTA for React Native/Expo apps. However, some reviewers interpret this as "downloading code." The team's experience suggests that removing all OTA mechanisms and APM libraries produces the cleanest review profile.

### The Value of a Dedicated Release Manager

Victor Hugo Costa served as the single point of contact for all store submissions. He managed App Store Connect, Google Play Console, TestFlight, AppCenter, and later AltStore PAL configuration. Having one person own the release process prevented miscommunication and ensured consistent review responses.

---

## 8. The Privacy Page

### Why It Was Needed

Apple requires all apps that collect, use, or share user data to provide a privacy policy URL. CAMDOM uses Bluetooth (which Apple classifies as a protected resource) and collects consent metadata. Apple explicitly demanded a privacy policy explanation during the Aug 22 review.

### What It Contained

The page at `https://www.pay4brain.com/privacy_camdom` included:
- What data CAMDOM collects (consent event metadata — timestamps, device identifiers, consent status)
- What CAMDOM does NOT collect (audio, video, location, contacts, health data)
- Why Bluetooth is required (peer-to-peer device pairing for consent protection)
- How data is stored and transmitted (encrypted, peer-to-peer only)
- Account deletion instructions
- Contact information for privacy inquiries

### How It Was Used in Review

Victor referenced the privacy URL in every subsequent Apple review submission under "App Review Information." The privacy page also satisfied Google Play's data safety requirements.

- Victor (Aug 30): `https://www.pay4brain.com/privacy_camdom` (published and shared with the team)

---

## 9. The AltStore PAL Pivot

After Apple formally rejected the original CAMDOM app (Oct 11) and continued delaying the new app submission, Alefita proposed an alternative: **AltStore PAL**.

### The EU Digital Markets Act Angle

Since Billy Boy (the client) is based in Germany, the EU Digital Markets Act (DMA) requires Apple to allow alternative app marketplaces on iOS. AltStore PAL is one such marketplace, available only in EU countries.

- Alef (Oct 19): "Lembra que eles estao na EU, da obrigatoriamente a Apple tem que dar suporte a instalacao de lojas de terceiros, como a altstore, podemos publicar na altstore e pra uniao europeia a experiencia vai ser um passo a mais so"

### The Process

1. **Oct 28**: Alef configured the Apple Developer account for alternative marketplace distribution
2. **Nov 28**: Felipe shared the AltStore PAL developer FAQ
3. **Dec 3**: Alef requested token from AltStore (`apps@altstore.io`); token received same day
4. **Dec 3**: Apple notarization submitted and approved quickly (24h)
5. **Dec 12**: Alef configured the AltStore PAL source JSON with notarized IPA URLs
6. **Dec 12**: App listed on AltStore PAL source

### Complications

- AltStore PAL requires EU-based Apple Developer accounts
- The app must be notarized by Apple (separate from App Store review — this was fast)
- AltStore PAL installation UX is rough: users must manually add a source URL
- The Reddit community consensus: "AltStore PAL is uma bosta" but there's no better alternative
- AltStore's developer communication is slow — best channel is their Thursday Discord "Office Hours"
- Direct distribution (without AltStore) requires an Apple authentication server and webhook — Alef was exploring this when the saga was documented

### Current Status (as of Dec 13, 2024)

CAMDOM is notarized by Apple and listed on AltStore PAL for EU distribution. The app can be installed by EU users who have AltStore PAL configured. The team was exploring direct distribution as a more user-friendly alternative.

---

## Cross-References

- [[camdom]] — Project overview
- [[camdom-people]] — Team members and roles
- [[camdom-development-timeline]] — Full development timeline
- [[camdom-stack-migrations]] — Technology stack changes
- [[camdom-code-quality]] — Code quality practices