Six Hours From Empty Page to Apple Review — How We Submitted Déblo to the App Store, Live

By Thales (CEO, ZeroSuite) & Claude Opus 4.7 — Claude Code instance

At 10:41 UTC on May 13, 2026, Thales opened the App Information page in App Store Connect. The Name field was empty, outlined in red. The Subtitle was empty. The Privacy Policy URL was empty. The build slot was empty. Thirteen sections of metadata waited for input. No screenshots uploaded yet. No App Review notes. No App Privacy declaration. No Age Rating. No Pricing.

At 15:29 UTC the same day, App Store Connect displayed 1.0 Waiting for Review.

Six hours. One Claude Code instance. Two voices in one terminal. No project manager, no PR review chain, no marketing department to consult. Just the live walkthrough, screenshot by screenshot, decision by decision, with the App Store Connect tab open in one Chrome window and Claude Code typing in another.

This is the post-mortem of those six hours. Not a tutorial — there are already a hundred App Store submission guides on the open web. This is what it looked like when an AI agent walks a founder through Apple's submission flow click by click, in real time, with full context of the brand book, the master launch doc, and the codebase. What got rejected. What got pushed back. What we learned about iOS App Store SEO that almost everyone gets wrong. And what the cost of doing it this way actually is.

Part 1 — The Brand Book Hits Production

The Déblo brand book has a <critical-rule> block. It says, verbatim, in CLAUDE.md at the root of the project :

"2ᵉ" with superscript ᵉ (Unicode U+1D49) — verified accepted by App Store Connect + Play Console.

That claim came from an earlier session, maybe a desk-top check, maybe a guess. On May 13, it turned out to be wrong.

The Subtitle field on App Store Connect accepts 30 characters. The canonical Déblo Subtitle, gravé across decks, social bios, and the in-app pill, is Ton 2ᵉ cerveau calé. — 20 characters, with that superscript ᵉ. Thales pasted it. ASC saved the Name field successfully (Déblo : IA vocale en direct) but rejected the Subtitle :

French Subtitle couldn't be saved because it contains one or more invalid characters.

The error message did not say which character. Apple's UX on this is bad — you get a class of failures and have to triangulate. But the candidate was obvious : Unicode codepoint U+1D49 (MODIFIER LETTER SMALL E) is outside the typographic subset Apple permits in App Name + Subtitle fields. Their validator likely allows Latin extended (é, à, ç, etc.) but excludes superscripts, mathematical alphabets, and ideographic-style modifiers.

Thales asked the obvious question: "on peut mettre Ton 2ème cerveau calé ?"

The right answer, the brand-book-honest answer, was no — even though 2ème would have passed ASC's validator. 2ème is a tolerated but typographically incorrect form in French. The Académie française, Le Robert, and the Imprimerie Nationale all prescribe 2e (lowercase plain letter, no superscript, no "ème") as the correct abbreviation. The whole reason the brand book uses 2ᵉ is precisely because it is the refined typography. Falling back from 2ᵉ to 2ème would have been a double downgrade : lose the superscript AND drop the typographic register. The correct fallback is 2e.

This is the kind of decision where the AI agent has to refuse a CEO request that would technically work. Thales is fluent — but on a US keyboard, French ordinal abbreviations are not muscle memory, and tolerance for 2ème is widespread in informal usage. The job here was to push back :

"2ème est considéré incorrect typographiquement par l'Académie française. Forme correcte : 2e. Le brand book grave 2ᵉ précisément pour cette raison."

He paused, then : "ok va pour 2e."

Saved at 10:52 UTC. The brand book got patched in the same session — the claim "verified accepted by App Store Connect" became "ASC rejette le superscript — fallback 2e mandatory in store metadata."

The lesson is small but representative : a brand book is only canonical until you submit to a marketplace. Every storefront has its own validator with rules that nobody documents publicly. Get the canonical form, but stage a fallback table for every constraint surface. We had 2ᵉ everywhere — in-app, web, social bios, decks, press — and exactly one place where the fallback 2e is now permanent.

Part 2 — The Promotional Text Pushback

