Every VibeKit Native component runs on Hermes, animates on the UI thread via Reanimated, recycles list rows via FlashList, and loads images through expo-image with disk cache + blurhash. Your app stays smooth scrolling 10,000 items, animating bottom sheets, and cold-starting under 2s.
Every component ships meeting these baselines. No jank, no lag, no surprises on real devices.
| Metric | Target | How it's achieved |
|---|---|---|
| App Startup | < 2s cold start | Hermes engine + lazy native module loading |
| Frame Rate | 60fps scrolling | FlashList with recycling + reanimated worklets on UI thread |
| Bundle Size | < 3MB per component category | Tree-shaken imports, no bloat per file |
| Image Load | < 500ms first paint | expo-image with disk caching + blurhash preview |
| Memory | < 150MB peak | FlashList recycling, image cache limits, no leaks |
Each layer targets a specific performance killer that React Native apps suffer from — and solves it at the component level.
Every component is tested with Hermes, the JavaScript engine optimized for React Native. Hermes compiles JS to bytecode ahead of time, cutting startup time in half and reducing APK/IPA size by 30%.
JSC engine uses JIT compilation — slower startup, larger binary, more memory. Each new screen adds parse time.
Hermes pre-compiles bytecode. Cold start in under 2 seconds. Binary size stays lean even with 65 components installed.
Animations run on the UI thread via react-native-reanimated worklets — never crossing the async bridge. Toast slides, bottom sheets, skeleton pulses all animate at a solid 60fps even under heavy JS thread load.
JS thread animations (Animated API) must cross the async bridge every frame. A flatlist scrolling with JS thread animations = jank.
Reanimated worklets run at native speed. The JS thread can be busy fetching data while the UI thread keeps animating smoothly.
Product grids, chat messages, order lists — every scrollable component uses @shopify/flash-list. It recycles views instead of creating new ones, meaning 10,000 items scrolls as smoothly as 10.
FlatList creates new views for each visible item. Scroll a list of 1,000 products = memory spikes, dropped frames, and jank.
FlashList recycles just 15-20 views regardless of list size. Memory stays flat at ~80MB even with infinite scroll.
All image components use expo-image with automatic disk caching and blurhash previews. Images load once from the network, then serve from disk cache. Blurhash placeholders mean zero layout shift while images load.
React Native Image component provides no caching. Every re-render re-fetches from the network. No placeholder means jumpy layouts.
expo-image caches to disk on first load. Subsequent renders are instant. Blurhash previews fill the space at 2KB vs 200KB for the full image.
Each component is a single plain TypeScript file with no provider setup, no configuration, and no additional dependencies beyond the core Expo stack. Installing 10 components adds < 100KB to your project's source.
UI libraries with providers, themes, and config files add 500KB-2MB before you write any code. You pay for components you never use.
Install only what you use, pay only for what you install. No registry lock-in, no bloat, no unused code in your bundle.
Animations use native-driven springs and transitions (not setInterval or requestAnimationFrame on JS thread). Bottom sheets, toasts, and skeleton loaders use minimal CPU — no battery drain from JavaScript timers.
setInterval-based animations keep the JS thread busy even when the app is in the background. Timer drift, battery drain, delayed responses.
Native animations driven by reanimated's timer worklets. Zero JS thread overhead once the animation starts. Battery-friendly even with multiple active animations.
Same feature set. Same framework. The difference is whether performance patterns are built into the components or left to chance.
| Dimension | Vanilla React Native | VibeKit Native |
|---|---|---|
| Startup Time | 4–6s cold start (JSC JIT compilation) | < 2s (Hermes bytecode) |
| Scroll Performance | FlatList drops frames at 500+ items | FlashList maintains 60fps at 10,000+ items |
| Animation Thread | JS thread bridge crossing = jank under load | UI thread worklets = smooth 60fps always |
| Image Loading | No cache, re-fetches on re-render | expo-image disk cache + blurhash previews |
| Bundle Size | 500KB–2MB for a UI library you barely use | ~10KB per component file, only what you install |
| Memory (Long Lists) | Spikes to 300MB+ with FlatList | Stays at ~80MB with FlashList recycling |
| Navigation | React Navigation with manual linking | expo-router file-based, lazy route loading |
Performance is built into every component from day one.