Advertise with Us|Sign Up to the Newsletter

MobilePro #223: Motion That Matters in React Native

Hi ,

It's easy to get caught up in the race to build apps faster.

This week alone, Apple continued its AI push with iOS 27 Beta 3, Xcode 27, and further investments that suggest AI will become deeply embedded in every stage of app development. The tooling is getting smarter, code generation is becoming more capable, and prototyping is moving faster than ever.

But once your app reaches a user's hands, none of that really matters if the experience feels clunky. That's why this week's article shifts the focus from AI back to the interface itself. It explores why animations shouldn't be treated as visual polish added at the end of a project, but as part of the way an app communicates with its users. Using React Native's Animated API and Reanimated as examples, it makes the case that the best animations aren't the flashiest ones—they're the ones users barely notice because they simply make the interface easier to understand.

TL;DR

Building with AI is quickly becoming part of every developer's workflow. Each week, Build with AI explores practical AI engineering, agentic development, LLMs, MCP, coding tools, and the techniques shaping modern software development. Here's a glimpse into a recent featured article:

Software development is undergoing its most radical transition in decades. For most of that history, the fundamental bottleneck in engineering was the human translation of intent into syntactic execution. We possessed grand architectures in our heads, but typing them out, debugging semicolons, satisfying borrow checkers, and memorizing standard libraries was a painstaking, manual craft.

Today, that bottleneck has largely evaporated.

LLMs and autonomous agents have commoditized syntactic generation. A developer can now describe a complex state machine or a fully functional REST API in natural language, and a system will generate it in seconds. Unlike a compiler, which translates one precise notation into another and produces the same output every time, these systems predict. They vary.

The same request can produce different code twice. That difference is the whole reason engineering discipline matters more here, not less.

However, this newfound velocity has introduced a severe vulnerability into our workflows. Early adopters of this technology have embraced a paradigm often referred to asvibe coding. Coined byAndrej Karpathyin early 2025 to describe an intent-first, syntax-second approach, vibe coding champions a fast, loose, iterative generation style.

The developer acts as a Head Chef, barking orders at algorithmic sous-chefs and letting the AI handle the mechanical slicing and dicing. It sounds liberating, and for small scripts or weekend side projects, it absolutely is. But when the goal is production-grade enterprise software, the same looseness becomes dangerous.

When you apply unstructured vibe coding to massive legacy codebases with strict security, performance, and scaling constraints, the magic quickly turns into a nightmare. AI agents are non-deterministic, bounded reasoners. Left to their own devices, they will write code that appears functionally correct but is structurally disastrous. They will tightly couple components, hallucinate dependencies, and introduce security vulnerabilities.

This leads to a fundamental thesis that runs through this entire series:agentic software engineering is the pinnacle of traditional engineering rigor, not a break from it.The disciplines that make an agent productive are the disciplines you already know: testing, version control, modular design, continuous integration, and tight feedback loops. None of this is new. What changes is who does the typing and how much leverage each decision now carries.

We need to move beyond vibe coding and integrate the rapid generative powers of AI with the structural discipline of classic software engineering. By doing so, we shift our focus from typing code to designing the systems that produce it, managing complexity, and optimizing for learning....

With a background in full stack development across .NET and React, Rodrigo Lobenwein leads a team of senior developers and QA specialists, focusing on the architectural decisions that sit between engineering and product.
His work centers on helping teams develop the judgment to make the right technical calls not just follow the right frameworks. He is a Tech Lead in Marlabs Brasil.

Many apps leave animation until the end of a React Native project. The core screens get built, the data flows work, the buttons do what they should, and motion gets treated as a layer of polish that can be added later if there is time.

That is understandable, but it often shows in the final product. A screen appears with no sense of where it came from. A list item is removed, and the rest of the list snaps into place.

A button accepts a tap without giving the user any visible acknowledgment. The app still works, but it feels more mechanical than it needs to.

Good animation is not decoration. On mobile, it is one of the ways the interface explains itself. Motion can show that an item was added, that a view changed context, or that a touch was received. Without those cues, users have to infer more from less.

The tooling has also improved enough that animation is easier to take seriously earlier in the work. The built-in Animated API is still useful, and Reanimated has become a common choice when interactions need to stay smooth under pressure.

The harder question is no longer only technical. It is deciding which animations make the experience clearer.

For a long time, animation work in React Native often started with the built-inAnimatedAPI. It can still be the right tool, but there is an important constraint to understand: animation code that depends on the JavaScript thread can compete with the rest of the app.

The JavaScript thread already has plenty to do. It runs component code, handles state updates, processes events, and reacts to network responses.

If an animation depends on that same thread while the app is busy rendering or running business logic, frames can be missed.

At 60 frames per second, each frame has about 16 milliseconds to be ready. Miss that window often enough and the animation looks uneven.

A one-second animation may still complete in roughly one second, but it will not feel smooth.

