When Hiragana Doesn't Match Katakana — Japanese-Aware In-App Search for Rork Apps

When I added a search box to one of the wallpaper apps I run as an indie developer, an early tester gave me a puzzling report: searching for さくら (sakura, written in hiragana) returned nothing — even though the catalog clearly contained wallpapers titled サクラ (the exact same word, written in katakana). To a Japanese reader these are interchangeable spellings of one word. To a string comparison, they are entirely different characters.

Rork will happily wire up a working search feature in minutes if you ask for one. But this class of problem — orthographic variation — will never be solved unless you spell it out as a requirement. Here is where my implementation fell short, how I fixed it, and the exact spec I now paste into Rork.

What the Search Rork Generates by Default Actually Covers

If you tell Rork nothing more than "add a search feature," the generated code usually boils down to this:

const [query, setQuery] = useState("");
 
const results = items.filter((item) =>
  item.title.toLowerCase().includes(query.toLowerCase())
);

Substring matching and case-insensitive English are covered out of the box. For an English-only catalog, this is perfectly serviceable — the AI infers the standard English-language implementation from the word "search," and it gets there fast.

For Japanese data, though, several variants silently slip through:

• さくら vs. サクラ (hiragana vs. katakana)
• ABC vs. ＡＢＣ (half-width vs. full-width alphanumerics)
• ｻｸﾗ vs. サクラ (half-width vs. full-width katakana)
• 夜 景 vs. 夜景 (a stray space inside a word)

In my app, wallpaper titles happened to be in katakana while tags were in hiragana — the inconsistency was baked in the moment humans typed the data. Rather than retroactively cleaning thousands of records, absorbing the variation at search time is the pragmatic move. The same lesson applies beyond Japanese: accented characters, ligatures, and width variants all fail "obvious" searches in exactly this way.

One Normalization Function That Folds Variants Together

The strategy is simple: immediately before comparing, run both the query and the data through the same transformation. That transformation is called normalization. This function is ready to drop in:

// utils/searchNormalize.ts
export function normalizeForSearch(input: string): string {
  return input
    .normalize("NFKC") // full-width → half-width latin, half-width → full-width kana
    .toLowerCase() // fold latin case
    .replace(/[ぁ-ゖ]/g, (ch) =>
      // hiragana → katakana (the blocks are exactly 0x60 apart)
      String.fromCharCode(ch.charCodeAt(0) + 0x60)
    )
    .replace(/[\s　]+/g, ""); // strip half- and full-width whitespace
}

The first line does the heavy lifting. Unicode ships a standard mechanism — NFKC normalization — for collapsing "visually similar but technically different" characters into a canonical form: full-width ＡＢＣ becomes ABC, half-width ｻｸﾗ becomes サクラ. No hand-maintained conversion tables required.

The one thing NFKC will not do is unify hiragana with katakana, so we handle that ourselves. Conveniently, the two scripts sit exactly 0x60 apart in Unicode, which makes the conversion a one-line character-code shift.

Run through this function, all three of these collapse to the same string サクラ:

normalizeForSearch("さくら"); // "サクラ"
normalizeForSearch("ｻｸﾗ"); // "サクラ"
normalizeForSearch("サ クラ"); // "サクラ"

Normalize Once at Load Time, Not on Every Keystroke

With the function in place, calling it on both sides inside filter works — but written naively, you are re-normalizing the entire catalog on every single keystroke.

My catalog held about 1,200 items, and on an older Android test device the input field developed a noticeable lag. The cause was plain: each keypress triggered 1,200 normalization passes. The fix is to normalize the data side once at load time and keep the result as a precomputed search key:

// hooks/useWallpaperSearch.ts
import { useMemo, useState, useDeferredValue } from "react";
import { normalizeForSearch } from "../utils/searchNormalize";
 
type Wallpaper = { id: string; title: string; tags: string[] };
 
