Appsheet Apps Speed

Hello everyone :slight_smile:

I have a few questions about Appsheet Apps Speed, just to know what is normal and if there is something specific to my situation that I can do to speed up the user experience through the app.

So I have an App made now, that uses one Google Spreadsheet that has 15 tabs out of which only 5 have more that 10 rows and 5 columns (they are the only tabs collecting data, the rest are categories, users etc.)
I would say this is a small or at most, medium sized App (let me know if I’m wrong).

The App I made is now used on the Free plan with 7 Users. We’re building it up as a Task Management app for Teams + Overviewing Clients and Managers.

The app itself is quite intricate in the way it uses these tables and it has a bunch of virtual columns added and so forth, but my following observations about it’s speed were true ever since the Spreadsheet was mostly empty, so I don’t think calculation time is really relevant here.

  1. It takes about 5-6 seconds when opening the App on a mobile device until you get to the default view.
  2. It takes about 6-8 seconds on a sync (it takes longer to sync after changing data, but that would be expected)
  3. It takes 2-3 seconds to move from a View to Another on a Mobile Device of any User using the app. This is true both for Android and Iphone Users.
    (as an observation here, it does take slightly less navigating the Views in the App Builder on Chrome browser on the PC)

Out of these observations, it’s the Third one that bugs me the most, the others are fine as they are expected. But I didn’t really expect a 2 seconds wait every time you touch a menu, a tab a view or a form on the Mobile Device.

Is this normal? Is everyone else here experiencing the same thing?
Is this about the Plan I’m on? And it wouldn’t have this delay if the App would be Deployed?

Or can I still hope to have more instant movement through the App, within these conditions I’m running the App in right now? Because the App is great and Appsheets functionality is amazing and I can’t imagine being able to do what I’m doing with Appsheet … with mainly anything else out there :smiley:
But I’m really curious about the cause of these slow interactions with the Apps build in it. This doesn’t make much of a Time Management App if it takes two second to click on anything in the App.

Thank you,

Hi Sorin,
No 2,3 seconds seems excessive but it could depend on other factor. Mostly how much data you load and in particular whether there are a lot of virtual columns that needs to be computed and if the data is setup such that you need to do a tons of join at data query time.
So if most of your tabs are short list, I suspect these are lookup tables type thing and doing joins on spreadsheet is not as efficient as doing it with relational DB that are optimized for this.
Could I suggest you try two things.
Replace your lookup table REF things with loading your lookup tables as enum column instead and entering these values once in your enum list.
The second thing I would try is to remove virtual columns and reads them one at a time to see if one in particular takes a long time to compute.
That should give us some first indications as to where the data is spent? Data joins or virtual column expression or elsewhere if neither of these suggestions have influence on the perf.
Hope this helps.


Often, the root cause of slow transitions between views is an inefficient Format Rule (a format rule with a SELECT in it can be very inefficient). I’d suggest look there first. The other cause I’ve seen is very large data sets, but that doesn’t seem to be your problem at all.

1 Like

Hy Thierry,
Thanks for writing.

Sorry, what does that mean?

So lets take one example:
There is a Projects Table and a Category of Projects Tabel. The projects Table is one of the Long Sheets that keeps gathering Projects as we make them. The Category of Projects is a short Sheet, with 4 Categories. Besides the Name of the Category, there are other Columns as well to this Sheet. When creating a new Project, there is a Dropdown to select the Category of Projects, which is indeed a Ref column to the Category of Projects Table.
What is the Change you suggest I make in such cases?

Well :smiley: is there a way to make them inactive? I’m kind of afraid of removing them as it took quite a while to make them …

But you seem to indicate this is a calculation time issue … I don’t know that “too many” means, I doubt I got to that point :)) but then again, to make sure, I guess the easiest way to display the amount of connections is to show you the Spec images:

So this is everything in there:

And this is an explenation of it all:

So for the main part of it, there is as I said, quite a number of connections, as the App has mainly a clear Hierarchy - There are Category of projects, Each heaving Many Projects, each Project can have many Objects, Each Object can have Many Tasks, each Task has Many Times, which are filled in by the Users.
The connections I made so that it’s very easy to navigate from any place in the Hierarchy to any other part of it, within that Project … but then again, it does look like this:

As for Virtual Columns, I use them a lot for displaying purposes, where they concatenate the info in other column, with up to 5-6 IFs. I’m happy to try them out one by one and see if there is one in particular that is using too much computing time, but I can’t remove them :slight_smile:


To test the virtual colimns, I’ll try not displaying them, maybe that will make a difference and then start displaying them one by one and see if there is a change in speed of load of different views…

This will be a problem if it isn’t now.

Rightly so! Yikes!

I agree with this.

I suspect he’s suggesting you replace Ref columns with Enum columns of base type Ref or Text. Doing so will prevent AppSheet from auto-generating the Related … virtual columns with reverse references (see Reverse References in References Between Tables). Because these virtual columns are recomputed at each sync, the expectation is that they can contribute to slow sync times, especially for complex interrelationships between tables. According to @praveen’s comments in another post, though, reverse references typically don’t contribute significantly to sync time, so it’s unlikely to help.

I would expect hiding them would have no significant effect, as virtual columns are computed at sync time, not on display. Format rules, however, are computed at display time (see here), hence @praveen’s suggestion.


