DEV Community: Webnaa

One Domain, 200+ Installable Apps: PWA id, scope and the Nested-App Trap

Webnaa — Sat, 07 Nov 2026 18:07:39 +0000

We are a small Saudi team in Riyadh, and we run 200 free browser tools in Arabic and English. People don't use a tool library the way they use a website. They come back to one tool, every day: a VAT calculator, a word counter, a PDF merger.

So we made every tool installable as its own app, with its own icon and its own window. Add the website, the forum and the tools hub, and one domain now serves a little over 200 installable apps.

The manifest part took an afternoon. The interesting part was everything around it, especially one trap we only found after launch.

One manifest per page, per language

Every tool page links its own manifest:

<link rel="manifest" href="/pwa/m/t-word-counter-en.webmanifest">
<link rel="apple-touch-icon" href="/pwa/i/t-word-counter/apple-180.png">

A Python build script writes all of them from the same list of tools that builds the pages, so a new tool gets its app without any manual work. Today that is 406 manifest files: one Arabic and one English for every app.

Two languages, one app: the `id`

Each tool has an Arabic page and an English page. If both manifests were independent, a person who installs the Arabic page and later the English one would end up with two copies of the same app. The fix is the id member:

id is shared. Both languages of Word Counter say "id": "/app/tool/word-counter", so the browser treats them as one app.
start_url and scope are per language. The English app opens /tools/en/word-counter/, the Arabic one /tools/word-counter/, each with its own dir.
Ids are forever. The id is how the browser recognises an installed app. Change it, and every existing install becomes a different app from the new one. We wrote ours down as permanent before the first deploy.

Icons: one drawing, four files

Each app ships any icons at 192 and 512 pixels, maskable icons at the same sizes, and a 180-pixel apple-touch-icon for iOS. The icons are drawn per category colour, so 200 apps on a phone don't look like 200 copies of the same logo.

Maskable icons are the ones people get wrong most often. The launcher, not you, decides the final shape:

Anything outside the central circle, 80% of the icon's width, can be cut off. We keep the whole drawing inside it and let the background colour run to the edges.

No service worker, on purpose

The tools already run in the browser and the pages are static, so we had nothing useful for a service worker to do. We shipped none, and Chrome offered installation anyway in our tests.

It also means one less thing that can serve a stale page after a deploy. That is a real cost on a site where a build regenerates hundreds of pages at once.

The trap: nested scopes

Here is what we found a week after launch. The website app has "scope": "/". The tools hub has "scope": "/tools/en/". Each tool has its own folder as scope. Three apps, nested inside each other:

On a device where the website app is installed, Chrome never fires beforeinstallprompt for any page inside its scope. That covers every tool on the domain. Our install button simply never appeared there.

We confirmed it by testing a nested tool page and an unrelated PWA side by side in the same browser: the tool page got no event, and the unrelated app got it at once. From Chrome's point of view this makes sense, because the page already "belongs" to an installed app. It just isn't what you want when the nested page is meant to be an app of its own.

The workaround works, and the result sticks:

Uninstall the website app.
Install the tool you want.
Reinstall the website app.

Both then stay installed, each in its own window.

What we did about it:

The install card now explains this to visitors when the prompt is missing, instead of failing silently.
The real fix is a design choice: give the parent app a narrower scope, so it no longer covers the tools. The cost is that links from the website into the tools then open in the browser instead of the app window. We haven't made that trade yet, and it is the first thing we would decide differently from day one.

Small things that mattered

Mirror the button for right-to-left pages. On the Arabic pages the install button sits on one side. On the English pages it moves to the other, so it never covers the same corner as the page's other floating button.
Shortcuts in the parent manifest. The website app lists the tools hub and the forum as shortcuts. A long-press on the icon jumps straight there.
Name the app after the job. Each short name says what the tool does, because that is the only text under the icon on a phone.

Checklist if you are doing the same

One id per app, shared across languages, and written down as permanent.
scope and start_url per language, with the right dir.
any and maskable icons, with the drawing inside the 80% circle.
Decide your scopes before launch. A parent app with "scope": "/" silently swallows every app below it.
Tell users why the install button is missing, rather than hiding it without a word.

Try it on any tool, for example the Word Counter, or browse all 200 tools. There is no sign-up and there are no ads.

We are Webnaa, a Saudi web design team based in Riyadh. We build websites and online stores for businesses in Saudi Arabia and the Gulf. This post was written by Claude, an AI assistant, from our live manifests and our own install tests.

Making Search Work for Arabic: Hamza, Taa Marbuta and Prefixes in Plain JavaScript

Webnaa — Sat, 07 Nov 2026 16:56:14 +0000

We run a library of 200 free browser tools: PDF, images, video, calculators, text and developer tools. Every tool has an English page and an Arabic page, and one search box has to find the right tool in either language.

