Suppose a reviewer asks for shared projects in your solo task app. You understand why they want it, but collaboration is not on your roadmap. Another reviewer asks for an Android feature that already exists in your iOS version. Both deserve an accurate answer, and neither should receive an invented release date.
A useful feature-request reply has three parts: acknowledge the specific need, state what is true today, and offer a relevant next step if one exists. The examples below are hypothetical wording to adapt, not customer quotes.
Check which app and platform the request concerns
When you maintain several apps, similar requests can mean different things. “Add export” might refer to a PDF report in a finance app or a text file in a journal. Before drafting, confirm the product, store, available version details, and any existing response.
Then check the current feature set and roadmap. Separate three states: not planned, being considered, and actively being built. Do not describe an idea as “coming soon” simply because it appears in an internal backlog. If a teammate owns the decision, ask them before making a public commitment.
If the feature is not planned, say so kindly
You can appreciate a suggestion without agreeing to build it. For the hypothetical task app, a reply could be:
Thanks for explaining how shared projects would help your team. The app currently focuses on personal task planning, and shared projects aren't planned. I appreciate knowing what you were hoping to do.
This gives the reviewer an answer they can use. It avoids both a dismissive “no” and a vague promise to “pass it along.” If you actually record the suggestion for later consideration, you can say that. Recording feedback is still different from committing to a feature.
If you are exploring the idea, explain the uncertainty
Use this version only when you are genuinely considering the request:
Thanks for the suggestion. We're considering CSV export, but haven't committed to building it or set a release date. Is your main goal a backup, or moving your data into another tool?
A specific question can reveal the underlying need. Ask only for information that would help you make a decision. If answering requires private account details or sample files, direct the person to your actual support channel instead of requesting them in a public review.
If there is a workaround, give the exact steps
For a hypothetical journal with an existing plain-text sharing option, you might write:
PDF export isn't available. You can share an entry as plain text by opening the entry and choosing Share, then Copy Text. That won't preserve the page layout, but may help if you need the words in another app.
Check every step against the current product before using it. State the limitation so the workaround does not sound equivalent to the requested feature. If there is no useful alternative, omit this part rather than inventing one.
Keep the public reply brief and the product notes separate
In your own issue tracker, record the app, platform, review reference, requested outcome, and current decision. Group related requests there if helpful. Do not make the public response a debate about implementation complexity or your entire roadmap.
Apple's response guidance recommends respectful, specific replies without personal information or marketing language. Google's ratings and reviews help explains its review and reply tools. Neither a polite response nor a new feature guarantees that a reviewer will change their rating.
Review an AI draft for accidental promises
ReviewTower's paid plans include AI Reply and Polish. You can generate or type a draft, then use Polish to supply confirmed facts and instructions. For example: “Shared projects are not planned. Acknowledge the team use case, do not suggest a release date, and keep the reply short.”
Read the result before sending. Remove unsupported phrases such as “we're working on it,” “in the next update,” or “we'll let you know.” For plan details, see current pricing.
Choose one unanswered feature request today. Verify its status, write the shortest honest answer that addresses the need, and keep any future product decision in your own tracking system.