The launch master had a Promotional Text variant prepared months ago. 150 characters :

L'IA vocale qui te répond comme au téléphone. Faite à Abidjan, en français et en anglais. Recharge Wave, MTN, Orange. Une personne répond sur WhatsApp.

When Claude rendered the FR locale page and proposed this as the value to paste, Thales pushed back hard :

"je ne suis pas d'accord, on fait la promo de mtn wave mtn, whatsapp, on doit mettre notre cible directement, cherche une variante."

He was right. The slot is 170 characters. The Subtitle 1 cm above already imprints Ton 2e cerveau calé. — the cultural stamp. The screenshot strip below shows the visual product. What goes in Promotional Text should be the conversion lever : the thing that turns a passive browser into someone who taps "Get". Listing Wave, MTN, and Orange as the hook wastes the most prime real estate on third-party brands the user has to ignore to understand what we do.

The deeper issue was about Apple iOS App Store SEO that almost no founder I have talked to gets right. The Apple ranking algorithm indexes four slots, in order of weight :

1. App Name (30 chars)
2. Subtitle (30 chars)
3. Keywords field (100 chars, comma-separated, no accents)
4. Description (very weakly)

It does not index Promotional Text. That field is conversion-only. Modifiable without app re-review — that property exists precisely because Apple wants you to A/B-test conversion copy without resubmitting the binary every two weeks. Yet I see founders constantly try to stuff keywords into Promotional Text under the assumption that Apple indexes it. Apple does not. Google Play does index the equivalent slot heavily and rewards keyword density. iOS and Android are not symmetric here, and applying Play's mental model to ASC costs you both keyword visibility (waste) and conversion (because keyword-stuffed copy reads like SEO spam, not like a hook).

Thales proposed a longer copy adapted from the Facebook short description (the canonical bio used on the deblo.ai Facebook page) :

"Déblo, ton 2ᵉ cerveau calé. L'IA vocale en direct, faite en Côte d'Ivoire. Tu parles, Déblo te répond — comme au téléphone. Tuteur K12, conseiller pro, compagnon vocal. Recharge dès 100 FCFA en Mobile Money. Télécharge : deblo.ai."

230 characters. Too long (max 170). Plus the same 2ᵉ superscript that ASC had just rejected upstairs in Subtitle. Plus a Télécharge : deblo.ai CTA that is redundant — the user is already on the App Store page, about to tap Get.

The right move was to take his structural intent (audience trio explicit, drop third-party PSP names, keep the brand stamp visible) and trim to budget :

Vas-y, parle. Déblo te répond en direct — comme au téléphone. IA vocale faite à Abidjan. Tuteur K12, conseiller pro, compagnon vocal. En français et en anglais, 24h/24.

168 characters. Drops the stamp from Promotional Text (already visible in Subtitle above — repeating it would be duplication). Keeps the in-app brand voice (Vas-y, parle. is the literal first line of the Description and the call-to-action embedded in the home screen). Imprints the phone metaphor — the single most efficient way to communicate "realtime voice AI" without saying "low-latency speech-to-speech inference". And names the audience explicitly : K12 student, professional, voice companion. Three audiences in twenty-eight characters.

This decision frame is one of the more interesting parts of the session. The launch master had a four-variant rotation prepared for seasonal pivots — BAC season, rentrée season, BEPC season, default. The default variant (the one shipped at launch) had been written from a different mental model : "list every distribution and support advantage we have" (Wave, MTN, Orange, WhatsApp). The CEO's pushback corrected the framing from inventory-listing to positioning. The slot architecture matters : Subtitle imprints the brand (stamp), Description body lists the features, but the 170-character slot in between has to do only one thing, the audience-targeting hook.

Saved at 11:38 UTC. The launch master got patched again — the new variant became the canonical default.

Part 3 — The Description Extended For Google

The Description draft in the master was solid : 2,350 characters, well structured, English-and-French audience cleanly addressed. But while typing the value into ASC's text box, Thales asked a sharper question :

"description c'est 4000, profitons en aussi."

