DEV Community: Ars Dev

Why React Native Dominates Cross-Platform Development in 2025

Ars Dev — Tue, 05 Aug 2025 09:42:55 +0000

From the author of the Telegram channel REACT NATIVE HUB

Join a growing community of React Native Devs! 👆

In the rapidly evolving world of mobile development, choosing the right technology stack is critical for project success. While Swift and Kotlin deliver top-tier native experiences, the overhead of maintaining separate codebases is a significant challenge — especially for startups and businesses looking to move fast.

That’s where React Native shines. In 2025, despite new frameworks entering the space, React Native continues to be a powerful, scalable, and cost-effective solution for cross-platform mobile development. Let’s dive into why.

Faster Development, Lower Costs

Time and budget are critical for any company, but especially for startups operating with limited resources. React Native’s ability to share 70–90% of code across iOS and Android platforms significantly reduces development time and costs. Features like Hot Reloading allow developers to see real-time changes without restarting the app, making the development process smoother and more efficient.

The numbers speak for themselves:

Up to 50% reduction in development costs
30–40% faster time-to-market
Single development team managing both platforms
Unified codebase for easier maintenance and updates

For companies launching an MVP or iterating quickly on features, React Native provides the perfect balance of speed and flexibility without sacrificing quality.

A Thriving Ecosystem & Large Developer Community

After Facebook (Meta) initially dropped support for React Native and made it open-source for the community, tech experts predicted the end of React Native. But the opposite happened. More companies, developers, and tech leaders have adopted it, and the community continues growing stronger than ever.

One of React Native’s biggest advantages is its massive and active developer community. Unlike newer frameworks that are still finding their footing, React Native benefits from years of contributions, battle-tested third-party libraries, and well-documented solutions to common problems.

Need a UI component? There’s a library for that.
Stuck on an issue? Someone in the community has likely solved it.

This level of support means faster troubleshooting, better third-party integrations, and a more developer-friendly experience overall.

Native Performance with Flexibility

React Native has come a long way in terms of performance. Starting with version 0.66, the new Bridgeless architecture became the default, featuring Fabric & TurboModules that have significantly improved rendering speed and memory efficiency. While pure native development will always have an edge in ultra-high-performance applications (like advanced gaming or AR/VR), React Native provides near-native speed for 95% of business and consumer apps.

Plus, if you ever need to drop down to native code for specific optimizations, React Native lets you do so seamlessly. This hybrid approach gives you the best of both worlds — cross-platform efficiency with the option to go native when needed.

Real performance improvements companies are seeing:

Up to 5x performance increases in specific use cases
3.8MB smaller app bundles on Android
~15ms faster startup times
Reduced memory footprint across both platforms

The React Native team has also merged multiple C++ Dynamic Libraries into a single library for Android, streamlining the entire architecture.

Powered by the JavaScript Ecosystem

React Native leverages JavaScript, the most widely used programming language in the world, with over 17 million developers worldwide. This means instant access to a vast ecosystem of libraries, frameworks, and tools that accelerate development exponentially.

For companies already working with React on the web, transitioning to React Native is a natural progression. Teams can share knowledge, UI components, and even business logic between web and mobile apps. This streamlines development and eliminates the need for separate specialized teams, saving both time and money.

Key ecosystem advantages:

Access to 2+ million npm packages
Shared development skills between web and mobile teams
Rapid prototyping with familiar tools
Consistent development workflows across platforms

Key Considerations for 2025 and Beyond

While React Native offers plenty of advantages, it’s important to approach it with best practices in mind:

Stay Up-to-Date — React Native is constantly evolving. To keep up with the latest updates, best practices, and community news, follow my channel: React Native Hub.

Optimize for Performance — While React Native has improved, proper architecture, state management, and avoiding unnecessary re-renders are key to ensuring a smooth experience.

Use Native Modules When Needed — Some complex or performance-intensive features (like AR, VR, or heavy animations) may require native code. React Native’s ability to integrate with Swift/Kotlin provides flexibility when needed.

Prioritize Testing & Debugging — While React Native has solid debugging tools, mobile testing strategies (including device testing) should always be part of the process.

Final Thoughts: Is React Native the Right Choice in 2025?

Absolutely. In 2025, React Native stands as one of the most compelling choices for cross-platform mobile development. Whether you’re a bootstrapped startup looking to build an MVP quickly or an established enterprise seeking scalability and efficiency, React Native delivers an unmatched balance of speed, performance, and cost-effectiveness.

With its thriving community, continuous innovation, and proven success stories from companies serving billions of users, React Native isn’t just surviving in 2025 — it’s thriving and setting the standard for modern mobile development.

The real question isn’t whether React Native will remain relevant, but whether you can afford to overlook it for your next mobile project. In today’s competitive landscape, the framework that lets you move fastest while maintaining quality wins.

If you’re considering mobile development in 2025, React Native should be at the top of your list.

Trusted by Industry Leaders

React Native isn’t just for startups — some of the world’s most successful companies continue to rely on it for their core mobile applications:

• Meta (Facebook, Instagram) — Over 1 billion users
• Shopify — Complete mobile platform migration
• Tesla — Vehicle control and monitoring systems
• Walmart — E-commerce and logistics apps
• Airbnb — Travel booking and host management
• Netflix — Content streaming and user interface
• Uber Eats — Food delivery platform

This kind of adoption at scale proves that React Native is scalable, battle-tested, and capable of handling real-world production workloads with millions of users.

About me: My name is Arsen, and I am a react native developer and owner of the TG channel 👇

🔗 Join TG community for React Native Devs: REACT NATIVE HUB

The Complete React Native Styling Guide Every Developer Needs

Ars Dev — Thu, 31 Jul 2025 09:08:36 +0000

From the author of the Telegram channel REACT NATIVE HUB

Join a growing community of React Native Devs! 👆

