Shipping a React Native List Library Worth Opening Up
FlashList, Shopify's React Native list component, started from a practical pain point that most mobile teams will recognize: lists that stutter, skip, and blank out under scroll. The library now fixes those issues with high-performance rendering, but getting it from an internal fix to an open-source project with over 1,000 GitHub stars in a day took more than good code. Here's what worked and what we'd do again.
Solving a Problem You Actually Have
Good open-source projects usually start from a problem the author already knows. That was true for FlashList. We were migrating the Shopify Mobile app from native code to React Native, and list performance was a major blocker. Lists appear throughout the app—products, orders, inventory, collections—and the React Native versions weren't good enough. Items failed to render while scrolling; the scroll would stop suddenly. Compared to the native implementation, it was a clear step backward.
When you're both the builder and the user, research is simpler: you already know the pains, the audience, and what would make the solution useful. That forced perspective shaped what we built.
Prototype Before You Polish
At Shopify, we call the first experimental stage the prototype phase. It's when you attempt the simplest possible version and test what's feasible. Don't clean up early—experiment with approaches that might be dead ends, and only commit to the implementation once you've proven the central idea.
Our proof of concept came from comparing the two common list options in React Native at the time: FlatList and RecyclerListView. FlatList was easy but not performant enough; RecyclerListView was fast but awkward to use. The question became: could we get RecyclerListView's performance with something closer to FlatList's API?
That's how FlashList was born.
Small Team, Clear Boundaries
A common assumption is that a polished open-source library requires a big company and many engineers. We had exactly four: Marek Fořt, Elvira Burchik, Talha Naqvi, and me. Small teams can ship powerful tools if they keep scope tight. Early on, we had a working prototype and the first thought that any team has: why keep this to ourselves?
Execution matters more than the idea, and one area where a small team can out-execute everyone is documentation. Everyone loves good docs; nobody wants to write them. That friction is precisely your chance to stand out. Spend serious effort on docs and you remove a barrier between your tool and its users.
Planning the Launch Before the Code Is Done
We started planning the launch six months before FlashList was close to finished. The exact plan changed, but the core components held: a landing page, a blog post, social media amplification, and a community channel.
Landing Page Goals
Create a basic page explaining what your project solves, how it does that, and who it helps. For FlashList, we gave each goal a priority:
- Primary: Understand the features versus FlatList.
- Secondary: Install FlashList to try it out.
- Tertiary: Read the full documentation.
A story, Not Just Features
We wanted to tell the story behind what we built, so we wrote a blog post about the journey. Storytelling gets people invested. They appreciate the work more when they know why it was built and how. Beyond the page, we planned social media, with Twitter and LinkedIn as amplifiers—tweets get retweeted, and relevance does most of the work.
The Hardest Part: Choosing the Launch Moment
Even when the library was being used in production inside Shopify Mobile and spread to other apps like Shop and Inbox, we wrestled with when to call it v1.0. It was scary. What if nobody cares? What if they care but it's not good enough? Plus, Shopify's bar for open source is high, and we wanted our release to match it.
Then the decision got made for us.
Momentum From a Conference Stage
Our original plan omitted live events. In June, FlashList was mentioned in an App.js conference talk by Monica Restrepo about Shopify's open-source projects. Some team members knew the mention was coming; others, including creators who were physically in the audience, didn't. Watching someone else present your work — even though it was good work, and the interest was genuine — was the point of no return.
Developers started responding on Twitter immediately. The React Native community had real pain with FlatList, and the need for solutions was clear.
Building Hype With a Closed Community
With social buzz rising, we shifted to finding people ready to engage. We decided on an invitation-only Discord channel and tweeted that developers could join. We DM'd people and invited them individually and got the first 100 members in. FlashList wasn't public yet, but we used the channel to share teasers: performance graphs, sneak peeks of videos. It bought time until everything was ready — but impatience set in quickly, memes started, and we knew we had to launch soon.
The library wasn't finished, but we'd already committed to the path. At that point we had to move fast or lose the momentum we'd built. Even with a pending launch, a working prototype, and groundwork done, knowing when to share is the moment everything changes — in FlashList's case, an outside event made the call for us. For your project, look for that signal: a public mention, a tweet that surprises you, a moment you can't take back. That's the sign you're ready.
Launch Day: What Actually Happened
The original plan called for a companion blog post to go live the same day as the FlashList release. That post wasn't finished, and rather than delay the launch, the team pushed the release out anyway. The decision paid off. The announcement tweet from Shopify Engineering drew over 1,200 likes and more than 300 replies, making it the account's most-engaged post since the previous Black Friday. On LinkedIn, the announcement became the most-engaged post the Shopify Engineering account had ever published, and the project quickly climbed to #2 on GitHub's trending list.
That reception wasn't accidental. The key ingredients were a solid library, advance preparation, the buzz generated at conferences, and a community that was clearly waiting for a better list component. A bit of timing luck helped too. The broader lesson is that launches don't follow a fixed curve. Some take off immediately; others build slowly. Missing one wave doesn't foreclose future opportunities. Keep working, keep listening to user pain points, and the traction will come.
Why Users Trusted FlashList
New open-source projects start with zero credibility. Even inside Shopify, developers were skeptical and stuck with FlatList simply because it was the established default. A known brand name helps — launching under Shopify's banner carried authority, but it also raised expectations. Independent developers have the opposite problem and advantage: no legacy attached, but no borrowed trust either.
The real question every project must answer is: why should anyone care? For FlashList, the answer was performance, but claims alone aren't enough. Third-party validation was critical. When an external developer tested the library with their own Flipper performance-monitoring plugin and shared the results publicly, that independent confirmation did more for credibility than any internal benchmark.
That's the pattern to aim for: get your project into other people's hands early and let their results speak for you.
Lessons for Anyone Open-Sourcing a Project
No two open-source efforts are the same, but the FlashList experience suggests a set of principles that generalize well beyond this particular case.
- Code is only part of the work. Popular libraries are products. Documentation, promotion, and presentation matter just as much as the implementation.
- Work from a plan. A concrete plan gives direction and a task list, even when it inevitably evolves. The plan doesn't have to match FlashList's exactly, but it should exist.
- Involve others early. External collaborators catch biases and blind spots. Early feedback improves the project.
- Don't wait for the perfect moment. There will always be loose ends. Once the library is genuinely useful to others, that's the time to launch.
- Focus on user value, not just internals. Zoom out from implementation details. Ask peers what value they see, and document benefits from the user's perspective.
- Build a community deliberately. A private Discord test group made members feel like early adopters. That closeness translated into organic promotion — several members became advocates without being asked.
- Plan for the long tail. The initial launch is just the first pitch point. Follow-up blog posts, deep technical dives, videos, and conference talks all create opportunities to relaunch and expand reach.
