Repository navigation
Add a way to update CupertinoPageRoute.title #175129
Description
Use case
CupertinoPageRoute.title (actually CupertinoRouteTransitionMixin.title) is used to report previous title for CupertinoNavigationBar.previousPageTitle and there is no good way to update it from the same page.
Changes are propagated by using CupertinoRouteTransitionMixin.didChangePrevious which is only ever called by Navigator from push/pop/replace/etc. actions (via _flushHistoryUpdates -> _flushRouteAnnouncement).
One can probably use replace but it's explicitly forbidden to replace current route in the docs:
The old route must not be currently visible, as this method skips the animations and therefore the removal would be jarring if it was visible.
Explicitly populating CupertinoNavigationBar.previousPageTitle in a widget tree is a suboptimal solution because you almost never know what was the previous page.
An actual use case is that we have product pages that loads data after page is opened (including title, which is a shimmer animation at the beginning), so we need to propagate this new title back to Route object.
Proposal
- Make
Route.changedInternalStatetriggerRoute.didChangePreviousandRoute.didChangeNextwhen needed. - Update
CupertinoPageRoutesuch that it would be possible to passValueListenableas a title argument. - Listen to title value and trigger
changedInternalStateon updates.
Alternatively add some other hook to trigger current route update.
I believe updating Route so that it could broadcast it's state updates to neighboring routes is a more future-proof solution which would add more new possibilities for cross-route interactions.
Activity
RootHex200 commentedon Sep 14, 2025
@darshankawar i already make a PR for this
MitchellGoodwin commentedon Oct 27, 2025
@Zekfad I'm going to respond to this comment here because that thread may become locked to responses.
I see what you are saying, but I'm still not convinced, and partially I think that's because I did not explain myself poorly. When I said it might be better handled by state management, I meant by state management above the routes, not within. Similar to how localization works.
And when I was talking about the URL changing, I meant the url for the pages you were on last often doesn't change. You are right that the URL for the current page does often change.
Going further, the Navigator and Router have to be careful about what's reported between pages so that unnecessary rebuilds aren't happening. I see this change as having a relatively high risk of introducing unwanted performance hits versus the benefits it provides.
For the Cupertino back button in particular, its behavior is pretty reliant on its text being static, since it does some fairly complicated animations on a page transition. I'm not even sure what the intended behavior would be, based on native behavior. Do you have an example of an Apple app with a dynamic previous page title, that still does the full transition?
Changing
CupertinoNavigationBar.previousPageTitledynamically would side step a lot of those issues. For the previous reasons, when this is set, it turns off the fancier transitions, but that's probably for the better for your case.Zekfad commentedon Oct 30, 2025
You can update previous title via this call in native I believe
https://developer.apple.com/documentation/uikit/uinavigationitem/backbarbuttonitem
It seems that native apps works more imperatively so there is no issues of you want to change title of the page and then controller would pick it up on navigation but in flutter as you can see name of route is fixed and you can update UI but name won't really change.
As for example app, use Files: you can rename folders being inside so title is updated (it even transforms to a text field).
While I understand your concerns about performance I think it can be negated by 2 factors: adding a documentation for change state function, mentioning that it can cause rebuilds (even if it's obvious) by notifying neighbours; custom routes that would notify neighbors is a rarely used feature (I think it's only Cupertino currently). Bedsides route is not required to rebuild even if it's neighbor updates, such as material routes don't care about title changes.
If this problem could be solved without modifying framework than it's fine (I'd make my own page route and call it a day), the issue is in a fact that navigator internals are inaccessible for solving this.
I don't know of how can you solve this with state above of router without reinventing the wheel. Localization is a bad example since it rebuilds whole app all of the time, and here we're trying to minimize update to a small rebuild.
Rebuilding whole router due to a single name change is the same/worse performance than 2 adjacent routes (in a worst case, since most of the time you're updating current title while there are no route on top).
One such worst case I can imagine is this: having slow EDGE Network, you open product page and while it's still loading you open details subpage then when product loads previous title indeed updates to reflect that. But again how many times there are working navigation buttons on a loading page, so this case is extremely specific. Most of the time title updates once on load, or a few times such as folder rename from above and no real issues with performance, since no routes paying attention to next route.
One solution is to create custom state for tracking route pushes and name updates, but in my opinion this is exactly what router should do, because router is not a simple push/pop stack and you have many factors to consider such as anonymous routes, nested navigation and so on. Trying to workaround this limitation on userland seems very complicated.
The other is to incorporate previous title when you push routes, but that won't work in a declarative navigation (e.g. deep link/browser url change).
Zekfad commentedon Nov 12, 2025
I've tried to implement custom router and found out that updating Page with the same key (this is required to prevent transition animations from same to same page) but different name doesn't update route's name, so title change is not propagated to CupertinoRouteTransitionMixin.didChangePrevious.
Screenshots
Here are 2 screenshots showing that previous page in the Navigator rebuilt with the new title from updated Page object and current still has old title in
CupertinoRouteTransitionMixin._previousTitleofModalRoute.of(context).