All numbers below come from my own notes between October 17 and October 24, 2026. Each one is a single observation, so treat them as notes rather than a benchmark.

Why I started measuring

App Store Connect shows which apps people came from before downloading. Over the 30 days I checked on October 20, ChatGPT accounted for 193 of those referrals. The Perplexity, Gemini and Claude apps accounted for zero. I wanted to know whether the other engines simply weren't mentioning the app, and if they were, what they were citing.

How I measured

I picked one question that describes what the app does, and asked it the same way each time:

best free iPhone app to hide Instagram Reels and YouTube Shorts but keep DMs

Then I asked the same thing in Japanese, Korean, Spanish, Portuguese, German and French, phrased the way a person in that language would search, not word for word.

For every answer I logged one row:

The source column turned out to be the useful one. A position tells you how you did. The sources tell you what to fix.

A few rules I followed:

• A new conversation for every question.
• Never decide from one run. Answers list two to five items and change between runs.
• Asking from Japan sometimes pulls the Japanese App Store, so results may differ from what a US user sees.
• Most of my Perplexity runs were made while signed in to my own account, which has a history of similar searches. I haven't repeated them signed out yet.
• Copilot requires sign-in, so I couldn't read its answers. Instead I watched the AI Performance report in Bing Webmaster Tools, which counts citations in Copilot and partners.

What I found

English and Japanese: cited. Spanish, Portuguese, German, French: not

On October 24, Perplexity put the app first for the English and Japanese questions and fourth for Korean. For Spanish, Portuguese, German and French it wasn't mentioned at all. At the time of that check the site already had more than 40 pages in each of those four languages. Having pages in a language was clearly not enough.

The cited source was GitHub, not my site

In English, Japanese and Korean, Perplexity's sources for my app were on GitHub: the app's README and a list I maintain of iPhone apps and settings for hiding Reels and Shorts, with a CSV and a note that I'm the author. For the Korean question, GitHub was the only source cited. The Korean pages on minulo.app weren't cited.

Back on October 19, with the English question, Perplexity had already ranked the app first with the README as its source, while two other engines didn't mention it.

Where my app was missing, same-language how-to pages won

In the languages where it didn't appear, the cited pages were how-to and comparison articles on other developers' own sites. They were written in the language of the question, had a table, and used the question's words (free, keeps DMs) in the title.

My working hypothesis: Perplexity prefers a page in the same language, with a table, that reads like a third-party overview. English and Japanese had that. The other languages didn't.

The other engines

• Brave's AI answer (English) listed the app third on October 24. In Brave's regular results, my English page about free options ranked second; on October 17 it hadn't appeared at all.
• Gemini didn't mention the app for the English question on October 24. On October 23 it listed it third for the Japanese question but wrote its Japanese reading as "ミニロ" (miniro) instead of "ミヌロ" (minuro). I added the correct reading to the structured data (alternateName) and to llms.txt.
• Copilot had zero citations in Bing's AI Performance report for October 1 to 19.

Bing's index was the real bottleneck for Copilot

Bing Webmaster Tools on October 23 showed that the sitemap had exposed 243 URLs to Bing, but only 3 were indexed, and Bing counted one referring domain. An audit the same day found nothing technical blocking crawlers. My reading is that a new domain with almost no outside links gets discovered but not indexed. No amount of markup fixes that on its own.

What I changed in the static site

Given the hypothesis, the plan was to put the same pages in every language and make sure each language version points to the others correctly.

More same-language pages

On October 24 I added 88 pages that existed in English but not in other languages (20 Spanish, 20 Portuguese, 19 German, 18 French, 11 Korean). The commit touched 255 files. Most of those were not the new pages but existing ones whose hreflang tags and footer language links had to change.

Rebuild hreflang from the files that exist

Page counts differ a lot by language. On the evening of October 24, English had 67 pages in its folder, Korean, German, French, Spanish and Portuguese 64 each, Japanese 62, and the smaller languages 12 to 15. So every page has its own set of alternates.

