{"id":16951,"date":"2021-10-20T21:08:43","date_gmt":"2021-10-21T04:08:43","guid":{"rendered":"https:\/\/cm-edgetun.pages.dev\/en-us\/power-platform\/blog\/power-apps\/app-startscreen-a-new-declarative-alternative-to-navigate-in-app-onstart\/"},"modified":"2025-06-11T07:52:11","modified_gmt":"2025-06-11T14:52:11","slug":"app-startscreen-a-new-declarative-alternative-to-navigate-in-app-onstart","status":"publish","type":"post","link":"https:\/\/cm-edgetun.pages.dev\/en-us\/power-platform\/blog\/power-apps\/app-startscreen-a-new-declarative-alternative-to-navigate-in-app-onstart\/","title":{"rendered":"App.StartScreen: a new declarative alternative to Navigate in App.OnStart"},"content":{"rendered":"

Note: If you are here because you have an app that was created before March 2021, that is now showing an error for using Navigate in OnStart, skip ahead to the section on Older apps with new Navigate workaround.\u00a0 It is an uncommon situation and there is a simple fix.\u00a0\u00a0<\/strong><\/p>\n

Everyone loves App.OnStart<\/a>.\u00a0 It is widely used for the initialization of global variables, the prefetching of data into collections, and to determine which screen should be shown first.\u00a0 \u00a0It has been widely successful and we promote its use heavily in our performance optimization guidance.<\/p>\n

But there’s a problem with this wonderful property.\u00a0 It is imperative<\/a>.\u00a0 It is an ordered list of work that needs to be done before the first screen is shown.\u00a0 Because it is so specific about not only what<\/em> needs to be done, but also when<\/em>\u00a0that work must be done based on order, it limits the reordering and deferring optimizations that could otherwise be done.<\/p>\n

The situation became acute with our Microsoft Teams integration.\u00a0 \u00a0Having quick app load times is always important, but for Teams it is critical – apps don’t stay in memory, they are expected to load and close within a few seconds at most.\u00a0 Analysis found that App.OnStart was a major culprit for slow loading apps in teams, and since it is imperative, there isn’t very much the system could do to improve the performance.<\/p>\n

So, today, we are all embarking on a journey.\u00a0 Over the course of many months we are going to provide new declarative<\/a> alternatives for all the things you do in App.OnStart today.\u00a0 Not only will your apps load faster and give a better user experience, but it will be easier to write and debug them too.\u00a0 Declarative means that you continue to tell us what<\/em> you want to happen, but you don’t need to tell us when<\/em> or how<\/em>.\u00a0 For example, an Excel spreadsheet describes a set of dependencies between cells (what<\/em>), it doesn’t say when they should be recalculated or in what order (when<\/em> and how<\/em>), that is Excel’s job.\u00a0 Going declarative relieves a lot of the tedium of keeping state variables up to date.<\/p>\n

To be clear, we have no plans to eliminate App.OnStart.\u00a0 There will likely always be a few outlier reasons to use it, but we do expect that it will become the exception rather than the rule.\u00a0 That’s a big shift from today.\u00a0 And that won’t happen overnight as we need, together, to determine the best declarative alternatives.\u00a0\u00a0Your engagement and feedback is the only way this will work.<\/p>\n

We are not forcing you to change anything today.\u00a0 Your apps will continue running App.OnStart as they always have.\u00a0 \u00a0I’m just unrolling the roadmap out on the table and pointing out our first milestone: App.StartScreen<\/a>.<\/p>\n

App.StartScreen<\/h2>\n

By default, the first screen shown when an app starts is the first is in the Tree View in Studio.\u00a0 That behavior can be modified today by calling the Navigate function from within App.OnStart.<\/p>\n

This poses a performance problem.\u00a0 If App.OnStart contains a Navigate function call, even if it is in an If function and rarely called, we must complete execution of the App.OnStart before we show the first screen of the app.\u00a0 Ideally we would show the first screen as soon as its dependencies are satisfied, but defer work that are only required by other screens of the app.<\/p>\n

App.StartScreen is the new declarative way to indicate which screen should be shown first, that doesn’t block optimizations.<\/p>\n

Where you may have written this in the past:<\/p>\n

App.OnStart = Collect( OrdersCache, Orders );\n              If( Param( \"AdminMode\" ) = \"1\", Navigate( AdminScreen ), Navigate( HomeScreen ) )<\/pre>\n
Instead, you can write this with version 3.21101 and later:<\/p>\n
App.OnStart = Collect( OrdersCache, Orders );\nApp.StartScreen = If( Param( \"AdminMode\" ) = \"1\", AdminScreen, HomeScreen )<\/pre>\n
I know, they look very similar, it’s a nuanced difference.\u00a0 Things to notice:<\/p>\n