Forem: yramstech

How I Built an Android Keyboard in Kotlin for Two Ghanaian Languages

yramstech — Fri, 24 Apr 2026 11:51:40 +0000

In late 2022 I got tired of watching friends type Ewe and Twi messages with English keyboards, missing all the letters that make those languages what they are. The diacritics — ɛ, ɔ, ŋ, ɖ, ƒ, ʋ, ɣ — were either auto-corrected out of existence or typed with workarounds like "3" for ɛ or ")","or" and "o" for ɔ.

So I gave myself two months to ship an Android Input Method Editor (IME) that would let Ewe and Twi speakers type natively, with every diacritic one tap away.

On February 25, 2023, Ewe Twi Keyboard went live on the Google Play Store. Three years and 10,000+ installs later, it's on v4 with a premium tier and a steady install rate.

Here's what I learned.

The problem — deeper than I thought

Before writing the first line of code, I tried every existing "African language keyboard" on Play Store. The results fell into three buckets:

English keyboards with an emoji-style diacritic panel. Users had to tap twice for every accented character. Nobody would use that for a sentence, let alone a conversation.
Keyboards that treated Ewe and Twi as afterthoughts. The interesting insight here is linguistic: every Twi letter is also an Ewe letter. Ewe's alphabet is a superset. So one well-designed keyboard can serve both languages natively — but most of what I tried bolted the extra letters onto an English layout without thinking about how people actually type mixed-language messages.
Abandoned apps. Beautiful ideas from 2016–2019, no updates since, broken on Android 10+.

The design goal became clear: one keyboard, both languages, no language-switching dance, every diacritic accessible in ≤ 1 extra tap.

The stack

The v4 app today is Kotlin end-to-end, with a clean separation between the keyboard service (which Android treats specially as an IME) and the rest of the app. It wasn't always this way — the 2023 release was Java — but more on that below. Here's the current stack:

Kotlin + InputMethodService — every Android IME extends this system service class. The OS decides when to show/hide the keyboard; I just provide the View.
Jetpack Compose + Material 3 — used for the settings screen, onboarding, and premium-upgrade flow. The actual keyboard layout stayed on the classic Android View system for performance reasons (you cannot afford Compose recomposition latency on every keystroke).
Clean architecture — service/, domain/, data/, ui/. A KeyboardLayoutProvider caches 200+ key objects so I'm not rebuilding them on every keystroke; a WordPredictor handles suggestions; an EmojiProvider serves the emoji panel; a LocaleHelper toggles English, French, and Spanish for the settings UI.
DataStore Preferences — for user settings (theme, sound, vibration, auto-capitalise). Async-first, avoids the pitfalls of SharedPreferences.
Coroutines throughout — for billing checks, update prompts, and anything that could block the IME thread.
Firebase Crashlytics + Analytics — an IME can crash the whole user experience across every app, so telemetry is non-optional.
Google Play Billing (BillingClient) — a premium tier removes ads. A coupon validator lets beta users and early supporters unlock it for free.
Google Play In-App Updates — if a user is on an old version, the app nudges them to update inline.
Google Mobile Ads SDK (AdMob) — banner ads in the settings screen only (never in the keyboard view itself — that would violate Play policy and user trust).
Lottie Compose — animated onboarding illustrations that show users how to enable the keyboard from Android settings.

No backend. No accounts. No text logging. Zero network calls from the keyboard view itself.

A note on 2023 vs 2026: the Java → Kotlin rewrite

The stack above describes the app as it exists today. The honest 2023 version was different: I originally shipped Ewe Twi Keyboard in Java. It worked, it passed Play Store review in 24 hours, and it had everything the first release needed.

In January and February 2026 I migrated the whole codebase to Kotlin, file by file, with Java and Kotlin coexisting in the repo during the transition. The trigger was Jetpack Compose: the new settings screens, onboarding flow, and premium-upgrade UI all wanted Compose — which is Kotlin-only. Rather than bolt Compose onto a Java app with a thin Kotlin surface, I committed to the full migration.

Deliberate ordering: the UI layer migrated first, the IME service last. Compose forced the settings, theme, and premium screens into Kotlin early. The CustomKeyboardService — the thing that actually runs inside every other app while you type — I saved for the end. A bug in an IME doesn't just break your own app; it makes every other app feel broken because users suddenly can't type. I wanted the surrounding data, domain, and UI layers stable and in idiomatic Kotlin before touching the keyboard surface itself.