When I first started building React Native apps, I thought styling would be the easy part. After all, it’s just CSS-like properties, right? I couldn’t have been more wrong. Over the years of shipping production apps, I’ve learned that thoughtful styling architecture is what separates amateur projects from professional, maintainable applications.

Today, I want to share the styling patterns and practices that have transformed how I approach React Native development — techniques that will save you hours of debugging and make your apps a joy to maintain.

The Foundation: Building a Design System That Scales

Why Most React Native Apps Look Inconsistent

The biggest mistake I see developers make is hardcoding values throughout their components. You’ll see things like:

// ❌ This leads to inconsistency and maintenance nightmares
const styles = StyleSheet.create({
  header: {
    backgroundColor: '#3498db',
    padding: 16,
    fontSize: 18,
  },
  button: {
    backgroundColor: '#3490db', // Oops, slightly different blue
    padding: 15, // Almost the same padding
    fontSize: 16,
  },
});

These small inconsistencies compound quickly, creating apps that feel unpolished and amateur.

Creating Your Design Token System

Instead, establish a centralized theme system from day one:

// theme.js - Your single source of truth
export const COLORS = {
  primary: '#3498db',
  primaryDark: '#2980b9',
  secondary: '#2ecc71',
  background: '#f9f9f9',
  surface: '#ffffff',
  text: '#333333',
  textSecondary: '#666666',
  border: '#dee2e6',
  error: '#e74c3c',
  success: '#27ae60',
};

export const SPACING = {
  xs: 4,
  sm: 8,
  md: 16,
  lg: 24,
  xl: 32,
  xxl: 48,
};

export const TYPOGRAPHY = {
  sizes: {
    small: 12,
    body: 16,
    heading: 20,
    title: "24,"
  },
  weights: {
    regular: '400',
    medium: '500',
    bold: '700',
  },
};

Now every component uses these constants:

import { COLORS, SPACING, TYPOGRAPHY } from './theme';

const styles = StyleSheet.create({
  container: {
    backgroundColor: COLORS.background,
    padding: SPACING.md,
  },
  title: "{"
    fontSize: TYPOGRAPHY.sizes.title,
    fontWeight: TYPOGRAPHY.weights.bold,
    color: COLORS.text,
    marginBottom: SPACING.sm,
  },
});

This approach has saved me countless hours. When the design team asks to adjust the primary color or increase spacing, I change one value and it updates everywhere.

Building Reusable Component Libraries

The Problem with Inline Styling

I used to write components like this:

// ❌ Repetitive and hard to maintain
function UserProfile() {
  return (
    <View>
      <Text style={{ fontSize: 24, fontWeight: 'bold', color: '#333' }}>
        John Doe
      </Text>
      <Text style={{ fontSize: 16, color: '#666' }}>
        Software Developer
      </Text>
    </View>
  );
}

Creating Semantic Component APIs

Now I build reusable text components:

// components/Typography.js
import React from 'react';
import { Text, StyleSheet } from 'react-native';
import { COLORS, TYPOGRAPHY } from '../theme';

export const Title = ({ children, style, ...props }) => (
  <Text style={[styles.title, style]} {...props}>
    {children}
  </Text>
);

export const Body = ({ children, style, variant = 'primary', ...props }) => (
  <Text style={[styles.body, styles[variant], style]} {...props}>
    {children}
  </Text>
);

export const Caption = ({ children, style, ...props }) => (
  <Text style={[styles.caption, style]} {...props}>
    {children}
  </Text>
);

const styles = StyleSheet.create({
  title: "{"
    fontSize: TYPOGRAPHY.sizes.title,
    fontWeight: TYPOGRAPHY.weights.bold,
    color: COLORS.text,
  },
  body: {
    fontSize: TYPOGRAPHY.sizes.body,
    fontWeight: TYPOGRAPHY.weights.regular,
  },
  primary: {
    color: COLORS.text,
  },
  secondary: {
    color: COLORS.textSecondary,
  },
  caption: {
    fontSize: TYPOGRAPHY.sizes.small,
    color: COLORS.textSecondary,
  },
});

Now my components are clean and semantic:

function UserProfile() {
  return (
    <View>
      <Title>John Doe</Title>
      <Body variant="secondary">Software Developer</Body>
    </View>
  );
}

Flexbox Mastery: Layouts That Actually Work

Common Flexbox Patterns I Use Daily

After building dozens of apps, I’ve identified the flexbox patterns I reach for constantly:

// styles/common.js
export const flexPatterns = StyleSheet.create({
  // Container patterns
  row: {
    flexDirection: 'row',
  },
  column: {
    flexDirection: 'column',
  },
  center: {
    justifyContent: 'center',
    alignItems: 'center',
  },
  spaceBetween: {
    justifyContent: 'space-between',
  },

  // Child patterns
  flex1: {
    flex: 1,
  },
  alignSelfCenter: {
    alignSelf: 'center',
  },
});

Real-World Layout Example

Here’s how I structure a typical product card:

import { flexPatterns } from '../styles/common';

function ProductCard({ product, onAddToCart }) {
  return (
    <View style={[styles.card, flexPatterns.row]}>
      <Image source={{ uri: product.image }} style={styles.image} />

      <View style={[flexPatterns.flex1, flexPatterns.column]}>
        <Title>{product.name}</Title>
        <Body variant="secondary" numberOfLines={2}>
          {product.description}
        </Body>

        <View style={[flexPatterns.row, flexPatterns.spaceBetween, styles.footer]}>
          <Text style={styles.price}>${product.price}</Text>
          <Button onPress={() => onAddToCart(product)}>
            Add to Cart
          </Button>
        </View>
      </View>
    </View>
  );
}

Responsive Design: One Codebase, All Screen Sizes

The Hook That Changed Everything

I created this custom hook that I now use in every project:

// hooks/useResponsive.js
import { useState, useEffect } from 'react';
import { Dimensions } from 'react-native';

