Coder Legion - Recent posts tagged react-native

How to Fix Metro Bundler Stuck or Not Starting Errors in React Native

Thu, 22 Oct 2026 12:02:08 +0000

If you've worked with React Native for a while, you've probably run into a problem where Metro refuses to start, gets stuck while bundling, or leaves your app waiting for JavaScript that never arrives.

Sometimes the terminal shows an error immediately. Other times, Metro appears to start normally, but the app stays on a loading screen or fails to connect to the development server.

The frustrating part is that these symptoms can have completely different causes. A port conflict, stale cache, broken dependency installation, invalid configuration, or network issue can all look like a Metro problem.

Here's how to narrow it down and fix the actual cause instead of repeatedly restarting your project and hoping something changes.

1. Identify What Metro Is Actually Doing

Before changing anything, identify which of these situations matches your problem.

Metro won't start: The development server exits with an error, refuses to launch, or reports that a port is already in use.
Metro starts but gets stuck bundling: The terminal shows that bundling has started, but it never finishes.
The app cannot connect to Metro: The server appears to be running, but the application displays a loading screen or a connection error.
Metro starts, but the app crashes: Bundling may be successful, but a JavaScript exception or native configuration problem prevents the app from running.

These are different failure points. Clearing the cache might help with a stale bundle, but it won't fix a port occupied by another process or an invalid native configuration.

Start with the simplest checks and move toward more disruptive fixes only when necessary.

2. Stop Metro and Start It Again

First, stop any Metro server running in the terminal by pressing Ctrl + C.

Then start it using the command appropriate for your project.

If you're using Expo

From your project directory, run:

npx expo start

To clear Expo's Metro cache at the same time, use:

npx expo start --clear

If you're using React Native CLI

Start Metro from your project's root directory:

npx react-native start

If you suspect stale cached files, use:

npx react-native start --reset-cache

Important: You don't need to clear the cache every time Metro fails. Start with the normal command. Use the cache-reset option when the symptoms suggest stale or inconsistent cached data, or when a normal restart doesn't help.

If Metro exits immediately, read the terminal output before trying another command. The first meaningful error is often more useful than the final stack trace.

3. Check Whether Port 8081 Is Already in Use

Metro normally uses port 8081. If another process is listening on that port, Metro may fail to start or ask you to use a different one.

The terminal might show a message similar to:

Error: listen EADDRINUSE: address already in use :::8081

This means another process is already using the requested address and port.

On Windows

Open Command Prompt and run:

netstat -ano | findstr :8081

Look for a line containing LISTENING. The last column contains the process ID (PID).

You can identify the process with:

tasklist /FI "PID eq 12345"

Replace 12345 with the actual PID.

If you've confirmed that the process is an old Metro server you no longer need, you can stop it:

taskkill /PID 12345 /F

On macOS or Linux

Run:

lsof -i :8081

Inspect the process listed for port 8081. If it's an old Metro process that you no longer need, stop that specific process:

kill <PID>

Replace <PID> with the actual process ID.

Don't terminate a process simply because it's using the port. Confirm what it is first, especially if other development tools are running.

Once the port is available, start Metro again.

4. Clear Metro's Cache When Bundling Gets Stuck

Metro transforms your JavaScript files and their dependencies into a bundle the application can execute. Cached transformation results help make subsequent builds faster, but stale or inconsistent cached data can sometimes cause confusing behavior.

Typical symptoms include:

Bundling worked before, but now fails after code or dependency changes.
The app appears to use an older version of your JavaScript.
Metro repeatedly fails while transforming files without an obvious dependency error.
A normal restart doesn't resolve the problem.

Try the appropriate cache-reset command from Step 2.

After the cache is cleared, let Metro rebuild the bundle. The first build can take longer because the cached transformation results need to be regenerated.

If the same error returns, don't keep clearing the cache. Look at the specific file, dependency, or configuration mentioned in the terminal output. A repeatable error usually means there's something more specific to fix.

5. Check Your Dependencies Before Reinstalling Everything

Metro depends on the packages and configuration in your React Native project. If a package installation was interrupted, dependencies were changed, or incompatible versions were introduced, Metro may fail while loading its configuration or resolving modules.

Start by checking the actual error.

For example, these messages point toward different problems:

Cannot find module ...

Unable to resolve module ...

Cannot find module 'metro-config'

A missing module doesn't automatically mean the entire dependency installation is broken. It might be an incorrect import path, a package that was never installed, or a version mismatch.

Check the following:

Did the problem start immediately after installing, removing, or updating a package?
Does the error identify a particular module or package?
Does your project use the package versions expected by its React Native or Expo version?
Did you accidentally run the installation command from the wrong directory?

If the project uses npm and has a valid, committed package-lock.json, a clean installation may be appropriate:

npm ci

This reinstalls dependencies according to the lockfile and removes the existing node_modules directory as part of the process.

For a Yarn project, use the installation command appropriate for its Yarn version and existing lockfile. Don't switch package managers or delete your lockfile just to see whether Metro starts.

Avoid deleting node_modules, lockfiles, and caches all at once as your first response. Doing so can introduce new version differences and make it harder to identify what originally caused the failure.

6. Check Metro and Expo Configuration

If Metro reports an error while loading its configuration, clearing the cache or reinstalling dependencies might not help.

Look for changes to files such as:

metro.config.js
babel.config.js
package.json
Expo app configuration, such as app.json or app.config.js

Pay particular attention to recent changes involving custom Metro configuration, Babel plugins, aliases, monorepo settings, or package versions.

For example, if Metro fails while loading metro.config.js, inspect the configuration and the package named in the error. A missing import or incompatible configuration dependency can prevent the server from starting at all.

If the problem appeared after a configuration change, compare that change with the last working version. Reverting one recent change is often more informative than rebuilding the entire environment.

For Expo projects, also make sure you're following the configuration requirements for your installed Expo SDK rather than copying a Metro configuration from an unrelated project or older tutorial.

7. If Metro Runs but the App Cannot Connect

A running Metro server doesn't guarantee that your app can reach it.

This distinction matters because repeatedly resetting Metro's cache won't fix a connection problem.

Check the development-server URL

When Metro starts, inspect the URL or connection information it prints in the terminal.

If you're using a physical device, make sure the device and computer can communicate over the selected network. VPNs, firewalls, guest Wi-Fi networks, and network isolation can interfere with local development connections.

If you're using Expo

Expo supports different connection methods depending on your environment and configuration. If the normal connection method doesn't work, try the tunnel option:

npx expo start --tunnel

A tunnel can help when the device cannot reach your computer directly over the local network, although it may be slower and depends on the tunnel service being available.

If you're using an Android emulator

Check that the emulator is running and that the development server is reachable. For a React Native CLI workflow using the standard Android emulator setup, you can forward port 8081 with:

adb reverse tcp:8081 tcp:8081

This is useful when the emulator needs a route to Metro through Android Debug Bridge. It isn't a universal fix for every device or connection setup.

If the app can connect but crashes after loading the bundle, move on to the JavaScript or native error shown by the app. At that point, Metro itself might be working correctly.

8. Don't Confuse a JavaScript Error With a Metro Startup Failure

Sometimes developers blame Metro because the application stops working immediately after a successful bundle.

But these messages describe different problems:

Metro startup error: The development server cannot initialize.
Module resolution error: Metro cannot find or resolve a requested module.
JavaScript runtime exception: The bundle loads, but the application encounters an error while executing code.
Native build error: The Android or iOS application fails during native compilation or configuration.

For example, if Metro reports that it cannot resolve a module imported by App.tsx, investigate the import path, filename, package installation, and any configured aliases.

If the Android build fails before the application starts, inspect the native build output instead of treating every failure as a Metro cache problem.

Finding the correct failure point saves time because each category requires a different solution.

9. When None of These Fixes Works

If Metro still refuses to start, collect the evidence before making more changes.

A useful troubleshooting report should include:

The exact command used to start Metro.
The full terminal error, especially the first meaningful error before the stack trace.
Your operating system.
Whether the project uses Expo or React Native CLI.
The relevant React Native and Expo versions.
Any recent dependency or configuration changes.
Whether Metro fails to start, gets stuck bundling, or starts while the app cannot connect.

Remove access tokens, passwords, private URLs, and other sensitive information before sharing logs publicly.

If the output contains several errors, don't assume the final message is the root cause. A failure to load one configuration dependency can trigger multiple follow-up errors.

This is also where a diagnostic tool can help. If you've already tried the obvious fixes and the logs are difficult to interpret, you can paste the relevant error and technical context into FixMyError. It can help analyze the failure, identify likely causes, and suggest targeted next steps instead of making you cycle through unrelated fixes.

Final Thoughts

When Metro Bundler gets stuck or refuses to start, the best approach is to identify where the failure occurs before changing your project.

Start with a normal restart, check port 8081, clear the cache when appropriate, and inspect dependency or configuration errors when they appear. If Metro is running but the app cannot connect, troubleshoot the connection rather than repeatedly resetting the bundler.

The goal isn't to run every possible fix. It's to find the specific reason your development environment stopped working and make the smallest change that resolves it.

One Design System, Two Runtimes: Sharing Contracts Between React and React Native

Sat, 26 Sep 2026 09:42:11 +0000

A cross-platform design system sounds simple until the first real component forces the platforms apart.

React and React Native can expose the same product concept — a button, checkbox, input, modal — while relying on very different runtime primitives. The web has DOM attributes, anchors, CSS, hover and keyboard behavior. React Native has Pressable, native accessibility props, gesture events, and a completely different styling model.

Trying to hide all of those differences behind one implementation usually makes the API worse. In Vellira, I have been taking a different approach: share the semantic contract, not the runtime implementation.

That distinction has become one of the most useful architectural rules in the project.

The real goal is consistency, not identical code

When I started building Vellira, it was tempting to think about cross-platform components mainly as a code-sharing problem.

If a web button and a native button look similar, why not make them use as much of the same component code as possible?

Because the important thing users consume is not the internal component tree. It is the behavior and mental model of the public API.

For a button, developers should be able to learn concepts such as:

color
appearance
size
shape
loading
disabled
fullWidth
iconOnly

once and carry that knowledge between platforms.

The implementation underneath those concepts does not need to be the same.

This leads to a more useful definition of parity:

Cross-platform parity means shared semantics where the platforms agree, plus explicit platform-specific capabilities where they do not.

That is much stronger than forcing two different runtimes through the same abstraction.

Put shared semantics in a platform-neutral contract

Vellira keeps the common Button vocabulary in @vellira-ui/types.

A simplified view of the shared contract looks like this:

export type ButtonSize = 'sm' | 'md' | 'lg';

export type ButtonColor =
  | 'primary'
  | 'neutral'
  | 'success'
  | 'warning'
  | 'danger';

export type ButtonAppearance =
  | 'solid'
  | 'outline'
  | 'ghost'
  | 'soft'
  | 'link';

export interface BaseButtonProps {
  color?: ButtonColor;
  appearance?: ButtonAppearance;
  size?: ButtonSize;
  shape?: 'square' | 'rounded' | 'pill';
  fullWidth?: boolean;
  loading?: boolean;
  loadingText?: string;
  disabled?: boolean;
  iconOnly?: boolean;
}

There is nothing web-specific or native-specific in that interface. It describes what a Vellira button means.

That shared layer gives both implementations a stable semantic center. If appearance="soft" exists on both platforms, it should represent the same design intent. If loading disables interaction, that rule should be understood consistently too.

This is where I want reuse to be strongest.

Let each platform extend the contract honestly

Once the common semantics are defined, the platform packages can extend them instead of pretending their runtimes are identical.

On the web, ButtonProps extends the shared contract and normal HTML button behavior. It can also expose anchor-related properties such as href, target, and rel.

export interface ButtonProps
  extends
    BaseButtonProps,
    Omit<ButtonHTMLAttributes<HTMLButtonElement>, 'color'>,
    Pick<
      AnchorHTMLAttributes<HTMLAnchorElement>,
      'href' | 'target' | 'rel' | 'download'
    > {
  children?: ReactNode;
  iconStart?: ReactNode;
  iconEnd?: ReactNode;
  tooltip?: string;
  badge?: ReactNode;
  shortcut?: ReactNode;
  asChild?: boolean;
}

React Native starts from the same BaseButtonProps, but the runtime-specific surface is different. It builds on PressableProps, exposes onPress, native styles, and accessibility properties that belong to the native platform.

export interface ButtonProps
  extends BaseButtonProps, Omit<PressableProps, /* platform exclusions */> {
  children?: ReactNode;
  iconStart?: ButtonIconElement;
  iconEnd?: ButtonIconElement;
  iconSize?: number;
  onPress?: (event: GestureResponderEvent) => void;
  style?: StyleProp<ViewStyle>;
  textStyle?: StyleProp<TextStyle>;
  accessibilityLabel?: string;
  testID?: string;
}

The two APIs are clearly related, but they are not artificially identical.

That is intentional.

A web developer still gets normal web capabilities. A React Native developer still gets normal native capabilities. The design system owns the common semantics without becoming an abstraction tax on either platform.

Healthy divergence is part of a good cross-platform API

Some differences should not be normalized away.

For example, a web button can naturally compose with an anchor or another DOM element. That is where properties such as href or Vellira's asChild capability make sense.

React Native does not have an HTML anchor element. Inventing a fake href prop just to make the type signatures look more symmetrical would create parity on paper while making the native API less natural.

The same rule applies in the opposite direction. React Native has concepts such as StyleProp<ViewStyle>, testID, and native press events. Wrapping every one of those in invented cross-platform names would make the system harder to understand and harder to debug.

So I use a simple test when deciding whether something belongs in the shared contract:

Does this property describe product-level component behavior, or does it describe the runtime that implements it?

Product-level behavior is a strong candidate for the shared layer. Runtime behavior usually stays with the platform package.

That distinction keeps the common API small enough to remain meaningful.

Component props are only one layer of cross-platform consistency.

Visual decisions such as spacing, radii, typography scales, colors, and semantic states also need a common source of truth. Those decisions can be represented as tokens and consumed differently by CSS on the web and native style objects in React Native.

The important architectural point is the same: share the decision, adapt the execution.

A radius token does not require the web and native styling engines to work the same way. It only requires both implementations to resolve the same design intent.

This is a useful pattern because it prevents "cross-platform" from turning into "lowest common denominator". Shared semantics stay centralized while each renderer remains free to use the platform correctly.

Test parity at the contract boundary

Once implementations are separate, drift becomes the next problem.

It is easy for the web Button to gain a new appearance or loading rule while the React Native Button silently falls behind. Separate implementations therefore need explicit validation around the things that are supposed to stay aligned.

In Vellira, both Button implementations have their own tests and Storybook coverage. The shared types define a common vocabulary, while platform tests verify actual runtime behavior.

That gives two different kinds of confidence:

Contract confidence — the shared semantic API is defined in one place.
Runtime confidence — each implementation proves that the contract behaves correctly on its own platform.

I prefer this over a large shared implementation with a growing number of platform conditionals. A shared file can look beautifully DRY while still hiding platform-specific bugs.

Separate runtime tests make those differences visible.

A practical three-layer model

The pattern I am converging on in Vellira can be summarized as three layers.

1. Shared semantics

Define the concepts developers should learn once:

size
appearance
color
loading
disabled
shape

These belong in platform-neutral types and design contracts.

2. Platform API

Extend those concepts with capabilities developers expect from the runtime:

Web:          href, target, DOM attributes, asChild
React Native: onPress, accessibilityLabel, style, testID

Do not disguise real platform differences.

3. Platform implementation

Use the native tools of each runtime:

Web:          DOM + CSS
React Native: Pressable + native styles

The implementation can diverge significantly as long as the shared semantics remain trustworthy.

What this changes when designing new components

This architecture also changes how I think about adding components.

Instead of beginning with "How can I reuse the most code?", I begin with questions like:

What behavior is actually common to both platforms?
Which names should mean the same thing everywhere?
Which states must have equivalent semantics?
Which capabilities are genuinely platform-specific?
What should be validated so parity cannot drift accidentally?

Only after those questions are answered does implementation reuse become interesting.

Sometimes there will be useful shared code below the component layer. Sometimes the correct answer is two mostly independent implementations. Both are acceptable if the public contract stays coherent.

This makes the design system easier to evolve because platform differences are treated as architecture inputs, not inconvenient exceptions.

The rule I keep coming back to

The most useful lesson so far is that cross-platform design systems do not need maximum code sharing. They need maximum semantic clarity.

Developers should feel that the React and React Native packages belong to the same system. They should recognize the vocabulary, states, design decisions, and interaction intent. But they should not have to give up the strengths of their platform to get that consistency.

For Vellira, that means sharing contracts aggressively and implementations selectively.

It is a smaller abstraction, but a much more durable one.

You can explore the project in the Vellira documentation or browse the implementation on GitHub.

AI Can Generate More UI. Who Keeps It Consistent?

Thu, 24 Sep 2026 16:57:01 +0000

AI makes UI faster to produce — and easier to fragment. Why Vellira is building cross-platform components and developer tooling to keep growing UI systems coherent as humans and coding agents move faster.

AI can now generate UI faster than many teams can review it.

A developer can describe a component, ask a coding model to implement it, and get a plausible result in minutes. The same model can refactor nearby code, write tests, update types, and produce several variations before a traditional implementation would have reached its first review.

That is a real improvement.

But it also moves the bottleneck.

The hard question is becoming less:

How quickly can we create another component?

And more:

How do we keep the whole UI system coherent when humans and AI can change it this quickly?

That is one of the problems we are building Vellira around.

Generation is getting cheaper. Fragmentation is not.

Imagine an AI-generated component that looks good, compiles, and works in a local preview.

That still leaves a surprising number of questions unanswered.

Does it duplicate something the system already has? Does its API fit the surrounding components? Does it use the shared design foundations? Is the same product capability represented correctly on React Native? Are accessibility expectations covered? Did the documentation and examples move with the implementation? Will the next contributor understand how this component is supposed to evolve?

A locally correct component can still make the system around it less consistent.

That distinction matters more as generation gets faster.

When UI changes slowly, teams can compensate for weak system boundaries with review, documentation, and memory. Someone remembers which component should be reused. Someone catches the one-off visual value. Someone notices that Web changed but React Native did not. Someone remembers to update Storybook.

As the rate of change increases, that becomes harder to sustain.

More UI output creates more opportunities for small differences to accumulate:

APIs drift between similar components;
accessibility behavior becomes inconsistent;
local values bypass shared tokens;
documentation falls behind implementation;
Web and React Native diverge unintentionally;
similar capabilities get implemented more than once;
tests encode different expectations for comparable behavior;
package and public surfaces become harder to keep aligned.

None of these problems were invented by AI.

AI simply increases the rate at which they can appear.

If a team can create five or ten times more UI changes, the system around those changes has to become stronger too.

A component library is necessary. It is no longer sufficient.

Traditional design systems are often described as collections of reusable components, tokens, guidelines, and documentation.

Those foundations still matter. Vellira has them too.

But a catalog can only tell you so much.

It can show that Button, Select, or Tabs exists. It cannot, by itself, keep every future change aligned with the same expectations around APIs, accessibility, platforms, documentation, testing, and quality.

This becomes especially visible when UI work is shared between developers and coding agents.

A coding model can generate a perfectly reasonable component that does not quite belong to the system around it.

It may introduce a slightly different API. It may recreate a capability that already exists. It may look correct on Web while ignoring the native side of the project. It may use values that are visually close to existing tokens without actually using the shared token system.

The code is not necessarily bad.

The surrounding system is simply asking a larger question than "does this component work?"

It is asking:

Does this change still belong to the same product and engineering system?

That is the layer we are increasingly interested in with Vellira.

What Vellira is becoming

Vellira started as a cross-platform design system for React and React Native.

The public project still has that foundation: reusable components, shared tokens, documentation, Storybook, and cross-platform implementation work.

But building the component set exposed a second problem very quickly.

Creating components is only part of the work. Keeping all of them aligned as the system grows requires repeatable workflows and tooling around the components themselves.

Today the public Vellira project already combines:

reusable React and React Native components;
shared design tokens and cross-platform foundations;
Storybook and documentation for discovery and usage;
repeatable component-generation workflows;
automated component quality checks;
accessibility-focused validation and testing;
metadata-backed tooling that gives the project structured information about its own components.

None of those features alone is the point.

The interesting part is what they allow us to work toward together: a UI system that becomes easier to extend without becoming easier to fragment.

We do not want adding a component to mean only "these files compile."

We want the surrounding project to help keep that component connected to the same design foundations, the same platform expectations, the same documentation, and the same engineering standards as the rest of Vellira.

That is useful when a developer writes the code manually.

It becomes even more useful when an implementation can appear in seconds.

Vellira is not trying to out-code the coding model

This distinction is important.

Coding models are getting better quickly. They should be able to write more implementation code, understand larger codebases, make broader changes, and handle more routine engineering work over time.

That is good for Vellira.

We are not building the project around the assumption that AI will remain bad at writing components.

We are building around the opposite assumption: AI will get very good at producing and modifying UI.

If that happens, the surrounding system becomes more important, not less.

A model can generate a new component.

The project still needs to keep APIs coherent.

A model can change ten components in one pass.

The project still needs to keep accessibility, documentation, public surfaces, tokens, and platform behavior from drifting apart.

A model can become better at understanding context.

The repository still benefits from making its important expectations explicit and repeatable instead of depending on every author to remember them perfectly.

So the goal is not to slow AI-assisted development down.

The goal is to make that speed safer to absorb.

The author matters less than the result

There is a temptation to treat AI-generated code as a completely separate category that needs a special design-system workflow.

I do not think that is the most useful distinction.

Once code enters a repository, the important question is not who typed it.

The important question is whether it fits the project.

A human can introduce an inconsistent API.

A coding agent can follow the existing conventions perfectly.

A developer can forget documentation.

An automated workflow can keep it current.

The author is not a reliable measure of system quality. The resulting state of the project is.

That is why Vellira is investing in tooling around the component lifecycle rather than relying only on the intelligence or discipline of whichever author produced the latest change.

Humans and AI can both move faster when the project around them carries more of the consistency burden.

Cross-platform UI raises the stakes

Vellira targets both React and React Native.

That makes this problem even more visible because "the same component" does not always mean "the same source code."

Web and native platforms have different primitives, interaction models, accessibility APIs, and constraints. Some behavior should be shared. Some behavior needs to diverge intentionally.

A useful cross-platform design system therefore needs more than copied implementations.

It needs to keep one product language coherent while still respecting each platform.

Faster code generation does not remove that challenge.

It can amplify it.

An AI tool can create two implementations very quickly, but speed alone cannot tell a team whether those implementations still represent one coherent component system.

That is why the tooling around Vellira's components matters as much as the component count itself.

The bottleneck is moving from production to coordination

This is the part of AI-assisted frontend development that I find most interesting.

Better coding models reduce the cost of producing code.

When producing UI is expensive, teams naturally make fewer changes. When producing UI becomes cheap, experimentation increases, more contributors can work in parallel, and automated agents can make changes of their own.

The limiting resource starts moving away from typing speed.

It moves toward coordination, consistency, review, and maintenance.

That creates a different kind of leverage for developer tooling.

If ten changes can be produced in the time it previously took to produce one, tooling that helps those ten changes remain part of the same system becomes more valuable.

This is the bet behind the direction Vellira is taking:

AI can generate more UI. Vellira is being built to help keep that UI coherent.

The better generation becomes, the more important the system around generation becomes.

Where Vellira is today

We are still building the foundation, and I want to be precise about that.

The immediate work is concrete: expand the cross-platform component set, strengthen component workflows, improve quality and accessibility checks, and make the public project easier to adopt and use.

We are proving these ideas inside Vellira itself before making broader claims about what the tooling can understand or manage outside the project.

That constraint is intentional.

It is easy to describe an ambitious future for developer tooling. It is more useful to earn that future by making the current system work reliably first.

But the product direction is already clear.

