DEV Community: Ethan Brooks

Treat image prompts like functions: what 1,446 shared prompts say about templates

Ethan Brooks — Mon, 05 Oct 2026 10:07:42 +0000

Most people write an AI image prompt the way they'd write a search query: once, for one result, then throw it away.

The prompts that get shared and reused look different. We went through 1,446 popular image prompts in an openly licensed dataset, and a lot of them are written more like code than like sentences.

Two patterns that stood out

About 22% are templates. 323 of the 1,446 prompts contain at least one placeholder in square brackets, such as [OBJECT], [COLOR], [COUNTRY] or [BRAND NAME]. The author wrote the structure once and left slots for the parts that change.

About 21% are written as JSON. 299 prompts are structured objects with keys for things like the scene, lighting and camera, rather than a paragraph.

They're also long. The median prompt is about 1,000 characters. These aren't one-liners.

Why a template beats a one-off prompt

The top-ranked prompt in the dataset, shared by TechieSA, starts like this:

Create a technical infographic of [OBJECT] with a 45-degree isometric 3D perspective…

Everything after that line, the angle, the annotation style, the colour-coded arrows, stays fixed. Only [OBJECT] changes. Swap in a phone, a camera or a coffee machine and you get a consistent series, not a pile of unrelated images.

That's the same reason we write functions instead of copying code: one definition, many calls, and a fix in one place applies everywhere.

Turning your own prompt into a template

Write it once for a real case and keep iterating until you like the result.
Circle what would change between uses: the subject, a colour, a place, a brand. Those become placeholders.
Name the slots clearly. [PRODUCT] is better than [X], because future you won't remember what X was.
Freeze everything else. The style, the lighting and the camera words are what make the series consistent, so resist editing them per image.
Fill the slots in code if you're generating many images:

template = open("infographic_prompt.txt").read()
for item in ["mechanical keyboard", "film camera", "espresso machine"]:
    prompt = template.replace("[OBJECT]", item)
    generate(prompt)  # your image API call here

When JSON helps, and when it doesn't

JSON prompts make each part of the image an explicit field, which is handy when a script fills them in or when you want to change one property and keep the rest. Models still read them as text, though, so there's nothing magic about the braces. If a plain paragraph with clear placeholders does the job, it's easier to read and edit.

Where the numbers come from

The counts are from the nanobanana-trending-prompts dataset, published by MeiGen.ai under CC BY 4.0. The prompts belong to the creators who shared them.

Prompt House is a free gallery built on that dataset, with each prompt shown beside the image it produced and credited to its creator. If you want to see templates like these in action, browse the trending AI image prompts and look for the square brackets.

Written by the Prompt House team. Prompt House is a free AI prompt gallery made by APPDOOK. The counts above were made by searching the dataset's prompt text in October 2026.

Four green buttons and only one is real: how to spot a dark-pattern download site

Ethan Brooks — Mon, 05 Oct 2026 09:04:18 +0000

You paste a link into a free download site, and the page suddenly fills with big green buttons. Download. Download Now. Start Download. Click one and a new tab opens, then another, and somewhere along the way your browser asks to show you notifications.

Most of those buttons are ads. Some lead somewhere much worse than an ad. Here's how to tell the difference, and what anyone building a free tool can learn from it.

Five warning signs

1. More than one "Download" button. Ads are often designed to look exactly like the site's own button. The real one usually appears only after you've chosen a format, right next to what you pasted. If several identical buttons appear at once, assume most of them aren't the site's.

2. A new tab opens wherever you click. Some sites open an advert or a chain of redirects in a new tab on your first click, sometimes even a click on empty space. A tool that works honestly doesn't need to take you anywhere else.

3. "Click Allow to continue." No download needs permission to send you notifications. That prompt is a way to push spam and fake alerts to your device later. Click Block, every time.

4. The file isn't what you asked for. You wanted a video or an audio file, and you got a file ending in .exe, .apk, .dmg or an unexpected .zip. Don't open it. Delete it.

5. "Install our app or extension for HD", or "your device is infected". A web tool that genuinely works in the browser doesn't need you to install anything, and a website cannot scan your device for viruses.

Three habits that keep you safe

Hover before you click. On a computer, the link's real destination shows in the corner of the browser.
Watch the download panel. Check the file name and type before you open anything.
Leave at the first warning sign. There's always another tool. There isn't always an easy fix for malware.

If you're building a free tool

Most free tools are paid for by ads, and that's fair. But there's a big difference between showing ads and disguising them. A few rules worth following:

Keep ads in a clearly separate space, never styled like your own controls.
Give the page one obvious primary action.
Never open a new tab on a click the user didn't mean for that.
Never ask for notification permission as a condition of using the tool.

Users notice. A tool that respects these rules is one people come back to, and recommend.

Where we stand

We built Kino around those rules: no fake download buttons, no redirect chains, no account and nothing to install. It's ad-supported, with the ads kept in their own space, and downloaded files are deleted automatically after a short time. You can try it at kinosave.social.

Kino is meant for saving content you have the right to keep, such as your own uploads or openly licensed video.

Written by the Kino team. Kino is a free video downloader made by APPDOOK.

Local news without a location prompt: how we pick a reader's edition in Next.js

Ethan Brooks — Mon, 05 Oct 2026 08:23:06 +0000

A news site with editions for different countries has to answer one question on every request: which edition should this reader see?

The easy answer is the browser's location prompt. We decided never to show it. Here's the order of fallbacks we use instead, and the small details that turned out to matter.

The resolution order

