← All posts

Published April 6, 2026 · Updated September 7, 2026

Why we built a keyboard, not an app

The case for living at the keyboard level instead of asking users to context-switch for every reply.

By Sebastian Kluger · Founder of KOPY · 9 min read

KOPY logo on light background

When we started building KOPY, the obvious product was an app: paste a message, get a reply, copy it back. We chose a keyboard instead. This is the founding thesis, not a 2024-vs-2026 history lesson and not a chatbot-vs-companion architecture catalog. Those are screenshot rizz vs keyboards and AI texting assistant comparison.

Key takeaways

  • Context switching kills the reply window. Keyboards sit in the field.
  • One extension works in any text field. Integrations do not.
  • Apple's custom keyboard model is hostile (RAM, Full Access, no background). We still took it.

Context switching kills the moment

Messaging is fast. Someone sends you something and there is a window of seconds to minutes where a reply feels natural. Every extra step shrinks that window. Opening a separate app, pasting, waiting, copying, switching back takes at least 30 seconds. By then the conversation moved, your mental state shifted, and the reply feels stale.

A keyboard extension removes those steps. You are already in the app. Copy, globe, generate, text appears in the field. I timed this on my own iPhone until I was bored. The number that mattered was not "model tokens." It was whether I still felt like the person in the thread.

It works everywhere by default

An app-based solution only works in apps that have integrations. A keyboard works in WhatsApp, iMessage, Tinder, Gmail, Slack, Telegram, LinkedIn, Instagram, Discord. Anything with a keyboard. We did not build twelve SDKs. Platforms that will never allow third-party bots still have a text field. That is the whole market.

Pew's 2023 dating survey is a demand map: 30% of U.S. adults have used a dating app. Those apps are infamously closed. If you want to help people reply there, you live at the keyboard or you live in screenshots. We refused screenshots as the default.

The tradeoffs are worth it

Keyboard extensions are limited to around 70MB of RAM. They cannot run background processes. They require Full Access for clipboard and networking. Setup is worse than tapping Get on the App Store. Apple documents this in Custom Keyboards because they consider keyboards sensitive. They are right.

The friction of setup happens once. The benefit happens every reply. That is the same logic as enabling 2FA. Ugly once. Then it disappears.

KPI table: app vs keyboard for the reply job

KPICompanion appKeyboard extension
Steps5-73-4
Host appsWhatever you integratedEvery text field
SetupInstallInstall + Settings + Full Access
RAM / processNormal appHostile, ephemeral
User feelingUsing a toolStill in the chat

What we rejected

A share-sheet action. Still leaves the thread visually. An iMessage app extension. Does not help Hinge. A floating overlay. Apple will not love you. A screenshot OCR pipeline. 2024's trick. We watched people hate it after week two.

Microsoft's 2025 Work Trend Index talks about agents taking execution while humans keep judgment. Cute for enterprise. On a phone, the "agent" that matters is the one that types where your cursor already is. If your agent lives in another app, you are the integration layer. That is unpaid labor.

Field notes from App Group hell

The main app writes tokens into an App Group. The keyboard reads them. If those IDs do not match, you get a beautiful UI that cannot call the API. I have lost weekends to suite names. This is not in the marketing site. It is why the thesis includes "we accepted native pain."

People will fail the globe key. Onboarding has to show it. Tutorial: enable a custom keyboard. Engineering: how the extension works.

Grammarly's 2024 research says gen AI can save on the order of a day a week of productivity for people who use it well, and also that 52% do not know how. A keyboard that generates in place is my answer to the fluency gap: fewer concepts. Copy, tone, go.

Worked counterarguments

"Users will not enable Full Access." Some will not. They were never going to paste chats into a bot either. "Keyboards are creepy." Yes, which is why the prompt should be small and the policy should be readable. "We could ship faster as a webview app." We could ship a demo faster. We would not ship a habit.

I still have a Notes.app graveyard of the companion-app wireframes. They look reasonable. They feel dead in the hand.

Frequently asked questions

Why not both? A container app is required to host the extension. The product is still the keyboard.

Is this just like Gboard? Gboard is a typing system. We are a reply generator that happens to be a keyboard. Roundup: best AI keyboard apps.

Would you choose this again? Yes. Every time someone generates a reply without leaving WhatsApp I remember why.

Founding-thesis extras from the build

The Figma companion that died