export const useResponsive = () => {
  const [dimensions, setDimensions] = useState(Dimensions.get('window'));

  useEffect(() => {
    const subscription = Dimensions.addEventListener('change', ({ window }) => {
      setDimensions(window);
    });

    return () => subscription?.remove();
  }, []);

  const { width, height } = dimensions;
  const isTablet = width > 768;
  const isLandscape = width > height;

  return { width, height, isTablet, isLandscape };
};

Building Adaptive Components

Now I can create components that respond intelligently to screen size:

function ProductGrid({ products }) {
  const { isTablet } = useResponsive();

  const styles = StyleSheet.create({
    grid: {
      flexDirection: 'row',
      flexWrap: 'wrap',
    },
    item: {
      width: isTablet ? '33.33%' : '50%',
      padding: SPACING.sm,
    },
  });

  return (
    <View style={styles.grid}>
      {products.map(product => (
        <View key={product.id} style={styles.item}>
          <ProductCard product={product} />
        </View>
      ))}
    </View>
  );
}

Platform-Specific Styling Done Right

The Shadow Problem

One of the most frustrating aspects of React Native is handling shadows. iOS and Android require completely different approaches:

// utils/shadows.js
import { Platform } from 'react-native';

export const createShadow = (elevation = 2) => {
  return Platform.select({
    ios: {
      shadowColor: '#000',
      shadowOffset: { width: 0, height: elevation },
      shadowOpacity: 0.2,
      shadowRadius: elevation * 2,
    },
    android: {
      elevation,
    },
  });
};

Using Platform-Specific Styles

Now I can apply consistent shadows across platforms:

const styles = StyleSheet.create({
  card: {
    backgroundColor: COLORS.surface,
    borderRadius: 8,
    padding: SPACING.md,
    ...createShadow(4),
  },
});

Dynamic Styling and Theme Support

Building a Theme Context

Modern apps need to support dark mode and theme switching:

// context/ThemeContext.js
import React, { createContext, useContext, useState } from 'react';
import { Appearance } from 'react-native';

const ThemeContext = createContext();
export const ThemeProvider = ({ children }) => {
  const [isDark, setIsDark] = useState(
    Appearance.getColorScheme() === 'dark'
  );

  const theme = isDark ? darkTheme : lightTheme;

  const toggleTheme = () => setIsDark(!isDark);

  return (
    <ThemeContext.Provider value={{ theme, isDark, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
};
export const useTheme = () => useContext(ThemeContext);

Theme-Aware Components

Components can now automatically adapt to theme changes:

function ThemedCard({ children }) {
  const { theme } = useTheme();

  const styles = StyleSheet.create({
    card: {
      backgroundColor: theme.colors.surface,
      borderColor: theme.colors.border,
      borderWidth: StyleSheet.hairlineWidth,
      borderRadius: 8,
      padding: theme.spacing.md,
    },
  });

  return <View style={styles.card}>{children}</View>;
}

Key Takeaways for Professional React Native Styling

Start with a design system — Define your colors, spacing, and typography constants before writing any component styles
Build reusable components — Create semantic APIs that encapsulate styling decisions
Master flexbox patterns — Lear
n the common layout patterns and reuse them consistently
Plan for responsive design — Use hooks and utilities to adapt to different screen sizes
Handle platform differences gracefully — Create utilities that abstract platform-specific styling
Support theming from day one — Modern apps need dark mode and theme flexibility

The time you invest in setting up proper styling architecture will pay dividends throughout your project’s lifecycle. When design changes come (and they always do), you’ll be able to implement them quickly and consistently across your entire app.

These patterns have transformed how I build React Native apps. They’ve made my code more maintainable, my apps more consistent, and my development process significantly more enjoyable. Give them a try in your next project — I think you’ll find them as valuable as I have.

About me: My name is Arsen, and I am a react native developer and owner of the TG channel 👇

🔗 Join TG community for React Native Devs: REACT NATIVE HUB

useDebounce — Stop Unnecessary API Calls in React Native

Ars Dev — Fri, 04 Jul 2025 11:48:20 +0000

From the author of the Telegram channel REACT NATIVE HUB

Join a growing community of React Native Devs! 👆

When handling search inputs or live updates, debouncing prevents excessive API requests by delaying execution until the user stops typing.

Implementation:

import { useState, useEffect } from "react";

function useDebounce(value, delay = 500) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const handler = setTimeout(() => setDebouncedValue(value), delay);
    return () => clearTimeout(handler);
  }, [value, delay]);

  return debouncedValue;
}

export default useDebounce;

Usage Example:

const [searchTerm, setSearchTerm] = useState("");
const debouncedSearch = useDebounce(searchTerm, 300);

useEffect(() => {
  if (debouncedSearch) {
    fetch(`https://api.example.com/search?q=${debouncedSearch}`)
      .then((res) => res.json())
      .then((data) => console.log(data));
  }
}, [debouncedSearch]);

<TextInput
  placeholder="Search..."
  onChangeText={(text) => setSearchTerm(text)}
/>;

✅ Why Use It?

Reduces unnecessary API calls
Improves performance in search fields
Ensures a smooth user experience

About me: My name is Arsen, and I am a react native developer and owner of the TG channel 👇

🔗 Join TG community for React Native Devs: REACT NATIVE HUB

Persist Data Like a Pro in React Native

Ars Dev — Fri, 04 Jul 2025 11:45:24 +0000

From the author of the Telegram channel REACT NATIVE HUB

Join a growing community of React Native Devs! 👆

When building React Native apps, there’s often a need to persist user preferences, tokens, or flags between sessions. While AsyncStorage is the go-to solution for persistent storage, interacting with it manually every time can get repetitive and messy.

Let’s fix that with a custom hook: useAsyncStorage

✅ Implementation using `@react-native-async-storage/async-storage`:

import { useState, useEffect } from "react";
import AsyncStorage from "@react-native-async-storage/async-storage";