Well, also they are mostly concatenate and if formulas, not Select, as praveen says they are the ones that might take up the time … so it sounds like those wouldn’t be the problem.

How do you mean?

Each virtual column is a linear multiplier to your sync time: the time to compute one row’s virtual column values times the number of rows. The more rows, the greater the effect on sync time. I generally prefer to keep as much data in normal columns as possible to avoid contributing to sync time.

1 Like

Aham, so you suggest that if I can actually make what the virtual column does, be done in a column with a formula in the spreadsheet and then display that column in appsheet, that would make things run faster right?

Because I could do that for the vast majority of my virtual columns…just didn’t know that would be part of best practices logics with appsheet…is it?

@sorin_mihai I am 99% certain your perf issue (delay in transitions between views) isn’t due to virtual columns or refs. it is most likely due to format rules. Virtual columns are computed at sync time. They are not computed during view transitions. However, format rules do have to be computed during view rendering and scrolling.

It sounds like you do have format rules. Could you try to disable all of them and see if your performance improves?



Well, I do have about 24 conditional formatting rules. Disabling them definitely has a positive impact on time. Now it takes just a bit under a second. It’s not instant but it’s faster.

However, taking all of them out, takes me from this:

to this:

Is this a choice I have to make? Speed vs. Ease of read?
Would you say there are certain Format Rules Guidelines to follow so things don’t go so out of hand? Or simply I just have too many?

Also, as an observation, on the Chrome Browser now, after disabling the formatting rules, the app reacts instantly to change of views. So there is some dependency on the computing power, if the mobile app is still a little slower then the Chrome Browser on a PC.
What would you suggest is still making that difference?

Thank you,

1 Like

Of course this is true.

I would suggest doing as little computation in the format rule as possible; try to do the computation in columns. You might also consider whether you need all of your rules. For instance, you appear to have two indicators that a row is done: a green checkmark and strike-through text. One or the other is probably sufficient. But if you need both, and both are computed by the same expression, find a way to compute the expression just once and reuse its result.


Also, in case its not totally apparent, you can combine multiple formatting “actions” into one rule.

For example, It seems that your example screen view above can be accomplished with 3 format rules

  1. Bold and underline - top row
  2. Circle icon, green highlight, Bold text and underline - for second row.
  3. Check mark icon, green highlight, text strikethrough - for remaining rows.

Then its just identifying the criteria to apply each rule.

As @Steve and @praveen have suggested above, it is likely the complexity in the expressions for these rules that are slowing things down.

And as @Steve mentions, the more “pre-processing” you can do to eliminate that complexity before the format rules are applied, the better for your entire app. This may mean having columns on each row that serve no other purpose than calculated indicators for that row that you can later test for “IS” or “ISNOT” conditions. A few split-second calcs sprinkled through the app are a LOT more acceptable to end users than the a 2 second delay to switch screens.


My general feedback is to go easy on format rules, both for a good user experience and also for performance. Expressions in format rules should be simple — avoid SELECT or its derivatives (like FILTER and MAXROW)

I’d be curious to see your app and figure out if there are obvious ways we could improve its performance. Do you mind sending the details to Thanks


Hi @sorin_mihai Maybe you could use slices to show the done work instead of formatting.

1 Like


I do use slices. The one in the example is a slice of Times added to Tasks and they represent All Tasks in that list.
But I have slices for My Not Finished Tasks for example, and the conditional formatting rules are for - tasks started/not started, tasks for today, urgent tasks. These could not go into smaller slices, it’s practical to have everything that is in progress display in the same list, with highlights to their particularities.

I will try to reduce them as much as I can now that I know :smiley: maybe I got a little over-enthusiastic about learning Appsheet and conditional formatting rules … I do that usually in order to learn something in more depth, but … now I just learned something new so I’ll adjust.

Thank you,


Hy @praveen

Thank you, that would be amazing to get some feedback from you.
I have sent the email to support already :smiley:

I have two warnings though, and please let me know how I can help:

  1. The whole app is in Romanian …

  2. This is my first Appsheet app … and only one so far. I was as clean as I could be but it’s still a work in progress and a learn by testing App as well :))

I don’t know if I crossed the Frankenstein app line so far, but some of the parts of the app, as I showed in the Specs, are in the making, and about to get connected to the main app.

Thank you and can’t wait for your feedback.


That’s true, it makes a lot of sense.
Some of those conditional formatting rules are paired as you suggest, but now I see I can do even more to take the calculations out of the Formatting Rule and into the spreadsheet.

I’ll definitely do that ASAP.


Be careful with adding a lot of formulas into the sheet. That can elevate wait times in the back end. When formulas are firing in the sheets, AppSheet cannot know if the results of those formulas effect data they are trying to retrieve, so they wait until formulas have completed. I’m sure this is over-simplified but the point is the more formulas in the sheet the more wait time AppSheet might have to endure.

If at all possible I would perform these calculations in the app as data changes.


Ok, so best case scenario:

  • no formulas in the spreadsheet,
  • only IF formulas in conditional formatting, and the fewer, the better.
  • real columns in the Spreadsheet, with formulas in Appsheet to calculate their values,
  • and conditional formatting based on the value of these columns (no calculation necessary, just if statements)

Does that sound correct?