The site used to be generated from JSON, but I had hand-edited the HTML so often that the JSON went stale. Running the old generators now would restore old titles and hreflang. So I stopped trusting any list and wrote a 37-line script that trusts only the file system:

have = [(h, d, n) for h, d, n in L if os.path.exists(path(d, s))]

L holds (hreflang, folder, display name) for the 13 languages. Japanese lives at the root, and the pt folder is Brazilian Portuguese, so its hreflang is pt-BR. For each page slug the script:

1. Removes every existing <link rel="alternate" hreflang=...> from each language version and inserts a fresh block right after the canonical tag. Rebuilding instead of patching means one-sided links can't survive.
2. Sets x-default to the English version if it exists, otherwise to the first language that exists, so it never points at a missing page.
3. Rewrites the footer's language links from the same list, with the current language in bold and hreflang/lang attributes on the others.
4. Replaces that slug's <url> entries in sitemap.xml, each with xhtml:link alternates for every existing version plus x-default.

One page has a different filename in Japanese because I published that version first and didn't want to change its URL. A one-line mapping handles it, and every path, URL and relative link goes through the same function:

JA = {'turn-off-youtube-autoplay-recommendations.html': 'youtube-autoplay-recommendations-off.html'}

The sitemap now lists 612 URLs. One known weakness: the script writes a fixed date into lastmod, so it records when I ran it, not when the content changed. Taking lastmod from git history is planned but not done.

llms.txt stays manual

llms.txt at the root has one line per page: the English title, a short note in parentheses about what the page answers, and the URL of each language version. I edit it by hand, because the note needs someone who has read the page.

Tell the indexes

After each push I send the changed URLs with IndexNow to api.indexnow.org, Bing and Naver. The site keeps an IndexNow key file at its root, and a 200 response means the request was accepted. On October 24 I sent all 398 URLs I had at the time this way. Bing's manual URL submission is capped at 100 a day, and Google's indexing requests at about 10, so IndexNow is the practical way to notify that many at once.

What I don't know yet

I haven't measured whether any of this worked. On October 31 I'll ask Perplexity, Brave and Gemini the same questions in the same languages as on October 24, and log the position and the cited sources again. If the new same-language pages show up as sources, the hypothesis holds. If GitHub is still the only source, the next step is outside links and same-language lists rather than more pages on my own domain.

If you want to try this

• Use one fixed question per language and log the sources, not just the position.
• Repeat runs. A single answer is noise.
• Check your own index coverage before blaming the engines.
• Build hreflang from the files you actually publish, and rebuild every language version at once.

Disclosure: I'm the developer of minulo. The site is at https://minulo.app/en/?ref=hashnode-en-aicite-1025

This is what the numbers look like, what I found when I checked the other assistants, and what I've been doing about it. The numbers are small. I'll say where they're too small to mean much.

What App Store Connect shows

App Store Connect lists "source apps" for product page views and downloads. From Sept 10 (the week the app went live) to Oct 16:

• ChatGPT: 179 product page views, 127 downloads.
• Claude, Gemini, Perplexity: nothing listed.

127 out of 179 is a high ratio for a product page. People arriving from ChatGPT have already been told what the app does and that it fits their question. They come to download, not to browse.

On one day (Oct 16), ChatGPT accounted for 15 downloads on its own. For an app at this size, that's a meaningful share of the day.

What my website analytics show

My site counts where each visitor came from (a ?ref= tag if present, otherwise the referrer). Over the last three days:

Fifteen people is not a sample I'd build a theory on. But the direction matches App Store Connect: people sent by ChatGPT already have intent.

In the report I published about the first month (data here), 28% of users said they found the app through an AI chatbot (the app asks where you heard about it).

Why the other assistants sent nobody

I assumed Claude, Gemini and Perplexity just weren't recommending small apps. When I checked, the reason was simpler: they couldn't see my site.