Frontend teams are going to work with more generated code, more automation, and more AI-assisted changes — not less.

The answer should not be to slow those tools down.

It should be to make the UI system around them stronger.

If you are building React or React Native interfaces and thinking about how AI changes design-system workflows, follow Vellira as we build this in public:

AI can help us build UI faster.

Vellira is being built so that faster does not have to mean more fragmented.

How to Fix Firebase `PERMISSION_DENIED` Errors in React Native

Tue, 22 Sep 2026 12:05:03 +0000

If you are using Firebase with a React Native app, sooner or later you will probably run into something like this:

FirebaseError: [code=permission-denied]: Missing or insufficient permissions.

Or:

Error: PERMISSION_DENIED: Permission denied

And the annoying part is that the error does not tell you much.

It does not say:

Your Firestore rule on this collection is blocking the request.

It just tells you that Firebase rejected it.

That can happen for several different reasons. Your Firestore rules might be doing exactly what you told them to do, your user might not actually be authenticated, App Check might be involved, or your app might be connected to a different Firebase project than you think.

So before changing random rules until the error disappears, it is better to figure out why Firebase is rejecting the request.

First, find out which Firebase service is rejecting the request

PERMISSION_DENIED is not limited to Firestore.

You can see permission-related errors with services such as:

Cloud Firestore
Realtime Database
Firebase Storage
Firebase App Check
Firebase Authentication-related operations

So start by looking at the full error.

For example:

FirebaseError: [code=permission-denied]: Missing or insufficient permissions.

If the stack trace shows a Firestore operation such as:

firestore()
  .collection("users")
  .doc(userId)
  .get();

then your first place to look is Firestore security rules.

If the error happens while uploading a file, Storage rules are more relevant.

This sounds obvious, but a long React Native stack trace can make it easy to focus on the wrong part.

Check your Firestore security rules

If the error comes from Firestore, check your rules first.

For example, you might have:

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {

    match /users/{userId} {
      allow read, write: if request.auth != null;
    }
  }
}

This rule only allows authenticated users to access documents under:

/users/{userId}

If your app makes the request before the user has signed in, Firebase will reject it.

That can produce:

permission-denied

The important part is that Firebase is not necessarily malfunctioning here.

Your rule may simply be doing exactly what it was written to do.

Check whether the user is actually authenticated

One of the easiest mistakes is assuming that the user is signed in when the request runs.

For example:

const user = auth().currentUser;

console.log(user);

If that prints:

null

then there is no authenticated Firebase user at that moment.

A rule such as:

allow read, write: if request.auth != null;

will reject the request.

This can happen when your app starts up and immediately tries to read Firestore before Firebase Authentication has restored the user's session.

For example, you might have code that effectively does this:

const user = auth().currentUser;

firestore()
  .collection("users")
  .doc(user.uid)
  .get();

If user is not available yet, the request can fail.

Instead, make sure your application waits for the authentication state before making requests that require authentication.

With React Native Firebase, you can listen for authentication changes:

useEffect(() => {
  const unsubscribe = auth().onAuthStateChanged(user => {
    if (user) {
      // Safe to make requests that require authentication
    }
  });

  return unsubscribe;
}, []);

The exact structure depends on your app, but the idea is the same:

Do not assume authentication has finished restoring just because the app has started.

Check that the rule matches the path you are actually using

This is another very common one.

Imagine your rules contain:

match /users/{userId} {
  allow read, write: if request.auth != null;
}

But your app actually accesses:

/profiles/123

That rule does not apply to /profiles/123.

You need a matching rule for the path being accessed.

This becomes especially confusing when you have nested collections.

For example:

/users/123/settings/theme

is not the same path as:

/users/123

Your rules need to match the actual document path.

If you are getting PERMISSION_DENIED, look at the exact collection and document your code is trying to access.

Do not assume the rule you are looking at is the one Firebase is evaluating.

Be careful with nested Firestore documents

Suppose you have:

users/{userId}/settings/{settingId}

You might write:

match /users/{userId} {
  allow read, write: if request.auth != null;
}

and expect that to cover everything underneath the user.

It does not automatically mean that every nested document is covered.

You may need a recursive wildcard depending on the structure and rules you want.

For example:

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null;
}

Be careful with this kind of rule, though.

It can give access to much more data than you intended.

Do not add a broad wildcard just because it makes the error disappear.

Do not use `allow read, write: if true` as the final fix

You will sometimes see people recommend this while debugging:

allow read, write: if true;

Yes, it can make the permission error disappear.

It also allows anyone who can access your Firebase project from the client to read and write the matching data.

That is not a real fix.

If you temporarily use an open rule to confirm that the rules are the cause, put the secure rule back immediately afterward.

For example, if the app should only allow authenticated users:

allow read, write: if request.auth != null;

is very different from:

allow read, write: if true;

The goal is not simply to make Firebase stop complaining.

The goal is to make the rule match what your application is actually supposed to allow.

Check whether you are using the correct Firebase project

This one can waste a lot of time.

Your React Native app might be connected to a different Firebase project than the one you are looking at in the Firebase Console.

You think you are checking the rules for:

my-production-project

but the app is actually connected to:

my-development-project

Now you change rules in the console and nothing happens.

The app keeps returning:

permission-denied

because you are fixing the wrong project.

Check your Firebase configuration and make sure the project ID matches the Firebase project you are inspecting.

For Android, check the Firebase configuration used by your Android app.

For iOS, check the corresponding iOS Firebase configuration.

If you have development, staging, and production projects, this becomes especially important.

Check your Android and iOS Firebase configuration

If the problem only happens on one platform, compare the Firebase configuration between them.

For Android, make sure the correct Firebase configuration is being used.

For iOS, make sure the correct configuration is being used there as well.

A situation like this is possible:

Android → Firebase project A
iOS     → Firebase project B

You can then spend hours changing Firestore rules in project A while testing an iOS build that is actually talking to project B.

If the error happens only on Android or only on iOS, platform-specific Firebase configuration should be on your checklist.

Check Firebase App Check

App Check can also be involved when Firebase rejects requests.

App Check is designed to help verify that requests are coming from your legitimate app rather than an unauthorized client.

If you recently enabled App Check or changed its configuration, check whether the failing request is related to App Check.

This becomes especially important if:

the app worked before enabling App Check
requests work in one environment but not another
you are testing a development build
you changed App Check enforcement settings
you changed the app's Android or iOS configuration

Do not immediately disable App Check just because it is involved.

First determine whether the request is failing because of App Check configuration or because of your Firestore/Storage rules.

Those are different problems.

Development and production can behave differently

A common source of confusion is:

"It works in development, but my production build gets PERMISSION_DENIED."

That does not necessarily mean the Firebase rules randomly changed.

Your development and production builds may be using different:

Firebase projects
application IDs
bundle identifiers
configuration files
App Check settings
authentication settings
environment variables

If the problem only happens in a release build, compare the Firebase configuration between the working and failing builds.

This is usually more useful than changing your Firestore rules blindly.

Check the exact user ID being used

Suppose your rule is intended to allow users to access their own documents:

match /users/{userId} {
  allow read, write: if request.auth.uid == userId;
}

That means this request:

/users/123

will only work if:

request.auth.uid == "123"

If your application accidentally requests:

/users/456

while the logged-in user is actually 123, Firebase will reject it.

So log the values you are using while debugging:

console.log("Current user:", auth().currentUser?.uid);
console.log("Requested user:", userId);

If they do not match, you have found the problem.

This is much more useful than changing the security rule to allow everyone.

Check your Storage rules if the error happens during uploads

If the problem happens while uploading an image, PDF, or another file, you may actually be dealing with Firebase Storage rather than Firestore.

For example:

FirebaseError: [storage/unauthorized] User is not authorized to perform the desired action.

Storage has its own security rules.

A Firestore rule like:

allow read, write: if request.auth != null;

does not control Firebase Storage.

If the error happens during:

storage()
  .ref("profile-images/avatar.jpg")
  .putFile(filePath);

look at your Storage rules instead.

The service producing the error matters.

Check Realtime Database rules separately

The same idea applies to Realtime Database.

Realtime Database has its own rules structure, for example:

{
  "rules": {
    ".read": "auth != null",
    ".write": "auth != null"
  }
}

Changing Firestore rules will not fix a Realtime Database permission problem.

If your application uses several Firebase services, make sure you know which one is rejecting the request before changing anything.

Use the Firebase Emulator when appropriate

If you are working on complicated security rules, the Firebase Emulator Suite can make debugging much easier.

Instead of repeatedly testing rules against production data, you can test your rules locally.

This is especially useful when your rules depend on things like:

request.auth
request.auth.uid
request.resource.data
resource.data

For example, a rule might look correct at first glance but fail because the incoming document does not contain the field your rule expects.

Testing the rule with known authentication and data values makes these problems much easier to see.

Look at what changed right before the error

This is one of the most useful debugging habits for Firebase errors.

Ask:

What changed immediately before PERMISSION_DENIED appeared?

Maybe you:

changed Firestore rules
added authentication
changed the user document structure
switched Firebase projects
enabled App Check
changed an Android package name
changed an iOS bundle identifier
updated a Firebase dependency
moved a Firestore collection
changed the document ID
created a new production build

The timing does not prove what caused the error, but it gives you a very good place to start.

A simple debugging order

When I get a Firebase PERMISSION_DENIED error, I usually go through these checks:

1. Identify the Firebase service

Is it:

Firestore?
Storage?
Realtime Database?
App Check?
something else?

2. Read the exact path

What collection, document, or storage path is the app trying to access?

3. Check authentication

console.log(auth().currentUser?.uid);

Is there actually a logged-in user?

4. Check the security rule

Does the rule actually match the path being accessed?

5. Check the values used by the rule

If the rule compares user IDs, roles, or document fields, verify those values.

6. Check the Firebase project

Make sure the app and Firebase Console are using the same project.

7. Check App Check

Especially if the problem started after enabling or enforcing it.

8. Check platform-specific configuration

If only Android or iOS is affected, compare the configuration for that platform.

9. Reproduce the problem again

After making one change, test again.

This gives you a much clearer debugging trail.

Example: finding a simple rules mistake

Imagine your Firestore rule says:

match /users/{userId} {
  allow read: if request.auth != null
               && request.auth.uid == userId;
}

Your app is logged in as:

abc123

but your code requests:

/users/undefined

Firebase sees:

request.auth.uid == "abc123"

and:

userId == "undefined"

The condition is false.

So Firebase returns:

permission-denied

The problem is not Firebase.

The problem is that your application generated the wrong document path.

This is why checking the exact request is so important.

Final thoughts

PERMISSION_DENIED can be frustrating because the error itself is often very short while the number of possible causes is not.

The important thing is to avoid treating it as simply:

"Firebase permissions are broken."

Start by finding out which Firebase service rejected the request, then check the exact path, authentication state, security rules, and Firebase project.

If the error appeared after a recent change, use that as a clue.

And avoid the temptation to solve everything with:

allow read, write: if true;

That only hides the real problem and can leave your data exposed.

If your error is buried inside a much larger React Native/Firebase log and it is difficult to tell whether the problem is authentication, rules, App Check, configuration, or something else, you can paste the full error into FixMyError and use it to narrow down what is actually going wrong.

Try it at https://www.fixmyerrorapp.com.

How to Fix Expo Doctor Errors in Expo

Mon, 07 Sep 2026 11:14:51 +0000

If you work with Expo long enough, you will probably run into expo-doctor.

You run:

npx expo-doctor

and instead of everything being green, you get something like:

✖ Check Expo config
✖ Check dependencies
✖ Check package versions

Sometimes there is one problem.

Sometimes there are several.

And sometimes the output looks much worse than the actual problem.

The good thing is that expo-doctor is usually pretty clear about what it does not like. The tricky part is knowing what the warnings actually mean and which ones you need to fix.

Here is how I usually work through Expo Doctor errors without immediately changing half of the project.

First, run Expo Doctor by itself

Start with:

npx expo-doctor

Let it finish and read the full output.

Do not immediately start changing dependencies just because you see a red ✖.

Expo Doctor runs several checks, and a failure in one check does not necessarily mean your entire project is broken.

For example, you might see:

✖ Check that packages match versions required by installed Expo SDK

That is very different from:

✖ Check for common project configuration problems

The first one points toward dependency versions.

The second could require looking at your Expo configuration.

So the first step is simply figuring out which check actually failed.

Check your Expo SDK version

A lot of Expo Doctor problems come down to package versions not matching the Expo SDK you are using.

You can check your Expo version in package.json:

{
  "dependencies": {
    "expo": "~54.0.0"
  }
}

The exact version will depend on your project.

You can also run:

npx expo --version

and:

npx expo config --type public

The important thing is to know which Expo SDK your project is actually using before changing dependencies.

This matters because Expo packages are not completely independent of the SDK.

You cannot always just install the newest version of every package and expect everything to work together.

Fix packages that are on the wrong version

One of the most common Expo Doctor messages is related to package versions.

For example:

✖ Check that packages match versions required by installed Expo SDK

Expo may tell you that some packages are expected to be on different versions.

If that happens, do not manually guess which version to install.

For Expo-managed projects, use:

npx expo install

Expo can use your current SDK to install compatible package versions.

You can also check the project with:

npx expo install --check

If it reports packages that are out of date, you can usually let Expo correct them with:

npx expo install --fix

This is generally safer than doing something like:

npm install package-name@latest

because the latest package version is not necessarily the version your current Expo SDK expects.

Do not blindly update everything

This is worth mentioning because it is an easy mistake to make.

Suppose Expo Doctor tells you that three packages have version mismatches.

You might think:

Fine, I'll just update everything.

Then you run something like:

npm update

and suddenly you have five new errors.

You have now changed many things at once, which makes it harder to figure out what actually caused the problem.

If Expo is telling you that a package should be on a specific version, start with that package.

For example:

npx expo install react-native-screens

rather than manually searching for the newest version and installing it.

Make one meaningful change at a time when possible.

It makes debugging much easier.

Check `package.json` for old dependencies

Another common situation is an old dependency that you no longer use.

Over time, a project can collect packages from old features, experiments, tutorials, or libraries you tried and later removed.

Your package.json might contain:

{
  "dependencies": {
    "some-old-package": "^1.2.3"
  }
}

even though nothing in your application imports it anymore.

If Expo Doctor complains about that package, first check whether you still need it.

Search your project for:

some-old-package

If there are no imports or references and you know you do not need it anymore, removing the dependency may be the correct fix.

For npm:

npm uninstall some-old-package

For Yarn:

yarn remove some-old-package

Then run Expo Doctor again.

Check for packages that are not compatible with your project

Sometimes the problem is not simply that a package is old.

A package may require native code or a setup that does not fit the way your Expo project is configured.

This becomes especially important when adding React Native libraries that were designed with bare React Native projects in mind.

You may install a package successfully with npm, but that does not automatically mean your Expo project is configured to use it correctly.

If Expo Doctor starts complaining immediately after adding a new library, that timing is useful information.

Try to remember:

What changed right before the error appeared?

If you just installed a package and Expo Doctor started failing, investigate that package first.

Check your Expo configuration

Expo Doctor can also complain about your project configuration.

Depending on your setup, this information may live in:

app.json

or:

app.config.js

or:

app.config.ts

For example, your configuration might contain something like:

{
  "expo": {
    "name": "My App",
    "slug": "my-app"
  }
}

If you recently changed your configuration, added a plugin, changed an Android or iOS setting, or installed a package that requires an Expo config plugin, check those changes carefully.

A configuration problem can sometimes look like a dependency problem because several parts of the Expo toolchain depend on the same project configuration.

Check Expo config plugins

Config plugins are another area that can cause confusion.

If you have something like:

{
  "expo": {
    "plugins": [
      "some-package"
    ]
  }
}

make sure that package is actually installed and that the plugin is valid for your current setup.

A common situation is:

You install a package.
You add its plugin to the Expo configuration.
Later, you remove the package.
The plugin entry stays behind.

Now Expo may still try to process something that no longer exists.

If you recently removed a native package, check app.json or your app config for leftover plugin entries.

Check for duplicate dependencies

Another useful thing to investigate is duplicate versions of the same package.

For example, your project might end up with different parts of the dependency tree using different versions of a React Native package.

You can inspect the dependency tree with npm:

npm ls

Or check a specific package:

npm ls react-native-screens

If you see multiple versions where you expected one, that can be a clue.

This does not automatically mean that multiple versions are wrong. Some projects legitimately have them.

The important part is to understand why they are there before trying to force everything onto one version.

Check your React Native version too

Expo SDK and React Native versions are closely related.

If you manually changed your React Native version, or upgraded one without properly upgrading the Expo SDK around it, Expo Doctor may start reporting compatibility problems.

For example, if your package.json contains:

{
  "dependencies": {
    "expo": "~54.0.0",
    "react-native": "..."
  }
}

make sure those versions belong together.

If you are upgrading Expo, follow the Expo upgrade process instead of manually changing a bunch of package versions and hoping they line up afterward.

A partially upgraded project is often harder to fix than a project that was left alone.

Run `expo-doctor` again after fixing something

This sounds obvious, but it is an important part of the process.

After making a change, run:

npx expo-doctor

again.

You want to know whether the change actually fixed the problem.

For example:

Before:
✖ Check package versions

After:
✔ Check package versions

Now you know that particular problem is gone.

If another check is still failing, you can work on that one separately.

This is much easier than making ten changes and running Expo Doctor once at the end.

What if Expo Doctor still fails?

If you have corrected the obvious dependency and configuration problems but Expo Doctor is still reporting an error, look at the exact check that is failing.

For example:

✖ Check for common project configuration problems

is not enough information by itself.

Read the lines underneath it.

Expo Doctor normally provides additional information about what it found.

That information is much more useful than the ✖ itself.

Copy the complete section of the output, not just the first line.

Clear the cache if the project still behaves strangely

Clearing caches is not usually the first fix for an Expo Doctor warning.

Expo Doctor is checking your project configuration and dependencies, so a cache reset will not magically fix an incorrect package version.

However, if you have already fixed the reported problem and the project is still behaving as if the old state exists, clearing the Metro cache can help.

For Expo:

npx expo start -c

This is particularly useful after changing dependencies, imports, or other files that Metro may have cached.

Just keep in mind that clearing Metro's cache and fixing Expo Doctor are two different things.

When reinstalling `node_modules` makes sense

If your package configuration looks correct but your installation itself seems broken, reinstalling dependencies can be worth trying.

Delete:

node_modules

Then reinstall:

npm install

Afterward:

npx expo-doctor

And if necessary:

npx expo start -c

I would not delete your lockfile automatically.

Your package-lock.json or yarn.lock records the dependency versions that your project is using. Removing it can cause a completely new dependency tree to be installed, which may introduce more changes than you wanted.

If you specifically need to regenerate the lockfile, that is a different situation.

Be careful when upgrading an Expo project

If the reason for your Expo Doctor errors is that you are trying to move to a newer Expo SDK, do not treat it like a normal dependency update.

An Expo SDK upgrade can involve:

Expo packages
React Native
React
native dependencies
config plugins
Android configuration
iOS configuration
other packages tied to the SDK

If you upgrade only one or two pieces, you can end up with a project where everything is technically installed but the versions do not belong together.

If your goal is specifically to upgrade Expo, follow the upgrade process for the target SDK rather than trying to fix every warning individually.

A simple way to approach Expo Doctor

When I get an Expo Doctor error, I usually work through it in this order:

1. Run Expo Doctor

npx expo-doctor

2. Find the failed check

Do not worry about every line yet. Find the actual ✖ checks.

3. Read the details underneath

That is usually where the useful information is.

4. Check what changed recently

Did you:

install a package?
update Expo?
update React Native?
remove a package?
change app.json?
add a config plugin?
switch branches?

Recent changes are often the best clue.

5. Fix the smallest thing first

If a package version is wrong, fix that package.

If a plugin is left behind, remove it.

If a dependency is no longer needed, uninstall it.

6. Run Expo Doctor again

npx expo-doctor

Then see what remains.

This gives you a much cleaner debugging loop.

One example

Imagine you run:

npx expo-doctor

and get a dependency version warning.

You check package.json and notice that you manually installed a newer version of an Expo-related package a few days ago.

Instead of immediately reinstalling everything, you can try:

npx expo install

or, if Expo identifies the package as needing a correction:

npx expo install --fix

Then run:

npx expo-doctor

again.

If the check passes, you have your answer.

If it does not, you now have a smaller problem to investigate.

That is the part that makes debugging much easier: change something, test it, and use the new output to decide what to do next.

Final thoughts

Expo Doctor is there to help you find problems before they turn into much bigger issues.

The important thing is not to treat every warning as a reason to rebuild your entire project.

Start with the exact check that failed.

If it is a dependency problem, check the package versions.

If it is a configuration problem, check your Expo config.

If you recently installed or removed a package, investigate that change.

And if you are upgrading Expo, make sure you are upgrading the related dependencies together instead of manually mixing versions.

Most importantly, avoid making a dozen changes at once. When you do that, even if the error disappears, you have no idea which change actually fixed it.

If your Expo Doctor output is more complicated—especially when several checks fail at the same time—you can paste the full error into FixMyError and use it to break down what the output is actually telling you.

You can try it at https://www.fixmyerrorapp.com.

Flutter vs React Native for MVP: Which One Should You Actually Choose?

Wed, 02 Sep 2026 21:53:13 +0000

You've validated the idea. You've got a rough spec, maybe a Figma file, and a deadline that's tighter than you'd like. Now you're stuck on a decision that feels bigger than it should: Flutter or React Native.

We get why this question causes so much hesitation. Picking wrong doesn't just mean a slower app; it can mean rebuilding parts of it six months in, paying more for developers than you budgeted, or watching your MVP timeline slip because the framework didn't fit your team's skill set. For a founder trying to get to market before the runway runs out, that's not a small mistake.

This isn't a "Flutter is better" or "React Native is better" article. It's a breakdown of what actually determines the right choice for an MVP- specifically, not for a five-year-old enterprise app, not for a game studio, but for a small team trying to ship something real, get it in front of users, and learn fast.

The Real Question Isn't "Which Framework Is Better"

It's "which framework fits your constraints." For an MVP, three constraints matter more than anything else:

How fast can you build and test
What talent you can actually hire or already have
How much native-feeling polish your app needs on day one

Framework benchmarks and GitHub star counts don't answer any of those. Your team, your budget, and your app's complexity do. If you want a broader look at how Flutter and React Native compare across performance, cost, platform support, and scalability, our React Native vs Flutter comparison covers those differences in more detail.

Flutter: What It's Actually Good At

Flutter, built by Google, compiles to native code and uses its own rendering pipeline rather than relying entirely on native OS UI components. On iOS and Android API 29+, Flutter's Impeller rendering engine is the default, giving the framework a rendering pipeline designed for predictable performance.

Consistent UI across platforms. A button looks and behaves the same on iOS and Android because Flutter draws it itself. For MVPs with a strong design system or a founder who cares about pixel-level consistency, this is a real advantage.

Strong performance for animation-heavy apps. If your MVP leans on custom transitions, gestures, or visual polish, Flutter tends to handle that more predictably than React Native, since it isn't bridging through native UI components.

Single codebase, genuinely. Flutter's "write once" promise holds up better in practice than it used to. Widget-based architecture means less platform-specific patching for most standard app types.

Ecosystem familiarity matters when hiring. Developer surveys such as the Stack Overflow Developer Survey provide a useful snapshot of the technologies developers use and want to learn, which can help put your team's existing skills and hiring options into context.

The trade-off: Flutter apps are written in Dart, a language most web developers haven't touched. If your existing team knows JavaScript or TypeScript, you're either training them or hiring fresh, and Dart talent is a smaller pool than JavaScript talent in most markets.

React Native: What It's Actually Good At

React Native, maintained by Meta, uses JavaScript or TypeScript, and its New Architecture includes Fabric for rendering and direct communication between JavaScript and native code through JSI. That gives it a different set of strengths:

Access to a broader pool of JavaScript/TypeScript talent. If you already have web developers who know React, the learning curve to React Native is short. For early-stage teams that can't afford long onboarding, this matters more than most technical comparisons.

Faster initial builds for standard app patterns. Forms, lists, navigation, and API-driven screens the bread and butter of most MVPs are well-trodden territory in React Native, with a large ecosystem of libraries already built for these use cases.

Easier path to a companion web app. If there's any chance your MVP will need a web version later, React skills transfer more directly than Dart skills.

The trade-off: React Native can still require additional optimization for highly animated, graphics-heavy, or gesture-intensive experiences, particularly when your app relies heavily on platform-specific functionality or complex native integrations. For a straightforward CRUD-style MVP, this is less likely to be a deciding factor.

Where Founders Get This Decision Wrong

We see the same few mistakes repeatedly when teams choose a framework for an MVP:

Choosing based on long-term scale instead of MVP speed. An MVP's job is to test a hypothesis, not to be future-proof for a million users. Optimizing for hypothetical scale before you have real usage data solves a problem you might never have.

Ignoring existing team skills. If you already have a React or JavaScript-heavy team and choose Flutter because a benchmark article said it's faster, you've added a learning curve to an already tight timeline. That cost is real and often larger than the performance gap you were chasing. Research on Flutter and React Native developer trends also highlights differences in developer satisfaction and job-market demand, reinforcing why your team's existing skills should factor into the decision.

Treating this as a permanent decision. Your MVP doesn't need to solve every future technical requirement on day one. But switching frameworks later still means significant redevelopment, so the goal should be to make a sensible decision now, not assume you'll simply rebuild when the product grows.

Skipping a technical spike. Before committing, building a tiny proof-of-concept one core screen, one core interaction in both frameworks for a day or two can surface friction that no comparison article will predict for your specific use case.

A Practical Way to Decide

If you're still unsure, this is roughly how we'd narrow it down:

If your team already knows JavaScript/React, and your MVP is mostly forms, lists, and API calls, lean React Native.
If your MVP depends heavily on custom animation, a highly branded UI, or gesture-based interaction, lean Flutter.
If you're hiring contractors and want the largest available talent pool, lean React Native.
If highly consistent rendering and custom visual interactions matter more than developer availability, lean Flutter.

Neither framework is a wrong answer for most MVPs. The wrong answer is picking one for reasons that don't match your actual constraints.

For teams weighing this decision alongside broader technical planning, work through this exact evaluation with founders before writing a single line of code, mapping the framework choice to the team, budget, and timeline rather than a generic recommendation.

The Bottom Line

Neither Flutter nor React Native is objectively better; they’re better for different situations. The right choice for your MVP comes down to what your team already knows, how visually complex your app needs to be, and how much you’re prioritizing speed versus long-term flexibility.

If you’re still weighing the trade-offs, the most useful next step isn’t reading another comparison. Build a small proof-of-concept in whichever framework you’re leaning toward and see how it actually feels to work with for a day. That will tell you more than any benchmark.

FAQs

1. Is Flutter or React Native faster to build an MVP with?
It depends on your team's existing skills more than the framework itself. A JavaScript-fluent team will usually move faster in React Native; a team with no strong language preference may find Flutter's tooling and hot reload just as fast, sometimes faster for UI-heavy screens.

2. Which framework is cheaper for an MVP?
Cost tracks talent availability more than the technology itself. React Native developers are generally more abundant, which can mean more competitive rates, particularly for freelance or contract hires.

3. Can I switch frameworks later if I start with the wrong one?
Yes, though it means a rebuild of the front end, not a simple migration. Many teams treat the MVP framework choice as temporary by design, planning to revisit it once the product has real user data and funding.

4. Does Flutter or React Native perform better?
For most standard MVP app types forms, dashboards, content feeds the performance difference is negligible to end users. The gap widens for animation-heavy or graphics-intensive apps, where Flutter tends to have an edge.

How to Fix “Unable to Resolve Module” Errors in React Native and Expo

Fri, 28 Aug 2026 13:36:15 +0000

How to Fix “Unable to Resolve Module” Errors in React Native and Expo

If you have been working with React Native or Expo for a while, there is a good chance you have seen an error that looks something like this:

Unable to resolve module ./components/Header from App.js

None of these files exist:
  * components/Header(.native|.ios|.android|.js|.jsx|.ts|.tsx)
  * components/Header/index(.native|.ios|.android|.js|.jsx|.ts|.tsx)

Or maybe:

Unable to resolve module react-native-safe-area-context from App.js

Or the error is buried somewhere inside a much larger Metro bundler log, making it harder to see what is actually wrong.

The annoying part about this error is that "Unable to resolve module" does not always mean the same thing.

Sometimes the file path is wrong. Sometimes the package was never installed. Sometimes it is installed, but your dependencies are in a bad state. And sometimes everything looks correct until you notice that one letter in a filename has the wrong capitalization.

I've run into all of these before.

So instead of randomly deleting node_modules and hoping for the best, here is how I usually work through this error.

First, read the exact module Metro cannot find

This sounds obvious, but the first line of the error usually tells you exactly what Metro is looking for.

For example:

Unable to resolve module ./components/Header from App.js

Metro is trying to find:

./components/Header

relative to:

App.js

That immediately gives you something to check.

Ask yourself:

Does that file actually exist?
Is the path correct?
Is the filename spelled correctly?
Are you importing it from the correct folder?

For example, imagine your project looks like this:

my-app/
├── App.js
└── components/
    └── Header.js

Then this import should work:

import Header from "./components/Header";

But this will not:

import Header from "./component/Header";

One missing s is enough to break the build.

When the error points to a local file, I usually start here before doing anything else.

Check the file name and capitalization

This one can be surprisingly annoying, especially if your app worked on one machine but suddenly fails during a build or after pushing the project somewhere else.

Imagine your file is named:

header.js

But your import says:

import Header from "./components/Header";

Depending on the operating system and environment, this can cause problems because:

header.js

and:

Header.js

are not always treated as the same file.

The same thing can happen with folders:

Components/

vs:

components/

If Metro says it cannot find a local module and the path looks correct at first glance, check every part of the path carefully.

I have lost more time than I would like to admit because of a single capital letter.

Make sure the package is actually installed

Sometimes the missing module is not one of your own files.

For example:

Unable to resolve module react-native-safe-area-context

In that case, check whether the package exists in your project.

You can look inside package.json and see whether it is listed under dependencies.

For an Expo project, it is usually better to install Expo-compatible packages with:

npx expo install react-native-safe-area-context

For a regular React Native project, you would normally use:

npm install react-native-safe-area-context

or:

yarn add react-native-safe-area-context

The exact command depends on your project, but the important part is this:

Do not assume a package is installed just because you used it in your code.

It is also possible that you copied code from another project, tutorial, or GitHub repository without installing all of the required dependencies.

Check if the package name is correct

Another simple but common problem is importing the wrong package name.

For example, you might write something like:

import Something from "react-native-something";

but the actual package name could be slightly different.

Before reinstalling everything, check:

The package name in your import.
The package name in package.json.
The package name from the package documentation.

One small typo can produce the same "Unable to resolve module" error as a completely missing dependency.

Reset the Metro cache

If the file or package exists and the import looks correct, the next thing I would try is clearing Metro's cache.

For Expo:

npx expo start -c

For React Native, you can try:

npx react-native start --reset-cache

Metro caches information to make development faster, but occasionally the cache gets in the way after things change.

For example, you might have:

renamed a file,
moved a folder,
installed a new package,
changed an import,
switched branches in Git.

If the project is still behaving like the old version exists, clearing the cache is a quick thing to try.

I would not start by deleting half the project, though. Resetting the cache is much less destructive.

Check your `node_modules`

Sometimes the dependency is listed in package.json, but something went wrong during installation.

This can happen after:

switching branches,
changing package versions,
interrupting an installation,
moving the project to another computer,
or getting dependency conflicts.

A common approach is to reinstall your dependencies.

First, remove node_modules.

Then run:

npm install

Or, if you use Yarn:

yarn install

After that, start the project again and clear Metro's cache.

For Expo, that could look like:

npx expo start -c

Try to use the same package manager consistently. If your project uses package-lock.json, randomly switching between npm, Yarn, and other package managers can create confusing dependency problems.

Check whether you are importing from the correct location

This is especially easy to miss after moving files around.

Imagine you originally had:

src/
├── screens/
│   └── HomeScreen.js
└── components/
    └── Header.js

Inside HomeScreen.js, you might import:

import Header from "../components/Header";

Then later, you move HomeScreen.js somewhere else:

src/
├── app/
│   └── screens/
│       └── HomeScreen.js
└── components/
    └── Header.js

The old import path may no longer be correct.

You would need to update it accordingly:

import Header from "../../components/Header";

When you see an "Unable to resolve module" error after reorganizing your project, check whether the import path still matches the new folder structure.

Be careful with relative paths

Relative imports can become difficult to read when your project grows.

You might end up with something like:

import Something from "../../../../components/Something";

At that point, it becomes much easier to accidentally use one ../ too many or too few.

If the error points to a long relative path, carefully trace it from the file where the import is written.

For example:

import Header from "../../../components/Header";

Do not just count the dots and slashes quickly. Actually check the location of the current file and follow the path step by step.

It is boring, but it is often faster than trying random fixes.

Check whether the package is compatible with Expo

This is more important if you are using Expo.

You may find a React Native package online, install it successfully, and then run into problems because the version does not match your Expo SDK or the package needs native setup that your project does not currently support.

When possible, use:

npx expo install package-name

instead of blindly installing the latest version with npm.

Expo can choose a version that is compatible with your current SDK.

You can also run:

npx expo-doctor

to check your project for dependency and configuration issues.

If Metro suddenly cannot resolve something after installing or updating a package, compatibility is worth checking.

Watch out for renamed or removed files

Another situation that can cause this error is when your code still imports something that no longer exists.

For example, you rename:

OldButton.js

to:

CustomButton.js

but somewhere in the project, you still have:

import OldButton from "./OldButton";

The error might not happen immediately if that file is not loaded until you visit a specific screen.

This is why I would search the project for the old filename.

Your editor's global search is useful here. Search for:

OldButton

and see whether any old imports are still left behind.

Check `index` files

Sometimes the missing module is actually caused by an index.js or index.ts file.

For example:

components/
├── Button/
│   ├── Button.js
│   └── index.js

You might import it like this:

import Button from "./components/Button";

That usually depends on Metro being able to resolve the folder's index file correctly.

If index.js was deleted, renamed, or contains a broken export, your import setup may stop working.

Check whether the folder contains the file Metro expects.

For example:

export { default } from "./Button";

Or:

export { Button } from "./Button";

The correct setup depends on whether you are using default or named exports.

The important part is to check the whole import chain, not just the first file.

Default exports and named exports are a different problem, but still worth checking

This usually causes a different error, but it can easily appear around the same time.

For example, this is a default export:

export default Header;

And it is imported like this:

import Header from "./Header";

A named export looks like this:

export const Header = () => {
  return null;
};

And it should be imported like this:

import { Header } from "./Header";

If you have already fixed the module resolution error but the app still fails afterward, this is one of the next things I would check.

Sometimes you fix one problem and Metro finally gets far enough to show you the next one.

That is just part of debugging.

Monorepos can make module resolution more complicated

If you are using a monorepo, workspaces, shared packages, or code outside the main app folder, Metro module resolution can become more complicated.

Your project might look something like this:

my-project/
├── apps/
│   └── mobile/
└── packages/
    └── shared/

Then the React Native or Expo app might need to import code from:

packages/shared

In these cases, a normal relative import may not be enough. Metro may need additional configuration to watch or resolve files outside the main project directory.

If you only started seeing the error after introducing a workspace or shared package, I would focus on your Metro configuration instead of repeatedly reinstalling dependencies.

Monorepo issues usually need a more specific fix because the correct setup depends heavily on how the project is structured.

If you use Expo Router, check your imports and project structure

Expo Router adds another layer to how files are organized.

For example, your routes may live inside:

app/

and you may have layouts, route groups, and nested folders.

If you recently moved or renamed route files, double-check your imports and references.

Also make sure the required Expo Router packages are correctly installed for your current Expo setup.

When something goes wrong inside a routing setup, the error message may make it look like a general Metro problem when the real issue is simply an incorrect import somewhere inside a route or layout.

Again, start with the exact module Metro says it cannot find.

Do not immediately delete everything

When developers hit a module resolution error, a common reaction is to do all of this at once:

Delete node_modules
Delete package-lock.json
Clear Metro
Clear npm cache
Reinstall everything
Restart the computer

Sometimes that works.

But it can also make debugging harder because now you have changed five different things and do not know what actually fixed the problem.

I would usually check the error in this order:

Read the exact missing module.
Check whether the file or package exists.
Check the spelling and capitalization.
Check the import path.
Check whether the dependency is installed.
Clear the Metro cache.
Reinstall dependencies if necessary.
Check Expo or React Native version compatibility.
Investigate Metro configuration for more complex project setups.

This is usually much faster than throwing random commands at the project.

A quick example

Imagine you get this error:

Unable to resolve module ./components/ProfileCard from App.js

You check your project and see:

components/
└── Profilecard.js

The problem is the capitalization.

Your import says:

import ProfileCard from "./components/ProfileCard";

But the actual file is:

Profilecard.js

Rename the file so it matches:

ProfileCard.js

Then restart Metro if necessary:

npx expo start -c

That is a simple example, but it shows why reading the exact error matters.

The error is not always asking you to reinstall your entire project. Sometimes Metro is simply telling you that it cannot find something because the path does not exactly match what exists on disk.

Final thoughts

"Unable to resolve module" errors can look more serious than they really are.

Most of the time, the problem comes down to one of these things:

A wrong import path
A missing package
A typo in the package name
A filename capitalization problem
A stale Metro cache
Broken or missing dependencies
A file that was moved or renamed
A more complex Metro configuration issue

The biggest thing I have learned is to start with the exact module Metro says it cannot find.

Do not start by reinstalling the entire project.

Check what Metro is looking for, where it is looking from, and whether that file or package actually exists. In many cases, the answer is much simpler than the size of the error message makes it seem.

If your error is much messier than this—especially if the missing module is buried inside a large Expo, Metro, dependency, or build error—you can also paste the full error into FixMyError and get help breaking down what is actually causing it.

Sometimes the hard part is not finding a fix. It is figuring out which part of a long error log actually matters.

Try it here: https://www.fixmyerrorapp.com

React Native Developer Hiring Models: Freelance, Dedicated or Agency?

Fri, 14 Aug 2026 02:56:09 +0000

Choosing a React Native developer sounds simple until the hiring model starts affecting your budget, control, and delivery timeline.

Finding a React Native developer is not usually the difficult part. The harder decision is figuring out how that developer should work with your business.

You could hire a freelancer for a specific feature, bring in a dedicated developer to work on the product long term, or partner with an agency that handles development as part of a larger team. All three options can work. The problem starts when the hiring model does not match the way your product needs to be built.

If you already know that your project requires React Native expertise, understanding the available React Native developer hiring options can help you evaluate the right type of engagement before you commit to a developer or team.

The decision may look like a simple pricing comparison at first, but it can eventually affect development speed, communication, technical ownership, and ongoing support.

What Goes Wrong When You Choose the Wrong Hiring Model?

The difference between a freelance React Native developer, a dedicated developer, and a development agency is about more than the amount you pay per hour.

The problems usually appear after development is already underway.

A few months into the project, availability can become an issue. A freelancer may have other client commitments, which can make it harder to handle an urgent bug, a new feature, or a release that suddenly needs more attention.

A major release can expose gaps in your development setup. A React Native application may require testing, debugging, native integrations, performance optimization, and app-store preparation. If one person is responsible for everything, the workload can quickly become difficult to manage.

Product growth can turn one developer into a bottleneck. An MVP might be manageable for one person, but adding payments, authentication, analytics, third-party APIs, new screens, and ongoing maintenance can change the workload considerably.

Changing requirements can create friction. Once real users start using an app, the original specification rarely remains untouched. New feedback can lead to changes in features, priorities, or timelines, and some hiring arrangements are better suited to that flexibility than others.

So instead of asking, “Which React Native developer is cheapest?”, it is more useful to ask, “Which hiring model gives this project the right balance of flexibility, control, expertise, and support?”

Freelance React Native Developer: A Practical Choice for Focused Work

Hiring a freelance React Native developer can make sense when you already know what needs to be built and the scope is relatively contained.

For example, you might need someone to add a feature to an existing app, fix a group of bugs, build an MVP, integrate an API, or provide extra development capacity while your internal team handles the rest.

The appeal is straightforward: you get access to React Native expertise without building a permanent team around the project.

The limitation becomes more noticeable when the product keeps growing. If you suddenly need QA, another developer, project management, or ongoing technical support, the original freelance arrangement may no longer be enough.

A freelancer is worth considering when:

You have a clearly defined development task.
The project is relatively small or short-term.
You need additional development capacity.
You already have someone managing the technical work.
You need a specific React Native skill for a particular feature.

Dedicated React Native Developer: Better for Products That Keep Evolving

A dedicated React Native developer is a different arrangement. Instead of bringing someone in for one isolated task, you have a developer working consistently on your product over a longer period.

That continuity matters when the application is going to change frequently. The developer becomes familiar with the codebase, architecture, product requirements, release process, and technical decisions that have already been made.

This can reduce the time spent explaining the same product context repeatedly and make it easier to keep development moving as new requirements appear.

A dedicated developer makes more sense when:

The product will need continuous development.
You expect regular feature releases
You want more control over development priorities.
The developer needs to understand your existing codebase deeply.
Maintenance and improvements will continue after launch.

For a product that is still finding its direction, this model can also provide more flexibility than treating every new requirement as a separate project.

React Native Development Agency: Useful When the Project Needs More Than One Developer

An agency becomes relevant when the project is bigger than the mobile development work itself.

Instead of hiring one person, you are working with a team that may include React Native developers, UI/UX designers, QA specialists, project managers, backend developers, or other technical resources.

That can remove some of the coordination work from your side. You do not necessarily have to find a separate person for every discipline required to get the application from an idea to a production release.

There is a trade-off, though. A broader team and managed delivery structure generally come with a higher overall engagement cost than hiring one developer directly. You also need to be comfortable with how the agency manages communication, resources, timelines, and technical decisions.

An agency may be the better option when:

You need an application developed from start to finish.
Your company does not have a technical team.
The project requires several different specialists.
You need someone to coordinate the development process.
You have a defined product goal but limited internal development resources.

Look Beyond the Hiring Model When Evaluating a React Native Developer

Choosing the engagement model is only one part of the decision. The developer or team still needs the technical ability to handle the requirements of the application.

React Native development can involve considerably more than building screens and connecting components. For example, AWS's React Native implementation guidance covers requirements involving React Native, JavaScript, Node.js, APIs, authentication, databases, iOS, and Android development. That is a useful reminder that technical evaluation should reflect the actual architecture and integrations your application will require.

For a more complex application, ask about previous experience with API integrations, authentication, state management, native modules, performance issues, testing, deployment, and maintaining applications after launch.

A portfolio can also be useful, but screenshots alone do not tell you what the developer actually contributed. Ask which parts they built, what technical problems they encountered, and how the application was maintained after release.

Match the Hiring Model to Where Your Product Is Right Now

The best choice can change as the application moves from an idea to a mature product.

Building an MVP? A freelancer may be enough if the immediate goal is to test the concept without building a large development setup.

Developing the product continuously? A dedicated React Native developer can provide the consistency needed for regular releases, improvements, and maintenance.

Launching a complete application without an internal technical team? An agency may be more practical when development, design, testing, backend work, and project coordination all need to happen together.

Already have an internal development team? Adding a dedicated React Native developer can fill a mobile-specific skills gap without changing the entire team structure.

The hiring decision should follow the product rather than the other way around. Your scope, timeline, technical requirements, internal resources, and expected growth should determine the model you use.

A Broader Look at Hiring Mobile Developers

The same evaluation principle applies when comparing developers across different cross-platform frameworks. The framework itself is only part of the hiring decision; the developer's understanding of architecture, integrations, testing, deployment, and long-term maintenance also matters.

For another perspective on evaluating mobile development talent before starting a project, this guide on what to know before you hire a Flutter developer covers areas such as technical experience, project complexity, dedicated teams, maintenance, portfolios, and development costs.

The specific framework may differ, but the underlying hiring question remains similar: does the developer or team have the experience required for the product you are actually trying to build?

Bottom Line: Which React Native Hiring Model Is Right for You?

There is no universal winner among a freelancer, a dedicated React Native developer, and an agency. A freelancer can be the sensible choice for a focused task, a dedicated developer can provide the continuity an evolving product needs, and an agency can make sense when several specialists are required to deliver the application.

The real mistake is choosing based only on the lowest initial price. A cheaper arrangement can become expensive if it creates delays, limits availability, or forces you to rebuild the development setup later.

The better approach is to start with the product requirements, determine how much technical coverage you actually need, and then choose the hiring model that can support those requirements without creating unnecessary overhead.

How to Fix EAS Build Failed Errors in Expo

Tue, 11 Aug 2026 11:46:41 +0000

There is a particular kind of Expo error that I think almost every developer eventually runs into.

You make a change to your project, run your usual build command:

eas build

and instead of getting a nice .apk or .aab at the end, you get:

Build failed

And that's it.

Well, not really.

If you open the build logs, you get several hundred lines of output containing Gradle tasks, Android dependencies, warnings, stack traces, environment information, and somewhere in the middle of all of that is the actual reason your build failed.

I've been there more times than I'd like to admit.

The frustrating part is that "EAS Build failed" isn't really an error by itself. EAS is just telling you that something went wrong during the build. The actual problem can be a completely different issue.

It might be an Android dependency conflict.

It might be a missing environment variable.

It might be an invalid app.json configuration.

It might be a native package that doesn't work with your current Expo SDK.

Or it might be something as simple as a credentials problem.

So instead of trying random fixes, let's go through how I approach these failures and how to find the actual cause.

First: Don't Focus on "EAS Build Failed"

When you see:

Build failed

it's tempting to search for that exact phrase.

The problem is that thousands of completely different problems can end with the same message.

EAS Build is responsible for building your application. It isn't necessarily responsible for the thing that broke.

For example, your log might eventually contain:

Execution failed for task ':app:mergeDexDebug'

That's an Android dependency/build problem.

Or:

Could not resolve all files for configuration

That's pointing toward dependency resolution.

Or you might see something related to:

Missing environment variable

That's an environment/configuration problem.

And if you see something related to signing credentials, you're dealing with an entirely different category of failure.

The first thing I do is therefore ignore the generic "Build failed" message and find the first meaningful error underneath it.

1. Open the Full EAS Build Logs

Start by looking at the failed build in the EAS dashboard.

You can also list recent builds from your terminal:

eas build:list

Find the failed build and open its logs.

Don't just look at the last few lines.

The last line might say:

Build failed

but that doesn't tell you much.

Instead, search through the logs for terms such as:

ERROR
FAILURE
Error:
Caused by:
Exception
Could not
Unable to

The useful error is often somewhere above the final failure message.

For example, imagine the bottom of your log looks like this:

> Task :app:mergeDexRelease FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:mergeDexRelease'.

> com.android.builder.dexing.DexArchiveMergerException:
  Error while merging dex archives

BUILD FAILED

Build failed

The useful information isn't really:

Build failed

It's:

Execution failed for task ':app:mergeDexRelease'

and whatever caused the DEX merge to fail.

That distinction saves a lot of time.

2. Check Whether the Problem Is Actually Your Expo Configuration

One of the first things I check after an EAS build fails is the project's configuration.

Depending on your setup, this can include:

app.json
app.config.js
app.config.ts
eas.json

A small configuration mistake can prevent the native project from being built correctly.

For example, if you've recently changed:

{
  "android": {
    "package": "com.example.myapp"
  }
}