English search is the easy half. Lowercase the query, split it into words, maybe strip a plural "s", and you are most of the way there.

Arabic breaks every one of those assumptions. This post walks through the search we ended up with: about 200 lines of plain JavaScript, no library, no server, no index file. Everything runs in the browser over the tool cards that are already on the page.

Why `includes()` fails for Arabic

Take the word for "invoice". All of these mean the same thing, and real users type all of them:

What people type	What changed
`فاتورة`	the dictionary form
`فاتوره`	taa marbuta (`ة`) typed as haa (`ه`), very common on phones
`الفاتورة`	the article "al-" glued to the front
`بالفاتورة`	"bi-al-" ("with the") glued to the front
`بِالفَاتُورَة`	full vowel marks, copied from a document

A plain name.includes(query) finds one of these five. The same problems hit hamza (أ إ آ ء ؤ ئ), alef maqsura (ى vs ي), Arabic-Indic digits (٢٠٢٦ vs 2026), the tatweel stretch character (ـ), and Persian letters that come from some keyboards (ی ک گ پ چ).

So the search works in three steps. It folds every string into one canonical spelling, generates the forms a word can take, and then scores every tool.

Step 1: fold the text

Here is one word going through the whole pipeline:

The folding function is short (shown with arrow functions for brevity):

var CHARS = { "ة": "ه", "ى": "ي", "ی": "ي", "ء": "", "ٱ": "ا", "ک": "ك", "گ": "ك",
  "پ": "ب", "چ": "ج", "ڤ": "ف", "ظ": "ض", "ذ": "ز", "ث": "س" };

// NFKD splits أ إ آ ؤ ئ and Latin accents into letter + mark;
// the marks are then dropped with the diacritics
function fold(s) {
  return s.normalize("NFKD").toLowerCase()
    .replace(/[\u0300-\u036f\u0610-\u061a\u064b-\u065f\u0670\u06d6-\u06ed\u0640]/g, "")
    .replace(/[\u0660-\u0669]/g, d => d.charCodeAt(0) - 0x660)   // Arabic-Indic digits to 0-9
    .replace(/[\u06f0-\u06f9]/g, d => d.charCodeAt(0) - 0x6f0)   // Persian digits to 0-9
    .replace(/[ةىیءٱکگپچڤظذث]/g, c => CHARS[c])
    .replace(/[^\p{L}\p{N}]+/gu, " ").trim();
}

A few things worth pointing out:

normalize("NFKD") does the hamza work for free. أ decomposes into ا plus a combining hamza mark, and the next regex removes the mark. The same call turns é into e, so English accents are handled by the same line.
The character map also folds letters people swap by sound. ظ and ض, ذ and ز, ث and س sound alike in many Gulf dialects, and people misspell them constantly. Folding them on both sides (the query and the tool names) means the misspelling still matches.
Digits become Latin digits, so a search for a year works whichever keyboard typed it.
Folding is applied to the data too. The tool names are folded once when the page loads, so the comparison is always canonical against canonical.

Step 2: generate the forms of a word

Arabic glues articles and prepositions onto the word. A real stemmer for Arabic works with three-letter roots and is a project of its own. For a search box over 200 short tool names, light stemming is enough: strip one known prefix and one known ending, and keep the original word as well.

var AR_PRE = ["وال", "بال", "فال", "كال", "لل", "ال"], AR_PRE1 = "وفبلك";
var AR_SUF = ["ات", "ون", "ين", "ان", "يه", "ها", "هم", "كم", "نا", "ه", "ي"];
var EN_SUF = ["ations", "ation", "ings", "ing", "ions", "ion", "ers", "er",
              "ors", "or", "es", "s", "ed", "e"];

The function forms(word) returns the word plus the versions without a prefix and without an ending. For بالفاتوره it returns six forms:

forms("بالفاتوره")
// ["بالفاتوره", "فاتوره", "الفاتوره", "بالفاتور", "فاتور", "الفاتور"]

Two rules keep this safe:

At least three letters must survive. Without that rule, a short word like بال would be stripped down to nothing.
The plain word is always kept. Stripping only adds candidates, so a wrong strip can never lose a match that the plain word would have found.

English goes through the same function with EN_SUF, which is why compressor, compress and compressing all land on the same tools.

Step 3: allow one typo

After folding and stripping, a typo is the last common reason for a miss. The search uses an edit distance that also counts a swap of two neighbouring letters as one edit (Damerau, the "optimal string alignment" variant), so mrege is one edit from merge, not two.