Android Studio's "Convert Java File to Kotlin" action was a starting point, not an endpoint. Every converted file needed a second pass for idiomatic Kotlin — nullability, extension functions, coroutines where callbacks used to live. But the interop layer Google ships is better than its reputation: the app stayed buildable and shippable throughout the migration, with mixed-language modules compiling cleanly.

The diacritic design

The core interaction pattern: long-press a base letter, a popup appears with every diacritic variant, tap the one you want.

Tap e → you get e
Long-press e → popup shows e, ɛ, and the tone marks ɛ́, ɛ̀, ɛ̃, ɛ̂, ɛ̌
Same pattern for o (→ ɔ and its tonal variants), n (→ ŋ), d (→ ɖ), f (→ ƒ), v (→ ʋ), g (→ ɣ)

A fluent user never leaves the home row. Every diacritic is one long-press away — not a separate layer, not a separate keyboard, not an emoji panel.

Publishing to Play Store — the paperwork, not the code

Keyboards get extra scrutiny from Google. Because IMEs see every keystroke a user types — passwords, credit card numbers, private messages — Play Console requires explicit answers to Data Safety questions about what the app stores, logs, or transmits.

My answers were simple because the architecture was simple: nothing leaves the device. No keystroke logging, no typed-text analytics, no cloud sync of any kind. The review passed in 24 hours.

The manifest still needs the standard IME plumbing — a service declaration with the BIND_INPUT_METHOD permission and the android.view.InputMethod intent filter, plus a method.xml that declares the subtypes Android shows in the system keyboard picker. Standard Android IME boilerplate; nothing exotic.

Things that surprised me

Views beat Compose for the keyboard itself. I tried building the key grid in Compose early on. Recomposition latency on every keystroke was visible even on a Pixel. I fell back to a classic View subclass for the keyboard surface and haven't regretted it. Compose is fantastic — just not inside the hot path.
Localisation is a first-class design constraint, not a feature. Once I accepted every keypress had to be optimal for mixed-language use, design decisions got easier. The "one keyboard, both languages" insight flowed naturally from watching how my friends actually type.
Crashlytics pays for itself in week one. An IME crash doesn't just break your app — it makes every other app feel broken because users can't type. Telemetry caught three OEM-specific bugs I never saw on my own device.
The narrowest-market projects have the most loyal users. Ewe Twi Keyboard will never compete with Gboard. But the users who install it use it every day. Three years after launch, the app has 10,000+ installs on Google Play, is on v4 with a premium tier, and keeps growing — proof that shipping small into a specific community compounds.

Try it

On Google Play (10,000+ installs): https://play.google.com/store/apps/details?id=com.bless.ewetwikeyboard
Tech: Kotlin · InputMethodService · Jetpack Compose · DataStore · Firebase · Google Play Billing

If you're a Kotlin developer wondering what to build for your community — look at the little frictions your friends complain about. The audience is narrower than "everyone," but it's real, and they notice when you ship something that works.

I Built an AI Text Summarizer in One Night with Claude + Next.js

yramstech — Wed, 22 Apr 2026 22:26:59 +0000

It was a Monday. I had the Anthropic API key provisioned, Next.js scaffolded, and one self-imposed deadline: ship a working demo live on the public internet before midnight.

A few hours later, https://ai-summarizer-next.vercel.app/ went live. You paste any block of text, pick a style — concise, bullet points, executive summary, or ELI5 — and Claude Sonnet 4.6 gives you back a clean summary in about a second.

Here's how I did it, what the code looks like, and a few things that surprised me.

The problem

Every day, we skim more words than we read. Articles, meeting notes, policy documents, contract clauses, research papers — the wall of text never stops. Existing summarization tools are either buried inside other products (Notion AI, Gmail) or too generic (just "tl;dr" with no control over tone or length).

I wanted something trivially fast, with a few quality knobs, and completely free for the user.

The stack

Next.js 14 (App Router) — one framework for UI + API in one repo
TypeScript — catches the silly mistakes I always make at 10 PM
Tailwind CSS — styling without leaving the TSX file
Anthropic SDK — Claude Sonnet 4.6 as the brain
Vercel — one git push and the world has access

Total cost: $0. Anthropic gives generous free credits for new accounts, Vercel's hobby tier is free, and everything else is open-source.