or added a plugin:

{
  "plugins": [
    "some-native-package"
  ]
}

and the build immediately started failing, that change is worth investigating.

The same applies to permissions, native configuration, app identifiers, and Expo config plugins.

If the failure started immediately after a configuration change, don't assume the EAS service itself is broken.

Look at what changed in your project first.

3. Check Your Expo SDK and Native Dependencies

This is one of the biggest sources of trouble I've encountered with Expo projects.

Expo SDK versions are tied to specific versions of React Native and a collection of native dependencies.

You can have a perfectly valid JavaScript project and still break the native build by installing a package that doesn't fit your current environment.

For example:

npm install some-package

looks harmless.

But if that package contains native Android or iOS code, it becomes part of your native build.

That's where things can get interesting.

Before randomly upgrading packages, check your project:

npx expo-doctor

This can identify common dependency and configuration problems.

If you're using Expo, I also recommend using Expo's package installation command when appropriate:

npx expo install package-name

rather than blindly installing a version with npm.

Expo can select a version that is compatible with your current SDK.

4. If the Error Mentions Gradle, Investigate the Android Build

Sometimes an EAS failure is actually an Android build failure hiding underneath Expo.

For example:

Execution failed for task ':app:mergeDexRelease'

or:

Could not resolve all files for configuration

or:

Duplicate class found

These are not really "Expo errors."

They're Android/Gradle dependency problems occurring during your Expo build.

This distinction matters because searching for:

EAS Build failed

will give you a huge number of unrelated results.

Searching for:

Execution failed for task mergeDexRelease React Native

is much more useful.

That's generally how I approach these logs: follow the most specific error rather than the generic EAS failure.

5. Check Your Environment Variables

Another surprisingly common cause of failed builds is an environment variable that exists locally but doesn't exist in EAS.

For example, your application might expect:

API_URL
SUPABASE_URL
SUPABASE_ANON_KEY

Your local development environment works because those variables exist in your .env file.

Then you create an EAS build and suddenly something breaks.

Why?

Because the remote build environment doesn't automatically have every variable from your local machine.

Check your EAS environment configuration:

eas env:list

Make sure the variables your application actually needs are available in the environment being used for the build.

This is especially important if the failure happens only on EAS while:

npx expo start

works perfectly locally.

6. Check Your EAS Build Profile

Your eas.json determines how your builds are configured.

A typical configuration might look something like:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal"
    },
    "production": {}
  }
}

If the problem only happens with one profile, compare that profile with the one that works.

For example:

eas build --profile preview

might work while:

eas build --profile production

fails.

That immediately gives you another clue.

The problem may not be your entire project. It may be something specific to the build profile.

7. Don't Ignore Credentials Errors

If the log mentions things such as:

credentials
keystore
provisioning profile
certificate
signing

don't start changing Gradle dependencies.

You're probably dealing with app signing or build credentials instead.

For Android, EAS can manage your app signing credentials for you.

You can inspect the credentials with:

eas credentials

If the error is specifically about signing, work through the credential configuration rather than treating it like a code or dependency problem.

This is one of those situations where identifying the category of the error is much more useful than knowing a particular command.

8. If It Worked Before, Ask What Changed

This is probably my favorite debugging question:

What changed immediately before the build started failing?

Don't underestimate how useful this is.

If yesterday you had:

EAS build → SUCCESS

and today you have:

EAS build → FAILED

something changed.

Maybe you:

installed a package
upgraded Expo
changed app.json
changed eas.json
modified environment variables
changed an Android dependency
added a config plugin
changed native code

Start there.

For example, if the failure appeared immediately after:

npx expo install some-package

I would investigate that package before touching ten unrelated parts of the project.

9. Clean Up Before Rebuilding

If you've already made changes trying to fix the problem, make sure you're not debugging an old local state.

For a native project, a clean build can sometimes help:

cd android
./gradlew clean
cd ..

For Expo projects using prebuild, you may also need to regenerate native projects depending on your setup.

But don't use cleaning as your first response to every error.

If the build is failing because a dependency is genuinely incompatible, cleaning won't magically make the dependency compatible.

It only removes cached/generated build artifacts.

The Most Important Part: Find the Root Error

This is the part that took me the longest to appreciate.

When a build log contains hundreds of lines, the error at the bottom isn't necessarily the error you need to fix.

For example:

Task :app:assembleRelease FAILED

is not particularly useful.

Neither is:

Build failed

The useful part might be 30, 50, or even 200 lines above it.

You might eventually find:

Duplicate class androidx.lifecycle.ViewModel

And suddenly the whole situation makes sense.

Or:

Could not resolve com.google.firebase:...

Now you're dealing with a dependency resolution problem.

Or:

Missing environment variable: API_URL

Now you know exactly where to look.

The final error tells you that the build stopped. The underlying error tells you why.

What If Your Error Doesn't Match Any Of These?

This is where things get much more frustrating.

You can search the exact error message and find ten different Stack Overflow answers.

One says to upgrade Gradle.

Another says to delete node_modules.

Another says to run expo prebuild --clean.

Someone else says to downgrade React Native.

And suddenly you're changing five different things without knowing which one actually matters.

I've made that mistake myself.

The problem with large React Native and Expo build logs is that they often contain a lot of information but very little prioritization.

You don't necessarily need another list of 15 possible fixes.

You need to know:

Which part of this particular log is actually causing the failure?

That's also the problem I wanted to solve with FixMyError.

Instead of manually digging through a huge React Native or Expo error log and trying to decide which line matters, you can paste the log into FixMyError and get a focused diagnosis aimed at identifying the most likely cause and the first fix worth trying.

It's particularly useful when your error doesn't fit neatly into one of the common categories above and you're staring at a wall of Gradle, Expo, or native build output wondering where to even start.

You don't need to use it for every error. If the log clearly tells you what's wrong, fix it and move on.

But when the useful information is buried somewhere inside a massive build log, that's exactly when a diagnostic tool becomes useful.

A Simple Workflow I Use Now

When an Expo EAS build fails, I don't immediately start changing dependencies or upgrading packages.

I go through this:

1. Find the actual failure

Don't stop at:

Build failed

Find the underlying error.

2. Identify the category

Is it:

configuration?
dependency?
Android/Gradle?
iOS/Xcode?
environment variables?
credentials?
native module compatibility?

3. Ask what changed

What did you install, upgrade, or modify immediately before the failure?

4. Check the full log

Don't assume the last error line is the root cause.

5. Run the relevant diagnostic tools

For example:

npx expo-doctor

and inspect your EAS configuration and dependencies.

6. Change one thing at a time

Don't simultaneously upgrade Expo, downgrade Gradle, delete node_modules, regenerate native projects, and change your dependencies.

If the build starts working afterward, you won't know what actually fixed it.

7. If the log is still unclear, diagnose the log itself

That's where a tool like FixMyError can save time.

Final Thoughts

An EAS Build failed message can look like a single problem, but it really isn't.

EAS is just the environment where the failure becomes visible.

The actual cause might be hiding in:

Expo configuration
native dependencies
Gradle
Xcode
environment variables
credentials
config plugins
or a package that isn't compatible with your current SDK

The biggest improvement you can make to your debugging process is to stop treating:

Build failed

as the error.

Treat it as the symptom.

Then work backward until you find the first specific failure that actually explains what happened.

And if you're staring at a huge build log and can't tell which of the hundreds of lines actually matters, that's precisely the kind of situation where having something analyze the error for you can be useful.

Happy debugging.

How to Fix `Execution failed for task ':app:mergeDexDebug'` in React Native

Tue, 04 Aug 2026 12:27:52 +0000

You make a small change to your React Native project, install a new package, or upgrade a dependency. Everything looks fine until you try to build your Android app.

Then Gradle stops with something like:

Execution failed for task ':app:mergeDexDebug'.

> com.android.builder.dexing.DexArchiveMergerException:
Error while merging dex archives

Or maybe you see:

Cannot fit requested classes in a single dex file

or:

Duplicate class found

At first glance, this error feels confusing because it happens during the Android build process, not inside your JavaScript or React Native code.

Your components are fine. Your logic is fine.

The problem is usually somewhere inside your Android dependencies.

In this guide, we will go through what causes mergeDexDebug failures, how to identify the real problem, and the fixes that actually work.

What Does `mergeDexDebug` Actually Mean?

When you build a React Native Android app, your JavaScript code is not the only thing being packaged.

Your project also includes native Android dependencies from:

React Native modules
Expo packages
Firebase libraries
AndroidX libraries
Third-party native packages

During the Android build, Gradle converts these Java/Kotlin dependencies into DEX files that Android can run.

The mergeDexDebug task is the step where Android combines those generated DEX files together.

When this step fails, it usually means:

there are too many methods to fit into one DEX file
two dependencies contain the same classes
dependency versions are conflicting

Cause 1: Your App Has Too Many Methods (64K Limit)

One of the most common reasons for this error is Android's method limit.

A single DEX file can only contain around 65,536 methods.

If your project includes many libraries, you can eventually exceed this limit.

The error usually looks like:

Cannot fit requested classes in a single dex file

or:

The number of method references in a .dex file cannot exceed 64K

This happens frequently in projects using packages like:

Firebase
Google Play Services
Maps
Analytics libraries
Multiple native modules

Fix: Enable Multidex

Open:

android/app/build.gradle

Find:

defaultConfig {
}

Add:

defaultConfig {
    multiDexEnabled true
}

Then add the multidex dependency:

dependencies {
    implementation 'androidx.multidex:multidex:2.0.1'
}

After that, clean your build:

cd android
./gradlew clean
cd ..

Then rebuild your app.

Cause 2: Duplicate Classes Between Dependencies

Another common reason is dependency duplication.

You may see something like:

Duplicate class androidx.lifecycle.ViewModel found in modules:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

and

androidx.lifecycle:lifecycle-viewmodel-ktx:2.6.1

This means two libraries are trying to include different versions of the same Android classes.

Gradle does not know which one should be used, so the build fails.

Fix: Align Dependency Versions

Check your Android dependencies.

You can inspect your dependency tree with:

cd android
./gradlew app:dependencies

Look for libraries that appear multiple times with different versions.

For example:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

androidx.lifecycle:lifecycle-viewmodel:2.6.1

The solution is usually to make all related dependencies use the same version.

After updating dependencies, run:

./gradlew clean

and rebuild.

Cause 3: A Recently Installed Native Package Introduced Conflicts

Sometimes the problem appears right after installing a package.

For example:

npm install some-native-library

Everything works until the next Android build.

This happens because native packages are not only JavaScript code. They also add Android dependencies.

A new package can introduce:

conflicting AndroidX versions
outdated libraries
duplicate classes

If the error appeared immediately after installing something new, that package is the first thing I would investigate.

How To Find The Real Cause Faster

Instead of guessing, get more information from Gradle.

Run:

cd android
./gradlew app:assembleDebug --stacktrace

The important part is usually not the final error line.

The useful information is often several lines above it.

Look for:

duplicate class names
conflicting library versions
dependency names

The last line often only says:

Execution failed for task ':app:mergeDexDebug'

but the actual reason appears earlier.

Clean Your Android Build Cache

After changing dependencies, Gradle may still use old build files.

Run:

cd android
./gradlew clean
cd ..

For React Native CLI projects:

npx react-native run-android

For Expo projects:

npx expo run:android

A surprising number of build problems disappear after a proper clean rebuild.

Preventing Future `mergeDexDebug` Errors

A few habits can save a lot of debugging time:

Keep dependencies updated

Old native dependencies are a common source of Android build conflicts.

Avoid installing unnecessary packages

Every native package increases the complexity of your Android dependency tree.

Check changes after adding native libraries

If your build breaks immediately after installing a package, don't start changing random Gradle files.

First check what dependency that package introduced.

Understand the error before applying fixes

A mergeDexDebug failure is not one single problem.

It is a symptom.

The real cause could be:

too many methods
duplicate classes
incompatible versions
a broken native dependency

Finding the cause is usually faster than trying random fixes.

Need Help Diagnosing React Native Errors?

Sometimes build errors are frustrating because the important clue is buried inside hundreds of lines of Gradle output.

That is exactly why I built FixMyError — a tool designed around the real debugging process developers go through.

You can paste your React Native or Expo error log and get a focused diagnosis that explains what is likely causing the problem and what fix is worth trying first.

Instead of searching through dozens of similar Stack Overflow answers, you can start with a clearer direction.

You can check it out here:

FixMyError

React Native Android build errors can look intimidating, but once you understand where the failure happens, most mergeDexDebug problems become much easier to diagnose.

The key is not memorizing commands.

It is learning how to read what Gradle is actually telling you.

How to Fix "Duplicate class ... found in modules" in React Native & Expo

Thu, 23 Jul 2026 12:36:11 +0000

If you've been developing with React Native or Expo for a while, chances are you've had a project that suddenly refuses to build for what seems like no reason.

Maybe you installed a new package. Maybe you upgraded Expo. Maybe you only changed a single dependency. You confidently run your Android build, expecting it to compile like always...

Instead, Gradle greets you with something like this:

Execution failed for task ':app:checkDebugDuplicateClasses'.

Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.8.2.aar and lifecycle-viewmodel-ktx-2.6.1.aar

Duplicate class com.google.android.gms.internal.measurement.zzab found in modules play-services-measurement-base-22.0.0.aar and play-services-measurement-impl-21.6.2.aar

Duplicate class ...

At first glance, the error looks straightforward: there are duplicate classes. Easy enough, right?

Not exactly.

In reality, this is one of those Android build errors that can send you down a rabbit hole of Gradle files, dependency trees and Stack Overflow threads, only to realize the real cause was something completely different.

Let's break down what's actually happening and, more importantly, how to fix it.

Why this error happens

Every Android library included in your project contains compiled Java or Kotlin classes.

When Gradle builds your application, it combines all of those libraries into a single APK or AAB.

If two different dependencies contain the exact same class, Gradle doesn't know which version should be packaged.

Instead of guessing, it stops the build with a Duplicate class error.

The difficult part is that the dependency causing the conflict usually isn't the one shown in the error.

Very often, it's another package pulling in an older or incompatible version behind the scenes.

The most common causes

After seeing this error many times, these are usually the culprits.

1. Two libraries depend on different versions of the same package

This is by far the most common scenario.

For example:

Library A requires:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

while Library B depends on:

androidx.lifecycle:lifecycle-viewmodel:2.6.1

Both versions get added to your dependency graph, eventually leading to duplicate classes.

2. An outdated React Native package

Older React Native libraries often haven't been updated for newer AndroidX or Google Play Services versions.

Even though your project is current, that one dependency may still reference libraries released years ago.

3. Expo SDK upgrades

After upgrading Expo, many native dependency versions change.

If one third-party package hasn't caught up yet, Gradle may end up resolving incompatible versions.

This is especially common immediately after major SDK releases.

4. Mixing manual native configuration with Expo-managed dependencies

Sometimes developers manually add Android dependencies that Expo already manages internally.

The result is two copies of essentially the same library.

How to fix it

There isn't one universal solution, but these steps solve the majority of cases.

Step 1 — Read the duplicated class carefully

Don't focus on the entire error.

Look specifically for the two modules involved.

For example:

lifecycle-viewmodel-2.8.2

lifecycle-viewmodel-ktx-2.6.1

Those names usually point you toward the conflicting dependency.

Step 2 — Find who is importing it

Run:

./gradlew app:dependencies

./gradlew app:dependencyInsight --dependency lifecycle-viewmodel

This shows which package is pulling each version into your project.

It's much faster than guessing.

Step 3 — Update outdated packages

If one library is significantly behind, updating it often resolves the conflict immediately.

Always check whether a newer version exists before trying complicated Gradle workarounds.

Step 4 — Clean the project

Sometimes Gradle continues using cached artifacts.

Try:

cd android

./gradlew clean

Then rebuild.

Step 5 — Regenerate native files (Expo)

If you're using Expo Prebuild:

npx expo prebuild --clean

This recreates the native Android project using your current configuration.

Step 6 — Force dependency versions (only if necessary)

Sometimes you need to force Gradle to use one specific version.

For example:

configurations.all {
    resolutionStrategy {
        force "androidx.lifecycle:lifecycle-viewmodel:2.8.2"
    }
}

Use this carefully.

If two libraries genuinely require incompatible versions, forcing one version may create runtime problems later.

How to avoid this error in the future

While duplicate class errors can't always be prevented, these habits reduce the chances considerably.

Keep Expo SDKs reasonably up to date.
Avoid abandoned React Native libraries.
Update dependencies together instead of one at a time.
Review package compatibility before major upgrades.
Avoid manually adding Android dependencies unless absolutely necessary.

When the error isn't actually the problem

One thing that makes this error frustrating is that the duplicate classes are often just a symptom.

The real issue might be:

an outdated library,
conflicting Firebase dependencies,
mixed AndroidX versions,
incompatible Google Play Services packages,
or an incomplete Expo migration.

That's why simply searching the duplicated class name doesn't always lead to the correct fix.

Understanding why those dependencies ended up together is usually more important than the class itself.

How FixMyError can help

Instead of manually digging through Gradle output, dependency trees and dozens of forum posts, you can paste the full error into FixMyError.

The tool analyzes the build log, identifies the likely source of the conflict, explains what's happening in plain English, and suggests fixes based on the specific dependencies involved.

Rather than treating every duplicate class error as identical, it tries to narrow the problem down to the actual cause behind your particular build failure.

Final thoughts

Duplicate class errors are among the most frustrating Android build issues because the message rarely points directly to the package that's responsible.

The good news is that, in most cases, the problem comes down to dependency resolution rather than something fundamentally broken in your project.

Once you identify which libraries are introducing conflicting versions, the fix usually becomes much more straightforward.

If you're currently staring at a wall of Gradle output wondering where to begin, start by identifying the conflicting modules, trace where they're coming from, and work outward from there.

It takes a bit of patience, but it's almost always easier than blindly trying random fixes from different Stack Overflow threads.

How to fix `global._getAnimationTimestamp is not a function` After Upgrading to Expo SDK 55

Thu, 16 Jul 2026 09:53:20 +0000

I recently spent far more time than I'd like to admit chasing down a hard crash after upgrading a project from Expo SDK 54 to 55.

The app launched fine. Navigation worked. Everything looked normal.

Then the moment a Reanimated animation fired, the app exploded with a red screen:

Render Error

global._getAnimationTimestamp is not a function (it is undefined)

In my case, the crash happened inside a useEffect that called withTiming() on a shared value when a tab gained focus.

My first assumption was a dependency mismatch between react-native-reanimated and react-native-worklets. I checked versions, verified the dependency tree, and even started looking for Babel configuration issues.

Everything looked correct.

As it turns out, the problem wasn't in the JavaScript code at all.

What Is Actually Happening?

At first glance, this error looks like a breaking change inside Reanimated or a bad project configuration.

In reality, it's usually a sync problem between your JavaScript bundle and your native application binary.

The important clue is the function name itself:

_getAnimationTimestamp

This isn't a function your application calls directly. It's one of the internal functions Reanimated expects to find in the native runtime.

Reanimated relies heavily on JSI (JavaScript Interface) to bridge JavaScript directly to native C++ code for performance-critical animation work.

When you upgrade to Expo SDK 55, Reanimated gets upgraded as well (typically from 4.1.x to 4.2.x, depending on your project).

Your Metro server immediately starts serving the updated JavaScript bundle.

The problem is that your custom development client is still running the native code that was compiled before the upgrade.

Now you have two different versions talking to each other:

The JavaScript side expects the newer Reanimated runtime.
The native side is still exposing the older implementation.

The updated JavaScript bundle expects _getAnimationTimestamp to exist.

Your older native client doesn't provide that function yet.

The moment Reanimated tries to use it, the app crashes.

Why Reinstalling Dependencies Doesn't Help

I went through the usual checklist first:

Reinstall dependencies
Verify package versions
Check Babel configuration
Clear node_modules
Run npm install again

None of it fixed the issue.

That's because the problem isn't living in your JavaScript dependencies.

Your packages can be perfectly correct while your device or simulator is still running an outdated native binary.

As long as the native client wasn't rebuilt after the upgrade, the crash will continue to happen.

When You'll Usually See This Error

One thing worth mentioning is that this mostly shows up when you're using a custom development client.

If you're using Expo Go, Expo manages the native runtime for you, so JavaScript and native code generally stay in sync.

This issue is much more common when you're working with:

Custom dev-clients
expo run:android
expo run:ios
Development builds generated through EAS

In those environments, it's entirely possible for Metro to be serving new JavaScript while your device is still running an older native build.

The Fix

A normal JavaScript reload won't solve this.

Pressing r in the Metro terminal only refreshes the JavaScript bundle. It does not rebuild the native application.

To fix the issue, you need both sides of the application running the same version.

Step 1: Clear Metro's Cache

Stop Metro completely and restart it with a clean cache:

npx expo start -c

This removes the possibility of Metro serving stale transformed files.

Step 2: Rebuild the Native Client

If you're building locally, generate a fresh native application:

npx expo run:ios

# or

npx expo run:android

This recompiles the native code using the versions currently installed in your project.

Step 3: Rebuild Your Development Build (EAS)

If you're using EAS development builds, you'll need to generate a completely new build and install it on your device.

eas build --profile development

Once the build finishes, install the new IPA or APK and launch the updated client.

Why This Fix Works

After rebuilding, both sides of the application are finally using the same version of Reanimated:

Metro serves the updated JavaScript bundle.
The native binary contains the matching JSI bindings.

Once those versions line up again, Reanimated can find the functions it expects and the crash disappears.

A Quick Note on Debugging

This was one of those bugs that initially looked like a dependency issue, then a Babel issue, then a Reanimated issue.

In reality, it was just an out-of-date native build.

Problems like this are one of the more frustrating parts of React Native because the error message rarely points to the actual cause. It's easy to spend hours looking at package versions when the real fix is simply rebuilding the native client.

After spending enough evenings digging through stack traces, GitHub issues, and old forum threads, I ended up building a small tool called Fix My Error.

You paste in the error output, and it helps narrow down likely causes and fixes without having to bounce between ten different tabs looking for someone who hit the same problem three years ago.

For this particular error, though, the fix turned out to be much simpler than I expected: clear Metro, rebuild the native client, and make sure your JavaScript bundle and native runtime are actually running the same version.

How to Fix: "Namespace not specified" Gradle 8 Error in React Native & Expo

Thu, 09 Jul 2026 12:45:41 +0000

Fixing the "Namespace Not Specified" Error in React Native and Expo Android Builds

If you recently upgraded a project to React Native 0.73+ or bumped your Expo SDK to version 50+, you may have run into an Android build error that looks something like this:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':react-native-some-old-library'.

> Namespace not specified for group 'react-native-some-old-library'
  and version '1.0.0' as per the Android Gradle Plugin 8.0+ guidelines.

At first glance, it looks like something is wrong with your app. In most cases, it isn't.

The error is usually coming from an older dependency inside node_modules.

Here's what's actually causing it and how to fix it properly.

The Root Cause

Before Android Gradle Plugin (AGP) 8.0, Android libraries could define their package name inside AndroidManifest.xml.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.someoldlibrary">

Starting with AGP 8.0, that is no longer enough.

Every Android module is now expected to define a namespace inside its build.gradle file.

When you upgrade React Native or Expo, your Android tooling gets upgraded as well. The problem is that many older React Native libraries haven't been updated to follow the new requirement.

As soon as Gradle encounters one of those libraries, it stops during configuration and the build fails.

This started showing up much more frequently after Expo SDK 50 and newer React Native releases adopted newer Android tooling.

Before You Change Anything

Look closely at the error message.

Most of the time you'll see something like:

A problem occurred configuring project ':react-native-some-old-library'

That project name is usually the library causing the issue.

A common mistake is to start editing your app's own Gradle files. In most cases, the problem is actually inside the dependency listed in the error.

The Fix: Use patch-package

Since the problem comes from a third-party library, editing files directly inside node_modules isn't a real fix.

