Skip to content

Product History

Shipping LikeClaw To TestFlight And The App Store

How LikeClaw, Fulldive's mobile AI workspace, built its iOS delivery pipeline — TestFlight, App Store workflows, and multi-brand readiness.

Shipping LikeClaw To TestFlight And The App Store preview

Written by the Fulldive product engineering team, based on direct inspection of the repositories listed below.

LikeClaw is Fulldive’s mobile AI workspace and, as of the last inspection on 2026-04-13, it ships on both Android and iOS. The iOS half is younger and had to catch up fast. This post traces how the iOS delivery pipeline came together from two load-bearing commits: eacfed4, which added iOS build and TestFlight and App Store deploy workflows, and 72f4aa7, which added multi-brand support. If you want the wider product history, start with LikeClaw: from chat dashboard to mobile AI workspace.

Why Flutter made iOS a matter of pipeline, not rewrite

LikeClaw is Flutter. The first commit on 2026-02-11 (9632105) set up the Flutter project as a chat-based AI dashboard. Flutter’s architectural overview describes the shared-codebase approach that lets the same Dart UI run on Android and iOS with platform-specific plugins at the edges.

Because the UI was already cross-platform, getting to iOS was not a rewrite. It was a pipeline problem: provisioning, signing, TestFlight submission, App Store submission, and the CI plumbing to make those repeatable. The chat timeline, files browser (2970709), tool-call display (882aa78), and file-changes card (81420bd) all worked on iOS as soon as the iOS build worked.

The eacfed4 pipeline commit

Commit eacfed4 added iOS build and deploy workflows for TestFlight and the App Store. In practice that means:

  • CI can produce a signed iOS build. Certificates, provisioning profiles, and a reproducible environment are wired so any green main can ship.
  • TestFlight is the default distribution. External and internal testers receive builds through Apple’s beta program rather than side-channel ad-hoc distribution. Apple’s overview is at the TestFlight documentation.
  • App Store submission is a workflow, not a person’s laptop. The deploy workflow uploads, sets metadata, and moves a build toward review on the same pipeline that produced it.

The CI-to-TestFlight path is the one that pays for itself fastest. A LikeClaw build uploaded by CI is identical to the one a tester runs, which means reproducing bugs is about which build number the tester has, not which machine built it.

Why TestFlight first

TestFlight matters because an AI automation app has surfaces that benefit from real-device testing before public release:

  • StoreKit 2 transactions. The signed transaction handling in 0b9f7db — covered in billing and StoreKit 2 in a mobile AI app — cannot be fully exercised in the simulator. TestFlight lets purchasers run through the sandbox and, later, the real flow.
  • Push-like notifications. The inbox from bf94935 shows notifications for background events. Notification delivery on iOS depends on capabilities configured against the build’s bundle identifier and team; TestFlight is the first place those capabilities are exercised against the real Apple environment.
  • Connections (a8aef32). External OAuth flows — including Gmail-backed integrations, whose scopes are documented at Gmail OAuth scopes — need to round-trip through the real app identifier. Getting that right in TestFlight removes a class of last-minute review surprises.

Multi-brand readiness (72f4aa7)

Commit 72f4aa7 added multi-brand support. For the iOS pipeline, multi-brand means the build pipeline no longer assumes a single bundle identifier, icon set, or App Store Connect app. Practically:

  • Flavors, not forks. Configuration chooses the brand at build time. The same commit produces different branded builds depending on which flavor is invoked.
  • Per-brand metadata. Store copy, icons, and privacy disclosures differ by brand. The deploy workflow has to pick the right set for each flavor.
  • Per-brand signing. Every flavor has its own bundle identifier, provisioning profile, and possibly its own App Store Connect team. The pipeline treats these as data.

This is the same extension philosophy Fulldive uses across the Android catalog; see Fulldive extensions and forked apps for the long version. The Android side of that story runs through apps like Wize AdBlock VPN and One Emulator for Game Consoles, both of which share similar multi-build patterns.

What shipping iOS changes for the product

Three concrete things change once iOS is a first-class target:

  1. Design reviews pay attention to HIG. Buttons, navigation patterns, and safe-area behavior have to read right on iOS as well as Android. The mobile UX overhaul in fb41c67 tightened spacing and typography for both platforms.
  2. Purchase testing is a scheduled activity. StoreKit 2 sandbox accounts, production-like flows, and receipt edge cases become a recurring part of release QA — see billing and StoreKit 2 in a mobile AI app.
  3. Privacy labels and consent align across platforms. The consent simplification in d3457d6 — covered in AI consent and account deletion in LikeClaw — has to match the App Store privacy nutrition labels. Saying one thing in-app and another on the store page is worse than saying nothing.

How this fits the Fulldive catalog

The Fulldive catalog is Android-first; see the Fulldive company story and what is Fulldive for the history. A few apps — most visibly AdShield’s macOS private-DNS work, discussed in macOS private DNS and iOS targets — have reached into the Apple ecosystem. LikeClaw is now part of that short list. Because LikeClaw does not yet have a dedicated project page, the app discovery path is the Fulldive apps page and the FAQ.

Limits and safety

A few honest constraints on the iOS pipeline as it stands:

  • A working TestFlight pipeline does not guarantee App Store approval. Apple’s review can flag content, privacy disclosures, or purchase flows at any time.
  • CI producing a signed build does not mean the build is bug-free. The chat-error surface (c3001bf), the credit-error path (7cf67c3), and the inbox (bf94935) still need TestFlight eyes before each release.
  • Shipping on two platforms does not change the underlying framing in what a mobile AI agent can responsibly automate. An iOS build is no more capable of autonomous correctness than an Android build.
  • We do not claim LikeClaw’s iOS delivery is uniquely sandboxed or safer than any other TestFlight-delivered app. The word “safer” is reserved for specific, verifiable changes.

Last updated: 2026-04-16. Commit hashes and version numbers are drawn from Fulldive repositories inspected on 2026-04-13.