It had onboarding, a paste box, a history tab, and a pretty empty state. Testers said 'cool' and did not open it the next day. The keyboard got cursed during setup and then used. Usage is the thesis. Pretty is not.

Share sheet temptation

A share sheet is still leaving the visual thread. Hinge does not want to share a message to KOPY. The field is the only universal API these apps accidentally give us.

iMessage app extension trap

Would have been a demo for iMessage only. Tinder would still be screenshots. We would have built a museum of one host.

OCR pipeline we refused

It worked in good lighting. Group chats, dark mode, and tiny type broke it. People blamed the model. The camera was the liar. Copy is ugly and true.

App Group as a relationship

Main app and keyboard must agree on suite names, keys, and token refresh. That is marriage counseling in UserDefaults. A paste-box app does not have this fight. It also does not live in WhatsApp.

Onboarding is the tax

Globe key education is the price of the thesis. If we skip it, reviews say 'doesn't work.' The tutorial post exists because the thesis has a UI problem Apple will not solve for us.

Why we still ship a container app

Apple requires a host. Settings, auth, paywall, keyboard enablement live there. The product people feel is still the extension. Do not market the container as the magic. That is a companion-app lie.

RAM as a product manager

Every animation I wanted, RAM vetoed. The thesis includes accepting an ugly-fast UI over a beautiful-dead one.

I would still not build a bot inside each app

WhatsApp will not let me. LinkedIn will not let me. The keyboard is the loophole with a privacy disclosure. I can live with that trade.

Counter: power users love ChatGPT

Good. They can keep it for beasts. The thesis is about the median reply, not the 600-word letter.

Counter: Full Access scare

Valid. Document it. Let people leave. The thesis is not 'trust us blindly.' It is 'here is the only layer that can be fast.'

KPI for the thesis

Not downloads. Whether a reply is drafted without the host app backgrounding. If we background, we failed the founding bet.

What I would tell 2024 me about the thesis

Ship the globe-key tutorial in week one. We shipped clever generate and drowned in 'it disappeared' reviews that were Settings. The thesis includes education, not just architecture.

Do not demo on Simulator. Clipboard lies. Full Access lies. I wasted time. Device or it is theater.

Do not promise an on-device model in the first keyboard. RAM will laugh. Server generate plus a small payload is the thesis's engineering twin.

Do not add a history tab in the container app as the product. History is how you become a companion app with a keyboard accessory. We almost did this because it photographs well.

Measure backgrounding. If the host app blurs, we lost. That KPI is the thesis in a number you can feel without fake MAU.

More questions people ask after reading this

Is the App Store listing an app then?

Yes. Apple requires a container. The bet is still that the habit lives in the globe key. If we market the container as the magic, we lied.

Would a share sheet have been faster to ship?

Yes. It would also have been easier to ignore. Speed-to-demo is not speed-to-habit.

What about Android?

Different IME world. This thesis is iOS constraints as a product choice. I am not hand-waving Android in a sentence to look global.

Did screenshot apps prove you wrong?

They proved demand in 2024. They did not prove the right surface. History post covers the shift. Thesis covers why we still picked the painful surface.

Is Full Access a dealbreaker?

For some users, yes. We lose them. The alternative was a pastebox nobody opens. I can live with honest attrition.

What KPI proves the thesis?

Draft without backgrounding the host. If we cannot show that, we should have built the app.

One more founding constraint I will not trade

If the reply does not appear in the same field the user was already looking at, we failed the company idea. History tabs, paste boxes, and screenshot queues can be prettier. They are not the product. I will keep saying this until someone tries to add a social feed to the container app. The feed would photograph well. It would also be an app. We did not start this to build an app.

Apple's custom keyboard documentation is not a vibe. It is the fence. RAM, Full Access, no background circus. We picked the fence because the cursor lives inside it. That is the whole thesis, repeated for anyone who arrived from a keyboard roundup and thought this was SwiftKey versus Gboard. It is not. Those are rows in another table. This is why the row named KOPY is a keyboard at all.

Sources

Source — Apple Developer Documentation, Custom Keyboards, retrieved 2026-09-07.

Source — Pew Research Center, From Looking for Love to Swiping the Field (2023), retrieved 2026-09-07.

Source — Grammarly / Harris Poll, 2024 State of Business Communication, retrieved 2026-09-07.

Source — Microsoft Work Trend Index 2025, The Year the Frontier Firm Is Born, retrieved 2026-09-07.

Related