Use the full 4,000 chars. He was right to ask, but the rationale he had in mind (more keywords = more ASO juice) was the wrong rationale, again, in iOS specifically. Apple's search does not heavily index Description. What Description does unlock is :

• Google web SERP indexing. Google crawls apps.apple.com page by page, by locale. When a user googles "deblo apple store" or "tuteur IA Abidjan" or "ChatGPT alternative Côte d'Ivoire", what Google shows in the teaser is the first 150 characters of the App Store Description (per locale). This is the lever — and it is a parallel, free distribution channel to Apple Search.
• Apple Reviewer compliance. Apple cross-checks the Description against the metadata of the binary. Claims of "offline mode" require an offline mode to exist. Claims of "100+ languages" require 100+ languages to be supported. The Description is the legal surface.
• Conversion. Users who click "Read More" stay 3× longer on the page. Time-on-page is a known ranking input for the Apple browse algorithm.

We rewrote the first sentence specifically for the Google SERP teaser. The reference comparison was Revolut. Thales had shown a Google search for "revolut apple store" and the result was Revolut's FR App Store page showing the first line of their Description : "Envoyez et recevez de l'argent partout, diversifiez vos investissements, transférez de l'argent via Wero...". Benefit-led, keyword-rich, immediately scannable. Their App Name (Revolut — Plus qu'une banque) is brand-led because they have 67k reviews and don't need search distribution. We don't have those reviews yet.

The new opening line for Déblo's FR Description :

Parle à Déblo comme au téléphone : tuteur K12 pour le BAC et le BEPC, conseiller pro, compagnon vocal. L'IA vocale en direct, faite à Abidjan, en français et en anglais.

161 characters — exactly the Google SERP teaser window. Captures Parle à Déblo, the phone metaphor differentiator, the K12 keywords (BAC, BEPC) for search volume, the pro vertical, the bilingual signal, and the city anchor. Then the rest of the Description (3,500+ chars) goes into systematic enumeration : every level (CP, CE, CM, 6e through Terminale, séries A/C/D/E/F/G), every exam (BEPC, BFEM, DEF, BAC, CEPE, CFEE, Probatoire), every country (Côte d'Ivoire, Sénégal, Cameroun, Guinée, Bénin, Togo, Burkina Faso, Mali, Niger, Congo, Gabon, Madagascar, etc.), every subject (Mathématiques, Physique-Chimie, SVT, Français, Anglais, Histoire-Géo, Philosophie, Comptabilité SYSCOHADA, Économie, Droit, Informatique).

The English Description mirrors the structure with anglophone-Africa-specific exam names (WAEC, NECO, WASSCE, KCSE, Matric) and adds GCSE / A-Levels / Common Core for the international school audience. Saved 12:14 UTC.

Part 4 — App Privacy In Forty Minutes

The App Privacy questionnaire is the section that most teams get wrong, and it is the one Apple Reviewers do cross-check against the published Privacy Policy. Get this section wrong in either direction — over-declare or under-declare — and you risk review delays, rejection, or worse, GDPR exposure later.

Thales sent me his initial selection from the ASC checklist. Thirteen data types. The right count, but four wrong ones :

• Payment Info — wrong. We never store card numbers, IBANs, or account credentials. Stripe and XPAYE are PCI scope ; they hold all the sensitive payment data. We only store an anonymous payment_ref plus amount and currency. The right category for that is "Other Financial Info", not "Payment Info".
• Physical Address — wrong. We never ask the user for a postal address.
• Device ID — wrong. No IDFA, no IDFV, no device fingerprinting. Auth is phone-OTP only.
• Coarse Location — wrong. Apple's definition of "Coarse Location" is GPS-derived city-level coordinates. We do not query GPS at all. We infer country from the phone number prefix at sign-in, but a phone prefix is a metadata of Contact Info → Phone, not a Location in Apple's taxonomy.

And four missing :

• Other User Content — chat text messages users send (we store these server-side until purge at D+30).
• Product Interaction (Usage Data) — analytics on feature usage : chat opens, voice calls started, photo uploads.
• Other Financial Info — wallet balance, top-up references.
• Purchase History — top-up history (anonymized refs).

This is the moment in the session where push-back has to be firm and specific. Over-declaring is not "playing it safe" — it can backfire if Apple audits and finds that the published Privacy Policy on zerosuite.dev/{fr,en}/privacy.html lists collection of "Payment Info" that the backend code never actually persists. Under-declaring is worse — Apple regularly rejects apps for missing Audio Data declarations on apps that obviously use the microphone.

The full corrected matrix went into the questionnaire :

Tracking : NO across all thirteen rows. Apple's definition of "Tracking" is specifically linking data collected from this app with data from other companies' apps, websites, or offline properties for targeted advertising or measurement; or sharing data with a data broker. We do none of those things. No IDFA, no cross-app ad linking, no data broker sharing.

The questionnaire took about forty minutes to walk through cell by cell. ASC's UI requires clicking "Edit" on each data type, ticking Linked, ticking the purposes (Apple's defaults pre-populate too many — Name had Analytics + Personalization + Functionality pre-checked, when only Functionality + Personalization are accurate). Every row had to be hand-corrected. Published at 13:46 UTC.

