Low-end Android

The rule

• Animate only transform and opacity. These are cheap on a weak GPU. Animating layout (width, height, top, margin) forces re-layout every frame and stutters — avoid it. Durations come from the motion tokens.
• Spend blur and shadow sparingly. Backdrop blur and large shadows are GPU-expensive; a couple per screen at most, and each must earn its place. On the grey canvas a white card needs neither.
• Bound your lists. Any list of user data must have an answer for 500+ items — pagination or virtualization, not an unbounded .map in a scroll view.
• Keep payloads light. Prefer token-driven shapes and SVG over raster images; don't add a heavy dependency for a small effect; stay on the three script font stacks already loaded.
• Be native-shell safe. Web-only APIs (navigator.*, window.*, CSS strings) must be feature-gated or wrapped, because the same screen runs inside the native WebView; platform-split components need both variants updated.
• Assume offline. Network calls need an offline answer — queue writes, label pending items, never leave a spinner that spins forever.

When to use it

Always — but especially after adding animation, blur, charts, or any list of user-generated content. That's when a screen quietly stops being device-friendly.

When NOT to use it

There's no exemption. Even a "quick" internal screen runs on the same phones. If a richer effect is genuinely worth it, prove it's smooth on a low-end device first — don't assume.

What user problem this solves

Speed, trust, and access. Jank and long loads read as "broken" to a user deciding whether to trust the app with their money. And many users simply don't have a fast phone or a stable connection — designing for the low end is what makes DayTwo usable for the people it's actually for, not just in a demo.