• Claude uses Brave Search for web results. A site:minulo.app search on Brave returned zero pages. Brave only knew about the App Store listing and a couple of my dev.to posts.
• Gemini leans on Google. Google had indexed part of the site, but a block of pages sat in "Discovered – currently not indexed".
• Perplexity, logged into my own account, actually recommended minulo first for "iPhone app that hides Instagram Reels but keeps DMs". I don't trust that result yet, because that account had searched similar things before. I'll recheck logged out.

ChatGPT, on the other hand, seemed to lean on the App Store page and a few third-party articles that mention the app.

What I changed

None of this is clever. It's mostly plumbing:

1. Submitted the site to Brave directly. Brave has a "submit URL" page. I've sent it 65 URLs so far, including the language versions of the main guides. I'll check site:minulo.app again in a week.
2. IndexNow on every push (Bing and Naver), and Bing Webmaster's URL submission for the rest.
3. One question per page, in the words people ask. "How do I turn off Reels on Instagram?", "Use Instagram only for DMs", "Screen Time limit on Instagram not working". Each page answers the question first, including the free built-in options, and only then mentions the app.
4. The same pages in 13 languages, with proper hreflang. A Korean student asking in Korean should get a Korean page.
5. llms.txt listing every page and language version, plus JSON-LD (FAQPage, Article) on the guides.
6. Third-party mentions. Assistants cite other sites more readily than a developer's own. So I write on dev.to, Hashnode, Qiita, Zenn and others, answer Quora questions with a clear disclosure, and email writers whose articles cover the same problem.

What I'd tell another indie developer

• Look at "source apps" in App Store Connect. You may already have AI referrals and not know it.
• Check what each assistant can actually see. site:yourdomain on Brave told me more in ten seconds than a week of guessing.
• Treat AI referrals as high-intent traffic. In my case they convert better than search, so a page that an assistant can quote is worth more than its raw traffic suggests.
• Be honest on the pages. If the free settings solve the problem, say so first. An answer that's actually useful is what gets repeated.

I'll post the follow-up numbers once Brave has had time to index the site.

I build minulo, an iPhone app that hides Reels and Shorts while keeping DMs. Hiding them is free.

Here's how they compare, and what made me pick the third.

First, what Screen Time can't do

The obvious first idea is the Screen Time API (FamilyControls + ManagedSettings). It can shield an entire app, or an entire web domain in Safari. It can't reach inside an app: there's no way to say "Instagram, but not the Reels tab." The native Instagram and YouTube apps are closed to third parties, and on iOS there's nothing like Android's accessibility services that could read another app's screen.

So any Reels blocker on iOS works on the web version of the network. The question is just where that web page gets rendered.

Option 1: Safari content blocker

A content blocker is a JSON list of rules. Safari compiles it and applies it itself. Your code never runs on the page.

[{
  "trigger": { "url-filter": "^https://www\\.instagram\\.com/" },
  "action": { "type": "css-display-none", "selector": "a[href='/reels/']" }
}]

Good:

• It's private by design: the extension can't read the page, so there's nothing to leak and nothing to explain in a privacy policy.
• It's fast, because Safari compiles the rules ahead of time.
• It's cheap to maintain.

Limits I ran into while preparing the rules:

• The only CSS you get is display: none on a selector. You can't change other properties, so you can't disable something without removing it. On one network's mobile site, the bottom tabs are laid out by position. Removing a tab with display: none didn't let its neighbours close the gap, and hiding the tab container instead left an empty grey box. Fixing that takes JavaScript.
• url-filter is a restricted regex. In particular, there's no | alternation, so "these two paths" means two rules.
• Be strict about the format. As I understand Safari's parser, an unexpected key can get the whole list rejected, and nothing on the page tells you why. I keep metadata (which rule came from which network) in a separate file, in the same order as the list.

Option 2: Safari web extension (content script)

A web extension can inject CSS and JavaScript, so it can handle the cases a content blocker can't: watching the DOM, disabling buttons, redirecting /reels/ to the inbox.