The prompt (simpler than you'd think)

The entire "AI" logic is one parameterised system prompt:

You are a summarization expert. Summarize in a ${style} style.
Return ONLY the summary.

That's it. I spent more time tuning the UI than the prompt. Claude is smart enough that you don't need to bludgeon it with instructions — you need to be specific about what you want and quiet about everything else. The line Return ONLY the summary is what keeps the model from prefacing every response with "Here's a summary:".

The API route

app/api/summarize/route.ts:

import Anthropic from '@anthropic-ai/sdk';
import { NextRequest, NextResponse } from 'next/server';

const client = new Anthropic();

export async function POST(req: NextRequest) {
  try {
    const { text, style } = await req.json();
    const msg = await client.messages.create({
      model: 'claude-sonnet-4-6',
      max_tokens: 1024,
      system: `You are a summarization expert. Summarize in a ${style || 'concise'} style. Return ONLY the summary.`,
      messages: [{ role: 'user', content: text }],
    });
    return NextResponse.json({ summary: (msg.content[0] as any).text });
  } catch (err: any) {
    return NextResponse.json({ error: err.message }, { status: 500 });
  }
}

Thirty lines. One Claude call. That's the whole backend.

The UI

app/page.tsx is a textarea, a dropdown, and a button. A feature doesn't have to look complicated to be useful:

'use client';
import { useState } from 'react';

export default function Home() {
  const [text, setText] = useState('');
  const [style, setStyle] = useState('concise');
  const [summary, setSummary] = useState('');
  const [loading, setLoading] = useState(false);

  async function summarize() {
    setLoading(true);
    const r = await fetch('/api/summarize', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ text, style }),
    });
    const d = await r.json();
    setSummary(d.summary || d.error);
    setLoading(false);
  }

  return (
    <main className="max-w-2xl mx-auto p-8">
      <h1 className="text-3xl font-bold mb-2">AI Summarizer</h1>
      <p className="text-gray-600 mb-4">Powered by Claude Sonnet 4.6</p>
      <textarea className="w-full p-3 border rounded-lg mb-3" rows={8}
        value={text} onChange={e => setText(e.target.value)}
        placeholder="Paste text to summarize..." />
      <div className="flex gap-2 mb-4">
        <select className="border rounded-lg p-2" value={style}
          onChange={e => setStyle(e.target.value)}>
          <option value="concise">Concise</option>
          <option value="bullet points">Bullet Points</option>
          <option value="executive summary">Executive Summary</option>
          <option value="ELI5">ELI5</option>
        </select>
        <button onClick={summarize} disabled={loading || !text}
          className="bg-black text-white px-6 py-2 rounded-lg disabled:opacity-50">
          {loading ? 'Summarizing...' : 'Summarize'}
        </button>
      </div>
      {summary && (
        <div className="bg-gray-100 p-4 rounded-lg whitespace-pre-wrap">{summary}</div>
      )}
    </main>
  );
}

Deploying to Vercel

Three shell commands and one web click:

git init && git add . && git commit -m "AI Summarizer on Next.js"
git remote add origin https://github.com/YOUR_USERNAME/ai-summarizer-next.git
git push -u origin main

Then on vercel.com/new:

Import the repo
Add environment variable: ANTHROPIC_API_KEY = your key
Click Deploy

About 60 seconds later the URL is live.

The single most important thing to get right: the environment variable must be set BEFORE you click Deploy. If you forget, the build succeeds but every request hits a 500. Add the env var first.

Things that surprised me

How boring the code got. I expected LLM-powered apps to need careful error handling, streaming, complicated state — but Claude is quick enough on a 1k-token summary that a plain request/response flow feels instant.
How clean the Anthropic SDK is. new Anthropic() just works if the env var is named ANTHROPIC_API_KEY. No config object, no initialisation dance.
How much the UI matters. I spent more time on textarea padding and the button's disabled state than on the API integration. That felt wrong, but users judge trust from design, not from clever prompts.

Try it + see the code

Live demo: https://ai-summarizer-next.vercel.app/
GitHub: [https://github.com/yramstech/ai-summarizer-next/]

If you've been putting off your first Claude API project — it's genuinely a Tuesday-night, one-sitting build. Pick a narrow problem, resist the urge to add features, and hit deploy before midnight.