function useAsyncStorage(key, initialValue) {
  const [storedValue, setStoredValue] = useState(initialValue);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    const loadValue = async () => {
      try {
        const item = await AsyncStorage.getItem(key);
        setStoredValue(item != null ? JSON.parse(item) : initialValue);
      } catch (error) {
        console.error("Error loading from AsyncStorage", error);
      } finally {
        setIsLoading(false);
      }
    };
    loadValue();
  }, [key]);

  const setValue = async (value) => {
    try {
      const valueToStore =
        value instanceof Function ? value(storedValue) : value;
      setStoredValue(valueToStore);
      await AsyncStorage.setItem(key, JSON.stringify(valueToStore));
    } catch (error) {
      console.error("Error setting AsyncStorage", error);
    }
  };

  return [storedValue, setValue, isLoading];
}

export default useAsyncStorage;

🧪 Usage Example: Theme Toggle

import React, { useEffect } from "react";
import { View, Text, Button, StyleSheet } from "react-native";
import useAsyncStorage from "./useAsyncStorage";

const ThemeSwitcher = () => {
  const [theme, setTheme] = useAsyncStorage("theme", "light");

  const toggleTheme = () => {
    setTheme((prev) => (prev === "light" ? "dark" : "light"));
  };

  return (
    <View style={[
        styles.container,
        theme === "dark" ? styles.dark : styles.light,
      ]}
    >
      <Text style={styles.text}>Current Theme: {theme}</Text>
      <Button title="Toggle Theme" onPress={toggleTheme} />
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: "center",
    alignItems: "center",
  },
  dark: {
    backgroundColor: "#222",
  },
  light: {
    backgroundColor: "#fff",
  },
  text: {
    fontSize: 20,
    marginBottom: 16,
  },
});

export default ThemeSwitcher;

🧩 When to Use It?
You can apply useAsyncStorage in:
🌙 Theme or UI preferences
🔐 Authentication tokens
✅ Onboarding screens
📦 Offline saved content
etc…

Final Thoughts

Hooks like useAsyncStorage are about more than just reducing boilerplate — they help encapsulate logic and build scalable apps faster. Whether you’re working solo or in a team, abstracting persistence logic like this is a pro move.

About me: My name is Arsen, and I am a react native developer and owner of the TG channel 👇

🔗 Join TG community for React Native Devs: REACT NATIVE HUB

Expo Folder Structure with Zustand

Ars Dev — Fri, 04 Jul 2025 11:37:58 +0000

From the author of the Telegram channel REACT NATIVE HUB

Join a growing community of React Native Devs! 👆

One of the most overlooked parts of building React Native apps — especially with Expo — is project structure. A clean and scalable folder layout can drastically improve your development speed, reduce bugs, and make onboarding easier for team members.

This example show how to set up folder structure for Expo Router-based project with Zustand for state management, Axios for API handling, and Maestro for E2E testing. This structure ensures maintainability, scalability, and better developer experience.

👉 Check out the full post with the complete folder structure example here: Read the post

Why Your React Native Components Don’t Need All Those Props (ISP)

Ars Dev — Fri, 04 Jul 2025 11:34:22 +0000

From the author of the Telegram channel REACT NATIVE HUB

Join a growing community of React Native Devs! 👆

As React Native developers, we often strive to build components that are flexible and reusable. But in trying to do it all, we can easily fall into the trap of over-engineering. Ever built a button component that accepts five different props just to cover every possible use case?

That’s where the Interface Segregation Principle (ISP) comes in.

ISP reminds us to keep components lean and purpose-driven by only accepting the props they truly need. In this article, you’ll learn how applying this principle in your React Native components leads to cleaner code, better reusability, and fewer bugs — without sacrificing flexibility.

What Is the Interface Segregation Principle?

Definition: Clients should not be forced to depend on interfaces they do not use.
In React Native: Ensure that components accept only the props they need, and use custom hooks to separate different concerns.

Not following ISP

In this example, the extended interface is forced to implement all props even if it doesn’t need them.

// ❌ BAD EXAMPLE - Violating ISP
interface ButtonProps {
  label: string;
  onPress: () => void;
  icon: React.ReactNode; // Not all buttons need icons
  loading: boolean;    // Not all buttons need loading state
  disabled: boolean;   // Not all buttons need disabled state
}

const Button: React.FC<ButtonProps> = ({ label, onPress, icon, loading, disabled }) => {
  return (
    <TouchableOpacity onPress={onPress} disabled={disabled}>
      {loading ? <ActivityIndicator /> : <Text>{label}</Text>}
      {icon && icon}
    </TouchableOpacity>
  );
};

Following ISP

Now, let’s refactor this code by Segregating interfaces for different aspects of the button.

// ✅ GOOD EXAMPLE - Following ISP
interface BasicButtonProps {
  label: string;
  onPress: () => void;
}

interface LoadingButtonProps extends BasicButtonProps {
  loading: boolean;
}

// Simple button without unnecessary props
const SimpleButton: React.FC<BasicButtonProps> = ({ label, onPress }) => {
  return <TouchableOpacity onPress={onPress}><Text>{label}</Text></TouchableOpacity>;
};

// Button with loading state
const LoadingButton: React.FC<LoadingButtonProps> = ({ label, onPress, loading }) => {
  return (
    <TouchableOpacity onPress={onPress}>
      {loading ? <ActivityIndicator /> : <Text>{label}</Text>}
    </TouchableOpacity>
  );
};

Why This Works

Components only depend on what they actually use.
Each button type has a clear responsibility.
Easier to test, reuse, and maintain.

About me: My name is Arsen, and I am a react native developer and owner of the TG channel 👇

🔗 Join TG community for React Native Devs: REACT NATIVE HUB

Cleaner Code with LSP: Writing Reusable React Native Components

Ars Dev — Fri, 04 Jul 2025 11:30:06 +0000

From the author of the Telegram channel REACT NATIVE HUB

Join a growing community of React Native Devs! 👆

When building scalable React Native apps, clean architecture matters. One of the key principles of clean code is the Liskov Substitution Principle (LSP)— often overlooked, but incredibly powerful for designing reusable, maintainable components.