The next time you run npm install, your changes will be overwritten.

Instead, make the change once and save it using patch-package.

Step 1: Find the Package Name

Navigate to the library's manifest file:

node_modules/react-native-some-old-library/android/src/main/AndroidManifest.xml

Look for the package attribute:

<manifest
    package="com.someoldlibrary">

Copy that value.

You'll use it as the namespace in the next step.

Step 2: Add the Missing Namespace

Open:

node_modules/react-native-some-old-library/android/build.gradle

Find the android {} block and add the namespace at the top:

android {
    namespace "com.someoldlibrary"

    compileSdkVersion safeExtGet('compileSdkVersion', 34)

    defaultConfig {
        minSdkVersion safeExtGet('minSdkVersion', 21)
        targetSdkVersion safeExtGet('targetSdkVersion', 34)
    }

    // ...
}

Make sure the namespace exactly matches the package name from the manifest.

Step 3: Generate a Patch

From your project root, run:

npx patch-package react-native-some-old-library

This creates a file inside a new patches directory containing the modification you just made.

Commit that file to Git.

Step 4: Apply the Patch Automatically

Open package.json and add a postinstall script:

{
  "scripts": {
    "start": "expo start",
    "android": "expo run:android",
    "ios": "expo run:ios",
    "postinstall": "patch-package"
  }
}

Now whenever someone runs npm install—whether it's you, another developer, CI, or EAS Build—the patch gets applied automatically.

That's It

Clear any caches if needed and run your Android build again.

The build should now complete normally.

More importantly, you won't have to keep making the same edit every time node_modules gets reinstalled.

If you're working with older React Native dependencies, this is usually the cleanest way to handle AGP 8 namespace issues without waiting for the library maintainer to release an update.

How to Fix Apple Silicon CocoaPods Errors Without Messy Terminal Aliases

Mon, 06 Jul 2026 12:55:19 +0000

The Crash

You pull down a fresh React Native repo, or you upgrade your Expo project, navigate to your ios directory, and run your standard installation command:

pod install

Instead of a clean build, your terminal drops a wall of text pointing to a compilation or architecture conflict:

LoadError - dylib library not found for ffi_c - /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.5/lib/ffi_c.bundle

Or you are hit with an explicit architecture clash during compilation:

Ignoring ffi-1.15.5 because its extensions are not built.
Arch mismatch: x86_64 vs arm64

Why the Common Internet Advice is a Trap

If you search for this error on Stack Overflow or Reddit, the top answers almost always tell you to run your terminal in Rosetta mode or force compilation with an architecture flag:

sudo arch -x86_64 gem install ffi
arch -x86_64 pod install

Do not do this.

While this might bypass the error temporarily, it introduces a highly unstable configuration to your machine. It forces an Apple Silicon Mac to use Intel x86 emulation for specific Ruby gems while running an underlying system interpreter that expects native ARM (arm64) code.

This mixed-architecture setup will inevitably break your bundler, conflict with Node native modules, and cause random, hard-to-diagnose failures during local builds.

The real problem isn't your hardware; it's that your environment is attempting to load global, system-level Intel configurations inside a modern ARM environment.

The Fix: Resolving the Conflict Natively

To resolve the issue permanently, you need to purge the conflicting configurations and ensure your dependency manager runs natively on Apple Silicon.

Step 1: Purge the Broken System Gems

First, clear out any global, system-level gems that were compiled incorrectly under mixed architectures.

Run the following command from your root directory to remove CocoaPods configurations managed by the system Ruby installation:

sudo gem uninstall cocoapods

Step 2: Install the Native ARM Version of CocoaPods via Homebrew

Instead of relying on the default macOS system Ruby interpreter to manage your gems, install CocoaPods through Homebrew.

Homebrew automatically detects your M-series architecture and fetches the dedicated, optimized native arm64 binary.

brew install cocoapods

Step 3: Isolate Your Ruby Environment (Optional but Highly Recommended)

Using the default pre-installed macOS system Ruby (/usr/bin/ruby) frequently causes permissions and architecture locks.

For a stable environment, switch to a local Ruby version manager like rbenv or chruby to handle your project dependencies cleanly.

# Install rbenv via Homebrew
brew install rbenv ruby-build

# Initialize rbenv in your shell configuration
rbenv init

# Install and set a modern native Ruby version
rbenv install 3.2.2
rbenv global 3.2.2

Step 4: Clear the Local State and Install Natively

Now that your environment relies on native binaries, clear your project's cached build configurations to ensure no stale artifacts remain:

cd ios
pod deintegrate
rm -rf Podfile.lock

Finally, run your installation command normally.

It will complete natively without requiring any arch -x86_64 prefixes or Rosetta terminal wrappers:

pod install

Wrestling with local environment drift, corrupted build paths, and conflicting architectures can pull you out of the development loop for hours.

If you are tired of decoding cryptic terminal logs and tracking down configuration bugs by hand, take a look at FixMyError. It is a clean diagnostic workspace built to parse your build outputs instantly, giving you clear solutions so you can get right back to building your app.

How to Fix Expo's Cryptic Upgrade Trap: Android Resource Linking Failed (splashscreen_logo not found

Sat, 20 Jun 2026 12:10:50 +0000

How to Fix "resource drawable/splashscreen_logo not found" After an Expo SDK Upgrade

Upgrading your Expo SDK version to keep up with the latest App Store and Google Play requirements is usually a smooth process—until Gradle decides to punch you in the face with a cryptic asset compilation error.

If you just kicked off an Android build or ran a prebuild, and your terminal suddenly spit out a wall of red text looking exactly like this, you are not alone:

A failure occurred while executing com.android.build.gradle.internal.res.LinkApplicationAndroidResourcesTask$TaskAction
> Android resource linking failed
error: resource drawable/splashscreen_logo (aka com.yourcompany.app:drawable/splashscreen_logo) not found.

The worst part about this error is that it doesn't give you a file name, a line number, or any mention of Expo.

It just drops a native Android resource compilation failure and leaves you to figure out the rest.

Let's break down exactly why this happens during Expo upgrades and how to fix it in two minutes flat.

Why This Happens: The Missing Asset Trap

This issue is a classic side effect of how newer Expo SDK versions handle Continuous Native Generation (CNG) via the expo-splash-screen plugin.

In older versions of Expo, if you only wanted a solid background color for your splash screen, you could get away with just defining backgroundColor in your config and skipping the logo image entirely.

The native generator would handle it gracefully.

However, in newer Expo SDK configurations, the prebuild engine has become much more strict.

If the image property is missing from your splash screen configuration, the Expo generator completely skips creating the native Android XML drawable references for the logo.

When the Android Gradle plugin compiles the app layer, it looks into the generated styles for the splash screen layout, tries to link the splashscreen_logo asset, finds a blank void, and crashes the entire build.

How to Fix It

To resolve this, we need to explicitly force the Expo prebuild engine to map a valid drawable resource so Gradle stops complaining.

Step 1: Update Your App Configuration

Open your app.json (or app.config.js) file and locate your plugins array.

Make sure the expo-splash-screen plugin block contains both a background color and an explicit path to a fallback image asset.

Even if you don't actually want a logo on your splash screen, you need to provide a placeholder image (like a tiny 1x1 transparent or solid pixel matching your background color) to satisfy the native compiler.

"plugins": [
  [
    "expo-splash-screen",
    {
      "backgroundColor": "#ffffff",
      "image": "./assets/splash-icon.png"
    }
  ]
]

Step 2: Clear and Regenerate Native Directories

Because native Android build directories heavily cache old configurations, simply changing app.json isn't always enough to clear out the corrupted Gradle state.

Run the following commands in your terminal to wipe the slate clean and force a fresh native generation:

# If you are testing local native builds:
npx expo prebuild --clean

# Or if you are running a fresh release compilation:
npx expo run:android --variant release --no-build-cache

Once the prebuild engine re-runs with the new configuration, it will successfully generate the splashscreen_logo.xml drawable file inside your native directories, and Gradle will breeze right past the linking stage.

Interactive Reference & Live Fix

If you want to view a fully verified configuration block or run this code through an interactive debugger to make sure your syntax matches up perfectly, you can check out the public resolution ledger here:

Fix My Error

Final Thoughts

Native Android build failures often look terrifying because the error message points to generated resources rather than the actual configuration mistake.

In this case, the root cause is usually a missing splash screen image definition after upgrading to a newer Expo SDK version.

Once you add a valid image path and regenerate your native directories, the build should proceed normally.

Have you run into any other weird compilation errors while moving your project up to the latest Expo SDK?

Drop them in the comments below and let's unblock them.

How to Fix "Module Could Not Be Found" in React Native & Expo

Tue, 16 Jun 2026 11:45:20 +0000

We’ve all been there.

You find an awesome library, you run npx expo install, you import it into your code, and you start your development server.

You expect magic.

Instead, your simulator turns blindingly red with an error that looks something like this:

ERROR Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'RNGestureHandlerModule' could not be found.

Verify that your native modules are linked correctly.

Your app is completely bricked, your Metro bundler is acting confused, and you’re left wondering why a package you just installed is allegedly missing from the face of the earth.

Let's look at exactly why this happens and the 3-step checklist to clear it up without losing your sanity.

The Root Cause: JavaScript vs. Native Code

Modern Expo apps are beautifully split into two worlds:

The JS Bundle:

Your components, logic, and regular styles. Metro can hot-reload this in milliseconds.

The Native Layer:

The underlying Kotlin/Java and Swift/Objective-C code that actually talks to the phone's hardware.

When you install a package that uses native code (like react-native-gesture-handler, react-native-reanimated, or a map library), Metro cannot hot-reload native code into an active app binary.

If you are running a pre-built Development Client or using Expo Go, it only knows about the native modules that were compiled the last time you built the app.

It has no idea this new native module exists yet, so the registry panics and throws an Invariant Violation.

The Ultimate "Un-Brick My App" Checklist

Next time this red screen of death pops up, run through these three steps in order.

1. Rebuild the App Binary (The Absolute Must)

Simply restarting the Metro bundler won’t cut it.

You need to recompile your native code so the new library gets bundled into the actual simulator app.

Stop your server and run:

# For Android Simulators / Devices
npx expo run:android

# For iOS Simulators
npx expo run:ios

2. Force a Clean Prebuild (If Using Custom Native Directories)

If you are managing your own android or ios directories and things get desynced, force Expo to regenerate them with the new native dependencies linked:

npx expo prebuild --clean

This removes the generated native projects and recreates them from your Expo configuration, ensuring newly installed native packages are correctly integrated.

3. Nuke the Metro Cache

Sometimes Metro holds onto a stale dependency graph like a grudge.

If you’ve rebuilt the binary and it still complains, start your project while forcing a total cache clearance:

npx expo start -c

This clears Metro's cache and forces it to rebuild the dependency graph from scratch.

Final Thoughts

Native linking issues can feel incredibly frustrating because nothing appears wrong in your JavaScript code.

The problem is usually that your app binary and your JavaScript bundle have fallen out of sync.

Whenever you see errors like:

RNGestureHandlerModule could not be found
Native module cannot be null
TurboModuleRegistry.getEnforcing(...) failed
Module has not been registered

Run through this checklist:

Rebuild the app binary.
Run a clean prebuild if you're using native directories.
Clear the Metro cache.

Most of the time, one of those three steps will get you back up and running.

If you're reading this at 2:00 AM while violently copy-pasting cryptic mobile stack traces into search engines, I feel your pain deeply.

I got so tired of hunting down hidden Gradle errors and obscure CocoaPods issues that I decided to build a tool to automate the headache.

It's called Fix My Error.

I set up a completely registration-free sandbox right on the homepage using this exact native linkage error so you can see how it works in real time without handing over your data.

If you like how it parses the logs, you can drop your own daily errors into the core engine with a free account (which gives you 5 free fixes per day), or check out the Pro tier if you're working in a heavy production environment.

Give the sandbox a spin next time Expo decides to ruin your afternoon, and let me know if it helps your workflow.

How do you usually handle these types of native linking bugs?

Drop a comment if this checklist worked for you, or let me know if there's an obscure Expo error that's currently driving you crazy.

Your Expo App Only Speaks English. Here's How to Fix That in 10 Minutes and make it Global

Sun, 14 Jun 2026 23:34:06 +0000

Most apps speak one language and silently lose everyone else.

If your app is English-only, you are telling a massive portion of the global market to meet you halfway. If you want them to open your app and instantly feel at home—in Spanish, French, Arabic, Hindi, or any of the 200+ global languages they call their own—you usually have to pay the standard "i18n tax."

Look at the traditional i18n package ecosystem on npm. It pulls in over 500,000 active downloads and 180,000 installs in last 7 days.

The demand is massive, but the workflow is stuck in the stone age. Standard i18n forces you into a brutal key-management chore: you invent arbitrary keys, maintain separate massive JSON dictionary files, and manually translate arrays or copy-paste phrases one by one. If you typo a key, your user gets an ugly, broken placeholder string.

We are developers. We are too busy for dictionary maintenance.
That is why I built expo-polyglot-ai—a zero-runtime overhead localization engine that eliminates manual translations entirely.

⚡ The Code IS the Key

With expo-polyglot-ai, you don’t abstract your screens into rigid backend tracking maps. You code naturally. You write plain, normal English directly into your UI layout, and let automated compilation hooks do the heavy lifting.

The Competitor vs. expo-polyglot-ai
The Traditional i18n Chore:

// Breaks your code layout. Forces you to maintain 5 separate JSON files manually.
<Text>{t('auth.dashboard.profile_alert_text_v2')}</Text>

The expo-polyglot-ai Way:

// Write normal text. The build script automatically discovers, translates, and generates your local bundles.
<TranslateText>Welcome back to your security dashboard profile.</TranslateText>

Why Drop It In?

•No Dictionary Maintenance: Just your existing app strings, your LLM of choice (like the Gemini gateway proxy), and a terminal command.
•0ms Native Performance (Persistent Local Caching): This isn't a slow runtime wrapper that makes users wait for an API call on every screen load. The translation happens at build time. Strings are cached locally, meaning each string is only ever translated once. Your user experiences lightning-fast, zero-network locale snapping.
•Layout Defenses Built-In (autoShrink): Different languages occupy different lengths (a short English phrase can turn into a massive sentence in French). By attaching an autoShrink property directly to our custom typography component, the engine micro-scales font sizes down proportionally to preserve your Tailwind/NativeWind layout constraints on smaller devices.

Shift to Autopilot in 5 Quick Steps
1.

npm install expo-polyglot-ai
npx expo install expo-localization @react-native-async-storage/async-storage
npx expo install @react-native-picker/picker  'This provides an easy way to create drop down menu list'

2. Replace Text with TranslateText

jsx
import { TranslateText } from 'expo-polyglot-ai';

// Before
<Text>Welcome back!</Text>

// After — now speaks French, Zulu, Arabic, Hindi... automatically
<TranslateText>Welcome back!</TranslateText>

Write all your strings in the your app inside these You Strings

3.Wrap the Root Layout

import { Picker } from "@react-native-picker/picker";
import {
  FlatList,
  SafeAreaView,
  StatusBar,
  StyleSheet,
  View,
} from "react-native";
// Import your custom package components cleanly
import {
  TranslateText,
  TranslationProvider,
  useTranslation,
} from "expo-polyglot-ai";

// Mock list data with various string lengths to test layout text expansion
const SAMPLE_MOCK_DATA = [
  { id: "1", phrase: "Welcome back to your security dashboard profile." },
  {
    id: "2",
    phrase: "Please tap application settings to modify your configurations.",
  },
  {
    id: "3",
    phrase: "Are you sure you want to confirm your active logout request?",
  },
];

// The developer defines what they built in their specific project
const MY_APP_BUNDLES = {
  fr: require("../../locales/fr.json"),
  es: require("../../locales/es.json"),
  yo: require("../../locales/yo.json"),
};

Export default function MainAppScreen() {
  const { currentLanguage, changeLanguage } = useTranslation();

  return (
    <SafeAreaView style={styles.container}>
      <StatusBar barStyle="dark-content" />

      {/* Dynamic Translated Static Heading */}
      <TranslateText style={styles.heading}>Choose Language</TranslateText>

      {/* 1. Language Dropdown Selector */}
      <View style={styles.pickerContainer}>
        <Picker
          selectedValue={currentLanguage}
          onValueChange={(langValue) => changeLanguage(langValue)}
          style={styles.picker}
        >
          <Picker.Item label="English (Base)" value="en" />
          <Picker.Item label="French (Français)" value="fr" />
          <Picker.Item label="Spanish (Español)" value="es" />
          <Picker.Item label="Yoruba (Èdè Yorùbá)" value="yo" />
          </Picker>
      </View>

      <TranslateText style={styles.subHeading}>
        Dynamic Feed Content apears here
      </TranslateText>

      {/* 2. FlatList implementation with automatic caching layer protection */}
      <FlatList
        data={SAMPLE_MOCK_DATA}
        keyExtractor={(item) => item.id}
        contentContainerStyle={styles.listContainer}
        renderItem={({ item }) => (
          <View style={styles.card}>
            {/* autoShrink is enabled here! If French/Yoruba text gets 
              too long, it safely shrinks the font to keep layouts unbroken.
            */}
          <TranslateText style={styles.itemText}>{item.phrase}</TranslateText>
          </View>
        )}
      />
    </SafeAreaView>
  );
}

export default function App() {
  return (
    /* 3. Wrap your root with the Provider. 
      Replace this URL string with your deployed Google Cloud Function Webhook endpoint!
    */
    <TranslationProvider
      apiUrl="https://"  //url to your deployed agentic ai in the cloud
      bundles={MY_APP_BUNDLES}
      apiKey={"Your X-API-Key"}// Developers pass their own runtime API key safely via configuration or props!

    >
      <MainAppScreen />
    </TranslationProvider>
  );
}

4. Create the polyglot-ai-agent(Engine) using Langgraph and deploy it to GCP.

import functions_framework
import os
from typing import TypedDict, List
import json
from google import genai
from langgraph.graph import StateGraph, END

# === Single-string agent (unchanged) ===
class AgentState(TypedDict):
    text: str
    target_lang: str
    translation: str
    quality_check: bool
    iterations: int

client = genai.Client(api_key=os.getenv("GEMINI_API_KEY"))

def translation_node(state: AgentState) -> dict:
    prompt = f"""
    You are an expert mobile UI string localization assistant. 
    Translate the following text into natural, fluent, context-aware {state['target_lang']}.
    Preserve technical variables and UI intent cleanly.
    Return ONLY the raw translated string.

    Text: "{state['text']}"
    """
    response = client.models.generate_content(model='gemini-2.5-flash', contents=prompt)
    return {
        "translation": response.text.strip(),
        "iterations": state.get('iterations', 0) + 1
    }

def validation_node(state: AgentState) -> dict:
    if state.get('iterations', 0) >= 2:
        return {"quality_check": True}

    validation_prompt = f"""
    Analyze this translated mobile application UI string. 
    Did the translation introduce unnecessary conversational phrasing, markdown, or text quotes? 
    Answer with exactly 'YES' if it is clean or 'NO' if it needs a rewrite.

    Translation: "{state['translation']}"
    """
    response = client.models.generate_content(model='gemini-2.5-flash', contents=validation_prompt)
    is_clean = "YES" in response.text.upper()
    return {"quality_check": is_clean}

def should_continue(state: AgentState):
    if state["quality_check"]:
        return END
    return "translator"

workflow = StateGraph(AgentState)
workflow.add_node("translator", translation_node)
workflow.add_node("validator", validation_node)
workflow.set_entry_point("translator")
workflow.add_edge("translator", "validator")
workflow.add_conditional_edges("validator", should_continue)
agent = workflow.compile()

# === Batch translation (new) ===
def translate_batch(texts: List[str], target_lang: str) -> List[str]:
    """
    Translates a list of strings in a single Gemini call.
    Uses a numbered-list format so the model returns strings in order,
    and we can reliably split the response back into a list.
    """
    numbered_input = "\n".join(f"{i+1}. {t}" for i, t in enumerate(texts))

    prompt = f"""
You are an expert mobile UI string localization assistant.
Translate each of the following numbered UI strings into natural, fluent,
context-aware {target_lang}. Preserve technical variables and UI intent.

Return ONLY a JSON array of strings, in the exact same order as the input,
with no markdown, no code fences, no extra commentary. The array must have
exactly {len(texts)} elements.

Input strings:
{numbered_input}
"""

    response = client.models.generate_content(model='gemini-2.5-flash', contents=prompt)
    raw = response.text.strip()

    # Strip markdown code fences if the model added them anyway
    if raw.startswith("```"):
        raw = raw.split("\n", 1)[1] if "\n" in raw else raw
        if raw.endswith("```"):
            raw = raw[:-3]
        raw = raw.strip()
        if raw.startswith("json"):
            raw = raw[4:].strip()

    try:
        translated = json.loads(raw)
        if not isinstance(translated, list):
            raise ValueError("Response is not a JSON array")
    except (json.JSONDecodeError, ValueError):
        # Fallback: if parsing fails, return originals untouched
        return texts

    # Pad/truncate to match input length defensively
    if len(translated) < len(texts):
        translated = translated + texts[len(translated):]
    elif len(translated) > len(texts):
        translated = translated[:len(texts)]

    return [str(t).strip() for t in translated]

@functions_framework.http
def polyglot_endpoint(request):
    if request.method == 'OPTIONS':
        headers = {
            'Access-Control-Allow-Origin': '*',
            'Access-Control-Allow-Methods': 'POST',
            'Access-Control-Allow-Headers': 'Content-Type,X-API-Key',
            'Access-Control-Max-Age': '3600'
        }
        return ('', 204, headers)

    headers = {'Access-Control-Allow-Origin': '*'}

    provided_key = request.headers.get('X-API-Key')
    expected_key = os.getenv("TRANSLATION_API_KEY")

    if not expected_key or provided_key != expected_key:
        return (json.dumps({"error": "Unauthorized"}), 401, headers)

    try:
        request_json = request.get_json(silent=True)
        target_lang = request_json.get('target_lang')

        if not target_lang:
            return (json.dumps({"error": "Missing target_lang parameter"}), 400, headers)

        # === Batch mode: { "texts": [...], "target_lang": "..." } ===
        texts = request_json.get('texts')
        if texts is not None:
            if not isinstance(texts, list) or not all(isinstance(t, str) for t in texts):
                return (json.dumps({"error": "'texts' must be an array of strings"}), 400, headers)

            if len(texts) == 0:
                return (json.dumps({"translated_texts": []}), 200, headers)

            translated_texts = translate_batch(texts, target_lang)
            return (json.dumps({"translated_texts": translated_texts}), 200, headers)

        # === Single mode (existing behavior, unchanged) ===
        text = request_json.get('text')
        if not text:
            return (json.dumps({"error": "Missing input text or target_lang parameters"}), 400, headers)

        initial_input = {"text": text, "target_lang": target_lang, "iterations": 0}
        final_state = agent.invoke(initial_input)

        response_payload = {"translated_text": final_state["translation"]}
        return (json.dumps(response_payload), 200, headers)

    except Exception as e:
        return (json.dumps({"error": str(e)}), 500, headers)

5. Pop in build folder that holds code for automatically extracting all your app strings and automatically translating all the strings to the languages you wish your app speaks.

Extract-strings.js

const fs = require("fs");
const path = require("path");

const SOURCE_DIR = process.argv[2] || "./src";
const OUTPUT_FILE = process.argv[3] || "strings.json";

const VALID_EXTENSIONS = [".js", ".jsx", ".ts", ".tsx"];

// Matches: <TranslateText ...>SOME TEXT</TranslateText>
// Captures only simple string children (no JSX expressions/interpolation)
const TRANSLATE_TEXT_REGEX =
  /<TranslateText\b[^>]*>([^<{][\s\S]*?)<\/TranslateText>/g;

function walk(dir, files = []) {
  for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
    if (entry.name === "node_modules" || entry.name.startsWith(".")) continue;
    const fullPath = path.join(dir, entry.name);
    if (entry.isDirectory()) {
      walk(fullPath, files);
    } else if (VALID_EXTENSIONS.includes(path.extname(entry.name))) {
      files.push(fullPath);
    }
  }
  return files;
}

