How to Build a Public Roadmap for Your iOS App (Templates + Tool Comparison)

If your app has any real usage, you already have the problem a public roadmap solves: someone asks "is dark mode coming?" in a support email, you answer once, and the next person asks the same question a week later because there was nowhere for them to check first. Multiply that across every requested feature and you've got a support queue full of repeat questions - and users who assume silence means "no" and leave a review instead of asking again.

A public roadmap fixes this by turning "I don't know if anyone's listening" into "I can see it's planned." This post covers what makes a roadmap actually work, three templates you can copy today, and where to build it - including the part most guides skip: what changes when your product is a mobile app instead of a website.

Why a public roadmap matters more for a mobile app

On the web, a support widget or live chat can answer "is X coming?" in real time. In a native app, that question usually shows up as an App Store review, a one-off email, or a DM - all channels where you're answering the same question repeatedly, privately, with no record the next user can find. A visible roadmap turns a per-user support cost into a one-time public answer, and it does something a private reply can't: it shows momentum. A roadmap with several "Shipped" items signals an active, listening team, even to someone who's never filed a request themselves.

What makes a good public roadmap

Four principles, before any template:

• Tie it to real requests, not internal opinion. A roadmap that only reflects what your team wants to build reads as a marketing page. A roadmap built from actual votes and submissions reads as evidence you're listening.
• Use status, not dates. "Planned" survives a slipped timeline; "Q3 2026" doesn't. Committing to dates publicly creates a promise you'll eventually have to publicly break.
• Link each item back to its source. When a status changes, the people who asked for it should be able to find out - ideally without having to remember to go check.
• Keep it visibly alive. A roadmap where nothing has moved in months is worse than no roadmap - it reads as abandoned, not just quiet. Stale beats absent; absent beats visibly stale.

Three roadmap templates you can copy

Now / Next / Later

Three columns, no dates, no fixed number of statuses. Good for a solo or small indie team shipping fast - "Now" is what's actively being built, "Next" is queued, "Later" is everything else under consideration. Low overhead, easy to keep current.

Under Review / Planned / In Progress / Shipped

Four stages, more granular. Good once you have enough incoming requests that "Later" would become a dumping ground - "Under Review" shows you triage everything, even things you haven't committed to.

Kanban-with-votes

Either of the above, but each card shows a vote count and doubles as your feature-request board rather than a separate document. This is the shape most dedicated feedback tools (Canny, WishKit, FeedbackOS) default to, because prioritization and the public roadmap end up being the same underlying data. If you're picking a board for this, our feature request tool guide covers the four stages worth checking - collect, vote, dedup, and closing the loop - beyond just the roadmap view.

Where to actually build it: DIY vs web tools vs native

DIY - a spreadsheet, a Trello board, or a public Notion page. Free, and you can have it live in an afternoon. The tradeoff: no voting mechanism, no automatic notification when a status changes, and it depends entirely on an external link that users have to already know about and remember to check.

Dedicated web feedback tools are purpose-built for roadmap plus voting, but each has its own catch we've covered in detail:

• Canny - mature web tooling, but its own highest-voted unshipped feature request is a native mobile widget; today it's a WebView.
• Userback - has a real native iOS SDK now, but feature voting is a separate paid add-on on top of per-seat pricing.
• WishKit - native roadmap and voting, but no bug-report capture alongside it.

Native, in-app. The roadmap renders as part of the app itself - no separate tool or link for users to remember, because it's already where they are.

The part most roadmap guides skip: where it actually lives

A roadmap hosted on your marketing site or a Canny board solves the "is anyone listening" problem in theory, but a user mid-session in your app isn't going to open Safari to go check it - see our breakdown of why web-based feedback widgets don't carry over to native apps for the same underlying issue. The roadmap that actually gets checked is the one that's a tap away inside the app someone already has open, not a link buried in your App Store description or a footer on your website.

What FeedbackOS's roadmap looks like

• Rendered as a native view inside the app - no separate site or tool.
• Directly tied to feature voting - the roadmap and the request board are the same data, not two things to maintain.
• Status changes are visible immediately, and the closed reply loop notifies anyone who voted or asked when something ships.

See the full pricing breakdown - $99/year founding, flat, unlimited apps and users.

Should you build your own or use a tool?

Honestly: if you're pre-launch with zero requests yet, a free public Notion page or a simple Trello board costs nothing and is enough to signal transparency from day one - don't let "which tool" become a reason to delay shipping a roadmap at all. The upgrade problem shows up once requests start arriving for real: a DIY board doesn't scale past a handful of items before it's disorganized, and it can't turn a vote into a structured prioritization signal the way a dedicated tool can. Move when the DIY version starts costing you more time to maintain than a real tool would.

FAQ