DEV Community: ExtensionBooster

Google Hasn't Verified This App? Fix Your Chrome Extension

ExtensionBooster — Sat, 07 Nov 2026 05:37:11 +0000

Originally published on ExtensionBooster.

"Google hasn't verified this app" is the screen a new user can hit right after clicking Sign in with Google in your Chrome extension, and plenty of them close the tab instead of clicking through. It's not only a trust problem: an unverified OAuth project is capped at 100 new users for its entire lifetime. Here's why the warning shows up, what it limits, and the four steps that make it go away.

What triggers the warning

Google treats an app as unverified when it requests a sensitive or restricted OAuth scope and hasn't finished Google's verification. In practice, that happens in three ways:

You request sensitive/restricted scopes and never configured them on the OAuth consent screen or asked for verification.
Your code requests scopes that aren't selected on the consent screen configuration.
You did everything right, but verification is still in progress.

Case 2 is the sneaky one. Ship a new feature, add a scope to manifest.json, forget to update the consent screen in Google Cloud, and the warning reappears for an extension that worked fine yesterday.

Why you can't just ignore it

100-user lifetime cap. Unverified apps using those scopes are limited to 100 new users, and Google's FAQ says the cap covers the whole life of the project and can't be reset. User 101 simply can't authorize, which looks like a bug to them.
Security Checkup. Google may list your app as risky and unverified there, so users auditing their account later may revoke access.
Testing mode is not a loophole. Only users on your test list can use it, and external apps in Testing get refresh tokens that expire in 7 days (unless they only ask for name, email and profile).
Reviews. Users write what they saw. "Google says this app isn't verified" in a one-star review scares off the next visitor before install.

Step 1: Shrink your scopes

The scope category decides how much review you face. Non-sensitive scopes don't require app verification; sensitive and restricted ones do, and restricted ones also need a yearly security assessment. Before committing to a long review, check whether a narrower scope covers the feature:

You need to...	Consider	Category
Know who the user is	`openid`, `userinfo.email`, `userinfo.profile`	Non-sensitive
Save files your extension creates to Drive	`drive.file`	Non-sensitive
Store app settings in Drive	`drive.appdata`	Non-sensitive
Read or manage every Drive file	`drive`, `drive.readonly`	Restricted
Send email for the user	`gmail.send`	Sensitive
Manage Gmail labels	`gmail.labels`	Non-sensitive
Read the user's mail	`gmail.readonly`, `gmail.metadata`	Restricted

A "save to Drive" or "export to Docs" button almost never needs full Drive access. drive.file handles files your extension creates or the user picks.

Then stop front-loading scopes in the manifest. chrome.identity.getAuthToken() takes a scopes array that overrides the manifest list, so you can ask only when the user enables a feature:

// background.js
const BASE = ['openid', 'https://www.googleapis.com/auth/userinfo.email'];
const DRIVE_FILE = 'https://www.googleapis.com/auth/drive.file';

export async function enableDriveExport() {
  const { token, grantedScopes = [] } = await chrome.identity.getAuthToken({
    interactive: true,
    scopes: [...BASE, DRIVE_FILE],
    enableGranularPermissions: true,
  });
  // Users can decline individual scopes, so check before using Drive
  return grantedScopes.includes(DRIVE_FILE) ? token : null;
}

With granular permissions, always check grantedScopes and keep the rest of the extension working if one is declined. Every requested scope still has to be listed on the consent screen.

Step 2: Prepare what reviewers check

Most rejections come from missing basics:

