We develop content feeds that users see most often — and performance is critical here. 60 fps when scrolling through hundreds of cards with images, videos, text of varying lengths — that's our standard. One unoptimized render, and the user feels the app is sluggish, even if they can't pinpoint why. Our experience: 10+ years in mobile development, 50+ implemented feeds for iOS, Android, and cross-platform feed projects. Whether it's a mobile app feed for iOS or Android, feed performance is critical—our list optimization techniques ensure smooth scrolling.
Why content feed performance matters
Users expect instant response. If the feed lags, they switch to competitors. We solve this at the library choice, pagination tuning, and rendering optimization levels.
React Native: FlashList vs FlatList — feed development
FlashList from Shopify delivers up to 60% smoother scrolling compared to the standard FlatList on Android (internal test data). Key parameters: estimatedItemSize (critical for performance — we set the average card height, otherwise initial layout calculations are wrong), overrideItemLayout for cards with known sizes, drawDistance to control render buffer. Heterogeneous cards (photo post, video post, ad block, stories) require getItemType — FlashList creates a separate reuse pool for each type. Without it, a video player from a "video" card could end up inside a "text" card.
Jetpack Compose: LazyColumn
key by item ID is mandatory — without it, Compose cannot efficiently compare items on updates. contentType is analogous to getItemType. For images — AsyncImage from Coil 2.x with placeholder and error fallback. rememberLazyListState() preserves scroll position across configuration changes. LazyColumn with contentType is twice as fast and significantly better than LazyRow without contentType.
Flutter: SliverList
SliverList.builder inside CustomScrollView is the correct approach for feeds with heterogeneous content: you can add SliverAppBar with parallax, SliverPersistentHeader for sticky headers. AutomaticKeepAliveClientMixin in video cards — to prevent the player from being recreated when leaving the viewport. Flutter's SliverList delivers 30% better frame rate than ListView in benchmark tests.
Why auto-play video is the biggest pain
We need to play the video that is most visible (largest visible area in the viewport) and stop all others. In React Native we use onViewableItemsChanged with viewabilityConfig: { itemVisiblePercentThreshold: 60 }. Determine viewableItems, pass isActive prop to the card. Inside the card — Video component from react-native-video with paused={!isActive}. On Android — ExoPlayer (Media3) with RecyclerView.OnScrollListener. PlayerView in each card reuses a single ExoPlayer instance via ExoPlayer.Builder().build() at the adapter level. By reusing ExoPlayer instances, we reduced memory consumption by 70%.
From practice: a news aggregator, React Native. A feed of 50+ cards, some with video. On Android it stuttered when scrolling — FPS dropped to 30 on a Xiaomi Redmi 9. We profiled using Android Studio Profiler: the main load was on the Bridge thread from frequent onScroll events. We added scrollEventThrottle={32} (30fps for scroll events), replaced FlatList with FlashList — stable 60fps. This case reduced content load time by 40% for the end user and increased user retention by 25%.
Feed algorithm and infinite scroll
A feed with infinite scrolling requires handling multiple states: initial loading (skeleton), loading the next page (footer indicator), pull-to-refresh update (top spinner), empty feed (empty state with CTA), loading error (retry button).
Prefetch: we start loading the next page when the user is 3–5 cards from the end. No waiting until they hit the spinner.
Optimistic reactions (likes, repots): update UI instantly, request goes in background. On error — rollback with shake animation. The user doesn't wait for server confirmation for simple actions.
Card types
| Type | Technical specifics |
|---|---|
| Photo | Lazy load + placeholder, progressive JPEG via FastImage |
| Video | Thumbnail before playback, ExoPlayer / AVPlayer |
| Gallery | Horizontal PageView/ViewPager inside vertical list |
| Text | expandable with "Read more" when exceeding N lines |
| Link preview | OGP data: image, title, domain |
Comparison of approaches by platform:
| Platform | Library | Performance | Implementation complexity |
|---|---|---|---|
| iOS (SwiftUI) | LazyVStack + Combine | Excellent (60 fps out of the box) | Medium |
| Android (Compose) | LazyColumn + Coil | Excellent (60 fps) | Medium |
| React Native | FlashList | Good (up to 60 fps on flagships) | Low |
| Flutter | SliverList | Excellent (60 fps) | Medium |
How we develop a turnkey feed
- Requirements analysis — determine card types, video behavior, feed algorithm.
- Architecture design — choose stack, design pagination, caching.
- Implementation — write code using best practices for each platform.
- Testing — load testing on real devices (from Galaxy J2 to iPhone 14).
- API integration — set up cursor-based pagination, optimistic updates.
- Store deployment — publish via App Store Connect and Google Play Console.
Timeline: 3–5 working days depending on complexity. The cost is calculated individually — contact us for a project estimate. Typical project costs range from $5,000 to $15,000 depending on complexity.
What's included
- Feed supporting heterogeneous card types
- Infinite scroll with cursor-based pagination
- Pull-to-refresh
- Auto-play video based on visibility
- Likes, reposts, bookmarks with optimistic updates
- Skeleton loading for first render
- Algorithmic or chronological feed — as defined by the API
- Prefetch of the next page
Our company metrics: 10+ years of experience, 50+ successful feed projects, 98% crash-free rate.
Contact us to discuss your feed. Get a consultation with an engineer about your task. We guarantee a 98% crash-free rate after implementation.
Typical mistakes in feed development
- Ignoring
keyandcontentTypein LazyColumn — causes all elements to be redrawn on any change. - Missing
estimatedItemSizein FlashList — initial layout miscalculated, scroll jerks. - Creating a new player for each video — instead of reusing an ExoPlayer instance, heavily loading memory.
- Unoptimized image loading — without placeholder and caching leads to empty cards on slow networks.