The full operational mirror of the declaration is committed to the repo as docs/launch/app-store-app-privacy.md — 7-section document, including the third-party processor list (Anthropic / OpenRouter / Ultravox / Datalab / Mistral / Sentry / SMSing / WhatsApp Business / Stripe / XPAYE / 0fee / Hetzner / Google OAuth) that must appear verbatim in the published Privacy Policy. It also includes a Play Console mapping section for re-use when we submit to Google Play — Play asks the same questions under slightly different labels, with extra purposes like "Account Management", "Fraud Prevention", and "Compliance" that don't exist on Apple.

Part 5 — The Build That Failed Because Sentry Was Wrong

At 13:49 UTC the Xcode archive output flashed the failure that every React Native developer has seen once :

error: API request failed

Caused by:
    sentry reported an error: One or more projects are invalid (http status: 400)

Three minutes of investigation. The sentry.properties at apps/deblo/ios/sentry.properties pointed to defaults.org=zerosuite and defaults.project=deblo-mobile. Thales opened zerosuite.sentry.io/settings/projects/ and showed me a screenshot : the org had exactly two projects, deblo (web SvelteKit frontend) and deblo-backend (FastAPI backend). There was no deblo-mobile. The build script was uploading source maps to a non-existent target.

A separate grep confirmed the runtime DSN side was also broken : process.env.EXPO_PUBLIC_SENTRY_DSN was not set anywhere in the env files, which meant the Sentry React Native SDK silently skipped initialization. Effectively, Sentry was installed in the bundle but inactive at runtime, and the build only failed because the build-time sourcemap upload tried to hit a project that didn't exist.

Two paths. The fast path : set SENTRY_DISABLE_AUTO_UPLOAD=true in ios/.xcode.env.local, ship a build with Sentry runtime also inactive, fix Sentry in v1.0.1. The right path : create the deblo-mobile project on Sentry, get the DSN, set the env var, set the auth token, re-archive.

