App Store keywords are 100 bytes, not 100 characters

Apple caps the App Store keyword field at 100 bytes, not 100 characters. If you ship in a language that is not written in ASCII, that sentence should worry you, and for a while it worried me.

A Korean syllable costs three bytes. An English letter costs one. Same budget, a third of the room.

Then I actually counted what fit in each, and the panic went away.

The fields do not use the same units

That is the root of the confusion, and it took me longer than it should have to notice.

Only three of those feed search. Apple indexes the name, the subtitle and the keyword field. The description is not part of ranking, which means the instinct to stuff it with search terms buys nothing and costs readability.

That changes what the description is for. Mine is written for people, and increasingly for the assistants that summarise apps on someone’s behalf. The first sentence is one plain statement of what the app is and what is different about it, written to survive being pulled out of context by something that will quote exactly one line of it.

What 100 bytes bought me

UTF-8the encoding Apple counts the field in gives an English letter one byte and a Korean syllable three. Both my keyword fields, filled to roughly the same fullness:

You can check your own field in one line. App Store Connect will not tell you the byte count, and pasting into a character counter gives you the wrong number entirely:

printf '%s' "wake up,morning,routine,motivation" | wc -c

The middle columns are the scary ones. Less than half the writing room for the same budget.

The right-hand column is the one that matters, and it says both fields hold the same number of search terms.

I budgeted to cut terms and cut none

Going into the Korean listing I assumed I would have to drop three or four entries. I dropped zero.

Korean words are short. Stripping the commas, my English terms take 82 characters across 11 entries, averaging about seven and a half characters each. The Korean terms take 29 characters across the same 11, averaging under three.

So the three-times-per-character penalty runs straight into words that are roughly three times shorter, and the two nearly cancel. Per term: English 8.4 bytes, Korean 8.8. Close enough to call it even, and the opposite of what the byte limit looks like when you first read it.

One honest limit. This is one app’s vocabulary in two languages. It held for alarm and morning-routine terms, where Korean happens to be compact. A category full of long loanwords transliterated into Hangul would go the other way and I have not tested that. Anyone budgeting for Japanese or Chinese should measure their own terms rather than trust my two rows.

The rule that freed more space than the encoding did

Nothing in my keyword field repeats a word already in the app name or the subtitle.

Apple treats those three fields as one pool for search, so a term sitting in the name is already working. Spending keyword bytes on it again buys nothing.

My Korean name is RYZA: 음성 해제 알람 and the subtitle is 소리 내어 읽어야 꺼지는 알람. Between them they carry the brand, the mechanism, and the word 알람. So 알람 never appears in the keyword field, and the bytes it would have eaten went to 알람시계 instead, which is a different search.

That one rule recovered more room than anything I did with encoding, and it took about a minute to apply.

What none of this tells you

Whether any of it moved the ranking.

I have byte counts, not rank data. Doing that properly means holding everything else still for a few weeks and watching placement per term, and I have not run it. Every number here describes what fit in the field, not what it earned.

I also picked the terms the cheap way: writing down what a person would type when they want an alarm that makes them do something, then checking each against App Store search to see what already ranks. That is a judgment call wearing a lab coat. It is what I could do without paid tooling, and I would rather say so than imply there was a method.

If you are doing the same exercise, the byte counter is the easy part. The AlarmKit problem that decides whether RYZA can keep its promise at all was considerably harder.