What you pay for that:

• The script can read the page, and that includes the user's DMs on that site. Safari asks the user for per-site permission and warns that the extension can read the page. For an app that's supposed to make your phone calmer, that's a hard first screen.
• You now maintain JavaScript against someone else's DOM, which changes without notice.

My rule for that case is: anything that can be expressed as a selector stays in the content blocker. Only what really needs a script goes to the script.

The problem both Safari options share

Both only work in Safari. The habit we're trying to break is tapping the Instagram icon, and the icon opens the native app, where Safari extensions don't exist. The user has to remember to go to instagram.com in Safari every time, at exactly the moment they're least likely to.

For a desktop browser that's fine, since people already live in the browser there. On a phone it's the weak point.

Option 3: your own app with a WKWebView

This is what minulo does. The app opens the official web version of the network in a WKWebView and injects its own CSS and JS. Login happens on the network's own login page, inside that web view.

The part that makes this work on iPhone is combining it with Screen Time: minulo can shield the native Instagram app, and the shield screen offers a button that sends you into minulo instead. The icon habit lands somewhere without Reels. (I wrote about getting from a shield screen into your own app, which is harder than it sounds.)

What I had to handle:

Inject twice. CSS goes in via injectedJavaScriptBeforeContentLoaded (react-native-webview), so Reels never flash on screen before the rules apply. Behaviour goes in after load, with a MutationObserver, because these sites keep adding DOM long after the first render.

URL-scoped rules need re-applying. Injection runs once per document, but single-page apps change the URL without reloading. A rule meant only for /explore/ either applies everywhere or nowhere unless the injected script watches the URL and swaps a scoped <style> itself.

Selectors fail silently. When a site renames a class, CSS doesn't throw, it just stops matching. I count matches per rule and treat a rule that keeps matching zero as broken. (More on that here.)

Injected code runs in the page's world. The site's own JavaScript can call window.ReactNativeWebView.postMessage just as easily as yours can. Messages from the page to the app are untrusted, so the app checks them against a per-screen token and an allow-list of message types, and treats that as a first line of defence only.

Send a current user agent. I had a fixed Safari user agent that was two iOS generations out of date. When I went through the App Store reviews of a similar web-view app, 18 of them mentioned suspicious-login warnings, bot checks or locked accounts. A stale user agent is an easy thing to stand out with, so the app now reports the same Safari version as the device it runs on.

One rule source, three outputs

I didn't want to choose forever, so the rules live in one TypeScript file and get exported:

• selector-only rules become content-blocker JSON
• the few rules that need code become content-script JS
• all of it is injected into the WKWebView in the app

The same declaration (urlFilter, css, redirect) is read by all three, so the iOS app and a future browser extension are harder to let drift apart. Earlier, the app ignored urlFilter while the other outputs respected it, and on iOS a rule hid things on every page. With one declaration that all three read, that kind of mismatch shows up in one place instead of three.

Summary

If you're building for desktop, start with a content blocker and add a content script only where you have to. On iPhone, the deciding factor is the icon: whatever you build has to be where the user's thumb goes.

I build minulo, an iPhone app that hides Reels and Shorts while keeping DMs. Hiding them is free.

The built-in setting: Shorts feed limit = 0

In the YouTube app, go to You → Settings → Time management → Shorts feed limit and pick 0. YouTube opened the zero-minute option to everyone in April 2026.

What it does: once you hit the limit, the Shorts feed on Home and the Shorts tab stop.

What it doesn't do:

• On an adult account you can dismiss the limit and keep scrolling.
• Shorts still appear in Subscriptions and in links people send you.
• It's an app setting. youtube.com in Safari isn't covered.

For most people this alone cuts a lot of Shorts time. If you find yourself dismissing it every evening, read on.

The weaker options

Why no app can delete Shorts from the YouTube app