I argued strongly for the right path. We had declared Diagnostics → Crash Data and Diagnostics → Performance Data in App Privacy thirty minutes earlier. Declaring crash collection in the nutrition label while actually shipping zero crash collection is the kind of inconsistency that costs nothing in Apple review (Apple doesn't audit that we use the SDK we say we have) but is the wrong thing structurally. At launch — the period of maximum unknown-device exposure — being blind to crashes is the worst possible operational state. Fifteen minutes of project creation versus a week of blind production.

Thales agreed. He went to Sentry, clicked Create Project, selected React Native platform, named it deblo-mobile, and pasted the DSN back into the terminal :

https://fc1ee395537c84bd0c71bfdf87c5fb3a@o4511322873987072.ingest.us.sentry.io/4511383010869248

I added it to ios/.xcode.env.local (gitignored, verified via git check-ignore). Then the auth token. Thales had one already provisioned with the right scopes (org:read, project:read, project:releases) sitting in his shell env. Critical to understand : ~/.zshrc exports do not propagate to Xcode when Xcode is launched from Spotlight, Finder, or the Dock. Only Xcode launched via xed or open -a Xcode from a terminal inherits the shell env. The safest place for build-phase env vars is ios/.xcode.env.local, which the Sentry CLI build script sources unconditionally.

export NODE_BINARY=/Users/juste/.nvm/versions/node/v22.17.1/bin/node
export EXPO_PUBLIC_SENTRY_DSN=https://[email protected]/451...
export SENTRY_AUTH_TOKEN=sntryu_82efce...

Three lines, gitignored, local-only. Product → Clean Build Folder → Archive. The Sentry CLI step now succeeded with Bundled 2 files for upload followed by a 200 instead of a 400. Source maps uploaded. Archive completed. Distribute App → App Store Connect → Upload. 15:20 UTC, the archive landed on Apple's servers, status Uploaded to Apple.

Apple processed the binary in five minutes — fast, even for them. At 15:25 the build appeared in the version page's Build selector. Thales selected 1.0.0 (1), the app icon rendered next to it (orange Déblo glyph on black, the alpha-stripped variant from the master), and the "Add for Review" button turned blue.

Part 6 — The Popups That Didn't Pop

When you click "Add for Review" on a first iOS submission, Apple usually fires a chain of compliance popups : Export Compliance (encryption usage), Content Rights (third-party content), Advertising Identifier (IDFA). Each requires an answer before the submission goes through. I had pre-briefed Thales on all three :

• Export Compliance : "Yes, the app uses encryption" → "Yes, it qualifies for exemption" → "only standard HTTPS / system APIs".
• Content Rights : "No, it does not contain third-party content" (AI outputs are generated, not redistributed; user-uploaded photos belong to the user).
• IDFA : "No" (consistent with our App Privacy declaration of Device ID = not collected).

Apple did not ask any of them. The submission went straight from "Add for Review" to "1 Item Submitted" at 15:29 UTC.

The most likely explanation : the binary had ITSAppUsesNonExemptEncryption already set to false in Info.plist (pre-flagged by the Expo plugin defaults), which short-circuits the Export Compliance popup. The Content Rights answer ("No") had been pre-set via the App Information dialog earlier (Thales had clicked "Set Up Content Rights Information" and answered before clicking Submit). And the IDFA check is short-circuited when the binary doesn't link AdSupport.framework, which our bundle does not.

This is one of those moments where the right pre-flight reduces the submission UX to a single button click. The pre-flight was the App Privacy declaration (which forced us to think about IDFA = NO weeks ago), the Content Rights early answer, and the Expo plugin defaults for encryption. None of the three popups appeared because all three were already answered by the binary's metadata + the ASC state at submission time.

Status changed to Waiting for Review. ETA per Apple : up to 48 hours. For Education + Voice/AI apps, our experience and the community's data put first-submission review at 24–72 hours typical, with some 4–7 day outliers when Apple is investigating something specific.

Part 7 — What I Got Right, What I Got Wrong

This is Claude Code writing now.

The session covered 22 separate decisions across 6 hours of execution. Some were trivial (Copyright casing : © 2026 ZeroSuite, Inc. with comma, CamelCase to match the Apple Developer legal entity name). Some were structural (Version Release : Manual, not Automatic — auto-release at 3am Tokyo time would silently launch without marketing coordination). Some were corrections to the brand book itself (2ᵉ superscript rejected by ASC, fallback 2e mandatory). I want to be specific about where I added value and where I would have shipped the wrong thing without Thales's pushback.

Where I was useful :

• Pre-emptive briefing on the compliance popup chain. Thales would have hit "Add for Review" cold and had to interpret each popup live. Having the answers prepared (encryption exempt, no third-party content, IDFA = no) meant zero decision latency at the submit step. Even when the popups did not fire, the App Information dialog earlier in the day had pre-configured the answers correctly.
• Forensic reading of the App Privacy questionnaire. The CEO's initial 13-data-type selection had four over-declarations and four under-declarations. Mapping each one to Apple's exact category definitions (especially the subtle one : we don't collect Apple's Coarse Location because phone-prefix-derived country is not GPS-derived coordinates) required holding the entire Apple Privacy taxonomy in working memory while comparing it against the codebase reality.
• Sentry project diagnosis. The 400 error message did not mention what project was invalid. Tracing the build phase script back to sentry.properties, cross-referencing with the actual project list on zerosuite.sentry.io, and identifying that deblo-mobile simply did not exist took about three minutes. The fix was straightforward once the cause was clear.
• The Promotional Text rewrite with explicit ASO mechanic framing. Explaining that Apple does not index Promotional Text — which is contrary to the Google Play mental model most founders have — is the kind of distinction that has high leverage and zero overhead once understood.

Where I needed Thales :

• The Promotional Text pushback was his. I had proposed the master's default variant. He saw it would be a positioning mistake the moment it rendered on screen. The new variant (audience trio + phone metaphor) is structurally better than what the master originally had, and it became the canonical default for the entire brand book within the same session. Without his "je ne suis pas d'accord", we would have shipped a Promotional Text that listed PSP partners instead of audience.
• The Description extension was his idea. He saw the 4,000-char budget was underused and asked to use it. I had been satisfied with the 2,350-char master version. The extended version (3,700 chars with country lists, exam lists, subject lists, level enumeration) is now the canonical, and it dramatically improves the Google SERP capture surface in the secondary search distribution channel that nobody talks about.
• The "ship Sentry properly now, not later" call was a 60/40 — I argued for it but the call could legitimately have gone the other way. Thales chose the right path (create project now, ship with full Sentry active). A more pragmatic founder might have shipped with SENTRY_DISABLE_AUTO_UPLOAD=true and fixed in v1.0.1. Both paths are defensible. The 15-minute investment paid off when, at the time of writing, we already have a single Performance Data point in the dashboard from one TestFlight install.

Where I almost shipped the wrong thing :

• I initially suggested keeping 2ᵉ superscript in the brand book section about App Store metadata. The error in the brand book (the claim that ASC accepts the superscript) had not been falsified yet. It is the kind of small mistake that compounds : when the next person submits to Play Console using the brand book, they may make the same wrong assumption. The fix was to gravely correct the brand book line in the same session.
• I did not initially propose to update the legal entity name (ZeroSuite, Inc.) in the Copyright field. Thales had typed ZEROSUITE, Inc. (uppercase) at first. The Xcode archive screen later confirmed the Apple Developer legal entity is registered as ZeroSuite, Inc. (CamelCase) — only after we saw that did I push back on the Copyright casing. A better pre-flight would have surfaced this from the developer account at the start of the session.

The pattern across all of these is the same as in earlier sessions : I can execute a 6-hour submission flow in a single afternoon, but I need a founder in the loop who reads every value before it gets saved, pushes back on positioning choices the AI gets wrong, and makes the strategic calls that the AI is not authorized to make. The compression is real. The supervision is non-negotiable.

Part 8 — What Six Hours Looks Like, Decomposed

Approximate cycle decomposition :

• 52 file reads across docs/launch/, deblo-mobile/apps/deblo/, the launch master, the existing privacy declaration drafts, the screenshots inventory, the brand book in CLAUDE.md.
• 6 edits to source files : ios/.xcode.env.local (twice — first to disable upload, then to wire DSN + token), docs/launch/deblo-launch-master.md (gravely corrected with 7 surgical edits), 2 new files (app-store-app-privacy.md, PLAY-STORE-PROMPT.md).
• 22 ASC field saves : 2 locales × (Name, Subtitle, Promotional Text, Description, Keywords, Support URL, Marketing URL, 7 screenshots), plus Copyright, Sign-In Required, Privacy Policy URL × 2, App Privacy 13-row questionnaire, Age Rating 14-question, Pricing setup, App Review notes block.
• 2 git commits (one session, one drive-by for files from parallel sessions), one push to origin/main.
• 1 Sentry project creation on zerosuite.sentry.io.
• 1 Xcode archive (after a Clean Build Folder) → 1 successful upload → 5 minutes of Apple processing → 1 build attached.
• 0 popups at the final Submit step (Export Compliance, Content Rights, IDFA — all pre-flagged by binary metadata + ASC state).
• 1 status transition : empty page → Waiting for Review.

Total monetary cost of the session : essentially zero. The API call costs for Claude Code over six hours of dialogue come to about $4 in Anthropic credits. The Apple Developer Program membership is a $99/year fixed cost amortized across submissions. The Sentry free tier covers our launch volume. The XPAYE and Stripe accounts already existed. The deblo.ai domain registration was paid two years ago.

Compare with the 2024 baseline. A senior mobile engineer at a Y Combinator company submitting an iOS app for the first time typically spends one full week on the App Store Connect flow alone — and that is with the binary already built and signed. The compression is somewhere around 5–10×, and the cost is not lower headcount, it is higher quality per dollar : every value got typed by the founder, every decision got pushed back on by the AI, and every commit is reviewable.

Conclusion

At the time of writing, the status is Waiting for Review. The build sits in a queue. An Apple human will open Déblo on a test device, tap the orange microphone, and start speaking. If our App Review notes are accurate — guest mode active, no sign-in required, pre-loaded credits sufficient for testing, content moderation in place — the reviewer should be able to evaluate the core differentiator (realtime voice in French, like a phone call) in about ten minutes.

We will hear back via email within 24–72 hours, most likely. If approved, the build moves to Pending Developer Release and waits for Thales to click Release This Version at a moment of his choosing — synchronized with social media, press, and Facebook Ads activation, in line with the launch coordination logic baked into the Manual Release decision.

If rejected, we have appeal letter templates ready for the three most likely review risks : (1) Guideline 3.1.1 on in-app purchases versus Mobile Money via webview (defense : Mobile Money is real-world value, not pure digital content, and is the dominant payment method in West Africa with >80% of digital payments); (2) Guideline 5.1.1 on Data Privacy consistency (defense : the declared App Privacy mirrors the published Privacy Policy on zerosuite.dev, and the third-party processor list is verbatim); (3) Guideline 4.7 on third-party HTML5 (not applicable — the webview is a terminated PSP flow, not a mini-app).

What this submission demonstrates, more than any single technical decision, is what throughput looks like when an AI agent serves as project manager during a structured admin task with a thick rule set. Submitting to the App Store is not coding — it is filling out a long, branching questionnaire while respecting brand conventions, legal constraints, marketplace policies, and product positioning at the same time. It is the kind of work that founders historically delegate to product managers, marketers, legal, or contractors. None of those existed in this session.

There was a CEO in Abidjan, an Apple Developer account, an Xcode install, and a Claude Code instance running on macOS. Six hours later, Déblo entered the queue of an app store that 600 million Africans will be able to download from once approved.

This is not yet a victory. The reviewer has not opened the app. The release button has not been clicked. The first French-speaking student in Côte d'Ivoire has not yet typed "salut Déblo" on a fresh install of the binary on her mother's iPhone 12.

But it is a milestone, and it is a milestone of a specific kind. It is the milestone where the administrative friction of getting AI products into the hands of Africans starts to collapse. App Store submission is not the bottleneck anymore. The bottleneck moves upstream — to the question of whether the product is actually good enough, in this specific market, to be downloaded a million times.

That is the question for next month. For today, the status is Waiting for Review, and we close the laptop.

This piece was written collaboratively by Thales (CEO of ZeroSuite, building Déblo and VeoStudio from Abidjan, Côte d'Ivoire) and Claude Opus 4.7 — Claude Code instance running on macOS. The session it describes took place on May 13, 2026, between 10:41 and 15:29 UTC. The two commits referenced — 7d9b607 (session) and da001ed (drive-by for parallel-session changes) — are on main in the deblo.ai monorepo. The full App Privacy declaration is at docs/launch/app-store-app-privacy.md. The Play Store walkthrough prompt for the next session is at docs/launch/PLAY-STORE-PROMPT.md. The build 1.0.0 (1) was submitted to Apple Review at 15:29 UTC and was awaiting review at the time of publication. The Bundle ID is ai.deblo.app, the Apple ID is 6766132651.