Skip to content

Engineering Guide

Billing And StoreKit 2 In A Mobile AI Automation App

How LikeClaw handles model selection, credit errors, localized billing copy, and StoreKit 2 signed transaction verification on iOS.

Billing And StoreKit 2 In A Mobile AI Automation App preview

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

An AI automation app that runs models on behalf of users is, at some point, also a billing app. Model time costs money, and the platform — Apple in particular — expects in-app purchases to follow its rules. This post walks through how LikeClaw implemented model selection, credit-error handling, localized billing copy, and StoreKit 2 signed transaction verification, using the commit history as the spine. It is an engineering-flavored read; if you want the broader product story, start with LikeClaw: from chat dashboard to mobile AI workspace.

Why billing landed early

A lot of mobile AI apps ship a free beta and bolt on billing later. LikeClaw did not. Commit 7cf67c3, in the same mid-February batch as rich chat and background polling, added model selection, billing, and credit-error handling. Three things landed together:

  • A model selector in the UI, so users can pick which model to run.
  • A billing flow for purchasing credits or subscriptions.
  • Explicit handling for the “you have run out of credits” path, including error surfaces in the chat timeline.

Front-loading billing forces a healthier architecture. If a model call can fail because of credits, the network layer and the chat-error surface (c3001bf) have to cooperate. You cannot fake that with a toast.

Localizing billing copy

Billing copy is where unclear wording creates the most support load. Commit 8a146d7 localized the billing flow. That is not just “translate the buttons.” It is currency formatting, plan names, legal disclosures, and receipt language — all of which vary by locale.

Practical guidance from this work:

  • Treat billing strings as their own catalog, separate from UI strings. They change at a different cadence, often triggered by legal review.
  • Make currency formatting data-driven, not hardcoded. The platform’s locale APIs give you the right answer more often than a hand-rolled format.
  • Test the “out of credits” path in every locale you ship. That is the string users see when they are already frustrated.

The credit-error surface

A credit error is a user-facing event, not only a backend 402. 7cf67c3 added the error surface that appears when a model call fails because of credits. That surface has to:

  • Explain why the call failed, in plain language.
  • Offer a next step (open the store, switch to a cheaper model, or wait).
  • Not block the user from other conversations or skills in the meantime.

The inbox added in bf94935 is the right home for follow-ups. If a background task fails mid-run because of credits, the chat shows the failure and the inbox records it. Background polling (09ee58f) makes sure the user sees the state change without having to refresh manually; 59125d2 adds pull-to-reload for the times they want to force it.

StoreKit 2 signed transactions on iOS

The meatier commit for iOS billing is 0b9f7db: StoreKit 2 signed transaction handling. StoreKit 2 is Apple’s modern in-app purchase API. It returns signed Transaction values that the app can verify locally and forward to a server for revenue accounting. Apple’s full description is in the StoreKit reference.

A few practical notes from integrating it:

  • Verify on the client, trust on the server. StoreKit 2 lets the app verify the signature of a transaction, but the server should do its own verification against Apple’s public keys before crediting anything to a user’s account. Signed does not mean trustworthy until the server independently checks the signature.
  • Handle finish semantics deliberately. A transaction has to be finish()-ed after the server has credited the purchase. Finishing before the server confirms risks losing revenue on a network drop; finishing too late risks Apple re-delivering the transaction next launch.
  • Subscribe to updates, do not poll. StoreKit 2 delivers transaction updates asynchronously. An app that treats purchase as a one-shot UI flow will miss updates that arrive later (renewals, refunds, family-sharing changes).
  • Model selection and billing are coupled. Because 7cf67c3 added model selection alongside billing, the purchase flow has to know which product corresponds to which model tier. Make the product identifier and the model identifier separate fields in your own domain model; mapping between them belongs in one place.

Android billing notes

This post focuses on the iOS pipeline because StoreKit 2 was the specific commit. Android billing follows the same principle — client flow, server-side verification, explicit handling of the credit-exhausted path — but uses Google’s Play Billing Library rather than StoreKit. Fulldive has shipped Google Play in-app purchases across the rest of the catalog, including Wize AdBlock VPN and the paid tier of One Emulator for Game Consoles. The broader ecosystem context is in the Fulldive company story.

Multi-brand readiness

Commit 72f4aa7 added multi-brand support. From a billing perspective, that means the purchase flow has to accommodate more than one brand’s products without forking the code. Practical outcome: configuration, not code, decides which product identifiers and branded copy a given build ships with. This is the same philosophy Fulldive uses across extension apps — see Fulldive extensions and forked apps for the long version.

What this is not

A few things the billing work in LikeClaw does not do, stated plainly:

  • It does not make the agent cheaper to run. It meters and prices model time; it does not reduce the underlying cost of a model call.
  • It does not certify the correctness of model output. A paid model can still be wrong. See what a mobile AI agent can responsibly automate for the oversight framing.
  • It does not replace server-side ledger discipline. Client-side StoreKit 2 verification is a defense-in-depth layer, not the primary source of truth for what a user has paid for.

Limits and safety

Three candid limits for anyone integrating billing into a mobile AI app:

  • Signed transactions prove a transaction is genuine. They do not prove the user understood what they were buying. Keep the purchase screen and the credit-error surface in the user’s language (8a146d7) and avoid dark patterns.
  • The platform owns the refund flow. Do not try to recreate refunds inside the app; rely on Apple’s and Google’s mechanisms and reconcile on the server.
  • Credits are not a promise about outputs. A credit buys a model call, not a correct answer. Every billing copy should be readable alongside the limits framing in what a mobile AI agent can responsibly automate.

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