function extractFromFile(filePath, strings) {
  const content = fs.readFileSync(filePath, "utf8");
  let match;
  while ((match = TRANSLATE_TEXT_REGEX.exec(content)) !== null) {
    let text = match[1];

    // Collapse whitespace/newlines, trim
    text = text.replace(/\s+/g, " ").trim();

    // Skip empty or expression-only content (e.g. {variable})
    if (!text || text.startsWith("{")) continue;

    if (!strings[text]) {
      strings[text] = { sources: [] };
    }
    const relPath = path.relative(process.cwd(), filePath);
    if (!strings[text].sources.includes(relPath)) {
      strings[text].sources.push(relPath);
    }
  }
}

function main() {
  if (!fs.existsSync(SOURCE_DIR)) {
    console.error(`Source directory not found: ${SOURCE_DIR}`);
    process.exit(1);
  }

  const files = walk(SOURCE_DIR);
  console.log(`Scanning ${files.length} files in ${SOURCE_DIR}...`);

  const strings = {};
  for (const file of files) {
    extractFromFile(file, strings);
  }

  const uniqueStrings = Object.keys(strings);
  console.log(`Found ${uniqueStrings.length} unique strings.`);

  // Output format: array of { text, sources }
  const output = uniqueStrings.map((text) => ({
    text,
    sources: strings[text].sources,
  }));

  fs.writeFileSync(OUTPUT_FILE, JSON.stringify(output, null, 2));
  console.log(`Written to ${OUTPUT_FILE}`);
}

main();

Translate-bundle.jsx

const fs = require("fs");
const path = require("path");

const API_URL =
  "paste your deployed ai agent url here";

const STRINGS_FILE = process.argv[2] || "strings.json";
const OUTPUT_DIR = process.argv[3] || "./locales";
const API_KEY = process.argv[4];
const LANGUAGES = (process.argv[5] || "fr,es,yo,zu,de,it")
  .split(",")
  .map((l) => l.trim())
  .filter(Boolean);

// Delay between requests to avoid rate-limiting / quota issues (ms)
const REQUEST_DELAY_MS = 1200;

// Retry settings
const MAX_RETRIES = 3;
const RETRY_DELAY_MS = 3000;

function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function translateOne(text, targetLang) {
  for (let attempt = 1; attempt <= MAX_RETRIES; attempt++) {
    try {
      const response = await fetch(API_URL, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          "X-API-Key": API_KEY,
        },
        body: JSON.stringify({ text, target_lang: targetLang }),
      });

      if (!response.ok) {
        const errBody = await response.text();
        throw new Error(`HTTP ${response.status}: ${errBody}`);
      }

      const data = await response.json();
      if (!data.translated_text) {
        throw new Error("No translated_text in response");
      }
      return data.translated_text;
    } catch (err) {
      console.warn(
        `  Attempt ${attempt}/${MAX_RETRIES} failed for "${text.slice(0, 40)}..." -> ${targetLang}: ${err.message}`,
      );
      if (attempt < MAX_RETRIES) {
        await sleep(RETRY_DELAY_MS);
      } else {
        throw err;
      }
    }
  }
}

async function main() {
  if (!API_KEY) {
    console.error(
      "Missing API key. Usage: node translate-bundle.js <strings.json> <output-dir> <api-key> [languages]",
    );
    process.exit(1);
  }

  if (!fs.existsSync(STRINGS_FILE)) {
    console.error(`Strings file not found: ${STRINGS_FILE}`);
    process.exit(1);
  }

  const strings = JSON.parse(fs.readFileSync(STRINGS_FILE, "utf8"));
  const texts = strings.map((s) => s.text);

  if (!fs.existsSync(OUTPUT_DIR)) {
    fs.mkdirSync(OUTPUT_DIR, { recursive: true });
  }

  console.log(
    `Translating ${texts.length} strings into ${LANGUAGES.length} languages (${LANGUAGES.join(", ")})...`,
  );
  console.log(
    `Estimated time: ~${Math.ceil((texts.length * LANGUAGES.length * REQUEST_DELAY_MS) / 1000 / 60)} minutes\n`,
  );

  for (const lang of LANGUAGES) {
    const outputFile = path.join(OUTPUT_DIR, `${lang}.json`);

    // Load existing translations to resume
    let bundle = {};
    if (fs.existsSync(outputFile)) {
      bundle = JSON.parse(fs.readFileSync(outputFile, "utf8"));
      console.log(
        `[${lang}] Resuming — ${Object.keys(bundle).length} already translated.`,
      );
    } else {
      console.log(`[${lang}] Starting fresh.`);
    }

    let translatedCount = 0;
    let skippedCount = 0;

    for (let i = 0; i < texts.length; i++) {
      const text = texts[i];

      if (bundle[text]) {
        skippedCount++;
        continue;
      }

      try {
        const translated = await translateOne(text, lang);
        bundle[text] = translated;
        translatedCount++;

        console.log(
          `[${lang}] (${i + 1}/${texts.length}) "${text.slice(0, 50)}${text.length > 50 ? "..." : ""}" -> "${translated.slice(0, 50)}${translated.length > 50 ? "..." : ""}"`,
        );

        // Save progress after every translation (resumable)
        fs.writeFileSync(outputFile, JSON.stringify(bundle, null, 2));

        await sleep(REQUEST_DELAY_MS);
      } catch (err) {
        console.error(
          `[${lang}] FAILED for "${text.slice(0, 50)}...": ${err.message}`,
        );
        console.error(
          `[${lang}] Skipping this string for now — re-run script later to retry.`,
        );
      }
    }

    console.log(
      `[${lang}] Done. Translated ${translatedCount} new, skipped ${skippedCount} cached. Total: ${Object.keys(bundle).length}\n`,
    );
  }

  console.log("All languages processed. Bundles written to:", OUTPUT_DIR);
}

main();

Bind the Automator (package.json)

JSON
"scripts": {
"translate": "node src/build/extract-strings.js src/app strings.json && node src/build/translate-bundle.js strings.json src/locales $EXPO_PUBLIC_POLYGLOT_API_KEY fr,es,de,ja"
}

Run It
Whenever you add copy, build new screens, or scale to new countries, just fire:
Bash

npm run translate

The script analyzes your files incrementally, ignores previously translated pairs to protect your API usage, and builds missing language targets in under 30 seconds.

And just like that your app is multi-lingual. When you build it, all translations will be there locally.

🔥 Retention is Readability
Stop asking your international users to meet you in English. Because an app your users can read is an app they'll actually keep.

📦 npm: npm install expo-polyglot-ai ⭐ GitHub: github.com/Inspire00/expo-polyglot-ai

Built for Expo developers who'd rather ship features than maintain translation files.

Example image 1
Example image 2
Example image 3

Why Your Mobile App Works Perfectly Locally But Crashes Instantly in TestFlight

Thu, 11 Jun 2026 09:01:21 +0000

We’ve all been there. You spend weeks building a feature, testing it on your local simulator or a physical device running a development stream. Everything is butter. No lag, no warnings.

You confidently bundle the app, ship it to TestFlight, wait for Apple to finish processing, download it... and the moment you tap the app icon, it instantly flashes and closes. Hard crash.

Before you lose your mind or start blindly tweaking code, remember that production builds behave entirely differently than development environments.

Here are the four most common reasons your app dies the literal second it hits production, and exactly how to fix them.

1. The Missing Privacy Keys String (`Info.plist`)

If your app requests permissions for features like Location Services (maps, background location), the Camera, or the Photo Library, Apple requires you to explicitly state why in your Info.plist file using usage description keys (like NSCameraUsageDescription or NSLocationWhenInUseUsageDescription).

The Gotcha

In a local development environment, sometimes a framework will let a missing string slide, fallback to a default, or catch the exception gracefully.

The Production Reality

Apple’s iOS security layer will ruthlessly and instantly terminate the application binary on launch if your production code attempts to initialize a library requiring these permissions without the matching text string configured.

The Fix

Double-check your Info.plist (or your Expo app.json plugins). Make sure every single hardware or permission API your code imports has a clear, user-facing explanation string attached.

2. Missing Push Notification Entitlements

If your application includes code for push notifications (even if you haven’t fully wired up the backend yet), your binary needs specific clearance to launch.

The Gotcha

Local builds often bypass strict entitlement checks, or run using a wildcard development provisioning profile that covers everything loosely.

The Production Reality

When built for distribution, if your app contains code for handling remote notifications but the App Store Provisioning Profile doesn't explicitly have the Push Notifications entitlement enabled, the OS will trigger a fatal launch mismatch exception.

The Fix

Head to your Apple Developer Account under Identifiers, verify that your App ID has Push Notifications checked, and regenerate your production profile.

3. Dead Code Elimination & Aggressive Minification

When building locally, your JS bundling or native compilation keeps debug code, metadata, and helper functions intact.

When you build for production, optimization tools like ProGuard/R8 (for Android native engines) or aggressive tree-shaking strip away "unused" code to shrink the binary size.

The Gotcha

Sometimes, these optimization tools accidentally strip away native modules or reflection classes used by third-party packages, assuming they are dead code because they aren't explicitly referenced in the main thread.

The Production Reality

The app boots up, looks for a compiled native library or native method bridge, finds a missing reference, and triggers a fatal crash right during initialization.

The Fix

If you are using native dependencies, make sure your obfuscation/minify configuration files explicitly include rules to keep specific third-party library paths intact.

4. Broken Initialization Flow (Environment Variables)

How does your app determine its backend URL or third-party service tokens?

If you are relying on a local .env file that is git-ignored, those values might not be making it into your production build machine or CI/CD pipeline.

The Gotcha

The app builds successfully because the compiler doesn't care if a string variable is blank or null at build time.

The Production Reality

On launch, your application's root mounting sequence tries to parse an undefined API key or a null base URL during setup. If your code doesn't have a fallback check, it throws a fatal JavaScript or runtime error before the first screen even renders.

The Fix

Always verify that your build dashboard (like Expo Application Services, GitHub Actions, or local production scripts) has your production environment variables explicitly mapped before hitting compile.

How to Stop Guessing and Find the Proof

Stop guessing and changing random lines of code hoping for a miracle. Apple leaves an exact paper trail for immediate launch crashes.

On Your Test Device

Open up the TestFlight app on your iPhone, tap on the application name, scroll down to Crash Logs, and you can view or share the exact file.

Inside Xcode

Navigate to:

Xcode > Window > Organizer > Crashes

Apple aggregates logs directly from TestFlight users here, often highlighting the exact line of compiled code that triggered the crash (look for terms like SIGABRT or EXC_CRASH).

What's the absolute strangest "works locally, breaks in production" bug you've ever had to hunt down?

Let's talk in the comments!

The React Native Native-Dependency Trap: How to Fix Demanding Build Failures Without Nuking node_mod

Tue, 09 Jun 2026 09:26:33 +0000

It’s the same story every time. You run a simple package upgrade, or you decide it's time to bump your Expo SDK version. Locally, JavaScript compiled perfectly. But the second you run a native build, your terminal explodes with hundreds of lines of red text.

On iOS, it’s a cryptic CocoaPods could not find compatible versions for pod or a sudden compilation failure in AppDelegate.mm. On Android, it’s a fatal Gradle lifecycle error or a missing namespace exception.

When native dependencies break, most developers fall back on the classic loop: delete node_modules, delete package-lock.json, clear cache, reinstall, and pray.

But blind-nuking your files rarely fixes the underlying architectural conflict. Here is how to actually diagnose and surgically resolve native dependency hell in modern React Native and Expo apps.

1. The Root Cause: Transitive Dependency Syncing

When you install a library like react-native-reanimated or a native camera module, that library relies on specific versions of underlying native libraries (Pods or Android libraries).

If two different third-party packages require the same native dependency but expect completely different versions, your package manager forces a compromise in JavaScript. But when the native build tool (Xcode or Gradle) steps in, it sees two conflicting native frameworks trying to occupy the same space.

For Expo Users: Always Prioritize the Pinned Versions

Running npm install can bypass Expo's guardrails. Always use:

npx expo install --fix

This forces Expo to look at your current SDK version and automatically downgrade or upgrade conflicting community packages to their exact validated native counterparts.

2. The iOS Podfile.lock Paradox

If your team introduces a package or you pull down main and suddenly iOS won't build, the culprit is usually an out-of-sync Podfile.lock. Running pod install blindly sometimes isn't enough if cached pods are conflicting.

The Surgical Fix

Instead of deleting your whole project configuration, clear the native iOS build cache specifically:

cd ios && pod cache clean --all
rm -rf Pods Podfile.lock
pod install

This forces CocoaPods to re-evaluate the dependency tree from absolute scratch based on your current package.json, without losing your local JS settings.

3. The Android Gradle Namespace Meltdown

With newer versions of Gradle and React Native, the way native Android modules declare their packages has changed (moving entirely to namespace inside build.gradle).

If you are using an older, unmaintained community package, Gradle will completely fail to compile the app on launch.

The Surgical Fix

Instead of waiting for an open-source maintainer to update a dead repository, you can use patch-package or Expo Config Plugins to alter the third-party library’s build.gradle file locally.

Alternatively, ensure your android/gradle.properties has the proper architecture properties enabled:

android.useAndroidX=true
android.enableJetifier=true

Triage Your Terminal Output

The biggest mistake developers make is trying to read the very bottom of a failed build log.

Xcode and Gradle put the actual error at the beginning of the failure block, while the bottom lines are just the generic system telling you the process exited with code 1.

Always scroll back up to locate the first root error flag.

I'm currently tracking down these weird native compilation bugs and building a database of exact solutions for them. If you are currently fighting a messy React Native or Expo native stack trace that makes absolutely no sense, I built a live beta engine to parse them and spit out precise resolutions over at fix-my-error-app.com. Drop your errors in there if you're stuck, and let me know in the comments what your most hated native build error is!

Drop your errors in there if you're stuck, and let me know in the comments what your most hated native build error is!

How to Fix Xcode C++ Compiler Errors in React Native (Yoga / glog / constexpr)

Sat, 06 Jun 2026 09:39:12 +0000

You just upgraded your local development environment, updated Xcode, or bumped a minor patch version in your React Native project. You open your terminal, run your standard iOS build command, and instead of a clean bundling process, the terminal throws a massive wall of raw C++ compiler text at you.

The error logs likely point to internal framework files like Yoga.cpp, glog, or the fmt library, screaming about constexpr or consteval issues, or complaining that a specific language standard identifier is missing.

This is one of the single most frustrating traps in mobile development. Your JavaScript is perfect. Your React components are clean. But your entire build is dead because an underlying C++ compilation standard is fighting your new Xcode tooling.

Why This Happens to JavaScript Developers

React Native relies heavily on a core C++ layout engine called Yoga under the hood. When Apple updates Xcode, they also update the underlying compiler tools (Clang) and shift the default C++ language dialect standard forward (for example, enforcing strict C++20 or C++23 rules).

If an older version of a library in your node_modules uses a syntax decoration that the new compiler now considers illegal or deprecated, the native compilation step fails instantly. Because most mobile developers do not actively write pure C++, looking at a raw Clang compiler failure feels like looking at alien code.

Nuking DerivedData or running pod install twenty times will not change the fact that the compiler rules have changed.

The Solution: Force the C++ Language Standard Backwards

Instead of attempting to manually modify source code deep inside your native node_modules dependencies (which will just get overwritten the next time you install packages), you can use a CocoaPods post-install hook to force the compiler to accept the specific language dialect your dependencies need to pass the check.

Open the Podfile located inside your project's native ios directory. Scroll down to the bottom where your post_install loop lives, and inject this compiler flag override block:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      # Force the compiler to use the stable C++17 standard for all sub-dependencies
      config.build_settings['CLANG_CXX_LANGUAGE_STANDARD'] = 'c++17'
    end
  end
end

By adding this configuration script, CocoaPods will automatically modify the native build files for every single sub-dependency when you run your installation pipeline, forcing Xcode to evaluate the underlying C++ libraries under a compatible standard framework.

Clear the Native Caches and Rebuild

Once the project configurations are updated, you must completely destroy the old build artifacts that were compiled under the conflicting settings, or Xcode will continue to throw the same syntax exception.

Run this quick command chain in your project terminal to wipe the native cache layers and execute a clean compilation:

# Clear Xcode's local compilation cache
rm -rf ~/Library/Developer/Xcode/DerivedData

# Re-evaluate the Podfile with the new compiler hook
cd ios
pod install --repo-update

# Return to root and boot the iOS simulator
cd ..
npx react-native run-ios

As soon as the native build pipelines evaluate your sub-dependencies through the consistent compiler standard, the cryptic layout exceptions will vanish and your bundle will build cleanly.

How to Fix Gradle Error: Unsupported class file major version (React Native & Expo)

Wed, 03 Jun 2026 08:49:58 +0000

If your React Native or Expo Android compilation suddenly crashes with a massive terminal stack trace pointing to an "unsupported class file major version" or claims a class file has the wrong version (e.g., wrong version 65.0, should be 61.0), your environment is caught in a silent version mismatch.

This error almost always triggers right after you upgrade your Expo SDK, bump your React Native core version, or update Android Studio.

Here is exactly why this happens, how to decode the cryptic internal version numbers, and how to get your build compiling cleanly.

Why Did This Happen Suddenly?

When React Native or Expo upgrades their framework architecture, they also upgrade the required version of the Android Gradle Plugin (AGP) inside your project.

Each version of AGP requires a strict minimum version of the Java Development Kit (JDK) to run the compilation pipeline. If your system's global terminal runtime environment or your IDE is still pointing to an older Java runtime, the build engine throws an immediate exception during the semantic analysis phase.

The Version Decoder Cheat Sheet

Java’s compiler doesn't map version numbers logically to their public marketing names. When the Gradle stack trace throws a decimal number at you, use this index to figure out what version your code is demanding:

Class file major version 66.0 = Requires Java 22
Class file major version 65.0 = Requires Java 21 (Common in newer 2025/2026 native modules)
Class file major version 61.0 = Requires Java 17 (The baseline standard for modern React Native)
Class file major version 55.0 = Requires Java 11 (Legacy)

If your terminal says wrong version 65.0, should be 61.0, your build script encountered a dependency compiled for JDK 21, but your system is executing the build toolchain using JDK 17.

Step 1: Find the Exact Path to Your Target JDK

Before making adjustments, you need to locate where the correct JDK version is actually installed on your machine.

On macOS

If you use Homebrew or standard installers, your JDK runtimes are stored under the virtual machine path. You can list all installed environments by running:
/usr/libexec/java_home -V

Copy the path to the required version. It will look similar to this:
/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home

On Windows

By default, standard Java installers or Android Studio bundle their JDK environments inside program directories. Check these common locations:

C:\Program Files\Java\jdk-17\
C:\Program Files\Android\Android Studio\jbr\ (Android Studio's embedded Java runtime)

Step 2: Apply the Explicit Project Override (Recommended)

Instead of fighting global system environment variables that might break older projects on your machine, you can force this specific React Native project to use the correct runtime directory.

Navigate to your project's native android folder: cd android
Open the gradle.properties file.
Add the following property at the bottom, supplying the absolute path you copied in Step 1:

org.gradle.java.home=/Insert/Your/Actual/Target/JDK/Path/Here

(Note: Windows users must escape backslashes in this file, format it like: C:\\Program Files\\Java\\jdk-17)

Step 3: Align Android Studio with Your Terminal

A massive source of frustration is when the project builds fine in the terminal via CLI, but crashes the second you open it in Android Studio (or vice versa). You must align the IDE's build path:

Open your project folder inside Android Studio.
Navigate to Settings (or Preferences on macOS) > Build, Execution, Deployment > Build Tools > Gradle.
Locate the Gradle JDK dropdown menu.
Change it from the default system runtime to match the exact version your project requires (e.g., JDK 17 or JDK 21).
Click Apply and hit Sync Project with Gradle Files.

Step 4: Clear the Aggressive Build Cache

Gradle caches compilation footprints deeply. If you change your Java version without clearing the cache, Gradle will try to read the old, mismatched class files and throw the same error again.

Wipe the execution deck completely by running these commands in your root directory:

Clean the native android directories

cd android
./gradlew clean

Return to root and clear bundler caches

cd ..
npx react-native start --clear

Once the development server reboots and paths match up seamlessly across your terminal, properties file, and IDE, run your run command (npx react-native run-android or npx expo run:android) and the version mismatch error will be gone.

Fixing Gradle TLS handshake_failure on Maven Central (Android Builds)

Tue, 02 Jun 2026 15:56:09 +0000

If your Android native build is constantly failing with a TLS handshake error when trying to download dependencies from Maven Central, the root cause might be an invisible environment variable polluting your Java settings.

The most frustrating part of this error is that your local internet connection is usually completely fine.

The Quick Diagnosis

Open your terminal and test the connection directly to the Maven repository using curl:

curl -I https://repo1.maven.org/maven2/

If curl connects successfully and returns an HTTP 200, but your Gradle build still throws a Received fatal alert: handshake_failure, your network is not the problem. Gradle itself is failing to establish the secure line.

The Root Cause

An environment variable called GRADLE_OPTS is likely injecting broken SSL or JSSE flags into your build process. Specifically, flags like -Djavax.net.ssl.trustStoreType=WINDOWS-ROOT force Gradle to look at system-specific certificate stores that conflict with standard Java behavior, breaking the handshake completely.

The Fix

To resolve this permanently, you need to wipe out the polluted configuration so Gradle can fall back to its clean JDK defaults.

Open your system Environment Variables settings.
Check both the User variables and the System/Machine variables.
Look for GRADLE_OPTS.
Delete the variable entirely from both locations.
Close your IDE, restart your terminal, and run your build again.

Once those injected flags are gone, Gradle will use standard JDK defaults, and your dependency downloads will start succeeding immediately.

I've been spending a lot of my spare time building out a diagnostic tool over at FixMyError to map out environment bugs like this automatically. I just put a live, free sandbox preview on the homepage if you want to see how the engine breaks down terminal stack traces before you ever make an account.

How to fix 'RNGestureHandlerModule could not be found' in React Native & Expo

Sun, 31 May 2026 17:13:39 +0000

Ever run a fresh compilation on a React Native project, change absolutely nothing, and watch your simulator immediately crash with this terminal masterpiece?

ERROR Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'RNGestureHandlerModule' could not be found. Verify that your native modules are linked correctly.

It usually happens right after initializing a navigation library or an interactive UI package that relies on react-native-gesture-handler under the hood.

If you are stuck looking at this stack trace right now, here is exactly why it is broken and how to resolve it in two minutes.

The Root Cause: JavaScript Is Floating Alone

When you run standard web frameworks, importing a package updates your node dependency tree and just works. In React Native, complex packages have two distinct layers:

The JavaScript API layer (the code you write in your editor).
The Native Architecture layer (the actual Swift/Objective-C or Java/Kotlin binaries compiled into the iOS/Android app wrappers).

This error occurs because your Metro bundler successfully loaded the new JavaScript components, but your local native build directory has no idea those new binaries exist yet. The framework is trying to call native routines that simply weren't compiled during your last native build cycle.

How to Fix It

1. For Expo Development Builds (Most Common)

If you are using Expo and running prebuilds, simply running a standard terminal refresh won't pass the native binary threshold. You need to trigger a full native binary compilation sequence to force Expo to link the missing native modules folder structure into your binary targets:

# For Android simulators/devices:
npx expo run:android

# For iOS simulators/devices:
npx expo run:ios

2. For Bare React Native Projects

If you are managing your own native folders directly, you need to clear your build cache and explicitly map the cocoapods dependency layer for iOS:

# Clear out your local build artifacts
watchman watch-del-all && rm -rf node_modules && npm install

# Re-link native iOS libraries
cd ios && pod install && cd ..

# Rebuild your active runtime binary
npx react-native run-ios

Once the compilation pipeline finishes creating the new application layout, the native module registration bridge hooks up properly, and your navigation screens will load without a hitch.

Hopefully, this saves you from losing an hour down a stack trace rabbit hole today.

If you run into other cryptic Expo or React Native native errors while building, I put together a quick web diagnostic tool called FixMyError.dev that contextually reverse-engineers stack traces into human-readable resolutions like this one. There's a free live sandbox on the landing page if you just want to test it out next time your terminal starts throwing errors.

Back to building!

How to fix "Gradle build daemon disappeared unexpectedly" in React Native & Expo

Mon, 25 May 2026 10:18:22 +0000

If you’ve been building mobile apps with React Native or Expo long enough, you’ve definitely hit that brick wall where a standard debug build works perfectly, but the moment you run eas build or try to compile a production AAB/APK for the Play Store, the terminal throws a generic, frustrating crash:

"Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)"

What makes this error so frustrating is that the terminal output rarely tells you why the daemon vanished.

The Root Cause: Out-of-Memory (OOM)

When you trigger a release build, the Node process responsible for bundling your JavaScript files, assets, and third-party native modules spikes heavily in memory. By default, Android's JVM (Java Virtual Machine) doesn't allocate enough heap space to handle these massive compilation steps for modern, dependency-heavy apps.

When the local or CI machine hits its limit, it forcefully kills the Gradle daemon to protect system stability.

The 3-Step Surgical Fix

Instead of blindly deleting your .gradle cache or reinstalling Android Studio, you can resolve this permanently by updating your configuration parameters.

1. Allocate More Heap Space

Navigate to your project's android/gradle.properties file and look for or append the org.gradle.jvmargs line. Increase the maximum heap size (-Xmx) to at least 4GB or 8GB depending on your app size:

org.gradle.daemon=true
org.gradle.jvmargs=-Xmx4g -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

2. Configure EAS Build (If using Expo)

If you are running your builds via Expo Application Services (EAS), you need to tell the remote builders to utilize a larger resource class. Open your eas.json file and specify a larger builder instance under your production profile:

{
  "build": {
    "production": {
      "android": {
        "resourceClass": "large"
      }
    }
  }
}

3. Clear and Reset

Once the files are saved, kill any lingering zombie daemons and clear the old build artifacts so Gradle can start fresh:

cd android
./gradlew clean
./gradlew cleanBuildCache

Taming the rest of your terminal logs

Native Android and iOS build logs can easily stretch to hundreds of lines of total noise, hiding the true dependency mismatch.

If you are currently fighting a different native module error or a breaking CocoaPods mismatch, I built a free developer utility called FixMyError that parses raw terminal dumps instantly. It strips out the conversational AI fluff and gives you the exact surgical terminal command or config change needed to unblock your build layout in 3 seconds.

Give it a spin if you are currently stuck: Try FixMyError Free

Let me know in the comments if increasing the JVM heap size successfully unblocked your production build!

Cross-Platform Music App Development Using Flutter and React Native

Thu, 14 May 2026 07:43:33 +0000

Quick Overview

Flutter (Dart) and React Native (JavaScript) are the top frameworks
for launching music apps on iOS and Android from a single codebase.
Both support essential music features, such as streaming, background
playback, waveform visualization, and media controls, through
well-maintained plugin ecosystems.
Audio performance, low latency, and real-time processing are the
main technical challenges in cross-platform music development.
The right framework depends on your team's skills, the app's
complexity, and performance requirements; there is no
one-size-fits-all solution.
Choosing a cross-platform approach can reduce development time and
costs by 30 to 50 percent compared to building separate native iOS
and Android apps.

You have a great idea for a music app. It could be a tool for collaborative playlists, a practice companion for musicians, or a complete streaming experience. You've done your research and have a development plan. Then reality hits: do you build it for iOS first, Android, or both at the same time? If you choose both, does that mean you need two separate teams, two separate codebases, and twice the budget?

This is the exact problem that has led developers to cross-platform frameworks. Right now, Flutter and React Native are the two main players in this field. This article explains how each framework approaches music app development, the trade-offs involved, and how to make the best choice for your project.

Why Cross-Platform Is a Smart Choice for Music Apps

Before exploring frameworks, note that cross-platform development offers benefits for complex music apps involving real-time audio, background playback, hardware controls, Bluetooth switching, and low-latency features. While native development historically excels here, the gap with cross-platform has narrowed.

Platforms like Flutter and React Native have developed to the point where most music app experiences feel just like native ones in everyday use. And for teams working with music app development services, the ability to ship one codebase to two platforms without sacrificing quality is a genuine competitive advantage.

The economics are clear: one cross-platform team costs less than two native teams, with streamlined maintenance and simultaneous feature releases. For startups and mid-sized companies, this advantage can determine a project's viability.

Flutter in Music App Development: Essential Insights

Flutter, supported by Google, uses Dart and the Skia rendering engine, now replaced by Impeller. Instead of relying on the host platform's UI components, Flutter renders every pixel itself. This approach benefits music apps.

Visual consistency: Waveform displays, equalizer animations, album
art carousels, and custom playback controls look the same on iOS and
Android, eliminating UI rendering frustration across platforms.
Audio handling: Since Flutter lacks a built-in audio engine, you'll
need packages like just_audio, audio_service, and flutter_sound.
just_audio supports streaming, gapless playback, pitch shifting, and
audio effects, suitable for most music apps. audio_service manages
background playback and media notifications, essential for any music
app.
Performance: Flutter's compiled Dart code and rendering pipeline
ensure smooth animations and a responsive UI, but can lag during
heavy platform-channel communication. Handling real-time native audio
processing may cause delays due to Dart-native exchange.
Ideal use cases: They include streaming, music discovery, podcast,
music education, and DJ mixing apps that don't need very low-latency
audio (under 10 ms).

React Native for Music App Development: Essential Insights

React Native, maintained by Meta, uses JavaScript or TypeScript and connects to native components. The newer "New Architecture" adopts JSI instead of the old bridge, significantly narrowing the performance gap with native development.

The JavaScript ecosystem: If your team already works with React or
JavaScript, the learning curve is much shorter. For React Native app
development, the large npm ecosystem means there are libraries for
almost everything a music app might need, from audio processing to
music-theory tools.
Audio libraries: react-native-track-player is the preferred tool for
streaming and queue management, supporting background playback, lock
screen controls, and CarPlay/Android Auto. react-native-sound is good
for basic audio, while react-native-audio-toolkit manages recording.
For advanced DSP, native modules are used.
Consistency: React Native uses native components, so your app adopts
each platform's look and feel. This works well for standard UI
patterns but can be inconsistent for custom designs.
Ideal use cases: It includes music players, streaming services,
social platforms, learning apps, and apps where React or
JavaScript skills are important.

Flutter vs. React Native for Music Apps

Key Technical Considerations Specific to Music Apps

Regardless of which framework you choose, certain challenges are common in cross-platform music development.

Background audio playback: Both frameworks handle this with dedicated
packages: audio_service for Flutter and react-native-track-player for
React Native, but require careful configuration of platform-specific
entitlements and permissions.
Low-latency audio: For apps requiring latency below ~20ms, such as
real-time tuners or live tools, cross-platform frameworks may reach
their limits, and custom native modules might be necessary regardless
of the framework.
Audio streaming and buffering: Managing an app's state is crucial.
Music streaming apps must handle network issues, adaptive bitrate,
and pre-buffering. Both frameworks support this, but implementation
is complex.
Waveform visualization: It uses significant CPU resources. Flutter
CustomPainter and React Native's canvas options, via
react-native-skia or WebGL, handle this. Optimization is vital,
especially on mid-range Android devices.

Conclusion

Choosing between Flutter and React Native isn't about picking the better tool but the right one for your team, timeline, and features. Flutter offers visual consistency and performance predictability, while React Native excels in ecosystem familiarity and native platform integration. Both can produce high-quality cross-platform music apps indistinguishable from native ones.

Understanding your app's technical needs early is crucial. If real-time audio is essential, evaluate how frameworks handle native modules. For streaming or discovery, either framework works, and cross-platform saves are substantial. The best framework is the one your team confidently uses. Choose it, build effectively, and let the music speak.

FAQs

1. Can Flutter or React Native handle real-time audio processing for music apps?

Both handle standard audio tasks well with plugins, but lack out-of-the-box ultra-low-latency (under 10ms) support. Features like live tuning or MIDI require native code in Swift or Kotlin. Still, both frameworks can stream and play without native tweaks.

2. Which is better for a music streaming app, Flutter or React Native?

Both work well. Flutter provides consistent UI and smooth animations, while React Native's react-native-track-player offers a stronger streaming ecosystem with CarPlay and Android Auto support. React Native teams ship faster; Flutter users may prioritize visual appeal.

3. How do cross-platform music apps handle background playback?

Both frameworks handle background audio, lock screen controls, and media notifications via dedicated packages: audio_service in Flutter and react-native-track-player in React Native. You must manually configure platform permissions and test on real devices, as emulators often poorly handle background audio.

4. Is Flutter or React Native faster to develop a music app with?

Your team's expertise influences the choice. JavaScript developers may prefer React Native for speed, while Flutter's clear structure eases Dart's learning curve and scalability. Both frameworks can cut development time by 30-50% versus native iOS and Android.

5. What are the main limitations of cross-platform frameworks for music apps?

Main limitations include low-latency audio, hardware integration, and delayed access to new APIs. Complex audio features often need native modules. But for most consumer music apps like streaming, playback, and visualization, these issues are generally not significant.

5 React Native Errors That Cost Me Hours (And How I Finally Fixed Them)

Thu, 07 May 2026 19:35:56 +0000

5 React Native Errors That Cost Me Hours (And How I Finally Fixed Them)

When I started building my React Native app, I thought the hard part would be designing the app itself.

Turns out, debugging the environment was the real boss fight.

I spent hours — sometimes entire days — fighting build failures, version mismatches, Gradle issues, and errors that made absolutely no sense at first glance. Some of them looked impossible to solve unless you were already an Android engineer.

The worst part is that many tutorials online either skip these issues entirely or give solutions that don’t actually work.

So I decided to write the post I wish I had when I started.

These are 5 real React Native errors I personally ran into while building my app, and exactly how I fixed them.

1. Gradle TLS Handshake Failure

The Error

This one nearly made me quit for the day.

Every time I tried building the Android app, Gradle failed while downloading dependencies from Maven Central with SSL/TLS handshake errors.

The logs looked something like this:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Or sometimes:

Could not GET 'https://repo.maven.apache.org/...'

Why It Happened

At first I thought:

Maven Central was down
my internet was unstable
Java was broken
Gradle was corrupted

None of those were the real issue.

The actual problem was an environment variable called GRADLE_OPTS that was injecting custom SSL settings into Gradle.

It included flags like:

-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT

Curl requests worked perfectly, but Gradle kept failing because its SSL configuration was being overridden.

How I Fixed It

I removed the GRADLE_OPTS environment variable completely from both:

User Environment Variables
System Environment Variables

Then I restarted the terminal and rebuilt the project.

Immediately after that, Gradle downloads started working again.

What I Learned

Sometimes the problem is not React Native itself.

Sometimes the environment around it is sabotaging the build process.

And when debugging network-related Gradle errors, always compare:

browser behavior
curl behavior
Gradle behavior

If only Gradle fails, something in the Java/Gradle SSL configuration is probably interfering.

2. Expo and React Native Version Mismatch

The Error

This one caused random crashes, dependency warnings, and builds failing for reasons that seemed unrelated.

I had packages that technically installed correctly, but internally they were incompatible with my Expo SDK version.

Why It Happened

React Native ecosystems are extremely version-sensitive.

You cannot always:

install the latest package
upgrade random dependencies
mix versions freely

Expo SDKs expect very specific versions of:

React Native
React
Expo packages
Gradle plugins
Android tooling

Even a small mismatch can create chaos.

How I Fixed It

I stopped manually installing random versions and aligned everything with the Expo SDK requirements.

I rebuilt the Android folder using the correct setup and standardized the project around:

React Native 0.80.2
Expo SDK 53
AGP 8.6.1
Kotlin 2.0.21
Gradle 8.13

After everything matched properly, the project became dramatically more stable.

What I Learned

In React Native development, version consistency matters more than having the newest package.

A stable stack beats a cutting-edge stack every single time.

3. Android Build Files Breaking Everything

The Error

At one point, Android builds completely stopped working because of Gradle configuration problems.

The project would either:

fail immediately
fail during dependency resolution
fail during configuration phase

And the logs were massive.

Why It Happened

React Native Android builds rely on multiple interconnected files:

settings.gradle
build.gradle
gradle.properties
app-level Gradle configs

One incorrect line can break the entire build system.

I also learned that newer React Native versions have different setup requirements compared to older tutorials online.

Following outdated tutorials made things worse.

How I Fixed It

I rebuilt the Android configuration using the proper modern structure:

correct includeBuild setup
Expo autolinking configuration
AndroidX enabled
Hermes enabled
New Architecture configuration aligned correctly

I also stopped randomly changing Gradle files without understanding what they did.

That alone saved me future debugging time.

What I Learned

When debugging Android builds:

avoid panic-editing files
change one thing at a time
keep backups of working configs

And most importantly:
older React Native tutorials can become outdated very quickly.

4. Metro Bundler Cache Weirdness

The Error

Sometimes the app behaved as if my code changes didn’t exist.

I would:

modify files
save changes
rebuild the app

…and somehow the old behavior remained.

At first I genuinely thought I was losing my mind.

Why It Happened

Metro bundler caching can occasionally become inconsistent, especially after:

dependency changes
package upgrades
Android rebuilds
native configuration updates

The cache can preserve outdated state even after rebuilding.

How I Fixed It

I cleared everything:

Metro cache
node_modules
Gradle cache
build folders

Commands like these became lifesavers:

npx expo start --clear

And sometimes:

gradlew clean

After cleaning the environment properly, the app started reflecting changes correctly again.

What I Learned

Never underestimate caching problems.

If behavior makes absolutely no sense, clear the caches before wasting hours debugging imaginary problems.

5. The “Works on One Device but Crashes on Another” Problem

The Error

This one was incredibly frustrating because the app seemed completely fine at first.

It worked on one device.
Then suddenly:

crashed on another device
failed on Android builds
behaved differently after rebuilding

Sometimes the exact same code would work one day and fail the next after changing dependencies.

Why It Happened

The real issue was inconsistency between:

Gradle versions
Android Gradle Plugin versions
Kotlin versions
React Native requirements
Expo SDK compatibility

At one point, parts of the Android environment were aligned while others were outdated or incompatible.

React Native Android builds are surprisingly sensitive to tooling mismatches.

Even if the app compiles, hidden incompatibilities can still create unstable behavior.

How I Fixed It

I standardized the entire Android stack instead of fixing things one-by-one.

I rebuilt the project around a stable configuration:

React Native 0.80.2
Expo SDK 53
AGP 8.6.1
Kotlin 2.0.21
Gradle 8.13
compileSdk 35
targetSdk 35

I also cleaned and regenerated parts of the Android setup to remove leftover configuration issues from older versions.

Once everything matched properly, the builds became dramatically more reliable.

What I Learned

A lot of React Native debugging problems are actually ecosystem consistency problems.

You can spend hours trying to patch symptoms individually when the real fix is making the entire toolchain compatible from top to bottom.

Now whenever I hit strange Android issues, the first thing I check is:
“Are all my versions actually meant to work together?”

Final Thoughts

Before building this app, I underestimated how much software development is actually debugging.

Not writing code.
Not designing features.

Debugging.

But strangely enough, this process also made me improve faster than any tutorial ever could.

Every painful issue forced me to:

understand the stack better
read logs more carefully
stay patient under frustration
stop blindly copying fixes from random forums

And honestly, solving these problems feels more rewarding than writing simple features.

If you're currently fighting React Native errors that make no sense:
you're definitely not alone.

Sometimes one line of configuration can cost you six hours.

And sometimes the fix is deleting a single environment variable.

Why React Native Builds Break After Updating Dependencies (And How to Fix It)

Sun, 19 Apr 2026 16:39:23 +0000

Why React Native Builds Break After Updating Dependencies (And How to Fix It)

If you've ever updated your dependencies and suddenly your React Native Android build stops working… you're not alone.

Everything worked before.

You change a few versions, run the build again—and now you're hit with cryptic Gradle errors, build failures, or crashes.

This post breaks down why this happens and how to actually fix it.

The Real Problem

React Native projects depend on a fragile ecosystem of:

Gradle
Android Gradle Plugin (AGP)
Java (JDK)
Firebase / native SDKs
Third-party libraries

When you update even one dependency, you can accidentally break compatibility between them.

Common Symptoms After Updating

You might see errors like:

Execution failed for task ':app:compileDebugJavaWithJavac'
Duplicate class found in modules
Could not determine Java version
A problem occurred configuring project ':app'
App works before update, fails after

The problem is rarely obvious from the error message.

Why This Happens

1. Version Mismatch

Some libraries require:

Specific Gradle versions
Specific Android Gradle Plugin versions
Specific Java versions

If one gets upgraded and others don’t → build breaks.

2. Transitive Dependency Conflicts

When you install or update a package, it may bring its own dependencies.

Sometimes:

Two libraries depend on different versions of the same module
Gradle can't resolve the conflict → build failure

3. Cached / Corrupted Builds

Gradle caches aggressively.

After updates:

Old compiled artifacts remain
Build system gets inconsistent → weird errors

4. Breaking Changes in Libraries

Some updates introduce:

Removed APIs
Changed configurations
New requirements (e.g. minSdk, compileSdk)

How to Fix It (Step-by-Step)

1. Clean Everything

Run:

cd android
./gradlew clean

Then delete:

node_modules
android/.gradle
android/build

Reinstall:

npm install

2. Verify Java (JDK) Version

React Native (especially newer versions) typically requires:

JDK 17

Check:

java -version

Mismatch here breaks builds instantly.

3. Align Gradle + AGP Versions

Check:

android/build.gradle
gradle-wrapper.properties

Make sure:

Gradle version matches AGP requirements
You're not mixing incompatible versions

4. Check compileSdk / targetSdk

In android/app/build.gradle:

compileSdkVersion 34
targetSdkVersion 34

Some libraries require newer SDK versions.

5. Look for Duplicate Dependencies

If you see:

Duplicate class found in modules

You may need to:

Exclude dependencies
Align versions manually

6. Reset Environment Variables (Advanced but Important)

One issue I ran into:

A broken GRADLE_OPTS configuration caused TLS handshake failures and dependency download issues.

Fix:

Remove custom GRADLE_OPTS
Let Gradle use default JDK settings

This is rarely mentioned—but can completely break builds.

7. Rebuild from Scratch

Run:

npx react-native run-android

Key Insight

React Native builds don’t usually break randomly.

They break because: your environment and dependency versions are no longer aligned

Final Advice

When updating dependencies:

Don’t update everything at once
Upgrade incrementally
Test after each change

This makes debugging much easier.

If you're dealing with a specific error after an update, feel free to share it—I’ve probably hit it before

React Native Android Build Failed: Could Not Resolve Dependency (Real Causes)

Mon, 13 Apr 2026 16:06:32 +0000

React Native Android builds can fail for a lot of reasons—but one of the most common (and confusing) ones is:

Could not resolve dependency

If you’ve seen this, you probably also noticed:

the error message is long
it looks very “Gradle-heavy”
and it doesn’t clearly tell you what to fix

Here’s what this error actually means—and how to approach it without wasting hours.

What “Could not resolve dependency” really means

This error usually appears when Gradle tries to fetch or link a dependency and fails.

But the important part is this:

it’s not always a network issue

Most of the time, it’s caused by something in your project setup.

1. Version mismatch (most common cause)

This is the #1 reason behind this error.

Examples:

a library requires a newer React Native version
your Gradle or Android plugin version is outdated
Kotlin version doesn’t match project setup

Even a small mismatch can break dependency resolution.

2. Repository configuration issues

Gradle needs to know where to download dependencies from.

Check your build.gradle files for:

mavenCentral()
google()

If a required repository is missing, Gradle simply won’t find the dependency.

3. Incorrect or missing dependency declaration

Sometimes the issue is simpler than it looks:

typo in dependency name
wrong version specified
dependency removed or renamed upstream

In these cases, Gradle is doing exactly what it should—it just can’t find what you asked for.

4. Caching problems

Yes—sometimes it really is cache.

You might have:

corrupted Gradle cache
stale dependencies
partial downloads

Cleaning can help here:

cd android
./gradlew clean

But keep in mind:
if the issue is structural, cleaning won’t fix it

5. Network / proxy issues

Less common, but still possible:

blocked connections
corporate proxies
SSL issues

If Gradle can’t reach the repository, dependency resolution fails.

6. Autolinking side effects

Sometimes this error shows up after installing a new package.

What’s happening:

the package introduces native dependencies
Gradle tries to resolve them
something in the chain fails

This is why the error often appears right after adding a library.

How to debug it faster

Instead of reacting to the full error message, do this:

Look for the exact dependency name that failed
Check its version compatibility
Verify your repositories
Connect it to the last change you made

This approach is much faster than trying random fixes.

Final thoughts

“Could not resolve dependency” sounds like a simple error—but it can come from multiple causes:

version mismatches
missing repositories
incorrect dependencies
caching issues

If you treat it as a category of problems instead of a single issue, debugging becomes much easier.

And in most cases, the fix is simpler than it first appears.

React Native Android Autolinking Issues: Common Problems and What to Check

Mon, 06 Apr 2026 16:56:36 +0000

Autolinking in React Native is supposed to simplify native module integration—but when it breaks, it can be frustrating and time-consuming to debug.

If your Android build is failing or a package isn’t being recognized, autolinking is often the root cause.

Here are the most common issues and what you should check.

1. Package not properly installed

Before diving deeper, make sure the dependency is correctly installed.

Check:

package.json includes the library
node_modules contains it
You’ve run:

npm install
# or
yarn install

If something feels off, delete and reinstall:

rm -rf node_modules
npm install

2. Missing or outdated Gradle sync

Autolinking depends on Gradle picking up native modules.

Try:

cd android
./gradlew clean

Then rebuild the project:

npx react-native run-android

3. Incorrect React Native CLI detection

Sometimes the React Native CLI doesn’t properly detect the module.

Run:

npx react-native config

Check if your dependency appears under:

dependencies
platforms.android

If it’s missing, autolinking is not working correctly.

4. Manual linking leftovers

If the project was upgraded or previously used manual linking, conflicts can occur.

Check:

MainApplication.java
settings.gradle
app/build.gradle

Remove any old manual linking entries.

5. Incompatible library version

Some libraries:

don’t support your React Native version
require additional setup

Always verify:

the library’s documentation
compatibility with your RN version

6. Android-specific configuration missing

Some packages still require manual steps.

Look for instructions like:

adding permissions in AndroidManifest.xml
modifying build.gradle
adding custom native code

Autolinking doesn’t cover everything.

7. Caching issues

React Native and Gradle caching can cause stale builds.

Try clearing everything:

watchman watch-del-all
rm -rf node_modules
rm -rf android/build
rm -rf android/app/build
npm install
cd android && ./gradlew clean

Final thoughts

Autolinking issues usually come down to:

installation problems
Gradle not syncing correctly
leftover manual configurations
version incompatibilities

Instead of guessing, go step by step through these checks—you’ll usually find the issue faster.

If you’re working a lot with React Native Android builds, you’ll notice most errors fall into a few recurring patterns like these.

React Native Quote Audit - USA

Mon, 02 Mar 2026 14:30:00 +0000

A Quick Test to See if your Quote is Missing Money.
If you are building a React Native app in the USA, a quote can look fine and still be missing big items.

Missing items do not stay missing.
They show up later as extra invoices, delays, and stress.

This post is a simple quote audit.
You can use it in 10 minutes before you sign.

Download the printable checklist PDF
React Native Budget Checklist USA 2026
Use it while reading the quote. Use it again during kickoff.

Section 1
---------
A Quick Test
Is your quote missing money?
Answer yes or no.

Does the quote show a clear list of what is included
Does it show what is not included
Does it include testing time and bug fixing time
Does it include store release work for iOS and Android
Does it include payment failure cases and double order prevention
Does it include device testing on more than two phones
Does it include who owns accounts, code, and access
Does it include change request rules and pricing

If you said no to three or more, the quote is likely missing money.

Section 2
---------
The 5 line items that are usually missing from quotes
These five items are where cost and time jump.

1. Testing and bug fixing
Many quotes say development, but they hide testing.

What this should include
QA testing time
Bug fixing time
Retesting time
Basic regression testing before release

If it is missing, you will pay later.

2. Device list and device testing
Testing on one iPhone and one Android is not real testing.

What this should include
A short device list
At least one mid range Android phone
A plan for bugs that happen on one device only

3. Store release work
Many quotes end at build ready.
Real work still remains.

What this should include
Signing and build setup
Store listing details
Screenshots
Privacy forms
Review notes
Buffer time for rejection and resubmission

4. Payments and failure cases
If your app has payments, the happy path is not enough.

What this should include
Payment failed handling
Payment success but order not confirmed
User taps pay again
Status checks to stop duplicate orders

5. Upload failure handling
If your app has uploads, failures will happen.

What this should include
Slow internet handling
Retry steps
Clear error messages
Safe continue steps so users do not get stuck

Section 3
---------
Questions to ask your developer before you sign
Ask these questions in a call.
If answers are vague, expect trouble.

Scope and plan

What is out of scope for version one
What are the hard screens in this app
Which parts have the most risk

QA and devices

What is your test device list
How many rounds of QA are included
Is bug fixing included or billed extra
What happens when a bug only happens on one Android model

Payments and uploads

How will you stop duplicate orders if payment is slow
How will you handle payment success but order not updated
How will uploads work on slow internet
What happens when users deny camera or photo access

Release and ownership

Who owns the Apple and Google store accounts
Who owns the code repo
Will you hand over all keys and access at the end
How many days do you keep for store review and fixes

Change control

How do you price a change request
What counts as a change
Who approves changes and how fast

If the team cannot answer these clearly, the quote is not ready.

Section 4
---------
Red flags checklist
Here are the red flags. If you see these, pause.

Red flag 1
One total number with no phases

Red flag 2
No QA time mentioned

Red flag 3
No device list mentioned

Red flag 4
No store release work mentioned

Red flag 5
Payments included but no talk about failure cases

Red flag 6
Uploads included but no talk about slow internet failures

Red flag 7
No clear list of what is included and not included

Red flag 8
No mention of who owns the repo and accounts

Red flag 9
No change request rules

Section 5
---------
Example
Medicine delivery app quote audit

Example app
A healthcare shopping app that sells medicines and daily use products.

Core features
Product list
Product page
Cart
Checkout
Order tracking
Prescription upload for some medicines
Notifications for order updates

Now the audit.

What many quotes cover
Screens and basic flows
Basic backend endpoints
Basic login
Basic checkout screen

What many quotes miss
Prescription upload details
Camera and photo permissions
Users deny access
Slow internet upload failures
Retry steps and clear messages

Payment edge cases
Payment success but order status not updated
Users retry and create duplicate orders
Need status checks and duplicate order prevention

Device testing
Android device differences
Notifications blocked by battery settings
Camera issues on certain models

Store release
Privacy forms
Permission text
Store review changes
Resubmission buffer

If the quote does not mention these items, the quote is missing money.

This is why a simple app can move from 8 weeks to 14 weeks.
Not because of new screens.
Because missing items show up late.

Section 6
---------
What a good quote looks like
A good quote is split into clear parts. Each part has a line item and a clear output.

1. Discovery
What it should include
Requirements list
User flows
Out of scope list
Hard screens list
Risk list

What you should receive
A written scope document
A clear list of what is included and not included

2. Design
What it should include
Key screens
All states for key screens
Error messages
Permission screens

What you should receive
Final screen designs
A simple flow for each key feature

3. Development
What it should include
App build work
Backend work
Admin work if needed

What you should receive
Working builds you can test
Access to the code repo

4. Integrations
What it should include
Payments
Push notifications
Analytics
Uploads
Maps or other tools

What you should receive
A list of all tools used
Proof that each tool works on iOS and Android

5. QA
What it should include
Device list
Test plan for key flows
Bug fixing time
Retesting time

What you should receive
A test report or bug list
A stable build before release

6. Release
What it should include
Signing and build setup
Store listing tasks
Screenshots
Privacy forms
Time buffer for review and resubmission

What you should receive
Store ready builds
A release checklist

7. Handover
What it should include
Repo access
Accounts access
Keys
Basic documentation

What you should receive
Full ownership and access
A handover checklist

8. Change rules
What it should include
What counts as a change
How changes are priced
Who approves changes

What you should receive
Clear change request rules in writing

If your quote does not look like this, ask for a rewrite.

I built an open-source IRC client for Android – AndroidIRCX

Thu, 29 Jan 2026 13:38:36 +0000

Hey everyone
I’ve been working on an open-source IRC client for Android called AndroidIRCX, and I wanted to share it with the community.
The goal was to create a modern, lightweight, and privacy-focused IRC app, while preserving the classic IRC experience. The app is actively maintained and continues to evolve based on user feedback.
Key features:
Real-time notifications
Optional app lock (PIN / biometrics)
Supports irc:// and ircs:// deep links
Multiple servers and channels
Reliable auto-reconnect logic
ZNC (bouncer) ready
IRCv3 protocol support
End-to-end encryption (E2EE)
Clean, simple UI with no unnecessary tracking
The entire project is fully open source, and contributions, issues, and pull requests are very welcome.
GitHub:
https://github.com/AndroidIRCx/AndroidIRCx
Google Play:
https://play.google.com/store/apps/details?id=com.androidircx
Website:
https://androidircx.com
This started mostly as a passion project and as a way to keep IRC usable and relevant on modern Android devices.
I’d love to hear your feedback, suggestions, or criticism
Thanks for reading!

React Native to Microservices

Tue, 22 Jul 2025 21:14:32 +0000

In the React Native world we pretty much only worry about calling an endpoint and receiving some data from such endpoint. We are usually blind to all the work that happens in retrieving this data. In this post I am going to trace the api call from when it leaves the device up until the response is received, in a microservices context — naive point of view.

The api call goes to a domain name server to resolve where this api call should go. If I am in Italy, the api call will go to the nearest load balancer around Italy. This is enabled by having geolocation routing.

After the nearest load balancer has been identified. The api call is taken to this load balancer. A load balancer makes sure that when too many users are on their beds watching tiktoks the servers are not overloaded with too many requests at once. It distributes the requests in a manageable manner.

The load balancers can also route the api request to the server that is responsible for processing the request. For example, /videos/1 should go to the videos server instead of the pictures server. The load balancer will then take the /videos/1 request to the videos server.

Once the api request has arrived at the videos server, this server will also communicate with other microservices, maybe analytics, views count, metadata, related videos, and such. The Synchronous part of the request will return to the react native app, the video data and metadata for example, on the other hand, the asynchronous part, analytics for e.g., usually make use of something called message queues to communicate with the other microservices.

Message queues ares queues usually read by other microservices, analytics, metadata, recommendations, each can be subscribed to a message queue. Message queues are ideal because if the service goes down, the message queue will hold the message until the service comes back up and acknowledges the message was processed. This prevent’s losing messages along the way.

This is a high level overview, there is so much in between these processes; ssl, caching, routing algorithm, message exchange, producer, broker, CAP theorem, rate limiting, and so much more.

Building Scalable React Native Apps with Nucleux and Supabase

Tue, 15 Jul 2025 03:35:09 +0000

Combining Supabase's powerful backend services with Nucleux's atomic state management creates a clean, scalable architecture for React Native applications. This guide shows you how to structure authentication and API services using class-based stores that naturally organize your application logic.

The Architecture Pattern

We'll build a three-layer architecture that separates concerns cleanly:

ApiService: Handles Supabase client configuration and lifecycle
SessionStore: Manages authentication state and user sessions
Auth Component: Provides the user interface for authentication

This pattern leverages Nucleux's dependency injection to create a clean separation where each layer has a single responsibility.

Setting Up the API Service

First, create a centralized API service that manages the Supabase client:

// src/services/ApiService.ts
import AsyncStorage from "@react-native-async-storage/async-storage";
import { createClient, SupabaseClient } from "@supabase/supabase-js";
import { Store } from "nucleux";
import { AppState, NativeEventSubscription, Platform } from "react-native";
import "react-native-url-polyfill/auto";

if (
  process.env.EXPO_PUBLIC_SUPABASE_URL === undefined ||
  process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY === undefined
) {
  throw new Error("Missing critical environment variables");
}

class ApiService extends Store {
  public apiClient: SupabaseClient;
  private appStateSubscription: NativeEventSubscription;

  constructor() {
    super();

    this.apiClient = createClient(
      process.env.EXPO_PUBLIC_SUPABASE_URL || "",
      process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY || "",
      {
        auth: {
          storage: AsyncStorage,
          autoRefreshToken: true,
          persistSession: true,
          detectSessionInUrl: false,
        },
      }
    );

    this.appStateSubscription = AppState.addEventListener("change", (state) => {
      if (state === "active") {
        this.apiClient.auth.startAutoRefresh();
      } else {
        this.apiClient.auth.stopAutoRefresh();
      }
    });
  }

  destroy() {
    this.appStateSubscription.remove();
    super.destroy();
  }
}

export default ApiService;

Key Benefits:

Centralized Configuration: Single place to manage Supabase setup
Lifecycle Management: Properly manages token refresh based on app state

Creating the Session Store

The SessionStore handles all authentication logic while staying completely decoupled from UI concerns:

// src/stores/SessionStore.ts
import ApiService from "@/services/ApiService";
import { Session, Subscription } from "@supabase/supabase-js";
import { Store } from "nucleux";

class SessionStore extends Store {
  public session = this.atom<Session | null>(null);
  public initialized = this.atom<boolean>(false);

  private apiService = this.inject(ApiService);
  private authSubscription: Subscription;

  constructor() {
    super();
    
    this.getSession();
    
    this.authSubscription = this.apiService.apiClient.auth.onAuthStateChange(
      (_, session) => {
        this.setSession(session);
      }
    ).data.subscription;
  }

  private async getSession() {
    try {
      const { data: { session } } = await this.apiService.apiClient.auth.getSession();
      this.setSession(session);
    } finally {
      this.initialized.value = true;
    }
  }

  private setSession(session: Session | null) {
    this.session.value = session;
  }

  public async signIn(email: string, password: string) {
    return this.apiService.apiClient.auth.signInWithPassword({
      email,
      password,
    });
  }

  public async signOut() {
    return this.apiService.apiClient.auth.signOut();
  }

  destroy() {
    this.authSubscription.unsubscribe();
    super.destroy();
  }
}

export default SessionStore;

Architecture Highlights:

Dependency Injection: this.inject(ApiService) automatically provides the API client
Atomic State: Only components using session or initialized re-render when these values change
Event Handling: Supabase auth changes automatically update the atomic state
Clean API: Simple methods for sign in/out that any component can use

Building the Auth Component

Finally, create a simple authentication component that consumes the session store:

// components/Auth.tsx
import SessionStore from "@/stores/SessionStore";
import { useStore, useValue } from "nucleux";
import React, { useState } from "react";
import { Alert, StyleSheet, Text, TextInput, TouchableOpacity, View } from "react-native";

export default function Auth() {
  const sessionStore = useStore(SessionStore);
  const session = useValue(sessionStore.session);
  const initialized = useValue(sessionStore.initialized);

  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [loading, setLoading] = useState(false);

  const handleSignIn = async () => {
    if (!email || !password) {
      Alert.alert("Error", "Please fill in all fields");
      return;
    }

    setLoading(true);
    try {
      const { error } = await sessionStore.signIn(email, password);
      if (error) Alert.alert("Error", error.message);
    } finally {
      setLoading(false);
    }
  };

  const handleSignOut = async () => {
    const { error } = await sessionStore.signOut();
    if (error) Alert.alert("Error", error.message);
  };

  if (!initialized) {
    return <Text>Loading...</Text>;
  }

  if (session) {
    return (
      <View style={styles.container}>
        <Text style={styles.title}>Welcome back!</Text>
        <Text>Signed in as: {session.user.email}</Text>
        <TouchableOpacity style={styles.button} onPress={handleSignOut}>
          <Text style={styles.buttonText}>Sign Out</Text>
        </TouchableOpacity>
      </View>
    );
  }

  return (
    <View style={styles.container}>
      <Text style={styles.title}>Sign In</Text>
      
      <TextInput
        style={styles.input}
        placeholder="Email"
        value={email}
        onChangeText={setEmail}
        autoCapitalize="none"
        keyboardType="email-address"
      />
      
      <TextInput
        style={styles.input}
        placeholder="Password"
        value={password}
        onChangeText={setPassword}
        secureTextEntry
      />
      
      <TouchableOpacity 
        style={[styles.button, loading && styles.buttonDisabled]} 
        onPress={handleSignIn}
        disabled={loading}
      >
        <Text style={styles.buttonText}>
          {loading ? "Signing In..." : "Sign In"}
        </Text>
      </TouchableOpacity>
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 20, justifyContent: "center" },
  title: { fontSize: 24, fontWeight: "bold", marginBottom: 20, textAlign: "center" },
  input: { borderWidth: 1, borderColor: "#ddd", padding: 12, marginBottom: 10, borderRadius: 5 },
  button: { backgroundColor: "#007AFF", padding: 12, borderRadius: 5, marginTop: 10 },
  buttonDisabled: { opacity: 0.5 },
  buttonText: { color: "white", textAlign: "center", fontWeight: "bold" },
});