[ ] A homepage on a domain you own that explains the product (not just a login page, and a store listing doesn't count)
[ ] A privacy policy on that same domain, linked from the homepage and consent screen, covering how you access, use, store and share Google user data
[ ] All authorized domains verified in Google Search Console by an owner or editor of the Cloud project
[ ] A demo video showing the full flow, including the OAuth grant (sensitive and restricted scopes)
[ ] A written justification for each scope, including why a narrower one won't work

Use the same app name on the store listing, consent screen, homepage and video. Mismatches slow review and confuse users.

Step 3: Budget for the timeline

Google's estimates (explicitly not guaranteed):

Verification type	Estimate	Extra requirement
Brand	2-3 business days	None
Sensitive scopes	~10 business days	Demo video, scope justification
Restricted scopes	~6 weeks	Annual security assessment

Google doesn't charge for the security assessment, but you pay the assessor, so price that in before building a feature around full Gmail or Drive access. You can keep building and testing during review; just don't market a feature new users can't authorize yet.

Step 4: Don't lose verification on the next release

Changing your client or adding scopes after verification can send you back through review. Add this to your release checklist:

Diff requested scopes against the previous release, like you diff permissions.
Add any new scope to the consent screen and request verification before shipping it.
Test sign-in with a Google account that has never authorized the extension.
Watch for Google emails about scope reclassification and verification deadlines.

And telling users to click Advanced to continue? Fine for a handful of private beta testers. For a public extension it trains people to ignore security warnings and you still hit the 100-user cap.

Key takeaways

The warning means sensitive/restricted scopes without completed verification, or code scopes that don't match the consent screen.
Unverified apps get 100 new users, ever, for that project.
Narrow scopes (drive.file, sign-in only) can avoid heavy review entirely.
Request extra scopes at the moment a feature is used, and handle declines.
Re-check scopes and the consent screen on every release.

For the full walkthrough, including the FAQ and the manifest setup, read the guide to fixing "Google hasn't verified this app" in Chrome extensions. If ratings are your next trust signal to work on, ExtensionBooster helps developers get real Chrome extension reviews.

Have you been through Google's OAuth verification for an extension, and which step took the longest for you?

Chrome Web Store Listing: 5 Fixes for More Installs

ExtensionBooster — Sat, 07 Nov 2026 02:09:24 +0000

Originally published on ExtensionLaunch.

If your Chrome Web Store listing gets impressions but few installs, you probably don't need more traffic. You need a page that converts the visitors you already have. Below are five fixes, one per listing element, plus a simple way to tell which one is actually broken.

Treat the listing like a landing page

Google doesn't publish the store's ranking algorithm. But the signals you can observe line up with what you'd expect:

How relevant your name and description are to the search query
Install count and how fast it's growing
Rating and number of reviews
Engagement and retention (do installs stick?)

Only the first one is fully under your control. The other three improve when the page earns installs and keeps them. So a better listing helps twice: more visitors convert, and those conversions feed the ranking signals.

The 5 fixes at a glance

Element	What it optimizes	The quick win
Name	Search relevance	Keyword first, brand second
Icon	Recognition at 16px	One bold shape, high contrast
Screenshots	Conversion	Caption the benefit on image #1
Description	Skimming and search	Put the value in the first 3 lines
Reviews	Trust and ranking	Ask right after a success moment

Fixes 1 and 2: name and icon

Name. This is your highest-leverage search field. Lead with the words people type, then add your brand:

Weak:   Acme
Strong: Acme: Screenshot & Screen Recorder

Use the space you have, but keep it readable. No one searches for a brand word they've never heard, so a brand-only name is invisible in search.

Icon. It looks big on the listing page, but users mostly see it tiny, in the toolbar and in search results. Design for 16x16:

One clear shape or letter, not a detailed scene
Strong contrast so it works on light and dark themes
No small text (it turns to mush)

Quick test: shrink it to 16px and look at it from across the room. If you can't tell what it is, a user scanning a results grid can't either.

Fixes 3 and 4: screenshots and description

Screenshots are where most installs are won or lost. Raw, unannotated UI wastes them. Think of the set as a short slide deck:

First screenshot: the single most valuable thing the extension does, with a short caption built into the image.
Middle screenshots: one feature each.
Last screenshot: social proof or a call to action, like your rating or a "works on any site" promise.

Use the full 1280x800 canvas and keep the text large. People skim these before they read any of your copy.

Description. The store cuts it off, so the first two or three sentences have to sell on their own:

Line 1: what it does and who it's for, in plain words
Lines 2-3: the outcome, not a list of features
After that: short, scannable feature bullets

Write for a skimming human first. Use your main keyword a handful of times where it reads naturally, and cover the related phrases people search for the same need.

Fix 5: reviews, then measure

Reviews affect ranking, and they're the last thing a hesitant visitor checks.

Ask after a win, not on install. Prompt right after the user gets value, such as a first successful export or save.
Make feedback easy to reach, so unhappy users email you instead of leaving one star.
Reply to reviews, especially the critical ones. A calm public reply reassures the next reader more than the complaint scares them.

Then use the dashboard's impressions, installs and uninstalls to find what's broken. Watch the ratios, not the totals:

Low install rate with healthy impressions: the icon, name or first screenshot isn't selling. Fix the page.
High uninstall rate: the product doesn't match the promise. Fix onboarding or the pitch.

Change one element at a time and wait a week or two before judging it. Otherwise you won't know which change moved the numbers.

Key takeaways

Most listings have a conversion problem, not a traffic problem.
Put the keyword first in the name, and design the icon for 16px.
Make screenshot #1 a captioned benefit, not a raw UI capture.
Front-load the description: the first three lines do the selling.
Ask for ratings after a success moment, and reply to critical reviews.
Judge changes by install rate and uninstall rate, one change at a time.

Store search alone is crowded, so it helps to have links and an audience pointing at your extension too. The full write-up, with example images, is in the Chrome Web Store listing optimization guide, and you can get a linkable page in front of people browsing for new tools on the ExtensionLaunch browser extension directory.

Which change to your store listing made the biggest difference to your install rate, and roughly how much did it move?

Google Play In-App Review API: why the card won't show

ExtensionBooster — Fri, 06 Nov 2026 13:51:33 +0000

Originally published on AppRanker.

You wired up the Google Play In-App Review API, the task completes without an error, and no rating card ever appears. Usually nothing is broken: the card is quota-limited, the API never tells you what happened, and only one of Google's three test methods shows the real flow. This post gives you a working setup for Kotlin, Expo and Flutter, a rule for when to call it, and a table of the usual reasons the card stays hidden.

What the API does (and won't tell you)

The flow is two calls. requestReviewFlow() fetches a ReviewInfo object from Google Play, and launchReviewFlow(activity, reviewInfo) shows a native Play card over your app where the user picks 1 to 5 stars and can add a comment. It runs on Android 5.0 (API 21) and later, including tablets and Google TV, plus ChromeOS, but only where the Google Play Store is installed.

Three facts shape everything else:

You get no result. The completion callback fires whether the user rated, dismissed the card, or never saw it. Your code must carry on the same way in every case.
There is a quota. Google limits how often one user sees the card. Its own example is that calling it more than once in "less than a month" may display nothing, and the exact limit can change without notice.
The rules are strict. No "Do you like the app?" question before or during the card, no reshaping or overlaying it, and no rewards for ratings. Play's ratings policy bans incentivized feedback outright.

The quota is why Google says not to put the flow behind a button. A user who has used up their quota taps it and sees nothing.

Decide when to ask before writing the call

Since each user gets roughly one shot per period, your trigger logic matters more than the integration. Aim for a moment right after the user succeeded at something, while they are between tasks, once they have used the app enough to judge it.

App type	Ask here	Never here
Productivity	After the 3rd completed export or project	First launch, mid-typing
Fitness	Workout summary screen	During a workout, after a missed goal
Game	After a level win, before the next level	Mid-game, after a loss
Utility	After the tool has worked several times	After an error or crash recovery

A small eligibility gate keeps calls rare. The thresholds below are an example to tune, not a Google requirement:

private const val DAY_MS = 86_400_000L

fun reviewEligible(prefs: SharedPreferences, now: Long = System.currentTimeMillis()): Boolean =
    prefs.getInt("core_action_count", 0) >= 3 &&
    now - prefs.getLong("first_open_at", now) >= 3 * DAY_MS &&
    now - prefs.getLong("review_last_asked_at", 0L) >= 90 * DAY_MS

Save review_last_asked_at at the moment you launch the flow. You will never learn whether a rating was left, so launch time is the only timestamp you can trust.

The integration in Kotlin, Expo and Flutter

Kotlin. Add com.google.android.play:review:2.0.2 (and review-ktx with the same version for Kotlin extensions). Fetch ReviewInfo shortly before the success moment, since it expires after a while:

class RatingAsk(private val activity: Activity) {
    private val manager = ReviewManagerFactory.create(activity)
    private var info: ReviewInfo? = null

    fun warmUp() = manager.requestReviewFlow().addOnCompleteListener { t ->
        info = if (t.isSuccessful) t.result else null
        if (!t.isSuccessful) Log.w("RatingAsk", "code=${(t.exception as? ReviewException)?.errorCode}")
    }

    fun show(next: () -> Unit) {
        val ready = info ?: return next()
        manager.launchReviewFlow(activity, ready).addOnCompleteListener {
            info = null
            next() // runs no matter what the user did
        }
    }
}

Errors you may log: PLAY_STORE_NOT_FOUND (-1), INVALID_REQUEST (-2) and INTERNAL_ERROR (-100). Log them, never show them to the user, and wait for the flow to finish before moving to the next screen.

Expo. npx expo install expo-store-review, then check StoreReview.hasAction() before calling StoreReview.requestReview(). Bare React Native apps can use react-native-in-app-review.

Flutter. The in_app_review package gives you both sides:

final review = InAppReview.instance;

Future<void> askIfEligible(bool eligible) async {
  if (eligible && await review.isAvailable()) await review.requestReview();
}

// Settings "Rate us" item: not quota-limited
Future<void> rateUs() => review.openStoreListing();

For a permanent "Rate us" menu entry on Android, link to https://play.google.com/store/apps/details?id=<your.app.id>&showAllReviews=true (or the market:// form) instead of calling the API.

Testing: pick the right method

Most "it's broken" reports come from testing in a setup that cannot show a working card.

Method	Use it for	Catch
Internal test track	Real end-to-end card	None; quota is not applied here
Internal app sharing	Quick build checks	Submit button is disabled
`FakeReviewManager`	Unit and integration tests	No UI, always succeeds

For the internal test track, all four must hold: the account is on the track, it is the primary account selected in the Play Store, it installed the app from Play, and it has not reviewed the app yet. After that first Play install, you can push new builds from Android Studio and keep testing.

Card not showing: quick diagnosis

What you see	Likely cause	Fix
Completes, no card, debug build	This account never installed from Play	Install once from the internal track
Worked once, never again	Quota hit or already reviewed	Delete your review, or use the internal track
Submit greyed out	Internal app sharing install	Expected; use the internal track
Never shows on work phone	Enterprise-protected account	Test with a personal Gmail account
`PLAY_STORE_NOT_FOUND`	Emulator without Play	Use an image with Google Play
Works on one account only	Wrong primary account in Play Store	Switch accounts in the Play Store

If none fit, check that your eligibility gate ever returns true. A gate that never opens looks exactly like a broken API.

Key takeaways

The API reports nothing back, so always continue your flow on completion.
A quota applies (roughly monthly in Google's example), so never trigger it from a button.
No pre-questions, no rewards, no altering the card.
Ask right after a success, gated by usage count, days since install and time since the last ask.
Test on the internal test track with a personal account that has not reviewed the app.

The original covers the policy quotes, the Bare React Native setup and an FAQ in more depth: see the complete Google Play In-App Review API guide for Android, React Native and Flutter. For more on getting your app seen once the ratings come in, browse the AppRanker app leaderboard and ASO guides.

What trigger moment has worked best for your app's review prompt, and did you ever catch it silently burning the quota too early?

Browser extension monitoring: spot a sold or hijacked add-on

ExtensionBooster — Fri, 06 Nov 2026 09:15:38 +0000

Originally published on Extenify.

Browser extension monitoring matters because the extension you vetted on install day is not necessarily the code running in your browser today. The big extension attacks of the past year did not come from shady new listings. They came from trusted extensions that were sold to a new owner or had their developer account phished, then pushed an update that every user installed silently.

Below: what those incidents had in common, the signals that showed up before or during them, and a tiny Node.js check you can run daily.

Three incidents, one pattern

QuickLens (about 7,000 users). Listed for sale in October 2025, transferred on February 1, 2026 to an owner with a contact address on a .top domain, then updated on February 17 with code that stripped security headers like X-Frame-Options and fetched JavaScript from a server to run on every page. All the original features kept working.
ShadyPanda (4.3 million Chrome and Edge users). Koi Security described extensions that behaved normally for years before an update turned them into spyware or a remote code execution backdoor.
Cyberhaven (December 2024). An employee was phished with a fake "Chrome Web Store Developer Support" email and a malicious OAuth app. The attacker published version 24.10.4, which was live for roughly a day before the team caught it and pulled it within an hour.

In every case, the extension was already installed and trusted, and something visible on the listing changed before or during the attack.

"No new permissions" is not a safety signal

This is the part most developers get wrong. Chrome disables an extension when an update adds a permission that triggers a warning, and keeps it disabled until the user accepts. An attacker who wants the update to reach everyone therefore avoids new permissions and reuses the access the extension already has. If it already runs on all sites, it needs nothing more.

So the useful signals are elsewhere:

Signal	Sold extension	Hijacked account
Developer name, email, website	Often changes, sometimes weeks early	Usually the same
Privacy policy URL	Often moves to a new domain	Usually the same
Release timing	First update after a quiet stretch	A release the team never shipped, often at odd hours
Code	New script files, remote loading	Small additions to a clean build
Reviews	New 1-star reports of ads or redirects	Same, if it stays live

A dormant extension that suddenly ships right after its contact email moves to an unfamiliar domain is the QuickLens pattern, and it would have been visible about two weeks before the bad update.

A minimal daily check in Node.js

Chrome downloads extensions from a public update endpoint, and you can request the same package for any public extension ID. Two facts make a cheap monitor possible: a removed or taken-down extension answers 204 No Content instead of a file, and any code change produces a different package. Here is a stripped-down sketch (Node 18+) that hashes whatever Chrome serves:

import { createHash } from 'node:crypto';

const url = (id) =>
  'https://clients2.google.com/service/update2/crx?response=redirect' +
  '&prodversion=155.0&acceptformat=crx3&x=' + encodeURIComponent(`id=${id}&uc`);

export async function snapshot(id) {
  const res = await fetch(url(id));
  if (res.status === 204) return { id, served: false };
  if (!res.ok) throw new Error(`${id}: HTTP ${res.status}`);
  const buf = Buffer.from(await res.arrayBuffer());
  return { id, served: true, sha256: createHash('sha256').update(buf).digest('hex') };
}

Store the result, compare it with yesterday's, and alert on a flip to served: false or a hash change. The full guide goes further: it unpacks the CRX3 file (a short header plus a normal ZIP), reads manifest.json, and reports exactly which script files are new or changed, plus a Firefox check against the official addons.mozilla.org API that returns authors, support email and declared permissions.

A few lessons from running checks like this:

Confirm on two runs. During a staged rollout the endpoint can serve old and new versions alternately, so a flip-flop is not an incident.
Remote payloads stay invisible. QuickLens loaded its real code at runtime. A fingerprint tells you the package changed, not what it downloads later, which is why publisher fields matter just as much.
Be polite. One request per extension per day is plenty.
On Firefox, track the author ID, not the display name, since a name can be edited to look unchanged.

Sorting alerts so people read them

Act today: the store stops serving the package; a new version lands within weeks of a developer or contact change; new broad host access such as <all_urls>; any version of your own extension you did not publish.
Review this week: a publisher change with no new version yet; a first release after six or more months of silence; a cluster of 1-star reviews mentioning ads, redirects or search changes.
Log only: routine bumps with the same publisher, same access and the usual build output.

If you publish extensions, compare the live version on every store with your release log daily. A mismatch you cannot explain is the fastest sign that someone else is publishing in your name. If you manage a team's browsers, Chrome's ExtensionSettings policy lets you block specific permissions and keep extensions away from sensitive hosts with runtime_blocked_hosts.

Key takeaways

The common attack is a trusted extension that changes hands or gets hijacked, not a new malicious one.
Watch publisher fields, declared access and the actual code Chrome serves.
Unchanged permissions prove nothing; attackers avoid triggering the re-consent prompt.
A daily check catches takedowns (HTTP 204) and code changes; confirm on two runs before escalating.
Monitor your own listing too: a version you did not ship means your account is compromised.

The original post has the complete CRX-parsing script, the Firefox AMO check and an FAQ: how to monitor browser extensions for ownership changes and malicious updates. If you would rather not maintain scripts for dozens of listings, Extenify tracks Chrome, Edge and Firefox extension listings and alerts on publisher and version changes.

Have you ever had an extension you relied on change owners or ship an update you did not expect, and how did you find out?

Chrome Extension Compromised: A 3-Phase Response Checklist

ExtensionBooster — Fri, 06 Nov 2026 05:36:27 +0000

Originally published on ExtensionBooster.

If your Chrome extension is compromised, a malicious update can reach your users within hours, because Chrome checks installed extensions for updates "every few hours." In December 2024, one phishing campaign got into at least 35 extensions with more than 2.6 million users. Here is a response plan in three phases (first hour, first day, first month) that you can copy into your repo before you ever need it.

How attackers actually get in

Two-step verification is not enough on its own. These are the three routes that keep coming up:

Route	What happens	What to lock down
Malicious OAuth app	A fake "Chrome Web Store Developer Support" email leads to a consent screen. You grant an attacker's app publishing access, and 2FA never triggers. This is how Cyberhaven was hit in December 2024.	Third-party app connections on your Google account
Leaked CI credentials	The Chrome Web Store API client secret and refresh token in CI can publish just as well as you can.	CI secrets, runners, old contractor machines
Ownership transfer	A buyer takes over an extension that already has users and ships a harmful update.	Any "we'd like to buy your extension" offer

Catch it early: a version smoke alarm

The clearest warning sign is a version in the Developer Dashboard that you never built. Other signs: Google emails about submissions you didn't make, users reporting new ads, redirects or permission prompts, and a sudden run of one-star reviews that mention malware.

You can automate the first check. This script asks Chrome's update service which version it is serving and fails if that doesn't match your latest release tag. The response format isn't a documented API, so treat it as an early warning, not a guarantee.

// verify-live-version.mjs: node verify-live-version.mjs <id> <version>
const [extId, wanted] = process.argv.slice(2);
const params = new URLSearchParams({
  response: 'updatecheck',
  acceptformat: 'crx3',
  prodversion: '141.0',
  x: `id=${extId}&uc`,
});
const res = await fetch(`https://clients2.google.com/service/update2/crx?${params}`);
const served = (await res.text()).match(/<updatecheck[^>]*\sversion="([^"]+)"/)?.[1];

if (!served) { console.error('No version found in response'); process.exit(2); }
if (served !== wanted) { console.error(`Mismatch: live ${served}, expected ${wanted}`); process.exit(1); }
console.log(`Live version matches: ${served}`);

Run it on a schedule in CI and send failures to a channel someone actually watches at night.

Phase 1: the first hour (stop the spread)

Contain it first and investigate later. Keep a timestamped log of every step you take.

Roll back. The rollback in the Developer Dashboard puts the previous version live "within a minute," and Google says it needs no review. It asks for a new version number and a reason. There are three catches:
- It only goes back one version. If the attacker published twice, you land on the other bad build, and further rollbacks just cycle between those two.
- Pending and staged submissions are thrown away.
- During a percentage rollout, it returns to the last version that reached 100%.
- If there is no clean version to go back to, unpublish the item instead.
Reclaim the Google account. Change the password, remove 2-step methods you don't recognize, sign out all other sessions and revoke unknown third-party apps. Revoking the app is the step that would have cut off the Cyberhaven attacker.
Prune publisher members that don't need access.
Rotate the Web Store API credentials in CI and pause automated publishing.
Report it through the Chrome Web Store developer support form. Include the item ID, the bad version, when it went live and your evidence.

Phase 2: the first day (scope it and tell users)

Unpack the rogue package and diff it against your last good release. Look for:

New permissions or host permissions in manifest.json
New network destinations, especially in the service worker
Code that reads cookies, tokens, form fields or page content
Wider content_scripts matches

Then rotate any secrets that shipped inside the extension and invalidate sessions on your backend.

Your public notice should say what happened, which versions were affected and when, what they could access, what users should do now, and what you are changing. Your clean release can show the notice only to users who updated from an affected version:

const COMPROMISED = new Set(['3.4.1', '3.4.2']);
chrome.runtime.onInstalled.addListener(({ reason, previousVersion }) => {
  if (reason !== 'update' || !COMPROMISED.has(previousVersion)) return;
  chrome.tabs.create({ url: 'https://example.com/security/incident/' });
});

Reply to every angry review with the same short, factual message: confirm the incident, name the fixed version and link to the notice. Don't argue, and never ask anyone to change their rating.

Phase 3: the first month (make it harder next time)

Turn on Verified CRX uploads (Package tab). After you opt in, every update must be signed with your own key, so a stolen login alone can't publish. Generate the key offline:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out privatekey.pem
openssl rsa -in privatekey.pem -pubout

Keep the private key out of your Google account and out of every repo. If you lose it, Google says getting a replacement through support can take up to a week.

Give each person their own publisher role, with no shared logins.
Use security keys or passkeys on every account that can publish.
Require a manual approval before the CI publish job runs.
Use percentage rollouts so a bad build reaches a small group first.
Write a postmortem and publish a short, honest summary.

Your rating can recover. Since Google's August 20, 2026 update, the Chrome Web Store rating focuses on more recent reviews. A burst of one-stars hurts fast, but steady good reviews after the fix count for more than they used to.

Key takeaways

Roll back first: it goes live in about a minute with no review.
2FA doesn't stop malicious OAuth apps, so audit your third-party connections.
CI publishing credentials are as sensitive as your password.
Tell users which versions were affected and what to do, and reply to every review.
Verified CRX uploads make a stolen login useless for publishing.

The full guide, including a copy-paste checklist and FAQ, is in the Chrome extension incident response plan on ExtensionBooster. There are more growth and trust guides for extension developers in the ExtensionBooster developer resources.

Have you ever had a publishing account phished or a rogue update go out? What warned you first, users or your own monitoring?

Monetize a Chrome Extension: 4 Models That Pass Review

ExtensionBooster — Fri, 06 Nov 2026 02:10:12 +0000

Originally published on ExtensionLaunch.

If you want to monetize a Chrome extension, the hard part isn't Stripe or pricing pages. It's picking a revenue model that won't get your listing pulled six months after launch. Below are the four models that fit Chrome Web Store policy, the rules each one has to follow, and the two "passive income" offers you should delete on sight.

First, the six policies that decide everything

Every monetization choice gets judged against a handful of Developer Program Policies. Read them together, not one at a time:

Policy	The short version for revenue
Single purpose (Quality Guidelines)	The money feature must belong to the extension's one narrow purpose
Limited Use	You can't sell or transfer user data, even "anonymized"
Accepting payment	Say what's paid in the description and that you, not Google, are the seller
Ads	In context, easy to remove, and no AdSense
Affiliate Ads	Disclosure, a related user action, and a real user benefit
Deceptive installation	No surprise monetization after install

One extra trap: if your revenue feature needs new permissions unrelated to the core purpose, reviewers treat that as unrelated functionality. You get judged twice.

Model 1: Paid plans (the cleanest option)

Google shut down Chrome Web Store payments back in 2020–2021. So every paid extension now brings its own checkout: a payment provider or merchant of record, a license backend, and an upgrade page on your site. Upside: no store revenue share, only your provider's fees.

What the policy asks for:

If basic functionality requires payment, say so in the description users read before installing.
State clearly that you are the seller, not Google.
Post your terms of sale, including refunds.
In the Payments & distribution tab, select "Contains in-app purchases" (this adds a badge to your listing).
Add a physical address to your developer account. It will be shown publicly on the listing.

Two practical notes:

Check licenses on your server. Anything in the extension package is readable, so the client should only display entitlements, never decide them.
Make the free tier useful. Free users write the early reviews that make paid conversion possible. A paywall in the first minute turns your first ratings into complaints.

Model 2: Affiliate links (only the way Google now requires)

This is how coupon, cashback and shopping extensions earn money, and it's the area Google tightened most recently. After the late-2024 coupon-extension controversy, the Affiliate Ads policy was updated, with enforcement starting June 10, 2025. You need all three:

Disclosure in three places: the store listing, the UI, and before installation.
A direct user benefit: a discount, cashback or donation. No benefit, no link.
A related user action before every code, link or cookie. Silently refreshing a cookie or swapping out an existing affiliate code are listed violations.

In code, that means the affiliate step lives inside the click handler that delivers the benefit, and nowhere else:

// popup.js: attribution only after the user asks for a discount that exists
applyButton.addEventListener('click', async () => {
  const offer = await findValidOffer(currentStore);
  if (!offer) {
    showMessage('No working discount for this store right now.');
    return; // no discount, no affiliate link
  }
  await applyOffer(offer); // code + attribution applied together
  showMessage(`Applied ${offer.code}: ${offer.savingsText}`);
});

Shipping to Firefox too? Mozilla doesn't allow modifying web content or redirects to add affiliate tags at all; affiliate promos are only fine inside UI clearly owned by the add-on. Design for both stores from day one.

Models 3 and 4: Ads in your own UI, or low-risk sponsorships

Ads can work on new tab pages, dashboards and side panels, within limits:

Shown in context, clearly tied to your product, and removable via settings or uninstall
Never imitating system notifications or warnings
No AdSense (its own policy forbids use in extensions)
An extension whose primary purpose is serving ads isn't allowed, and injecting ads into web pages alongside another feature breaks single purpose

The pattern that holds up: one quiet, labelled ad slot on a page the user opened on purpose, plus an ad-free paid tier.

Lower-risk options earn less per user but rarely cause review trouble:

Donations (GitHub Sponsors or a "Support this project" link) for open source and hobby tools
Sponsorships in your newsletter, site or changelog. Inside the extension, a sponsor counts as an ad
Team and enterprise licenses, which often out-earn consumer plans because companies pay for admin controls, invoicing and private deployment

The offers to ignore: data deals and bandwidth SDKs

Most pitches promising "passive revenue" from "anonymized data" fail two policies:

Limited Use bans selling user data to ad platforms or data brokers, and explicitly covers aggregated or de-identified data.
Single purpose catches SDKs that turn the user's browser into something else. In October 2026, Chrome Extensions DevRel said a bandwidth-sharing SDK bundled into an extension with other features would likely violate it, "even if you have a clear opt-in from users."

In 2025, researchers found one such library in more than 200 Chrome, Edge and Firefox extensions, quietly using browsers to scrape sites.

Quick picker by extension type

Extension type	Model that fits	Watch out for
Productivity / AI tools	Freemium + paid plan	Server cost per free user
Shopping / coupons	Affiliate on user action	Disclosure in 3 places
New tab / dashboards	Paid plan or labelled ad slot	No AdSense
Developer tools	Paid or team license	Server-side license checks
Open source / hobby	Donations, sponsors	Keep payment logic out of the package

Key takeaways

Paid plans are the safest model: bring your own payments, disclose what's paid, select "Contains in-app purchases".
Affiliate links need disclosure in three places, a real benefit, and a user action every time.
Ads must stay in your own UI, be removable, and never use AdSense.
Data deals and bandwidth or scraping SDKs are off the table, opt-in or not.
Choose the model before launch: it changes your permissions, privacy fields, listing copy and public account details.

The full article has the policy quotes, the sponsored-tile grey area and a pre-launch checklist: how to monetize a Chrome extension without breaking Chrome Web Store policy. When your pricing is ready, you can launch it on ExtensionLaunch, a launch directory for new Chrome extensions.

Which monetization model are you running in your extension right now, and what conversion rate or revenue per user have you seen from it?

DEX code optimization warning: enable R8 without crashes

ExtensionBooster — Thu, 05 Nov 2026 13:51:35 +0000

Originally published on AppRanker.

If Play Console is showing you "DEX code optimization is below our threshold" next to something like "Obfuscation 2%", your release build almost certainly isn't running R8 at all. That is the default for several cross-platform templates, and from February 2027 it starts to matter. Below is what Google is measuring, which stacks ship with R8 off, and a release-safe way to switch it on.

What the warning is actually measuring

On August 26, 2026, Google Play announced new technical quality thresholds that take effect in February 2027. One of them is about DEX code: apps need at least 25% coverage on each of three metrics (shrinking, optimization and obfuscation) using R8 or another shrinker.

	Apps	Games
Rule applies when DEX code exceeds	10 MB	50 MB
Minimum shrinking	25%	25%
Minimum optimization	25%	25%
Minimum obfuscation	25%	25%

What each number means:

Shrinking: the share of classes, fields and methods R8 is allowed to drop when unused.
Optimization: the share it may rewrite, for example by inlining or merging classes.
Obfuscation: the share it may rename to short identifiers.

Google says missing these "can affect an app's visibility and publishing capabilities on Google Play". A single-digit score doesn't mean R8 did a poor job. It means R8 never ran, or your keep rules left it almost nothing to touch.

Why a "JavaScript app" has 10 MB of DEX

Your Hermes bundle or AOT-compiled Dart isn't DEX. But the framework runtime, native modules, Firebase, ad SDKs, analytics and billing libraries are all Java or Kotlin bytecode, and that adds up fast. Whether R8 runs depends on the template you started from:

Stack	R8 in release by default	Where to change it
React Native CLI	Off (`enableProguardInReleaseBuilds = false`)	`android/app/build.gradle`
Expo SDK 57 and earlier	Off	`expo-build-properties`
Expo SDK 58	On	`android/gradle.properties`
Flutter	Always on, optimize preset	`android/app/proguard-rules.pro`
Capacitor	Off, uses `proguard-android.txt`	`android/app/build.gradle`
.NET for Android / MAUI	Runs with `-dontobfuscate` hardcoded	Tracked upstream (dotnet/android #12535)

First, check whether the rule even applies to you. In Play Console go to Test and release > App bundle explorer, select your latest production bundle, and read the DEX size plus the three percentages. Under 10 MB? Not urgent yet, though still worth doing.

Turning R8 on, per stack

React Native CLI and Capacitor use the same release block in android/app/build.gradle:

def enableProguardInReleaseBuilds = true

android {
  buildTypes {
    release {
      minifyEnabled enableProguardInReleaseBuilds
      shrinkResources enableProguardInReleaseBuilds
      proguardFiles getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro"
    }
  }
}

Two gotchas: use proguard-android-optimize.txt, not proguard-android.txt (the old file contains -dontoptimize, and Android Gradle plugin 9 no longer supports it), and remove any leftover android.enableR8.fullMode=false from gradle.properties. On Capacitor, resist a blanket -keep class com.getcapacitor.** { *; }.

Expo SDK 57 and earlier: set it in app.json, then npx expo prebuild or rebuild on EAS. extraProguardRules is appended to proguard-rules.pro, so it survives a clean prebuild.

{
  "expo": {
    "plugins": [
      ["expo-build-properties", {
        "android": {
          "enableMinifyInReleaseBuilds": true,
          "enableShrinkResourcesInReleaseBuilds": true,
          "extraProguardRules": "-keep class com.example.reflected.Model { *; }"
        }
      }]
    ]
  }
}

On SDK 58 R8 is already on. If a release build breaks after upgrading, fix the keep rules instead of opting out, because opting out puts you back under the threshold.

Flutter already runs R8, so a flagged Flutter app usually has a plugin or custom rule keeping whole packages. Dart's --obfuscate flag doesn't help here: it renames Dart symbols, not DEX.

Native Android / KMP: confirm isMinifyEnabled in the app module. AGP 9.3+ also adds an optimization block per build type, with keep rules allowed in src/<variant>/keepRules/*.keep.

Avoiding "works in debug, crashes in release"

R8 only touches release builds, so a debug build or dev client proves nothing. Run a real release variant on a physical device:

npx react-native run-android --mode release   # React Native CLI
npx expo run:android --variant release        # Expo, local
./gradlew bundleRelease                       # any Android project

Typical symptoms when R8 removes or renames something accessed by name at runtime: ClassNotFoundException at startup, NoSuchFieldException/NoSuchMethodException, or model fields that quietly vanish after JSON serialization. Expo issue #49779 is a good example: Calendar.createEventAsync() failed only in minified SDK 57 builds.

Rules for keep rules that fix crashes without sinking your scores:

Read app/build/outputs/mapping/release/missing_rules.txt first; R8 writes what it needs there.
Keep a class, not a package: -keep class com.example.api.UserDto { *; }, never com.example.**.
Prefer -keepclassmembers when a JSON parser only needs the fields.
Check whether the library already ships consumer rules before adding your own.
Upgrade the crashing library; a missing rule is a library bug that may already be fixed.

Still flagged with R8 on? Run the analyzer

A broad keep rule is the usual culprit, and Google's R8 Configuration Analyzer ranks rules by how much code each blocks. On AGP 9.3+:

./gradlew :app:analyzeReleaseR8Config
# report: app/build/reports/r8/r8-config-analyzer-release.html

It also flags subsumed rules and rules matching nothing. Third-party SDKs are often to blame: one open issue on Google's ads mediation repo measured adapter consumer rules each blocking 5% to 10.6% of an app's live code.

Last thing: Play deobfuscates its own crash and ANR reports from the bundle (AGP 4.1+), but Sentry, Crashlytics and Bugsnag each need the mapping file uploaded through their own plugin or CLI. Verify that step in CI.

Key takeaways

Each of shrinking, optimization and obfuscation must hit 25% by February 2027 if your DEX exceeds 10 MB (50 MB for games).
React Native CLI, Capacitor and Expo SDK 57 and earlier ship with R8 off; Flutter and Expo SDK 58 have it on.
Use proguard-android-optimize.txt and test a real release build on a device.
Narrow, class-level keep rules beat package-wide ones; the R8 Configuration Analyzer shows which rules cost you most.
Make sure your crash reporter gets the mapping file for every release.

The original has the full FAQ and sources in this guide to fixing the Play Console DEX code optimization warning with R8, and once your build is in shape you can list it on the AppRanker app leaderboard for Android and iOS apps.

What was the first thing that broke when you switched R8 on in your React Native, Expo or Flutter release build?

MCP Server in Node.js: What the v2 TypeScript SDK Changes

ExtensionBooster — Thu, 05 Nov 2026 09:16:13 +0000

Originally published on Extenify.

If you build an MCP server in Node.js today, most tutorials you find will still show the v1 @modelcontextprotocol/sdk package and server.tool(), and both are now behind the curve. Version 2 of the official TypeScript SDK is the stable line, it implements the 2026-07-28 MCP spec, and it changes how you structure a server. Here is what changed, a minimal stateless server, and the security checks worth adding before you connect Claude.

What actually changed in 2026

The 2026-07-28 spec revision is the biggest shift since remote servers appeared. The parts that affect your code:

No more sessions. Protocol-level sessions and the Mcp-Session-Id header are gone from Streamable HTTP.
No initialize handshake. Each request carries its protocol version and client capabilities in _meta, and servers must implement server/discover.
One stream for updates. subscriptions/listen replaces the HTTP GET endpoint and resource subscriptions.
Deprecations. Roots, Sampling, Logging and the old HTTP+SSE transport are deprecated. Dynamic Client Registration gives way to Client ID Metadata Documents for OAuth.

The SDK follows suit. The single package is split into @modelcontextprotocol/server, @modelcontextprotocol/client and adapters such as @modelcontextprotocol/node. You need Node.js 20+ and Zod 4 (Zod 3 is not supported), and server.tool() is replaced by registerTool() with a config object.

The upgrade trap

Bumping the package version does not make your server speak the new protocol. According to the v1-to-v2 migration guide, a server that still calls server.connect(new StdioServerTransport()) serves 2025-era clients only. You need createMcpHandler() (HTTP) or serveStdio() (local) to serve both old and new clients.

This matters more than it sounds, because clients lag behind specs. In the original article's tests, both the v2 and v1 clients still opened with an initialize request for protocol version 2025-11-25. Use the handler that speaks both and you stop caring which version a client picks. Existing projects can start from the official codemod:

npx @modelcontextprotocol/codemod@latest v1-to-v2 .

A minimal stateless server

createMcpHandler() takes a factory and calls it once per HTTP request, so nothing lives between requests and the endpoint scales horizontally. Here is the shape of it with a single read-only tool:

import { createServer } from 'node:http';
import { createMcpHandler, McpServer } from '@modelcontextprotocol/server';
import { hostHeaderValidation, originValidation, toNodeHandler } from '@modelcontextprotocol/node';
import * as z from 'zod/v4';

function buildServer({ authInfo }) {
  const server = new McpServer({ name: 'my-stats', version: '1.0.0' });
  server.registerTool('get_summary', {
    description: 'Latest totals for one project owned by the caller.',
    inputSchema: z.object({ projectId: z.string().min(1) }),
    annotations: { readOnlyHint: true, openWorldHint: false },
  }, async ({ projectId }) => {
    const data = await loadSummary(authInfo.extra.userId, projectId); // your DB call
    return { content: [{ type: 'text', text: JSON.stringify(data) }], structuredContent: data };
  });
  return server;
}

const mcp = toNodeHandler(createMcpHandler(buildServer));
const hosts = ['localhost', '127.0.0.1'];
const checkHost = hostHeaderValidation(hosts);
const checkOrigin = originValidation(hosts);

createServer(async (req, res) => {
  if (!checkHost(req, res) || !checkOrigin(req, res)) return;
  const user = await verifyBearer(req.headers.authorization); // your token check
  if (!user) return res.writeHead(401, { 'WWW-Authenticate': 'Bearer' }).end();
  req.auth = { token: user.token, clientId: 'pat', scopes: ['read'], extra: { userId: user.id } };
  await mcp(req, res);
}).listen(3100, '127.0.0.1');

A few details that are easy to miss:

The Zod schema is the contract. The SDK turns it into JSON Schema for the client and rejects bad arguments before your handler runs, with an error the model can read.
req.auth is how the caller reaches your tools. toNodeHandler() forwards it as authInfo. The SDK never verifies tokens, so that must happen first.
Keep the factory cheap. Create database clients once at module scope, not inside buildServer.
Return errors as results. An isError: true result with a plain-language message ("call list_projects to see valid IDs") helps the model recover instead of failing.

For a personal tool, serveStdio() from @modelcontextprotocol/server/stdio accepts the same factory, so HTTP and stdio can share one set of tool definitions.

Security checks a model-driven API needs

An MCP server is an API that a model drives, which adds a few risks on top of the usual ones:

Validate Host and Origin. The spec says servers must validate Origin to prevent DNS rebinding and should bind to localhost when local. The @modelcontextprotocol/node guards return 403 for an unknown Host or Origin and let Origin-less (non-browser) requests through.
Scope every query to the caller. Never accept a user ID as a tool argument, because a model can be talked into passing someone else's.
Hash tokens at rest and keep them out of URLs.
Treat text output as untrusted. If a tool returns user-written text such as reviews, "ignore previous instructions" reaches the model verbatim. Keep those tools read-only and away from tools that write.
Pick auth for the client. A bearer token works for Claude Code and scripts. For per-user data in claude.ai you need OAuth 2.0, and sign-in starts only when your server answers 401 with a WWW-Authenticate header.

Design tools for the model, not for humans

Return computed answers ("+1.5% in 7 days") rather than raw rows the model has to subtract.
Stay within client limits: about 150,000 characters per tool result and a 240-second timeout on claude.ai and Claude Desktop, and 25,000 tokens by default in Claude Code (MAX_MCP_OUTPUT_TOKENS).
Write descriptions that say when to call the tool and what the arguments look like.
Register tools in a stable order. The new spec asks for a deterministic tools/list order to help client and prompt caching.

Key takeaways

Use @modelcontextprotocol/server plus an adapter for new servers; v2 needs Node.js 20+ and Zod 4.
Upgrading the package alone keeps you on the 2025 protocol. Use createMcpHandler() or serveStdio() to serve both generations of clients.
Stateless per-request servers are the default now; sessions are gone from the spec.
Validate Host and Origin, scope every query to the authenticated user, and mark data tools readOnlyHint: true.
Keep results small and descriptions model-friendly.

The original post walks through the full build, including a MongoDB data layer, three analytics tools, end-to-end tests with both SDK clients and connecting to Claude: read the complete guide to building an MCP server in Node.js with the v2 SDK. If the data you want to expose is browser extension stats, Extenify tracks daily users, ratings and versions across Chrome, Edge and Firefox stores.

Have you moved an MCP server to the v2 SDK yet, and did the stateless model break anything that relied on sessions?

Extension Not in Chrome Web Store Search? 9 Causes to Check

ExtensionBooster — Thu, 05 Nov 2026 05:36:51 +0000

Originally published on ExtensionBooster.

Your extension not showing in Chrome Web Store search is a confusing bug to chase: the dashboard says it's live and the listing URL loads, yet typing its name into the store returns nothing. Behind that one symptom sit two separate problems, and the fix depends on which one you have. Here's a quick way to tell them apart, plus the nine causes worth checking.

Step zero: hidden, or just ranked low?

Open a signed-out Chrome profile or a Guest window first, so your own account doesn't skew what you see. Then try:

A search for your exact extension name.
The same exact-name search from a signed-in adult Google account.
A search for your main keyword (say, "tab manager").
Your listing URL opened directly.

Result	Diagnosis	Causes to check
Listing URL fails or shows a notice	Not published, or taken down	2, 7
URL works, exact name returns nothing	Hidden from that searcher	1, 3, 4, 5, 6
Exact name works, keyword doesn't	Indexed, but ranks low	8, 9

Causes 1–4: status and distribution settings

1. You published a few hours ago. Google's discovery docs say a new extension may take a few hours to be indexed. Give it a day before digging in. Don't resubmit to "nudge" the index; a new submission goes back into review, which can take days.

2. It isn't live yet. Check the dashboard status:

Pending review: most reviews finish in a few days, some take a few weeks.
Staged: if you turned off automatic publishing, the item waits for you. You get 30 days to publish before it reverts to a draft and has to be reviewed again.
Rejected: users get no notice, so the rejection email and the dashboard are your only signals.

3. Visibility is Unlisted or Private. This one fools people because Unlisted items install fine from a direct link. Unlisted creates no store listing at all, so it never appears in search. Switch it to Public in the Distribution tab.

4. The searcher's country isn't in your Regions. Published items only show in search for the regions you selected. A limited launch or a test setting you forgot to revert is the usual culprit. Select all regions, then clear only the ones you really want to exclude.

Causes 5–7: language, maturity, and takedowns

5. Your listing language doesn't match the query. Someone searching in Spanish is matched against your English text. Add localized listings (name, summary, description) for your biggest non-English markets.

6. The Mature flag is on. Mature items don't appear in search for signed-out users, only for signed-in adult accounts. If it shows up signed in but not signed out, check this flag under Additional fields in the Store listing tab.

7. It was taken down, or it's still Manifest V2. Taken-down items vanish from search, collections and category pages. And as of August 31, 2026, all remaining MV2 extensions were removed from the store. If yours was still on MV2, migrating to Manifest V3 and resubmitting is the only way back.

Causes 8–9: it's indexed, it just ranks low

8. Low ranking for your keyword. This is the most common answer. Google says search ranking draws on:

the item name
description relevance
popularity and user experience
number of ratings and average rating
usage stats, such as downloads vs. uninstalls over time

A brand-new listing with zero ratings is up against items with thousands of users for the same term. What helps, roughly by impact:

A name and summary (132 characters max) that say what the extension does, not just the brand.
A description built around one use case, with the keyword used naturally in the opening lines.
A steady flow of ratings from real users.
Onboarding that stops installs from turning into quick uninstalls.
Traffic from outside the store, which Google itself suggests to help an item rise.

9. Keyword stuffing or duplicate listings. Repetitive or irrelevant keywords can get an item suspended, and the spam policy bans multiple extensions with duplicate functionality. Strip keyword lists and competitor names, and merge near-copies into one listing.

Quick checklist

[ ] Status = Published (not Pending, Staged or Rejected)
[ ] Visibility = Public
[ ] Regions include the searcher's country
[ ] Mature flag only if content really is mature
[ ] No takedown email; item is Manifest V3
[ ] A few hours (ideally a day) since publishing
[ ] Name + summary describe the core function
[ ] Keyword in the first lines of the description
[ ] No keyword lists or duplicate listings
[ ] Real ratings coming in, early uninstalls kept low

Key takeaways

Run an exact-name search signed out before anything else; it separates "hidden" from "ranked low".
Hidden items are a dashboard problem: status, visibility, regions, the Mature flag or a takedown.
MV2 extensions were removed from the store on August 31, 2026.
Ranking draws on name, description relevance, ratings count and average, and installs vs. uninstalls.
Keyword stuffing and duplicate listings can get you suspended, not boosted.

The original post has the exact Google documentation quotes and an FAQ: why your extension isn't showing in Chrome Web Store search, with 9 fixes. For more on ratings and listing growth, see the ExtensionBooster guides for Chrome extension developers.

Have you ever had a live extension that refused to show up in store search? Which of these causes turned out to be the culprit for you?

Product Hunt Alternatives for Extensions: 7 Sites Compared

ExtensionBooster — Thu, 05 Nov 2026 02:09:29 +0000

Originally published on ExtensionLaunch.

If you're hunting for Product Hunt alternatives for a browser extension, you've probably hit the same walls: your launch might not get featured, a new account has to wait a week before it can post, and you can't relaunch the same product for two months. Here's a comparison of seven other launch platforms, what each one costs, and a simple way to stack them over a month.

Why Product Hunt alone isn't enough for an extension

Product Hunt is still the best-known launch site, but its rules shape who wins:

Featuring isn't guaranteed, and the guidelines say decisions are generally final.
New accounts wait a week before posting.
You need a two-month gap (and a significant update) to relaunch.
The audience is broad. SaaS, AI and hardware all compete for the same front page, and makers who already have a following do best.

A smaller platform that's focused on your niche often sends fewer visitors, but more of them actually install.

The 7 alternatives at a glance

Details as checked on October 30, 2026:

Platform	Best for	Free path	Paid path
ExtensionLaunch	Extensions and mobile apps	Daily quota of free listings	One-time plans
Hacker News (Show HN)	Developer tools	Free, no queue	None
Uneed	Any digital tool	Waiting line plus vote threshold	$14.99 fast-track / $39.99 pick your date
Peerlist Launchpad	Makers with a dev or design profile	Free with a verified profile	—
BetaList	Startups with their own website	None found	Plan chosen at submission
DevHunt	Developer tools only	Free listing	$19 chosen week / $49 boosted
Tiny Startups	Small, bootstrapped products	Hand-approved	£69 listing

Most platforms work the same way: a free path with a catch (a long queue, a vote threshold or a verified profile) and a paid path that skips it.

The catches worth knowing before you submit

Show HN needs something people can try right away, ideally without a signup or email. Landing pages, waitlists and newsletters don't qualify. Expect comments on broad permissions or required accounts, and never ask friends to upvote.

Uneed's free line assigns you a date at least 30 days out, and when this was checked the next free date was May 2027. You need 10 upvotes to stay published and 20 for a do-follow link. If you fall below 10, your launch goes back to your dashboard and can't rejoin the free line. The $14.99 fast-track gets you a date about two weeks out.

BetaList won't accept an app store page as your product URL, so you need a landing page on your own domain first. It features about 20 startups a day to a newsletter of 70,000+ subscribers, but it won't feature the same site twice within 12 months. You get one shot.

DevHunt is only for dev tools: APIs, SDKs, frameworks, IDE add-ons, testing and monitoring. Voting needs a GitHub login, and launches go out in a Tuesday newsletter.

Peerlist launches weekly on Mondays and needs a verified profile and a 100% complete project. It works best if you're already active there.

Tiny Startups suits extensions for founders, marketers and small teams. Its newsletter reaches 25,000+ subscribers.

(Disclosure carried over from the original: the author of the source guide runs ExtensionLaunch, a launch directory that builds your listing from a store link or ID.)

How to stagger launches without burning out

Here's a reusable method:

Match the platform to the user. Dev tools go to Show HN and DevHunt. Consumer extensions go to extension directories and broad discovery sites.
Write one product brief and reuse it: name, 60-character tagline, 160-character summary, description, category, pricing, logo, screenshots and demo video.
Space launches a week or more apart, so you have time to answer every comment.
Tag every link with its own utm_source. The Chrome Web Store's Google Analytics integration records installs, so you can compare platforms directly.
Judge by week-one retention, not votes. A hundred upvotes from other makers is worth less than twenty installs that stick.

https://chromewebstore.google.com/detail/your-id?utm_source=uneed&utm_medium=launch
https://chromewebstore.google.com/detail/your-id?utm_source=peerlist&utm_medium=launch

A sample four-week plan for a consumer extension:

Week 1: extension directory, once the store listing is public
Week 2: Product Hunt
Week 3: a paid Uneed date
Week 4: Peerlist, the following Monday

For a dev tool, swap Show HN and DevHunt into that plan.

Key takeaways

Product Hunt still has a place: it's free, it's big, and you keep a public page even if you aren't featured. Treat it as one date in a sequence.
Launch where your users already browse, not where the biggest crowd is.
Read the fine print: vote thresholds, custom-domain rules and one-time-only policies decide whether a launch is worth your time.
Use one brief, one UTM tag per platform, and retention as the metric.

The full guide has per-platform details and an FAQ: Product Hunt alternatives for launching a browser extension. If your extension's store listing is already live, you can also list it in the ExtensionLaunch extension directory as your first launch date.

Besides Product Hunt, which launch platform sent you the most installs that actually stuck, and roughly how many?

Android developer verification: keep your APK installable

ExtensionBooster — Wed, 04 Nov 2026 13:51:05 +0000

Originally published on AppRanker.

Android developer verification has been enforced since September 30, 2026, and the failure mode is quiet: your build is fine, your CI is green, but a user on a certified phone in Brazil, Indonesia, Singapore or Thailand taps your APK and the normal install path simply refuses it. Google plans to roll the same rule out to every certified device in 2027. Below is what the rule actually checks, which commands get you the certificate data it asks for, and a checklist you can finish in one sitting.

What the check looks at

There are two things Android wants to see before it installs your app the normal way:

A verified developer identity. The account behind the app has passed ID verification (government ID for individuals; organizations also need a D-U-N-S number).
A registered package. Each package name is tied to that account, along with the signing key or keys that sign it.

If both are true, the app counts as "registered" and installs as usual. If either is missing, new installs through the standard flow are blocked in the enforcement regions. Google's stated motivation is malware: its March 2026 announcement says sideloaded sources carry over 90 times more malware than Google Play.

Key dates:

When	What
March 2026	Verification opens to all developers in Play Console and the Android Developer Console
June 2026	Google confirms September 30 and the four launch countries
August 2026	Developer APIs, limited distribution accounts and the user "advanced flow" ship
September 30, 2026	Enforcement begins in Brazil, Indonesia, Singapore, Thailand
2027	Planned global rollout to all certified devices

The first phase covers Google Play plus HONOR App Market, OPPO App Market, Samsung Galaxy Store, Palm Store, V-Appstore and GetApps.

How much work you have depends on where you ship

Play-only apps. Google says more than 99% of Play apps were registered automatically from details you already gave Play, and new apps get their package registered when you create them. Your job is a quick audit: check the Play Console Home page for any app flagged as needing registration, confirm your details under Settings > Developer account, and fix anything left over. Play Console's guidance warns that unregistered apps risk removal from Google Play globally, so do not skip this.

APKs distributed elsewhere (your website, partner stores, enterprise channels, F-Droid-style repos). This is where the real work is. With a Play Console account, you can register off-Play apps from inside Play Console. Without one, create an Android Developer Console account, verify your identity and register packages there. A full account is a one-time $25. If you are an organization without a D-U-N-S number, request it today: it can take up to 28 days.

Students and hobbyists. A free limited distribution account needs no government ID but only reaches up to 20 devices. Good for a class project or a closed test group, not for a public release.

Getting the certificate data with keytool and apksigner

Registration works per package name. For a new package you supply the public key certificate. For an existing package with installs, you prove key ownership by uploading an APK signed with the matching private key.

Print fingerprints and export the certificate from your keystore (swap in your own path and alias):

# SHA-256 and other fingerprints for the signing key
keytool -list -v -keystore release.jks -alias release

# Public key certificate as PEM, for registering a new package
keytool -exportcert -rfc -keystore release.jks -alias release -file release-cert.pem

Before registering, confirm the key in your keystore is the one your users actually have installed:

apksigner verify --print-certs app-release.apk

If the fingerprints disagree, stop. The usual causes are an old key, a key held by a build service, or a release someone else signed. Once they match, sign the proof APK the console asks for:

apksigner sign --ks release.jks --ks-key-alias release \
  --out signed-proof.apk unsigned-proof.apk

In Play Console the flow is: Android developer verification page > Package names tab > Register package name. You get an email when it completes.

A few edge cases worth knowing: if one package name has been signed by several keys (forks, repackaged builds), the key behind more than 50% of known installs gets priority. With no majority, any key with at least 50 installs can register directly; smaller ones go through a request to Google. Agencies handling many packages can automate this with the Android Developer ID Status API and the Android Developer Console API.

What still works without registration

ADB installs are exempt, so your local dev and test loop does not change.
The advanced flow lets power users allow unverified apps: enable developer mode, confirm no one is pressuring them, restart, wait a day, re-authenticate with biometrics or PIN, then allow unverified installs for seven days or indefinitely, with a warning on every install.

That second path is a safety valve, not a distribution channel. Hardly any regular user will wait 24 hours to install your app. Treat registration as required.

The checklist

[ ] Identity verified (Play Console Settings > Developer account, or Android Developer Console)
[ ] D-U-N-S number on file if you publish as an organization
[ ] Chosen the right account type: free limited (20 devices) or full ($25)
[ ] Listed every package you distribute, on and off Play, including old downloads
[ ] Checked each package's registration status
[ ] Exported the certificate (new) or prepared a signed proof APK (existing)
[ ] Matched fingerprints with apksigner verify --print-certs
[ ] Removed download links for packages you no longer maintain
[ ] Documented which key signs each package and who controls it
[ ] Added "register package before announcing" to your release checklist
[ ] Told sideload users in the four countries their updates will keep working

Key takeaways

Enforcement is live in four countries now and is planned globally for 2027.
Play-only developers are mostly registered already, but should still audit Play Console.
Off-Play APKs need explicit registration; start D-U-N-S early because it can take 28 days.
Use keytool and apksigner to make sure the key you register is the key users already trust.
ADB stays exempt, so testing is unaffected.

The original post has the full timeline, FAQ and sources in its Android developer verification checklist for app makers. Once your app is installable again, it still has to be found, and AppRanker's app leaderboard links each listing straight to its store page.

If you ship APKs outside Google Play, what was the hardest part of registering your packages: the identity step, the D-U-N-S wait, or tracking down which key signed your old releases?

Gemini API logging is on by default now: opt out in Node.js

ExtensionBooster — Wed, 04 Nov 2026 09:15:18 +0000

Originally published on Extenify.

Gemini API logging flipped to "on" for every paid project created on or after October 26, 2026, and nothing in your code or your error logs will tell you. From that date, generateContent calls in new projects keep the full prompt, the response and earlier turns for up to 55 days. Here is what gets stored, who can read it, and the few lines of Node.js that put the decision back in your hands.

What actually changed

Google's changelog says new paid-tier projects now store Generate Content requests by default, the same way the Interactions API always has. Projects created before October 26 keep whatever they had, which is usually off.

API	Project created before Oct 26, 2026	Created on or after Oct 26, 2026
Generate Content	Off unless someone enabled it	On
Interactions API	On	On

The scope is wider than the name suggests:

Batch and streaming calls (batchGenerateContent, streamGenerateContent) are logged too.
Calls through the OpenAI-compatible endpoint are logged.
Only paid projects have logs. Free-tier keys have no logs but fall under different (looser) data terms.

A few inputs are never logged: Imagen, Veo, Gemini embedding models, the Robotics model, requests containing video, GIFs or PDFs, and public preview agents. So an embeddings pipeline is safe; a review classifier is not.

What a log entry holds, and for how long

This is not a token counter. Opening an entry in Google AI Studio's Logs page shows the whole payload: prompt, response and prior conversation context. Anyone with access to the project can read it.

Retention works like this:

55 days by default, after which entries are marked for deletion.
Owners can shorten it to 7, 14 or 28 days.
Entries you save into a dataset never expire until you delete the dataset.

On the paid tier, logged data is not used for training. That changes only if you share a dataset with Google or join the invite-only Contributor Tier, both of which move the data under the Unpaid Services terms, where human reviewers may read it.

One thing opting out does not touch: Google's separate abuse monitoring still keeps prompts and outputs for 55 days, used only for policy enforcement.

Opt out per request in Node.js

A request-level setting overrides the project setting, so the most dependable fix lives in code. In @google/genai (2.31.0 or later), store sits inside config. Over REST it is a top-level store field next to contents.

The trap is scattered call sites. Wrap the SDK once and make "don't store" the default:

// llm/gemini.js - the only file allowed to import @google/genai
import { GoogleGenAI } from '@google/genai';

const client = new GoogleGenAI({}); // uses GEMINI_API_KEY

export function askGemini(model, contents, { config = {}, keepLog = false } = {}) {
  // store is set last, so a stray config.store can't re-enable logging
  return client.models.generateContent({
    model,
    contents,
    config: { ...config, store: keepLog },
  });
}

Then guard it in CI:

# fail the build if anything else imports the SDK directly
! grep -rl "@google/genai" src --include=*.js | grep -v "llm/gemini.js"

Pin the minimum SDK version in package.json. Older versions silently ignore the setting.

Interactions API caveat: it stores requests on purpose so you can continue a conversation with previous_interaction_id. Its store flag is a top-level argument, and turning it off means you must send the full history yourself on each turn.

Belt and braces: the project switch

In AI Studio, open Logs, pick the project that owns your production key and check the Settings panel. It has separate toggles for Generate Content and Interactions. Turn Generate Content off unless you use it deliberately.

You want both layers:

The request flag protects you from the project someone creates next month with the new default.
The project switch protects you from a call site that forgot the flag, and covers OpenAI-compatible calls where the docs show no per-request option.

Repeat the check for every project that holds a production key. New features and new environments often get fresh projects, which is exactly where the new default applies.

If you keep logging on

Logs are useful: real production prompts make better evaluation sets than invented ones. If you keep them, keep them tidy:

Cut retention to 7 or 14 days.
Strip emails, phone numbers and order IDs before sending. A classifier rarely needs them.
Treat datasets as permanent copies and delete them after the evaluation.
Don't share datasets containing user content with Google.
Limit who can open the project.

This matters most if you pipe user text through Gemini: store reviews, support tickets, or page content from a browser extension's AI feature. Make sure your privacy policy and store data disclosures still describe what your backend really does.

For comparison, OpenAI's Responses API also keeps application state for 30 days by default and accepts store: false. If you abstract several providers behind one client, make "no storage" the default there too.

Key takeaways

Paid Gemini projects created on or after Oct 26, 2026 log full Generate Content requests by default; older projects are unchanged.
Logs live up to 55 days; datasets built from them never expire.
Send store: false (SDK 2.31.0+) through a single wrapper, and switch off project-level logging too.
Opting out doesn't stop Google's separate 55-day abuse-monitoring retention.
If you keep logs, shorten retention and redact personal data first.

The original post has the full checklist, FAQ and the exact policy quotes in the complete guide to Gemini API logging and how to opt out. If store reviews are the text you feed into an LLM, Extenify's app review and extension analytics dashboard collects them daily so you only send the ones that matter.

Did your team find out about this default from the changelog, or from spotting full prompts in AI Studio's Logs page?