Mobile performance and sync

What it does

The sizing and tuning work that decides whether an offline app syncs in two minutes or forty. It's mostly offline profile design — how many rows, how many tables, which columns, which filters — plus the network and battery assumptions you make about the people carrying the device.

Key facts

Microsoft's recommended ceilings for an offline profile: under 200,000 records, fewer than 100 tables, under 1 GB total data, and under 4 GB of files and images. Exceeding 3,000,000 records isn't supported at all.
Beyond those guidelines you get slower syncs, higher data and battery use, and slower app performance — Microsoft states this directly rather than leaving it implied.
Column selection is the biggest single lever on sync time. Select only required columns in the profile strips unused columns from the download, and the effect is largest on first sync where there are most rows to move.
Sync interval is set per table. Slow-moving reference data like a product catalogue can refresh once a day rather than on the standard cadence.
Filters that produce slow Dataverse queries produce slow downloads. Avoid Contains, Begins with, Ends with, multiple relationship levels and long chains of ORs.
Background sync only runs while the app is in the foreground with the screen unlocked. On Windows you can change this with the Let this app run in the background setting; on iOS and Android you can't.
Admins can let users adjust their own sync frequency, and can let users restrict automatic sync to wifi only.
Column optimisation isn't available for canvas apps that use a selected profile. Canvas apps on an autogenerated profile get it through the Faster offline synchronisation setting instead.

When to use / skip

Do this on any offline app that will carry more than a demo dataset — which is all of them. The tuning work is cheap compared to the alternative, which is a field team that stops opening the app because it takes twenty minutes to become usable. The one time you can reasonably defer is a genuine pilot with a handful of users and a small filtered dataset, where you'd rather learn the real access patterns first and tune afterwards. Don't defer it past the point where the profile is in a managed solution and everyone's afraid to touch it.

Configuration decisions

Where the filter boundaries fall per table — status, region, owner, date window — and whether those match how the business actually assigns work.
Whether files and images come down at all, and if so which columns, given they dominate the download size.
Sync interval per table, weighing freshness against data and battery cost.
Whether users can adjust sync frequency and restrict to wifi, which trades control for a better experience on a poor data plan.
Whether one heavy app should become two lighter ones with separate profiles, which is often the cleanest answer to a sizing problem.

Gotchas

Small time windows on frequently-changing tables look like a good filter and behave badly. A rolling filter on a busy table churns rows in and out of the local store on every sync.
The related-rows filter combined with a custom filter behaves as OR, so the "tightened" filter downloads more, not less. Watch this one.
Users on cellular in a rural area experience a completely different first sync from users on office wifi. Sizing against the wrong network makes the numbers meaningless.
Battery complaints usually trace back to continuous location or an aggressive sync interval, not to the app logic everyone starts by investigating.
The foreground-only sync rule means a phone in a pocket isn't syncing. Users assume it is and are surprised by pending upsync counts at the end of the day.

Consultant notes

Test with the heaviest realistic user, not the average one. Sizing against the average and discovering the regional manager takes forty minutes is a go-live problem, and it's always a manager.
Put the sync numbers in the design document — records, tables, data size, measured first-sync time on a representative device and network. It turns a subjective argument about performance into a measurement.
Add profile review to the change process. Every new table someone adds to the app quietly changes the sync profile, and that drift is where the second-year performance complaints come from.
Warn the client about the first-sync spike on go-live. Staggering the rollout across a few days is free and avoids fifty devices doing an initial sync in the same depot at 7am.

Worth revisiting if the recommended profile ceilings change, or if background sync arrives on iOS and Android.