Let’s break it down and see how LSP applies in React Native, especially when creating buttons, inputs, or any shared UI components.

What Is the Single Responsibility Principle?

Definition: Objects or components should be replaceable with instances of their subtypes without altering the correctness of the program.
In React Native: When creating components or extending them, ensure they can be used interchangeably without breaking the application.

Bad Example: Violating LSP in React Native

In this example, incorrect use of interface methods and not following the base interface for the same type of component violates the LSP principle.

// ❌ BAD EXAMPLE - Violating LSP
interface BadBaseButton {
  onPress: () => void;
  text: string;  // Restricts to string only
}

const BadBaseButton: React.FC<BadBaseButton> = ({ onPress, text }) => (
  return (
    <TouchableOpacity onPress={onPress}>
       <Text>{text}</Text>
     </TouchableOpacity>
  );
);

// Violates LSP by changing prop structure and behavior
interface BadPrimaryButton {
  label: string;  // Different prop name
  onAction: () => Promise<void>;  // Different type
}

const BadPrimaryButton: React.FC<BadPrimaryButton> = ({ label, onAction }) => {
  return (
    <TouchableOpacity onPress={onAction}>
      <Text>{label}</Text>
    </TouchableOpacity>
  );
};

// Usage shows incompatibility
const BadExample: React.FC = () => {
  const handleClick = () => console.log('clicked');

  return (
    <View>
      <BadBaseButton
        onClick={handleClick}
        text="Click me"
      />

      {/* Won't work! Different props and behavior */}
      <BadPrimaryButton
        label="Click me"
        onAction={async () => console.log('clicked')}
      />
    </View>
  );
};

Following LSP

It helps to ensure base props are extended consistently, the same onClick type throughout, components are interchangeable & add features without breaking the base contract.

// ✅ GOOD EXAMPLE - Following LSP
interface GoodBaseButtonProps {
  onPress: () => void;
  children: React.ReactNode;
}

const GoodBaseButton: React.FC<GoodBaseButtonProps> = ({ onPress, children }) => (
  <TouchableOpacity onPress={onPress}>{children}</TouchableOpacity>
);

// Properly extends base props
interface GoodPrimaryButtonProps extends GoodBaseButtonProps {
  variant?: 'solid' | 'outline';  // Optional additional prop
}

const GoodPrimaryButton: React.FC<GoodPrimaryButtonProps> = ({
  onPress,
  children,
  variant = 'solid'
}) => {
  const bg = variant === 'solid' ? 'bg-blue-500' : 'border-blue-500';
  return (
    <TouchableOpacity onPress={onPress} style={{backgroundColor: bg}}>
      {children}
    </TouchableOpacity>
  );
};

// Usage shows compatibility
const GoodExample: React.FC = () => {
  const handleClick = () => console.log('clicked');

  return (
    <View>
      {/* Both components can use the same handler */}
      <GoodBaseButton onPress={handleClick}>
        Click me
      </GoodBaseButton>
      <GoodPrimaryButton onPress={handleClick} variant="solid">
        Click me
      </GoodPrimaryButton>
    </View>
  );
};

Key Takeaways

LSP ensures that your components remain interchangeable.
In React Native, always extend base props when creating variants.
Avoid re-inventing props or behavior for components that serve the same role.
Following LSP leads to better code reuse, less duplication, and easier maintenance.

About me: My name is Arsen, and I am a react native developer and owner of the TG channel 👇

🔗 Join TG community for React Native Devs: REACT NATIVE HUB

Why the OCP Makes You a Better React Native Dev

Ars Dev — Fri, 04 Jul 2025 11:26:43 +0000

From the author of the Telegram channel REACT NATIVE HUB

Join a growing community of React Native Devs! 👆

When building scalable React Native apps, clean architecture matters. One of the most powerful design principles you can apply is the Open/Closed Principle (OCP)

What Is the Open/Closed Principle?

Definition: Software entities should be open for extension but closed for modification.
In React Native: Use higher-order components (HOCs), render props, or composition to extend component behaviour without modifying the existing code.

❌ The Anti-Pattern: Modifying Components for Every Change

Imagine you have a Button component that handles different visual styles based on a type prop:

// ❌ BAD EXAMPLE - Violating OCP
import React from 'react';
import { Text, TouchableOpacity } from 'react-native';

const Button = ({ type, label }) => {
  let style = {};

  if (type === 'primary') {
    style = { backgroundColor: 'blue', color: 'white' };
  } else if (type === 'secondary') {
    style = { backgroundColor: 'gray', color: 'white' };
  } else if (type === 'danger') {
    style = { backgroundColor: 'red', color: 'white' };
  }

  return (
    <TouchableOpacity style={style}>
      <Text>{label}</Text>
    </TouchableOpacity>
  );
};

export default Button;

Each time you need a new button variant, you edit the component’s internal logic. This violates OCP and leads to fragile code that's hard to maintain.

✅ Following OCP

A better approach is to make the base Button component generic and use Higher-Order Components (HOCs) to extend it with different styles. This way, the Button stays closed for modification but open for extension.

import React from 'react';
import { Text, TouchableOpacity } from 'react-native';

// Base Button Component
const Button = ({ label, style }) => (
  <TouchableOpacity style={style}>
    <Text>{label}</Text>
  </TouchableOpacity>
);

// HOC
const withButtonStyle = (customStyle) => (WrappedComponent) => (props) => {
  return <WrappedComponent {...props} style={customStyle} />;
};

const PrimaryButton = withButtonStyle({ backgroundColor: 'blue' })(Button);
const SecondaryButton = withButtonStyle({ backgroundColor: 'gray' })(Button);
const DangerButton = withButtonStyle({ backgroundColor: 'red' })(Button);

export { PrimaryButton, SecondaryButton, DangerButton };

Usage:

import React from 'react';
import { View } from 'react-native';
import { PrimaryButton, SecondaryButton, DangerButton } from './Buttons';

const App = () => (
  <View>
    <PrimaryButton label="Save" />
    <SecondaryButton label="Cancel" />
    <DangerButton label="Delete" />
  </View>
);

export default App;

Key Takeaways

OCP helps you extend functionality without changing existing code.
In React Native, use composition or HOCs to build flexible, scalable UI components.
Avoid piling up logic inside a single component—modularize it instead.

Applying OCP leads to more maintainable and testable code, especially in growing codebases where new requirements come in fast.

About me: My name is Arsen, and I am a react native developer and owner of the TG channel 👇

🔗 Join TG community for React Native Devs: REACT NATIVE HUB

Why Every React Native Developer Should Respect the SRP

Ars Dev — Fri, 04 Jul 2025 11:22:07 +0000

From the author of the Telegram channel REACT NATIVE HUB

Join a growing community of React Native Devs! 👆

As React Native developers, it’s easy to fall into the trap of building components that do too much — fetching data, managing state, rendering UI, and handling user interactions all in one place. While it might work for small components, this approach quickly becomes a nightmare to maintain and debug as your app scales.

Enter the Single Responsibility Principle (SRP) — a cornerstone of clean code and scalable architecture.

What Is the Single Responsibility Principle?

Definition: A component should have only one reason to change, meaning it should do one thing and do it well.
In React Native: Break down large components into smaller, reusable pieces, each handling a single responsibility.

What Happens When You Don’t Follow SRP?

In this example, the UserProfile component handles fetching data, managing state, and rendering the UI — all in one component.

// ❌ BAD EXAMPLE - Violating SRP
import React, { useState, useEffect } from 'react';

const UserProfile = () => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchUserData = async () => {
      try {
        const response = await fetch('<https://api.example.com/user>');
        const data = await response.json();
        setUser(data);
      } catch (err) {
        setError(err);
      } finally {
        setLoading(false);
      }
    };
    fetchUserData();
  }, []);

  if (loading) return <View><Text>Loading...</Text></View>;
  if (error) return <View><Text>Error: {error.message}</Text></View>;

  return (
    <View>
      <Text>{user.name}</Text>
      <Text>{user.email}</Text>
    </View>
  );
};

export default UserProfile;

Following SRP

Now, let’s refactor the code to adhere to the Single Responsibility Principle by breaking it into three separate components.

Custom Hook for Data Fetching (useUserData)

// ✅ GOOD EXAMPLE - Following SRP
import { useState, useEffect } from 'react';

const useUserData = () => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchUserData = async () => {
      try {
        const response = await fetch('<https://api.example.com/user>');
        const data = await response.json();
        setUser(data);
      } catch (err) {
        setError(err);
      } finally {
        setLoading(false);
      }
    };
    fetchUserData();
  }, []);

  return { user, loading, error };
};

export default useUserData;

Loading and Error Handling Component (UserInfo)

// ✅ GOOD EXAMPLE - Following SRP
import React from 'react';

const UserInfo = ({ user, loading, error }) => {
  if (loading) return <View><Text>Loading...</Text></View>;
  if (error) return <View><Text>Error: {error.message}</Text></View>;

  return (
    <View>
      <Text>{user.name}</Text>
      <Text>{user.email}</Text>
    </View>
  );
};
export default UserInfo;

Main Component (UserProfile)

// ✅ GOOD EXAMPLE - Following SRP
import React from 'react';
import useUserData from './useUserData';
import UserInfo from './UserInfo';

const UserProfile = () => {
  const { user, loading, error } = useUserData();

  return <UserInfo user={user} loading={loading} error={error} />;
};

export default UserProfile;

Why This Matters

By following SRP:

Your code is easier to test. Each unit can be tested in isolation.
You improve reusability. The UserInfo component can now be reused anywhere.
Future changes are easier. Want to change how data is fetched? You only touch the hook. Want to redesign the UI? Only modify the UI component.

About me: My name is Arsen, and I am a react native developer and owner of the TG channel 👇

🔗 Join TG community for React Native Devs: REACT NATIVE HUB

Why Every React Native Developer Should Understand useCallback

Ars Dev — Fri, 04 Jul 2025 11:18:39 +0000

From the author of the Telegram channel REACT NATIVE HUB.

Join a growing community of React Native Devs! 👆

In React Native development, optimizing performance is crucial for creating responsive and efficient applications. One common challenge developers face is the unnecessary re-creation of functions during component re-renders, which can lead to performance bottlenecks. The useCallback hook in React provides a solution by memoizing functions, ensuring they maintain consistent references between renders. This article explores the useCallback hook, its benefits, and practical applications in React Native.

Understanding the Problem: Function Recreation in React Components

In React, defining functions within a component causes them to be recreated on every render. This behavior can lead to performance issues, especially when these functions are passed as props to child components that rely on reference equality to prevent unnecessary re-renders. For instance, consider a scenario where a parent component passes a callback to a memoized child component

import React, { useState, memo } from 'react';
import { Button, Text, View } from 'react-native';

const ChildComponent = memo(({ onPress }) => {
  console.log('ChildComponent rendered');
  return <Button title="Press me" onPress={onPress} />;
});

const ParentComponent = () => {
  const [count, setCount] = useState(0);

  const handlePress = () => {
    console.log('Button pressed');
  };

  return (
    <View>
      <Text>Count: {count}</Text>
      <ChildComponent onPress={handlePress} />
      <Button title="Increment count" onPress={() => setCount(count + 1)} />
    </View>
  );
};

In this example, each time ParentComponent re-renders, a new instance of handlePress is created. Since ChildComponent is memoized using React.memo, it should only re-render when its props change. However, because handlePress is a new function on every render, ChildComponent perceives it as a prop change and re-renders unnecessarily.

Introducing `useCallback`