The edition is decided in Next.js middleware (the proxy), before any page renders. It takes the first of these that exists:

The reader's own choice. If they've picked an edition in the switcher, a cookie remembers it and it wins over everything else.
The hosting network's geo headers. The host already derives an approximate country, region and city from the IP address. We read those.
The device's time zone. When there are no geo headers, the browser's IANA time zone is a surprisingly good hint.
A default. If all else fails, the U.S. edition.

Nothing in this list needs a permission dialog. All of it is information the request already carries.

Detail 1: validate the geo header, even though your host sent it

Geo headers aren't always a clean two-letter country code. Cloudflare uses XX for "unknown" and codes with digits for things like Tor. If you pass those straight through, you end up looking for the "XX edition".

We accept a country only if it matches ^[A-Z]{2}$ and isn't XX. Everything else falls through to the next step in the list.

Detail 2: skip time zones that span several countries

Asia/Kolkata points to India. Europe/London points to the U.K. Some zones are shared by several countries, though, and guessing among them is worse than not guessing.

Our time-zone table simply leaves those out. Where a zone does pin down a place, like Australia/Perth, it fills in the state and city as well.

Detail 3: overwrite the headers your pages trust

The middleware passes the result to pages as request headers such as x-user-country. It always sets them itself and deletes any incoming copies first:

const requestHeaders = new Headers(request.headers);
requestHeaders.set(COUNTRY_HEADER, country);
requestHeaders.delete(REGION_HEADER);
requestHeaders.delete(CITY_HEADER);

Otherwise a client could send its own x-user-country and the page would believe it.

Detail 4: only show state and city for the reader's own country

If a reader in Ohio switches to the U.K. edition, they shouldn't see "local news for Ohio" mixed into British headlines. Region and city are only passed on when the edition being served is the reader's detected country.

Detail 5: don't set cookies on pages that should be cached

The middleware remembers the detected edition in a short-lived cookie. At first it set that cookie on every response, including article pages. But a caching layer like nginx or Cloudflare won't store a response that sets a cookie, so the pages most readers arrive on from search could never be cached.

Article pages are the same for every reader, so they don't need the cookie at all. Now the middleware returns early for /news/ paths, and the cookie is set on the first edition-dependent page the reader opens instead.

What we store

No precise location, ever. The cookies hold the chosen or detected country code, how it was detected, and the time zone name. A VPN can put a reader in the wrong edition, which is exactly why the manual choice comes first.

This is how editions work on Yuphora, our free news site with editions for 13 countries. The About page lists every source we draw on and how each is licensed.

Written by the Yuphora News team. Yuphora is a free, ad-supported news site published by APPDOOK.

Should you require the new iOS? A five-question checklist before you touch the deployment target

Ethan Brooks — Mon, 05 Oct 2026 07:11:22 +0000

Every September someone on the team asks the same thing: now that the new iOS is out, can we just require it?

It sounds like housekeeping. It isn't. Raising your minimum OS is one of the few decisions that can quietly remove paying users from your app, and it's usually made in a five-minute conversation. Here is the checklist we use at APPDOOK to slow that conversation down.

1. Can every affected user actually update?

This is the question people skip, because they picture the user who just hasn't tapped Update yet. That user exists, but they're not the problem.

The problem is hardware. iOS 27, released on 14 September, runs on the iPhone 15 Pro and Pro Max, the iPhone 16 line and later, iPhone Air and iPhone Duo. Every non-Pro iPhone before the 16 is left out. That is a cut into phones people bought in the last two years.

For those users, a higher deployment target isn't a nudge to update. It's a request to buy a new phone. Most won't, and they won't email you about it either. They'll just stop getting updates, or stop finding you in the App Store.

2. Is the API you want load-bearing, or just convenient?

The reason given for raising the target is almost always one specific API. Ask honestly which kind it is.

If it's convenient, an availability check costs a few lines:

if #available(iOS 27, *) {
    useNewAPI()
} else {
    useExistingPath()
}

If it's load-bearing, you need a designed fallback anyway. A feature that silently disappears on older devices doesn't save work. It turns into support tickets.

3. Are you confusing "build with the new SDK" and "require the new OS"?

These are two separate decisions, and they get bundled together all the time.

Building against the newest SDK is cheap and you should do it immediately. You get the new APIs, and you see deprecation warnings early. Requiring the newest OS is expensive, for all the reasons above. You can do the first without the second.

The short version: build against the newest SDK, and require the oldest OS you can live with.

4. Do you have your own numbers?

Industry averages for OS adoption are interesting, but they're not your users. Before the conversation, pull the OS version split from your own analytics or App Store Connect.

Every argument in this checklist gets stronger, or weaker, once you can say "this would cut off X% of our active users" instead of "probably not many people".

5. Is this one of the real exceptions?

There are cases where requiring the newest OS is fine:

a brand-new app with no installed base to leave behind
an internal tool on managed devices, where you know exactly which hardware is in the fleet

Those are real. They're also much rarer than the number of times the question gets asked.

What to do instead

Keep the deployment target where it is, and adopt new APIs behind availability checks.
Build and test against the new SDK now.
Bring your own OS version numbers to the discussion.
Put the question back on the calendar for about a year from now, once the current hardware generation has spread.

That last step matters. "Not now" is a much easier answer to give when it comes with a date for "later".

We went through this year's device list in more detail, including why this cut is different from most years, in APPDOOK's notes on raising the deployment target.

Written by the APPDOOK team, a small product studio in Surat, India. If your team has a different rule of thumb for this decision, we'd like to hear it in the comments.