Why This Architecture Works

1. Clear Separation of Concerns
Each layer has a single responsibility, making the code easier to test and maintain.

2. Automatic Reactivity
Components automatically re-render when authentication state changes, without manual subscription management.

3. Reusable Business Logic
The SessionStore can be used across multiple components without duplicating authentication logic.

4. Type Safety
TypeScript ensures you catch authentication-related bugs at compile time.

5. Easy Testing
Each store can be unit tested independently of React components.

The Result

This architecture gives you a robust foundation for React Native apps that need authentication. The SessionStore becomes the single source of truth for authentication state, while the component layer focuses purely on user interface concerns.

Want to explore more patterns? Check out the complete Nucleux documentation and see how this same approach scales to complex applications with multiple data stores and API services.

Ready to build your next React Native app? Try combining Nucleux with Supabase for a powerful, type-safe development experience.

Starting a new web app with a React project, should you go with React JavaScript or TypeScript?

Tue, 24 Jun 2025 07:48:50 +0000

Deciding between React with JavaScript and React with TypeScript is an important early choice.

Go with React + TypeScript if:

You want type safety – TypeScript helps catch bugs during development by checking types.
Your project will grow in complexity or involve a team – It’s much easier to maintain and refactor code with TypeScript.
You want better editor support (autocomplete, refactoring, etc.) – TS improves the development experience in VS Code and similar editors.
You’re comfortable learning/using TypeScript or are willing to invest a bit of time upfront to learn it.

Pros:

Fewer runtime errors
Better documentation via types
Easier onboarding for new developers
Huge ecosystem support (React + TS is now the standard in many teams)

Go with React + JavaScript if:

You want to move quickly and keep things simple, especially for prototypes or MVPs.
You’re not yet familiar with TypeScript and don’t want the learning curve at the moment.
The project is small or throwaway, and long-term maintainability is not a concern.

Pros:

Faster to start
No need to learn types or manage TS config
Slightly simpler build tooling

Recommendation (TL;DR):

Use React + TypeScript unless you have a strong reason not to.
It's now the default for many professional React projects and will pay off as your codebase grows.

Create a Video Chat App in React Native with Pre-built API

Tue, 06 May 2025 06:08:30 +0000

Want to create a video chat app like Zoom, Google Meet or MS Teams for your business? In this tutorial, we'll walk through how to build a 1:1 video calling app.

We will start with creating a video call feature where one user can initiate a video call and the other can receive, accept or reject it.

The app will be built in React Native and we'll use a pre-built video call solution from MirrorFly.
If you already have an app, you can use the below steps to add the video chat feature. If not, you can use this sample app, upon which you'll add the video calling features as instructed below.

Since we'll build the app in React Native, we'll need the below pre-requisites:

Node.js: >= 18.20.4
npm: >= 10.7.0
React Native: >= 0.73.0 and <=0.75.4
SDK License Key Firebase Cloud Messaging (FCM) setup for Android
VOIP push notification support for iOS

Note: This post assumes you have the basic understanding on handling React Native.

Step 1: Install the SDK

Install the SDK from npm:

npm install mirrorfly-reactnative-sdk

The SDK will have all the methods to initialize the call, register the user, connect and make calls.

import { SDK } from 'mirrorfly-reactnative-sdk';

After installation, this line imports the SDK to get the methods initializeSDK, register, connect, getJid, into your project

Step 2: Adding Peer Dependencies

"react-native-webrtc": "124.0.4",
"react-native-background-timer": "^2.4.1",
"react-native-permissions": "^5.2.1"
}

To support the SDK to run without any errors, you'll need the following npm packages:

react-native-webrtc: This package provides the JavaScript access to
native WebRTC APIs for enabling real-time audio and video streams on
your app. It exports objects like RTCPeerConnection, MediaStream,
MediaDevices, etc.
react-native-background-timer: This keeps your app awake when calls
are ongoing. This package is the one that provides Methods like
setInterval, setTimeout, clearInterval, etc., that continue to work
even when the app is minimized.
react-native-permissions: This package is responsible for initiating
requests for mic, camera, and notification permissions from the OS.
It checks and asks for runtime permissions with methods like
check(), request(), and openSettings().

Step 3: Initializing the SDK

When you initialize the SDK, you need it to listen to the connection status. For this you'll need to define a callback as mentioned below.

const connectionListener = (response) => {

if (response.status === "CONNECTED") {

console.log("Connected to MirrorFly");

} else if (response.status === "DISCONNECTED") {

console.log("Disconnected from MirrorFly");

}
};

This line logs a message when the client connects or disconnects from the server.

const initializeObj = {

apiBaseUrl: "https://api-preprod-sandbox.mirrorfly.com/api/v1",
licenseKey: "YOUR_LICENSE_KEY_HERE",
isTrialLicenseKey: true,
callbackListeners: {

connectionListener,
// Add more listeners if needed (e.g., incomingCallListener)

},
};

apiBaseUrl: URL of the backend you are connecting to.
licenseKey: Your SDK key for authentication.
isTrialLicenseKey: Boolean to indicate trial mode.
callbackListeners: List of event listeners your app reacts to.

await SDK.initializeSDK(initializeObj);

Now, this line initializes the SDK with your configuration and sets up event listeners. Most importantly, this must be called before you use other functions in the SDK like register() or connect().

Step 4: Registering a New User

You'll need to import modules for:

FCM (Android push token)
VOIP push notifications (iOS)

For this, use this line:

import messaging from '@react-native-firebase/messaging';

import RNVoipPushNotification from 'react-native-voip-push-notification';

Here,
addEventListener('register', callback): Listens for the VOIP token from iOS.
messaging().getToken(): Gets the FCM token from Firebase for Android.
SDK.register(...): Registers a new user using:

user123: Unique user ID
fcmToken: Required for push calls on Android
voipToken: Required for VOIP on iOS

DEV ? false : true: Sets IS_PRODUCTION based on dev or release mode

RNVoipPushNotification.addEventListener('register', async (voipToken) => {

const fcmToken = await messaging().getToken();
await SDK.register('user123', fcmToken, voipToken, DEV ? false : true);
});

Next, to receive VoIP push notification on iOS, you need to trigger the registration process by adding this line:

RNVoipPushNotification.registerVoipToken();

Step 5: Connecting the User

Using the credentials obtained from the register() step, this line logs the registered user into the server.

await SDK.connect("user123", "securePassword123");

Once connected, the user will be able to start or receive calls. The connection listeners will start monitoring the connection status.

Step 6: Getting User JID

Next, add this line:

const userJid = SDK.getJid("user123");

This will return the Jabber ID (JID) of a user. JID is an identification system used internally by the XMPP system to uniquely identify users. You can therefore use userJid when initiating or accepting calls.

With these steps, you’ve built the core structure of a one-on-one video calling app. You now have

Real-time communication between users
Customizable call UI
Call control features (answer, decline, hang up)
SDK-level connection and call event tracking

From here, you can implement beyond the basics like outgoing and incoming call UI, Audio controls (mute/unmute), and analytics.

Got queries? Feel free to add your questions in the comments. I'd be more than happy to join a healthy discussion on the technologies.

Learn more in this video tutorial, How to build a video chat app with React Native?

Coder Legion - Recent posts tagged react-native

How to Fix Metro Bundler Stuck or Not Starting Errors in React Native

1. Identify What Metro Is Actually Doing

2. Stop Metro and Start It Again

If you're using Expo

If you're using React Native CLI

3. Check Whether Port 8081 Is Already in Use

On Windows

On macOS or Linux

4. Clear Metro's Cache When Bundling Gets Stuck

5. Check Your Dependencies Before Reinstalling Everything

6. Check Metro and Expo Configuration

7. If Metro Runs but the App Cannot Connect

Check the development-server URL

If you're using Expo

If you're using an Android emulator

8. Don't Confuse a JavaScript Error With a Metro Startup Failure

9. When None of These Fixes Works

Final Thoughts

One Design System, Two Runtimes: Sharing Contracts Between React and React Native

The real goal is consistency, not identical code

Put shared semantics in a platform-neutral contract

Let each platform extend the contract honestly

Healthy divergence is part of a good cross-platform API

Share design decisions separately from component implementations

Test parity at the contract boundary

A practical three-layer model

1. Shared semantics

2. Platform API

3. Platform implementation

What this changes when designing new components

The rule I keep coming back to

AI Can Generate More UI. Who Keeps It Consistent?

Generation is getting cheaper. Fragmentation is not.

A component library is necessary. It is no longer sufficient.

What Vellira is becoming

Vellira is not trying to out-code the coding model

The author matters less than the result

Cross-platform UI raises the stakes

The bottleneck is moving from production to coordination

Where Vellira is today

How to Fix Firebase `PERMISSION_DENIED` Errors in React Native

First, find out which Firebase service is rejecting the request

Check your Firestore security rules

Check whether the user is actually authenticated

Check that the rule matches the path you are actually using

Be careful with nested Firestore documents

Do not use allow read, write: if true as the final fix

Check whether you are using the correct Firebase project

Check your Android and iOS Firebase configuration

Check Firebase App Check

Development and production can behave differently

Check the exact user ID being used

Check your Storage rules if the error happens during uploads

Check Realtime Database rules separately

Use the Firebase Emulator when appropriate

Look at what changed right before the error

A simple debugging order

1. Identify the Firebase service

2. Read the exact path

3. Check authentication

4. Check the security rule

5. Check the values used by the rule

6. Check the Firebase project

7. Check App Check

8. Check platform-specific configuration

9. Reproduce the problem again

Example: finding a simple rules mistake

Final thoughts

How to Fix Expo Doctor Errors in Expo

First, run Expo Doctor by itself

Check your Expo SDK version

Fix packages that are on the wrong version

Do not blindly update everything

Check package.json for old dependencies

Check for packages that are not compatible with your project

Check your Expo configuration

Check Expo config plugins

Check for duplicate dependencies

Check your React Native version too

Do not use `allow read, write: if true` as the final fix

Check `package.json` for old dependencies

Run `expo-doctor` again after fixing something

When reinstalling `node_modules` makes sense

Check your `node_modules`

Check `index` files