iOS doesn't let one app change what another app draws. So only YouTube can remove Shorts from the official app. Third-party apps have two moves:

1. Open YouTube's website in their own view and hide the Shorts entry points.
2. Use Screen Time to shield the official app.

The first move breaks quietly when YouTube changes its markup. In minulo I count how many elements got hidden on each page load, so I notice when that number drops to zero.

Where minulo fits

minulo does both moves: YouTube opens in minulo with Shorts hidden (regular videos, search and subscriptions still work), and the official app can be shielded with Screen Time so the block screen sends you to the Shorts-free view. Hiding is free. UNDOOMED, Nope and LoomWeb take similar approaches, so compare a few.

If the 0-minute limit already works for you, you don't need any of this.

Full list with sources: How to block YouTube Shorts on iPhone and keep normal videos

The app is React Native (Expo). The Screen Time parts start from react-native-device-activity by Robert Herber, with my own changes on top.

What I wanted

1. Lock Instagram and other apps with a ManagedSettings shield.
2. When the user taps the Instagram icon, show a custom block screen (ShieldConfiguration).
3. The primary button, "Open in minulo", opens my app on the Reels-free version of Instagram.

1. Opening a URL from ShieldAction does nothing

Button taps arrive in ShieldActionDelegate.handle(action:for:completionHandler:). Trying to open my own URL scheme from there:

let context = NSExtensionContext()
context.open(url) { _ in }

did nothing on a real device. No error, the request is silently ignored. Assume there is no direct way to open another app, including your own, from a shield extension.

2. Post a local notification and let the user tap it

Instead, the ShieldAction extension posts one local notification. Tapping it opens the app.

sendNotification(contents: [
  "title": title,              // localized text the app stored in the App Group
  "body": body,
  "userInfo": ["url": url],    // the app routes to this URL
  "identifier": "minulo-open", // same id, so it replaces the previous one
  "interruptionLevel": "active",
], placeholders: [:])

The app handles the notification tap and opens userInfo.url. The flow becomes two taps: the button on the block screen, then the banner that drops in right away.

3. Wait a little before calling completionHandler

Calling completionHandler lets the system tear the extension down, which can happen before the notification is scheduled. For the notification button only, I wait 0.4 seconds and return .defer, so the block screen stays up during the wait.

DispatchQueue.main.asyncAfter(deadline: .now() + 0.4) {
  completionHandler(.defer)
}

4. Without notification permission, the button does nothing

Because the flow goes through a notification, a user who denied notifications gets a button that does nothing, which is the worst outcome. The app writes the permission state to the App Group, and when notifications are off, both the ShieldConfiguration and ShieldAction extensions show and handle a single "Close" button instead.

5. ShieldConfiguration cannot write to the App Group

I wanted to count how often the block screen appears, so I wrote to the App Group's UserDefaults from the ShieldConfiguration extension. The writes were silently dropped (analytics showed "none" for every event). Reading works; writing does not. I count in ShieldAction instead, where the button tap happens.

6. The app name is not always passed in

I put the blocked app's name into the block screen text and the button URL. Apple sometimes does not pass the name to the extension, so plan for it to be empty. Depending on how you substitute placeholders, the literal string "applicationName" can end up in the text.

7. Percent-encoding non-ASCII names

CharacterSet.alphanumerics includes non-ASCII letters (Japanese, for example), so names pass through unencoded. I use an explicit ASCII set:

let allowed = CharacterSet(charactersIn:
  "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~")

Summary

• A ShieldAction extension cannot open your app directly. Go through a local notification.
• Wait briefly and return .defer so the extension is not torn down before the notification is posted.
• No notification permission means a dead button. Show only "Close" in that case.
• ShieldConfiguration can read the App Group but cannot write to it.

minulo on the App Store (hiding is free): https://apps.apple.com/app/id6809352229 A neutral list of apps and settings that hide Reels and Shorts: https://github.com/ayumu-kitabayashi/awesome-reels-shorts-blockers