Turn App Reviews into Linear Issues: A Bug-Triage Workflow

• Engineers live in Linear, not in store consoles. If bug reports only exist in App Store Connect and Play Console, they depend on someone remembering to copy them over.
• Reviews catch problems your telemetry misses. Crash reporting shows crashes; reviews also surface broken flows, confusing UI, login loops and payment failures that never throw an exception.
• Release regressions show up fast. A cluster of new 1-star reviews mentioning the same screen right after a release is a strong signal.
• It creates a record you can reply from. When the issue is linked to the review, you know whom to tell when it is fixed.

The goal is not to file every review as an issue. It is to make sure the reviews that describe a defect land in the place where defects get prioritized.

A good starting filter combines a rating ceiling with bug-related keywords. Reviews rated 4–5 rarely describe blocking bugs, and keywords cut out general complaints ("too expensive", "boring") that are not engineering work.

Tips for keyword lists:

• Use short stems: a contains-match on "crash" also matches "crashes" and "crashing".
• Avoid very generic words like "app" or "issue"; they match almost everything.
• Add translations if a large share of your reviews are in other languages.
• Revisit the list after a month. Look at what got filed but was not a bug, and what bug reports were missed.

Review Expert syncs App Store and Google Play reviews (history first, then roughly every 5 minutes) and can create Linear issues from matching reviews. The Linear destination is included on Starter and above.

1. Connect your apps under Apps & Businesses.
2. In the Review Expert dashboard, open Automation, choose Manage destinations (or Add destination), click Connect next to Linear and approve access.
3. Set the filters: a maximum rating (for example 3) and keywords. Keywords match when the review text contains any of them, ignoring case. You can also set a minimum rating.
4. Add more destinations for separate keyword groups if you want them handled differently.

Each matching review creates its own issue with the review details. See the Linear integration page for more.

A little structure on the Linear side keeps review issues from becoming a junk drawer:

• Labels: create a label such as source:app-review, plus platform labels (ios, android). Linear's labels docs cover label groups if you want platform as a group.
• Triage: if your team uses Linear's Triage inbox, review-sourced issues are a natural fit: someone accepts, merges or declines each one before it reaches the backlog.
• Templates: an issue template for confirmed review bugs keeps the important fields consistent: platform, app version, device or OS (if the reviewer mentioned it), steps to reproduce, and a link back to the review.

A useful template body:

Source: App Store / Google Play review
Rating: ★★☆☆☆
App version / OS: (from review or console)
What the user reports:
Reproduced? yes / no / not yet
Steps to reproduce:
Linked reviews: (add each duplicate review link here)
Reply after fix: [ ]

Pick a rhythm and an owner. A pattern that works for many small teams:

• Daily (10 minutes): the triage owner scans new review issues, merges duplicates, closes non-bugs and assigns anything urgent.
• After every release (for a few days): check more often. New 1–3 star reviews mentioning the same area are the earliest regression signal you will get from users.
• Weekly: look at which review issues are still open, which got fixed, and which reviewers are waiting for a reply.

Rotate the owner if you can. Reading raw user reports regularly is valuable context for everyone on the team.

Popular bugs generate many reviews, and each matching review creates a separate issue. Deduplication is a manual triage step, and it is worth doing well:

1. Pick one canonical issue for the bug (usually the one with the clearest report).
2. Mark the others as duplicates of it using Linear's duplicate handling, so they close but stay linked.
3. Keep the list of review links on the canonical issue. The count of linked reviews is a rough, honest signal of user impact when you prioritize.

Automatic grouping of reviews by topic is not something Review Expert does today; topic extraction is on the roadmap as a coming-soon feature.

This is the step most teams skip, and it is the one reviewers see. When the fix is live in a store build:

1. Open each review linked to the canonical issue.
2. Reply, or update your earlier reply, with the version that contains the fix: "Thanks for reporting this. The crash on photo upload is fixed in version 5.4. Please update and let us know if it still happens."
3. Tick "Reply after fix" on the issue.

Both stores let you edit a reply, and Apple notes that reviewers are notified of responses and may update their review. In Review Expert you can write or update the reply and it is posted back to the App Store or Google Play. For wording, see our reply templates, and for store rules, how to respond to app reviews.

• Review issues created vs closed as real bugs: tells you whether your filters are tuned. Many non-bug closures means the keywords are too broad.
• Time from first review to fix shipped for review-sourced bugs.
• Reviewers replied to after fix: what share of linked reviews got a follow-up.
• Rating distribution and negative share over time: the Review Expert dashboard shows rating distribution, reviews over time and rating-based sentiment (1–2 stars negative), which you can compare around releases.
• Response rate and average response time, also on the dashboard.

More on how engineering teams use this in Review Expert for developers.