Showing results for 
Search instead for 
Did you mean: 
Level: Powered On

Big app



We're planning a rather large project (20ish screens). We're experienced Power Apps developpers, following most guidances highlighted in the best-practices whitepaper (for exemple, most of the heavy-lifting is done server-side with SQL procs on Azure SQL DB) and we're quite ruthless on documentation so I'm not too worried on that end.


Nevertheless, we've never attempted THAT big of a project and was curious if anyone had experiences to share. For exemple, on another project, the web authoring client started to slowdown after a certain point (the app itself was fine). I was wonding if anyone had found some not-so-obvious limitations and gotchas when dealing with large apps. For one, we're planning to lean heavily on reusable componants to standardise certain behavious and looks, and we haven't really battle-tested them yet either.


There's a possibility to break down the app into 3 smaller apps, but there would definetly be downsides on both usability for the client and on maintanability (some of the logic would have to be duplicated and maintained in multiple places). If we can have a single app for the project, that would be our prefered scenario.


Any feedback ?

Community Support Team
Community Support Team

Re: Big app

Hi @FredericForest ,

Could you please share a bit more about your scenario?


If you want to develop an app using PowerApps, there are some limits you need to note:

1. Data Source itself.

When you connect to data source from your app, there are some limits within data source connector itself. Please check the following article for more details about the limits in supported connectors in PowerApps:


2. System requirements and limits

If you want to create an app or run a PowerApps app, there are some System requirements and limits you need to know. Please check the following article for more detials:


3. App Performance tip

When you run a PowerApps app, you may face a Performance issue, please check the following performance tips for more details:


4. Common Issues within PowerApps

Currently, within PowerApps, there are some common issues you need to know. Please check the following article for more details:


If you have any questions about PowerApps when you develop your canvas app, please feel free to reply here.

Best regards,

Community Support Team _ Kris Dai
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
Level: Powered On

Re: Big app

Hi Kris @v-xida-msft 


The app has a single data source (Azure SQL DB) mainly adressed through Stored Procedures and we use local caching of values exentsively. So no worries about delegation, the use of variables or other data-related issues.


There were some interesting stuff in the performance tip link you sent. I knew about the white paper that came out on the subject, but there seem to be additional stuff here.

  • The limitation on the number of controls is common sense but a good reminder nonetheless
  • I didn't know about the Delayed Load option. That sounds quite interesting in my case since not every usage of the app will require every screen. I don't bind data source directly on controls tho, so we'll see how much of an impact this really has.
  • The DelayOutput properties might also be interesting in some cases. 

My initial comment was more to ask if anyone had made these larger apps and if they had tips to share (beside general good practices). Smiley Happy


Cheers !

Level: Powered On

Re: Big app

I have started down the path of making a single large app for my team.  I chose to go with a single app vs several smaller apps mostly for management/version tracking, and also to make it easier on my team (who has shown issues following directions consistently and remembering where certain things are).

I started with my main custom app, and started adding other functionality into it.  I customized a version of the "Book A Room" app, and then copied all of the screens into my main app.  I am up past 20 screens now.


Things to keep in mind, as I havnt really run into any show stoppers yet, are:
You have to really consider what needs to be a global variable vs what can be a screen context variable.  This is more of an issue when you use multiple screens for a single process, like the "book a room" app.  

Making sure your context/global variables are reset when they should be so you always have the correct information on whatever screen you are using.  As the app grows, and navigations to different screens become more complex, you will need to keep this in mind.

Usage of "Back()" to go to a previous screen can get you in a loop in some circumstances, so i limit when i use this.  Most of my "back" buttons navigate to a specific screen which works better for my app flow and keeping users out of trouble.

I have noticed some slowness when loading going between screens, and specifically when there are a bunch of items hidden unless a use-case/formula is met (or they are manually toggled visible via a button), some of them might show for a moment then disapear; but using a "loading" variable wrapped around my onVisible data functions could help with this if it becomes more of an issue.

Ill try to chime in as more come to mind and as i keep developing out my app.

Level: Powered On

Re: Big app

@mbarone :


I know what you mean for planning context properly. Personally, I stay away from local variables and the Back() function. I'm planning to have a side navbar as a custom componant (to be tested!) and a small subtle icon at the bottom of the app that show the value of current variables in the rollover text. I was tinkering with the idea of having a flow to dump the content of variables and collection by mail or in a Blob when clicking this debug icon...


@v-xida-msft :


Quick question you may have the anwser for (or may be able to find it for us) : is there any performance gain in using custom componants over regular ones ? Typically, I tended to customize all my components a lot with global variables (for colors, fonts, some behaviour, etc). Now I'm planning on having a master copy (say : customTextInput) where said customization takes place and instanciate that. It just seems like a more maintainable approach. But there might be a performance gain as well if the componant definition is cached and all the instance only point to the master.