The useNativeDriver option helped by letting some animations run on the native side. It is especially useful for properties such as opacity and transform.

The limitation is that it does not apply to every style property, especially layout-related properties, and every animation using a given animated value needs to stay consistent about which driver it uses.

That history explains why some teams became cautious about animation. The problem was rarely that animation was impossible.

The problem was that smooth animation required knowing which work could stay away from the busy JavaScript thread.

Reanimated approaches the problem differently. Its core idea is to let animation-related JavaScript run as worklets in a separate runtime, commonly on the UI thread, instead of relying on the main JavaScript thread for every frame.

A worklet looks like an ordinary JavaScript function with a directive at the top:

function simpleWorklet() {

"worklet";

}

In everyday Reanimated code, you often do not write that directive yourself because hooks and gesture callbacks can be workletized automatically.

The important point is what it enables: animated styles, gesture reactions, and shared values can update close to the rendering work, so they are less exposed to unrelated JavaScript workload.

This is where the newer architecture matters. Modern React Native gives libraries better low-level tools through JSI, and Reanimated 4 is designed for the New Architecture. That does not mean all overhead disappears or that every animation is automatically smooth.

It does mean the common path for high-quality motion is much better than hand-managing every frame from the JavaScript thread.

In practice, this gives developers more room to focus on what the motion communicates instead of treating every animation as a threading problem.

The best animations in a mobile app usually do a small amount of work very clearly. They answer a question the user already has.

Mount and unmount animations are a good first example. When an item appears in a list, a short fade or slide helps the user understand that something was added.

When an item is removed, animating it out gives the user a moment to register the change before the layout closes the gap.

Reanimated makes that kind of behavior concise withenteringandexitingprops on animated components:

<Animated.View entering={SlideInLeft} exiting={SlideOutRight}>

<TodoItem />

</Animated.View>

That small declaration is often enough for list-heavy screens. The component describes how it should enter and leave, and the surrounding UI feels less abrupt.

Touch feedback is another high-value use case. Mobile users do not have hover states, so pressable elements need another way to confirm that a touch was received.

A button that scales down slightly or changes opacity on press gives immediate feedback. Without that signal, users may wonder whether they tapped correctly or whether the app is slow.

Navigation transitions are the third common pattern. Moving from a list to a detail screen is not just a visual replacement. It is a change in context.

A familiar push transition helps users understand that they moved deeper into the app, while a reverse transition helps them understand they returned.

These are not dramatic effects. They are small pieces of spatial and tactile feedback that make the app easier to follow.

Not every interaction needs animation. The useful question is not "could this move?" It is "would movement help the user understand what just happened?"

A few cases are strong candidates. Something appears, disappears, or changes position. The user has just tapped, dragged, or submitted something and needs feedback. The app moves between screens, tabs, modals, or other contexts.

Other cases deserve skepticism. Motion that only calls attention to itself can make an interface feel less focused. A looping bounce, a decorative spin, or a transition that is longer than the action requires may be technically impressive but still make the product worse.

The standard I would use is simple: if removing the animation removes useful information, keep it. If removing it changes only the style, reconsider it.

None of this means every app should be full of motion. It means animation should be part of the interaction design discussion earlier than it often is.

Reanimated and the New Architecture lower the technical cost, especially for gesture-driven interactions, shared values, and entering or exiting views. That gives teams room to make the better decision: choose animation where it clarifies state, confirms input, or preserves context, and skip it where it only adds noise.

For most production apps, that leads to a restrained set of animations rather than a flashy one. The app feels more native because it communicates more clearly, not because every element moves.

The best test is still practical. If removing the animation also removes useful information for the user, the animation probably belongs. If removing it only makes the screen less flashy, the interface may be better without it.

This article is based on Chapters 16 and 26 ofReact and React Native, Sixth Edition,published by Packt. The book covers React 19, React Native, and their surrounding ecosystems from the ground up, with practical examples throughout.

If you’re looking to build modern web and mobile apps with React, React and React Native by Mikhail Sakhniuk, Rodrigo Lobenwein, and Adam Boduch offers a practical guide to mastering React, React Native, TypeScript, state management, testing, and performance optimization for production-ready applications.

🧑‍💻New content on TypeScript, React frameworks, state management strategies, and unit testing

🛠️Get to grips with React fundamentals and modern React techniques and architecture

📱Broaden your React expertise through mobile development with React Native

We’ll be moving MobilePro to Substack soon. From that point forward, all issues will come frompacktmobilepro@substack.com.

To ensure uninterrupted delivery, please whitelist this address in your mail client. No other action is required.

You’ll continue receiving the newsletter on the same weekly cadence, and on Substack you’ll also gain more granular control over your preferences if you wish to adjust them later.

Are your React Native animations helping users—or just decorating the UI?

Reply and let me know.

Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email and our team will get in touch with next steps.

Cheers,

Runcil Rebello,

Editor-in-Chief, MobilePro