export function useWallpaperSearch(items: Wallpaper[]) {
  const [query, setQuery] = useState("");
  // keep the input responsive; let the result list render at lower priority
  const deferredQuery = useDeferredValue(query);
 
  // normalize the data side exactly once
  const indexed = useMemo(
    () =>
      items.map((item) => ({
        item,
        key: normalizeForSearch(item.title + " " + item.tags.join(" ")),
      })),
    [items]
  );
 
  const results = useMemo(() => {
    const q = normalizeForSearch(deferredQuery);
    if (!q) return items;
    return indexed
      .filter((entry) => entry.key.includes(q))
      .map((entry) => entry.item);
  }, [indexed, deferredQuery, items]);
 
  return { query, setQuery, results };
}

useDeferredValue is a standard React 18 hook, so there is nothing to install: it prioritizes the text field's responsiveness and lets the list re-render trail slightly behind. In my experience, precomputed keys plus this hook keep client-side search over a few thousand records feeling smooth — and standing up a search server for a catalog of this size would be over-engineering, in my view.

Don't Let the Zero-Results Screen Become a Dead End

Even with normalization, some queries will return nothing. If the user is left staring at a blank area, they cannot tell an empty result from a broken app. With FlatList's ListEmptyComponent, I make sure two things are always communicated: what happened, and what to do next.

<FlatList
  data={results}
  keyExtractor={(w) => w.id}
  renderItem={({ item }) => <WallpaperCard wallpaper={item} />}
  ListEmptyComponent={
    isLoading ? null : (
      <View style={{ padding: 32, alignItems: "center" }}>
        <Text>No wallpapers matched "{query}"</Text>
        <Pressable onPress={() => setQuery("")}>
          <Text style={{ color: "#6366f1", marginTop: 12 }}>
            Clear search and show everything
          </Text>
        </Pressable>
      </View>
    )
  }
/>

One caveat: ListEmptyComponent also renders while data is still loading, so unless you gate it behind isLoading, users see a "no results" flash at startup. For diagnosing lists that render blank, see FlatList Renders Blank in Rork? A Calm, Ordered Way to Debug Empty Lists; for what to show during loading, see Skeleton Screens in Rork Apps — Practical Patterns for Better Perceived Performance.

The Spec I Paste Into Rork

Everything above can be built in from the start if you hand Rork the requirements explicitly. This is the instruction block I actually use:

Add a search feature with the following requirements:
 
1. Filter by substring match against titles and tags
2. Before comparing, normalize BOTH the query and the data
   with the same rules:
   - Unicode NFKC normalization (full-width latin → half-width,
     half-width katakana → full-width)
   - Fold latin characters to lowercase
   - Convert hiragana to katakana before comparison
   - Ignore half-width and full-width whitespace
3. Normalize the data side once at load time — do not
   re-normalize the whole list on every keystroke
4. When there are zero results, show a button that clears the query
5. Never show the zero-results state while data is loading

The difference between this and a one-line "add search" request shows up immediately in the generated code. Even with a no-code tool, translating your market's language-specific quirks into an explicit spec remains a human job — and frankly, it is one of the places where an indie developer can out-polish bigger apps.

One more thing I routinely patch in Rork-generated search fields is the TextInput configuration. For Japanese input, OS-level auto-capitalization and autocorrect tend to fight the user, so I explicitly set autoCapitalize="none", autoCorrect={false}, and returnKeyType="search" so the keyboard's search key submits the query. Generated code rarely includes these three, and they quietly change how pleasant the field feels to type in.

Since a search field means the keyboard is constantly appearing and disappearing, if your input ends up hidden behind it, Fix Keyboard Hiding Input Fields in Rork Apps: A Complete Troubleshooting Guide walks through the fixes.

Your Next Step: Hunt for One Miss in Your Own App

If your app has a search box, try two probes: query in hiragana for data stored in katakana, and query in full-width latin for data stored in half-width. If either slips through, the ten-line normalizeForSearch above is worth shipping. The cleaner your own data looks, the easier this is to postpone — but you can never clean what users will type. That was the lesson search taught me.

I hope this saves someone wrestling with the same problem a few hours.