The useCallback hook is designed to memoize functions, ensuring that they retain the same reference between renders unless their dependencies change. By wrapping a function with useCallback, React returns a memoized version of the function that only changes if one of the specified dependencies changes. This behavior helps prevent unnecessary re-renders of child components that depend on stable function references.

The syntax for useCallback is as follows:

const memoizedCallback = useCallback(() => {
  // function logic
}, [dependency1, dependency2]);

Function Logic: The code to be executed within the memoized function.
Dependencies Array: A list of dependencies that, when changed, will cause the function to be recreated.

Applying `useCallback` in React Native

To address the earlier issue of unnecessary re-renders, we can utilize useCallback to memoize the handlePress function:

import React, { useState, useCallback, memo } from 'react';
import { Button, Text, View } from 'react-native';

const ChildComponent = memo(({ onPress }) => {
  console.log('ChildComponent rendered');
  return <Button title="Press me" onPress={onPress} />;
});

const ParentComponent = () => {
  const [count, setCount] = useState(0);

  const handlePress = useCallback(() => {
    console.log('Button pressed');
  }, []);

  return (
    <View>
      <Text>Count: {count}</Text>
      <ChildComponent onPress={handlePress} />
      <Button title="Increment count" onPress={() => setCount(count + 1)} />
    </View>
  );
};

By wrapping handlePress with useCallback and providing an empty dependency array, we ensure that handlePressmaintains the same reference across renders. As a result, ChildComponent will not re-render unless handlePresschanges, thereby improving performance.

Practical Use Cases in React Native

Optimizing List Rendering with `FlatList`

In React Native, the FlatList component is commonly used to render long lists of data. To optimize performance, it's essential to prevent unnecessary re-renders of item components. By memoizing the renderItem function using useCallback, we can achieve this optimization:

import React, { useCallback } from 'react';
import { FlatList, Text, TouchableOpacity } from 'react-native';

const MyList = ({ data, onItemPress }) => {
  const renderItem = useCallback(
    ({ item }) => (
      <TouchableOpacity onPress={() => onItemPress(item.id)}>
        <Text>{item.title}</Text>
      </TouchableOpacity>
    ),
    [onItemPress]
  );

  return <FlatList data={data} renderItem={renderItem} keyExtractor={(item) => item.id.toString()} />;
};

In this example, renderItem is memoized with useCallback, ensuring that it maintains the same reference unless onItemPress changes. This approach prevents unnecessary re-renders of list items, enhancing the performance of the FlatList.

Handling Event Listeners

When adding event listeners, it's advisable to use stable function references to ensure proper addition and removal of listeners. Using useCallback helps maintain consistent references:

import React, { useEffect, useCallback } from 'react';
import { BackHandler } from 'react-native';

const MyComponent = () => {
  const handleBackPress = useCallback(() => {
    // Handle back press
    return true;
  }, []);

  useEffect(() => {
    BackHandler.addEventListener('hardwareBackPress', handleBackPress);
    return () => BackHandler.removeEventListener('hardwareBackPress', handleBackPress);
  }, [handleBackPress]);

  return (
    // Component JSX
  );
};

By memoizing handleBackPress with useCallback, we ensure that the same function reference is used during the addition and removal of the event listener, preventing potential issues with stale references.

Best Practices for Using `useCallback`

While useCallback is a powerful tool for optimizing React Native applications, it's important to use it correctly to avoid unnecessary complexity. Here are some best practices:

Use it for Performance-Critical Components
- useCallback is most useful when working with memoized components (React.memo) or lists (FlatList, SectionList).
- If a function does not cause unnecessary re-renders, using useCallback may add unnecessary complexity.
Keep Dependencies Accurate
- Always include all dependencies in the dependency array to avoid potential bugs caused by stale closures.
- For example, if a function depends on a piece of state, include it in the dependency array:
```
const handlePress = useCallback(() => {
  console.log(count);
}, [count]); // count is a dependency
```
Avoid Overusing useCallback
- Wrapping every function in useCallback is unnecessary and may actually make the code harder to read.
- Functions that don’t depend on component re-renders don’t need useCallback.

Combine with useMemo When Needed

If you’re passing a memoized function to a memoized object or array, use useMemo to prevent unnecessary recalculations:

const memoizedData = useMemo(() => calculateData(items), [items]);
const handlePress = useCallback(() => {
  console.log('Pressed');
}, []);

When Not to Use `useCallback`

While useCallback helps with performance, using it everywhere can make code harder to understand without tangible benefits. Here are cases where you don’t need useCallback:

For simple inline event handlers
```
<Button title="Click me" onPress={() => console.log('Clicked')} />
```
The function inside onPress is simple and doesn’t need memoization.
For stable functions that don’t cause re-renders

If a function is defined outside of the component or doesn’t change on re-renders, useCallback isn’t necessary.
When optimizing prematurely

Don’t use useCallback unless there’s a measurable performance issue.

Conclusion

The useCallback hook is a powerful tool for optimizing React Native applications by preventing unnecessary function recreations and improving rendering efficiency. However, it should be used strategically to avoid unnecessary complexity.

Key Takeaways

✔ Use useCallback to prevent unnecessary re-renders in performance-critical components.

✔ Always include all dependencies in the dependency array to avoid stale closures.

✔ Avoid overusing useCallback—only apply it where function references impact performance.

✔ Combine with useMemo for optimal performance in complex scenarios.

By understanding when and how to use useCallback, you can build more efficient and performant React Native applications. 🚀

About me: My name is Arsen, and I am a react native developer and owner of the TG channel 👇

🔗 Join TG community for React Native Devs: REACT NATIVE HUB

How I Increased List Scroll FPS from 30 to 58 in React Native

Ars Dev — Fri, 04 Jul 2025 11:09:45 +0000

From the author of the Telegram channel REACT NATIVE HUB.

Join a growing community of React Native Devs! 👆

Performance optimization is one of the most critical phases of mobile application development. As React Native developers, we often deal with lists containing hundreds or even thousands of items.