// edit distance with swaps of neighbours; stops early above max
function dist(a, b, max) {
  if (Math.abs(a.length - b.length) > max) return max + 1;
  var d = [], i, j;
  for (i = 0; i <= a.length; i++) d[i] = [i];
  for (j = 1; j <= b.length; j++) d[0][j] = j;
  for (i = 1; i <= a.length; i++) {
    var low = max + 1;
    for (j = 1; j <= b.length; j++) {
      var c = a[i - 1] === b[j - 1] ? 0 : 1;
      d[i][j] = Math.min(d[i - 1][j] + 1, d[i][j - 1] + 1, d[i - 1][j - 1] + c);
      if (i > 1 && j > 1 && a[i - 1] === b[j - 2] && a[i - 2] === b[j - 1])
        d[i][j] = Math.min(d[i][j], d[i - 2][j - 2] + 1);
      if (d[i][j] < low) low = d[i][j];
    }
    if (low > max) return max + 1;   // the whole row is already too far
  }
  return d[a.length][b.length];
}

The early exit matters. The search runs on every keystroke against every word of 200 tools, and most pairs are obviously different. The length check rejects many of them before the table is even built, and the row check stops the rest as soon as no path can come back under max.

Words of 4 to 7 letters get one typo, words of 8 or more get two, and words under 4 letters get none. Short words have too many one-edit neighbours.

Step 4: score, don't filter

Every tool gets a score for every word of the query. The best kind of match wins for that word, and the word scores are added:

The modifiers do most of the ranking work:

Name words count double. A word in the tool's name beats the same word in its description.
Coverage beats strength. Each query word that matches anything adds 10, so a tool that matches all three words always beats a tool that matches one word perfectly.
Word order counts. If the folded words appear in the tool text in the order typed, the tool gets +5. That is the whole reason jpg to pdf and pdf to jpg return opposite tools first.
Ties go to what people actually search for. Each tool carries its monthly search volume in Saudi Arabia, and that adds a tiny, log-scaled bonus. The shorter, more specific name wins after that. Both are kept under 0.2 together, below the smallest real gap between two scores, so they only ever break ties.

Two more rules handle the edges:

Joined and split words. If the query with its spaces removed is found inside the tool text with spaces removed, it counts as a full match. That makes whats app find WhatsApp.
Let one word miss. With three or more words, one may miss. If still no tool passes, the search allows one more miss instead of showing an empty page.

Here is the real page, recorded from the live site:

Step 5: the wrong keyboard layout

This one is specific to bilingual users, and it happens all the time. You switch windows, start typing calc, and the keyboard is still on Arabic. The search box receives ؤشمؤ.

When a query returns nothing, the search reads the same physical keys on the other layout and tries again:

// standard Arabic (101) keyboard: the key each Arabic letter sits on
var KEYS = "qضwصeثrقtفyغuعiهoخpح[ج]دaشsسdيfبgلhاjتkنlم;ك'طzئxءcؤvرnىmة,و.ز/ظ`ذ";
var TO_AR = { b: "لا" }, TO_EN = {};   // plus the shifted hamza keys, omitted here
for (var k = 0; k < KEYS.length; k += 2) {
  TO_AR[KEYS[k]] = KEYS[k + 1];
  TO_EN[KEYS[k + 1]] = KEYS[k];
}

It only runs when the first search finds nothing, and only when the query is all Arabic or all Latin, so it never hijacks a real result. When it is used, the page says so: Showing results for "calc".

The b key is a nice detail. On the Arabic layout it types two letters at once, لا (lam-alef), so the reverse mapping has to read two characters as one key.

What it still gets wrong

Light stemming has limits, and it is better to know them:

Stacked prefixes. وبالفاتورة ("and with the invoice") has two prefixes. The search strips one, so it finds the bill-splitting tools, which contain الفاتورة, before the invoice generator. A second pass would fix this, at the cost of more false matches.
No roots. Arabic words grow from three-letter roots, and a real morphological analyser would connect words our stripping never will. For 200 tool names, the extra weight is not worth it.
Stop words are a fixed list. Words like "tool", "free", "online" and their Arabic equivalents are ignored unless they are the only words typed.

Takeaways for any non-English search

Fold both sides. Whatever you do to the query, do to the data, once, at load time.
Let Unicode do the work. normalize("NFKD") plus one regex removes accents and Arabic marks in one go.
Add candidates, never replace. Keep the original word next to every stripped form, and stripping can only help.
Rank instead of filtering. A sorted list with a forgiving fallback beats an empty "No results".
Watch real queries. The keyboard-layout fix and the sound-alike letters both came from what people actually typed, not from a linguistics book.

You can try all of this on the live page: webnaa.com/tools/en. There is no sign-up and there are no ads, and most tools process your files in the browser without uploading them.

We are Webnaa, a Saudi web design team based in Riyadh. We build websites and online stores for businesses in Saudi Arabia and the Gulf, and we made these tools for the same people. This post was written by Claude, an AI assistant, working from our live search code. Every code sample and result was checked against that code.