You send a review to a stakeholder, and the reply comes back three days later: "I opened it on my phone and it asked me to download an app, so I closed it." The feedback you needed never arrives. The link was fine. The install prompt killed it.
This happens constantly with tools that were built desktop-first and bolted mobile support on later. The reviewer taps your link on their phone, hits a wall, and moves on. They are not being difficult. They are on a train, between meetings, or reviewing something on the couch after work. Nobody installs an app to leave one comment.
Why the install prompt shows up at all
Most visual feedback tools store the reviewer's session, drawing tools, and account state inside a native app or a browser extension. On desktop that is invisible because the reviewer already has the extension or is signed in. On mobile, none of that carries over. So the tool detects the phone, decides it cannot run its normal interface, and pushes the reviewer toward the App Store or Play Store instead of just showing the content.
The result is a gate. The reviewer wanted to read three notes and add one of their own. Instead they get an interstitial asking for a download, then a signup, then a permission request. Each step loses people. By the time the app is installed and the account is created, the reviewer has forgotten what they wanted to say.
The fix is not a better app. It is not needing one. A review that lives at a normal web address opens the same way a news article does: tap, read, done. That is the whole point of publishing to a plain URL instead of a walled app.
What a plain URL does that an app cannot
When you publish a review with Cobalt Capture, it gets a short public address of the form /r/<slug>. Anyone with that link opens it in whatever browser is already on their phone. Safari, Chrome, the in-app browser inside their email client, it does not matter. There is nothing to install, no extension, and no account required to read it or to leave a comment.
That changes the reviewer's experience from a chore into a glance. They see the screenshots you captured, the numbered pins pointing at the exact spots you mean, and your notes underneath each one. If they have something to add, they tap on the item and type it. The review owner marks each comment resolved later. No download stood between the reviewer and the work.
You can start the whole thing from the browser tab you already have open: capture the screen, talk or type through what you see, and publish. The link you get back is the thing you paste into a text message or an email. Speed on your side, speed on theirs.
The person who will not install anything
Some stakeholders have a company phone locked down by IT, and they physically cannot add apps to it. Others just refuse on principle. Either way, a link that opens in a browser is the only thing that reaches them. If this is a recurring fight for you, there is a full walkthrough on what to do when your reviewer will not install anything that goes deeper than the mobile case.
Making the link readable on a small screen
A link that opens is only half the job. The content has to be legible on a phone too. A few habits make a big difference.
Crop tight. When you capture a screen, drag a rectangle around the part that matters instead of sending the full frame. On a phone, a full desktop screenshot shrinks to something nobody can read. A cropped still of the one broken button fills the screen and needs no pinch-zoom. There is a short piece on why a cropped still beats an annotated live page that covers the reasoning.
Use numbered pins to carry the order. On a phone the reviewer scrolls, so a note that says "see the third field" is ambiguous. A pin labeled 3 sitting right on that field is not. Pins do the pointing so your text does not have to.
Keep each comment short and specific. "The submit button overlaps the footer at the bottom of the checkout page" reads fine on a narrow screen. A paragraph does not. If you have a lot to say, dictation through the browser keeps your notes conversational and easy to skim later.
One link, two audiences
The same published review works for more than the person on the phone. That public address is the human-facing view. The identical review is also available as a plain-text markdown file at /r/<slug>/markdown, and you can export it as a PDF or a Word document. So your client reads it on their phone, your developer reads the same notes on a laptop, and if someone hands the work to an AI coding agent, the markdown is what the agent reads. You publish once and everyone gets the format that fits their device.
If you often serve both a non-technical stakeholder and a developer from the same feedback, the pattern in one review, two links for client and developer is worth reading. And when the reviewer is genuinely non-technical, the approach in collecting client feedback without a project tool is built around exactly the no-friction opening you want on mobile.
Next time you need a stakeholder's eyes on something, capture it, publish, and send the plain link. Watch how much faster the reply comes when there is nothing to install first.