In this article, I'll walk you through how I optimised large lists by replacing FlatList with FlashList, a high-performance alternative from Shopify.

I'll also share additional optimisations like getItemLayout, viewabilityConfig, and item render caching to improve rendering efficiency and scrolling smoothness.

🚀 The Problem: Low Performance in Large Lists

When dealing with large lists (1000+ items), you may notice:

Slow initial renders: The app takes longer to display the first few items.
Frame drops while scrolling: Laggy scrolling with low FPS (frames per second).
High memory usage: FlatList keeps too many items in memory, affecting performance.

These issues occur because FlatList renders items dynamically but still incurs unnecessary rendering overhead, especially when items enter or leave the viewport.

✅ The Solution: Using FlashList for Better Performance

Install:

React Native
yarn add @shopify/flash-list cd ios && pod install

Expo
npx expo install @shopify/flash-list

Here's how you can integrate FlashList into your app:
import { FlashList } from "@shopify/flash-list";

const ITEM_HEIGHT = 100; // Define your item height
const OptimizedList = ({ items }) => {
  const renderItem = ({ item }) => (
    <ItemComponent data={item} />
  );
  const getItemLayout = (data, index) => ({
    length: ITEM_HEIGHT,
    offset: ITEM_HEIGHT * index,
    index,
  });
  return (
    <FlashList
      data={items}
      renderItem={renderItem}
      estimatedItemSize={100} // Helps FlashList optimize rendering
      getItemLayout={getItemLayout}
      viewabilityConfig={{
        waitForInteraction: true,
        viewAreaCoveragePercentThreshold: 50,
      }}
      windowSize={5} // Controls the number of items rendered around the viewport
    />
  );
};

🔍 Breaking Down the Optimization Techniques

1️⃣ Replacing FlatList with FlashList

FlashList estimates item sizes in advance, reducing re-renders and improving performance.
Uses optimized memory management to keep only essential items in memory.

2️⃣ Implementing getItemLayout

Pre-defining item heights avoids unnecessary calculations, making scrolling smoother.
Benefit: Eliminates UI lag caused by recalculating positions dynamically.

3️⃣ Optimizing viewabilityConfig

Helps control when items are considered "visible," reducing excess re-renders.
Setting viewAreaCoveragePercentThreshold: 50 ensures items are efficiently tracked.

4️⃣ Using windowSize for Efficient Memory Management

Reducing windowSize ensures only a small number of items are kept in memory at any time.
Benefit: Lowers memory consumption and improves overall performance.

📊 The Results: Huge Performance Gains

After implementing these optimizations, we observed:

✅ FPS boost: From 30fps to 58fps 📈
✅ Initial render time reduced by 40% ⏩
✅ Memory usage decreased by 25% 🔥

💡 Final Thoughts

If you're building React Native apps with large lists, switching to FlashList can significantly improve performance. By combining it with smart optimizations like getItemLayout, viewabilityConfig, and reduced windowSize, you can achieve smooth scrolling, faster renders, and lower memory consumption.

Have you tried FlashList in your project? Share your experience in the comments below! 🚀

About me: My name is Arsen, and I am a react native developer and owner of the TG channel 👇

🔗 Join TG community for React Native Devs: REACT NATIVE HUB

DEV Community: Ars Dev

Why React Native Dominates Cross-Platform Development in 2025

Faster Development, Lower Costs

A Thriving Ecosystem & Large Developer Community

Native Performance with Flexibility

Powered by the JavaScript Ecosystem

Final Thoughts: Is React Native the Right Choice in 2025?

Trusted by Industry Leaders

The Complete React Native Styling Guide Every Developer Needs

The Foundation: Building a Design System That Scales

Why Most React Native Apps Look Inconsistent

Creating Your Design Token System

Building Reusable Component Libraries

The Problem with Inline Styling

Creating Semantic Component APIs

Flexbox Mastery: Layouts That Actually Work

Common Flexbox Patterns I Use Daily

Real-World Layout Example

Responsive Design: One Codebase, All Screen Sizes

The Hook That Changed Everything

Building Adaptive Components

Platform-Specific Styling Done Right

The Shadow Problem

Using Platform-Specific Styles

Dynamic Styling and Theme Support

Building a Theme Context

Theme-Aware Components

Key Takeaways for Professional React Native Styling

useDebounce — Stop Unnecessary API Calls in React Native

Persist Data Like a Pro in React Native

✅ Implementation using @react-native-async-storage/async-storage:

🧪 Usage Example: Theme Toggle

Expo Folder Structure with Zustand

Why Your React Native Components Don’t Need All Those Props (ISP)

What Is the Interface Segregation Principle?

Not following ISP

Following ISP

Why This Works

Cleaner Code with LSP: Writing Reusable React Native Components

What Is the Single Responsibility Principle?

Bad Example: Violating LSP in React Native

Following LSP

Key Takeaways

Why the OCP Makes You a Better React Native Dev

Key Takeaways

Why Every React Native Developer Should Respect the SRP

What Is the Single Responsibility Principle?

What Happens When You Don’t Follow SRP?

Following SRP

Why This Matters

Why Every React Native Developer Should Understand useCallback

Understanding the Problem: Function Recreation in React Components

Introducing useCallback

Applying useCallback in React Native

Practical Use Cases in React Native

Optimizing List Rendering with FlatList

Handling Event Listeners

Best Practices for Using useCallback

When Not to Use useCallback

Conclusion

Key Takeaways

How I Increased List Scroll FPS from 30 to 58 in React Native

🚀 The Problem: Low Performance in Large Lists

✅ The Solution: Using FlashList for Better Performance

🔍 Breaking Down the Optimization Techniques

📊 The Results: Huge Performance Gains

💡 Final Thoughts

✅ Implementation using `@react-native-async-storage/async-storage`:

Introducing `useCallback`

Applying `useCallback` in React Native

Optimizing List Rendering with `FlatList`

Best Practices for Using `useCallback`

When Not to Use `useCallback`