Rethinking the App OnStart property to improve Power Apps performance

App OnStart is a familiar place for canvas Power Apps makers. The formulas there are executed when the application starts. What a great place to store everything you need.

But really, it’s not a good place to do actually anything.

Why not?

The more formulas are executed in OnStart, the slower the application starts. And it can end up being really slow to start. I mean, really.

Formulas originally placed in App OnStart were always executed first. Only after this did the application’s screens continue to be downloaded.

Microsoft tried to fix the slowness by allowing App OnStart to run in parallel with loading screens (Using non-blocking OnStart rule).

If your application gives end users rare and completely random mysterious errors when opening, you may have come across this optimization.

For example, if you initialize the date variable in App OnStart and use it in the filter condition of the gallery on the start screen. In this case, sometimes, Power Apps has time to create a gallery with filtering conditions on the screen before the variable used in it has received a value in App OnStart. An error occurs and the gallery appears empty.

Boring. But the reason is this optimization, which can be turned off.

For several years, Microsoft has tried to steer developers away from using App OnStart. Power Apps even has a setting to disable the whole thing.

For a while, App OnStart was disabled by default. Which, of course, caused confusion among the makers who were used to using it.

How to get rid of App OnStart?

If the use of App OnStart is so horrible, then where and how should the actions typically performed there be done?

Wait and see.

Named Formula (experimental)

Named formulas are in a way constant. Their value is defined in one place (App -> Formulas) and can be used everywhere in the application. However, their value can change if the value of the formula changes.

In addition to this, named formulas differ from global variables in one significant way. Their value is calculated only when it is needed for the first time.

They do not delay the start of the application and are lighter for the platform and easier to optimize than the global variables that everyone loves. Take advantage of them whenever you can (as long as they become generally available first).

Typical applications for formulas are, for example, the following.

Constants related to the user interface (colors, fonts, font sizes, etc.).

MainFontSize = 10;
HeaderFontSize = 14;
MainColor = RGBA(168, 0, 0, 1) ;
SecondaryColor = RGBA(237, 237, 237, 1)

Values ​​received as url parameter. For example, the identifier of the record to be opened.

ParamID = Param("Id");

User settings retrieved from the data source.

UserSettings = LookUp('User settings', Title = User().Email);

In Power Apps, named formulas look like this.

The values ​​of the formulas can be used in the application like variables.

But the value of the formula is always defined in one and the same place. Makes it clear.

App StartScreen

When the application starts, we often want to determine which of the application’s screens will open. Normally we open the main screen. If the application received a record identifier as a parameter, we will go to the screen showing that record. If the user starts the application for the first time, we guide him to fill out his user profile.

All this is typically done in App OnStart. But it shouldn’t. There is a feature of its own for this, namely App StartScreen. As the name suggests, it defines what the application’s home screen is.

For example, if the application did not receive the id of the record as a parameter, we go to the Main Screen. Otherwise, we go to the Details Screen.

StartScreen: If(IsBlank(ParamID), 'Main Screen', 'Details Screen')

Please note that named formulas can be used to define the startup screen. Global variables defined in App OnStart cannot be used.

This way, App OnStart, App StartScreen and App Formulas can be executed simultaneously.

The logic can also be more complex. For example, if the user is missing profile information (first time use), they will be directed to fill it in. Otherwise, we go to the start screen, except if the application received the record identifier as a parameter. Then we go to the records screen

StartScreen: If(IsBlank(UserSettings), 'My Profile Screen', IsBlank(ParamID), 'Main Screen', 'Details Screen')

Separate loading screen

Often, some actions are forced to be executed in App OnStart. However, I recommend removing everything from there and making your own startup screen where these actions are performed.

Why?

• The application seems to start faster when the right screen, branded in the style of the organization, opens quickly
• On the loading screen, you can tell the user what is being done in the background at any time

How is such a display made?

Let’s add a screen to the application, where the title tells what is happening.

The heavy lifting is done in the screen’s OnVisible event. The variable (locIsLoadingReady) is used to tell when we are ready.

UpdateContext({locIsLoadingReady:false});

//Put here all operations you need to do

UpdateContext({locIsLoadingReady:true});

Finally, a toggle is added to the screen, whose default value is the variable (locIsLoadingReady). Its value changes to true when everything is ready.

When the toggle is turned on, we navigate to the home screen.

Finally, the toggle control is of course hidden from the page.

Remember the performance optimization best practices

Everything mentioned above is a secondary adjustment if unnecessary heavy measures are taken when the application starts. Like loading all the rows into collections just to be sure they are immediately available when needed.

In brief:

• Use collections to store data from the data sources only if absolutely necessary. Unnecessary use of collections is poison!
• When the application starts, do not perform heavy operations that are not necessary for the home screen. Heavy operations should only be done when absolutely necessary. For example, when screen X opens (OnVisible).
• Take advantage of parallel execution (Concurrent)

For more guidance, see Microsoft’s performance tips and best practices for Power Apps canvas apps. If you are considering building large and complex canvas apps, keep in mind that it is not merely about solving the technical problems. My colleague Jukka has written a lessons learned article about building big apps in small steps, with one of the recommendations being “don’t build a big app”.

Anyway, I encourage you to try Power Apps completely without the familiar and safe App OnStart, because sooner or later it will disappear completely.