An AI writing keyboard for every iOS app, in native Swift on Firebase.
An AI writing keyboard for iPhone: grammar fixes, rewrites, tone changes and translation inside any text field, in any app. It is native Swift and SwiftUI, not Flutter, because the product lives in a keyboard extension: a separate process that can only see a sliver of the text it is editing. Behind it sits a Firebase backend that keeps the model key off the device and makes a free tier impossible to game.
A custom keyboard is one of the most constrained places to ship software on iOS. It runs as an extension in its own process, outside the app, with no network access until the user grants Full Access, and it never gets to read the document it is typing into. It sees a short window of text either side of the cursor and nothing more. The product has to rewrite a whole message from inside that window, show the user exactly what changed before anything is replaced, and do it through a paid model whose cost has to stay below what a free tier and a subscription bring in.
Read the whole field through a keyhole
iOS hands a keyboard only the text near the cursor. Keyboarda walks the cursor to the top of the field and back down in chunks, collecting as it goes, then writes the result back the same way, so a rewrite covers the full message rather than the last sentence.
Show the edit, not just the answer
A word-level diff lays the rewrite over the original, with every change grouped into a hunk the user can revert on its own before tapping Use Text.
One user across two processes
The app and the keyboard share a Keychain access group and an App Group, so both run as the same Firebase user with the same entitlement, language settings, custom styles and limits.
A backend that holds the key and the quota
Every AI request goes through a callable Cloud Function that checks identity, reserves a quota slot in a Firestore transaction, calls Gemini with a server-held key, and refunds the slot if generation fails.
How it is put together
Keyboard extension
SwiftUI keyboard in its own process: 19 built-in tools plus user-created styles, height modes that grow with the result, and a Full Access prompt only for the tools that need the network
Document proxy service
Cursor-walking reader and writer over UITextDocumentProxy, which only ever exposes a window of text either side of the cursor
Diff engine
Word-level longest-common-subsequence diff, grouped into change hunks the user can revert one at a time
Shared core
One App Group and one Keychain access group, so the app and the extension share a Firebase identity, the entitlement, settings and custom styles
Cloud Functions
A callable generateText in front of Gemini, a RevenueCat webhook that sets premium as an Auth custom claim, and a scheduled cleanup of stale usage records
Quota and entitlements
Daily quota reserved in a Firestore transaction and refunded on failure; free and premium limits read from Remote Config
Data access
Firestore closed to client writes; a signed-in user can read only their own usage documents
The calls worth defending
Nearly everything else I ship is Flutter. A keyboard extension is the exception: it has a tight memory budget, it starts every time the user switches to it, and it has to talk directly to UITextDocumentProxy and the host app's text field. A Flutter engine inside that process would cost memory and start-up time the extension does not have, so the whole product is SwiftUI, with the shared code in one module that both targets compile.
Before release I reviewed my own architecture as if it were someone else's, including cost models from 500 to 200,000 monthly users. It graded security a D. The function trusted a user ID sent by the client, the quota check could be raced, prompts had no size limit, usage records were never cleaned up, and the app's own usage display was blocked by its security rules. Each of those is fixed in the shipping backend. The review mattered because the model bill is the business: a rate limit that can be bypassed is a cost with no ceiling.
Counting a request after the model answers lets six concurrent requests all see a count of four. Keyboarda reserves the slot first, inside a Firestore transaction, and gives it back if generation fails. The limit holds under concurrency, and a timeout never costs the user one of their free requests.
The RevenueCat webhook writes premium status as a Firebase Auth custom claim, so the function reads it from the verified token with no database round trip on the hot path. When the app's local entitlement and the token's claim disagree, in either direction, it forces a token refresh, so a new subscriber is not rate-limited and an expired one does not keep premium limits.
Premium users get a fair-use ceiling far above normal use, because a leaked or scripted account with no ceiling at all is an open tab on the model bill. Both limits live in Remote Config, and the error tells the keyboard which one was hit, so a free user sees an upgrade offer and a subscriber sees a fair-use notice rather than a paywall they have already paid.
What shipped
Rewrite, shown as a diff
Word-level diff over the original message, each change revertible before Use Text
Translate in place
Target language switchable per request from the keyboard itself
Most of my products are Flutter apps. Keyboarda is native Swift and SwiftUI because of where it runs. A custom keyboard on iOS is an app extension: a separate process that the system starts whenever the user switches to it, with a tight memory budget, no network until the user grants Full Access, and no direct access to the document it is editing.
That last constraint is the product's central problem. A writing assistant has to read what the user wrote, and a keyboard is not allowed to.
A keyboard reads the host app's text through UITextDocumentProxy, which returns a short run of text before the cursor and a short run after it. For a one-line message that is enough. For a paragraph with line breaks, it is a keyhole.
So Keyboarda reads the field by moving through it. The proxy service walks the cursor to the top of the document, stepping across the paragraph boundaries where the proxy tends to go blind, then walks back down in chunks of up to two hundred characters, working out from the before-and-after snapshots how far the cursor actually moved and collecting exactly that much. Writing the result back is the same problem in reverse: walk to the end, delete in batches, check for anything that survived, then insert the new text. Every step yields to the run loop so the host app can process the change, because the proxy talks to another process and its state lags behind the calls made against it.
It is the least glamorous code in the app and the reason the app works.
An AI rewrite that silently replaces a message is a rewrite people stop trusting after the first time it changes something they meant.
Keyboarda lays the rewrite over the original as a word-level diff: removed words struck through, new words underlined. The diff is a longest-common-subsequence comparison over tokens that keep their whitespace, so the text reassembles exactly. Adjacent removals and additions are grouped into a single change, and each change can be flipped back to the original on its own before the user taps Use Text. The text that gets inserted is composed from those choices, not taken wholesale from the model.
The diff also knows when not to appear. A translation, a summary or a table is a different text rather than an edited one. A short intent like "ask Sam to move the meeting to Friday" is expanded into a full message, which makes a diff against six words meaningless. And when a rewrite shares no words with the original at all, the diff would be one long strikethrough. In each case the keyboard shows the plain result instead.
The app and the keyboard are two processes with no shared memory. They share state through two deliberate channels: an App Group for settings, custom styles, tool order, email profiles, the synced daily limit and the review-prompt counters, and a shared Keychain access group so Firebase Auth resolves to the same user in both.
That second channel was a fix, not the first design. Originally each process signed in anonymously on its own, and the backend accepted a user ID from the client to reconcile them. Sharing the Keychain made both processes one authenticated user, which let the backend trust only the ID in the verified token. It also halves the anonymous-auth user count, which is the second-largest line on the Firebase bill once the product grows.
Early builds called Gemini directly from the device, which meant the key shipped in the app. The backend exists to move it: a callable Cloud Function in TypeScript holds the key in Secret Manager, and the app never sees it. Prompt construction deliberately stayed on the client, so tuning a style's wording is an app change rather than a function deployment, while the function enforces what matters: who is asking, how much they have used, and how long the prompt is.
Before launch I audited that architecture and costed it at four scales. The model is the dominant cost at every one of them, which made the rate limit the part that had to be right. The shipping function takes the user from the verified token and nowhere else, reserves the day's slot inside a Firestore transaction before calling the model, refunds it if the call fails, rejects oversized prompts before any quota is touched, and reads both limits from Remote Config, cached for an hour so the lookup is not paid on every request. A scheduled function clears usage records older than a week, and the security rules let a user read their own usage and nothing else.
Around it: RevenueCat for the subscription, keyed to the Firebase user so the webhook and the token agree on who is premium; Remote Config synced into the App Group so the keyboard knows the current limit without fetching it; a review prompt that waits until the keyboard has completed enough successful requests; and Firebase Analytics.
Hiring for a senior mobile or full-stack role?
Open to senior, lead and architect roles on Flutter and mobile teams, full-time and remote.