Building mobile applications for both iOS and Android doesn’t have to mean writing everything twice. That’s the promise of React Native. You use JavaScript to describe your app’s interface, and it handles the translation into the real, native components each platform uses. But to do this well, to make an app that feels right at home on an iPhone and a Pixel, you need good habits. You need patterns.
I think of these patterns as a set of blueprints. They help you solve the common problems you’ll bump into, like making a button look correct on two different operating systems or saving data when the phone loses its signal. Let’s walk through some of the most important ones I use every day.
First, let’s talk about how you build your pieces. In React Native, you don’t use HTML tags like <div> or <h1>. Instead, you use components like <View> and <Text>. The layout uses Flexbox, which is a powerful way to say, “put this here and that there,” and have it work on any screen size. The real trick starts when you need something to look or behave slightly differently on iOS and Android.
You can write this logic directly into your component. The Platform module lets you check which OS you’re running on and adjust accordingly. It’s straightforward and works for small tweaks.
import { Platform, Text, TouchableOpacity } from 'react-native';
function PlatformAwareButton({ title }) {
// Check the operating system once
const isIOS = Platform.OS === 'ios';
return (
<TouchableOpacity
style={{
padding: isIOS ? 14 : 12, // More padding on iOS
backgroundColor: '#007AFF',
borderRadius: isIOS ? 10 : 6, // More rounded on iOS
}}>
<Text style={{ color: 'white', fontWeight: isIOS ? '600' : '500' }}>
{title}
</Text>
</TouchableOpacity>
);
}
For bigger differences, where the iOS and Android versions are almost completely separate, React Native has a neater trick. You can create two files: CustomButton.ios.js and CustomButton.android.js. When you import CustomButton, the system automatically picks the right file. This keeps your code clean. The iOS file can use Apple’s design language, and the Android file can follow Material Design, but to the rest of your app, it’s just one CustomButton component.
Getting around in a mobile app is different from a website. Users expect to swipe back, tap tabs at the bottom, and have the app remember where they were. This is where navigation patterns come in. A library like React Navigation is the standard tool for this job.
You typically have a stack of screens. Think of a news app: you tap a headline on the main list (the Feed screen) and it slides in a new screen with the full article (the Details screen). That’s a stack. Then you might press the back button, and it slides the article away to return to the list.
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';
// This creates the navigator
const Stack = createNativeStackNavigator();
function App() {
return (
<NavigationContainer>
<Stack.Navigator>
{/* The first screen in the stack is your home */}
<Stack.Screen name="Feed" component={FeedScreen} />
{/* Other screens you can navigate to */}
<Stack.Screen name="ArticleDetails" component={DetailsScreen} />
<Stack.Screen name="UserProfile" component={ProfileScreen} />
</Stack.Navigator>
</NavigationContainer>
);
}
// Inside your FeedScreen component, you can navigate
function FeedScreen({ navigation }) {
const handleArticlePress = (articleId) => {
// This line pushes the Details screen onto the stack
navigation.navigate('ArticleDetails', { id: articleId });
};
return (
// ... your list of articles, each with an onPress calling handleArticlePress
);
}
For apps with a few main sections, you use a tab navigator at the bottom (or top on Android). It’s common to combine these: tabs for the main areas, and each tab has its own stack of screens inside it. This structure gives users the familiar, smooth navigation they expect from any good mobile app.
Your app needs to remember things. Is the user logged in? What theme did they pick? This is state. For small amounts of data that should survive when the app closes, like user settings, I use AsyncStorage. It’s like a simple key-value store on the device.
import AsyncStorage from '@react-native-async-storage/async-storage';
// Saving a user's preference
const saveThemePreference = async (theme) => {
try {
await AsyncStorage.setItem('@app_theme', theme);
} catch (e) {
console.log('Failed to save theme:', e);
}
};
// Loading it when the app starts
const loadThemePreference = async () => {
try {
const theme = await AsyncStorage.getItem('@app_theme');
if (theme !== null) {
return theme; // Return 'light' or 'dark'
}
} catch (e) {
console.log('Failed to load theme:', e);
}
return 'light'; // A default value
};
For state that needs to be shared across many parts of your app, like the current user object or a global theme, React’s Context is perfect. It lets you broadcast data down the component tree without passing it manually through every level.
import React, { createContext, useState, useContext } from 'react';
// 1. Create the Context
const AuthContext = createContext();
// 2. Create a Provider component
export function AuthProvider({ children }) {
const [user, setUser] = useState(null); // This state is now global
const login = (userData) => {
// Perform login logic, then...
setUser(userData);
};
const logout = () => {
// Perform logout logic, then...
setUser(null);
};
// This value is available to any child component
return (
<AuthContext.Provider value={{ user, login, logout }}>
{children}
</AuthContext.Provider>
);
}
// 3. A custom hook to use the context easily
export function useAuth() {
return useContext(AuthContext);
}
// 4. Wrap your app with the provider
// In your main App.js: <AuthProvider><App /></AuthProvider>
// 5. Use it in any component deep in the tree
function ProfileHeader() {
const { user, logout } = useAuth(); // Get the user and logout function
return (
<View>
<Text>Hello, {user?.name}</Text>
<Button title="Log Out" onPress={logout} />
</View>
);
}
For very large and complex apps, you might eventually add a library like Redux, but Context and AsyncStorage handle a huge amount on their own.
Sometimes, you need to talk to the phone itself. You might need to access the fingerprint scanner, the Bluetooth radio, or a specific sensor. React Native provides many of these APIs, but not all. When you need something it doesn’t offer, you write a “native module.” This is a bridge between your JavaScript code and the native Java/Kotlin (for Android) or Objective-C/Swift (for iOS) code.
Don’t let this scare you. The pattern is consistent. You write a small piece of native code that exposes a function, and React Native makes it available as a JavaScript promise. Here’s a simplified look at how you’d make a module to get the device model.
On Android (Java):
// AndroidNativeModule.java
public class DeviceInfoModule extends ReactContextBaseJavaModule {
@ReactMethod
public void getDeviceModel(Promise promise) {
try {
String model = android.os.Build.MODEL;
promise.resolve(model); // Send back to JavaScript
} catch (Exception e) {
promise.reject("ERROR", e.getMessage()); // Send an error back
}
}
}
On iOS (Objective-C):
// DeviceInfo.m
RCT_EXPORT_METHOD(getDeviceModel:(RCTPromiseResolveBlock)resolve
rejecter:(RCTPromiseRejectBlock)reject) {
@try {
NSString *model = [[UIDevice currentDevice] model];
resolve(model); // Send back to JavaScript
} @catch (NSException *exception) {
reject(@"ERROR", exception.reason, nil); // Send an error back
}
}
In your JavaScript, you use them together:
import { NativeModules, Platform } from 'react-native';
// Platform.select picks the right one automatically
const deviceModule = Platform.select({
ios: NativeModules.DeviceInfo,
android: NativeModules.DeviceInfoModule,
});
const getModel = async () => {
try {
const model = await deviceModule.getDeviceModel();
console.log('Your device is a:', model);
} catch (err) {
console.error('Could not get model:', err);
}
};
This pattern is powerful. It means you can access every feature of the phone, even if React Native doesn’t support it yet.
Phones have less memory and slower processors than laptops. A pattern that works on the web might feel sluggish in your hand. Performance matters. A key area is lists. If you have a list with hundreds of items, rendering them all at once will freeze the app.
You use the FlatList component. It only renders the items that are on the screen (or just about to be), plus a few for a smooth scroll. It’s called “windowing” or “virtualization.”
import { FlatList } from 'react-native';
function BigList({ data }) {
const renderItem = ({ item }) => <ListItem item={item} />;
return (
<FlatList
data={data} // Your big array of items
renderItem={renderItem} // How to draw one item
keyExtractor={item => item.id} // A unique key for each
initialNumToRender={10} // How many to start with
maxToRenderPerBatch={5} // How many to add per frame
windowSize={5} // How many screens ahead to keep rendered
removeClippedSubviews={true} // Unmount off-screen items (Android help)
getItemLayout={(data, index) => ({
length: 80, // Each row is 80 units tall
offset: 80 * index, // So item 10 starts at 800
index,
})} // This makes scrolling to a specific index very fast
/>
);
}
Images are another big one. Downloading and displaying many large images can crush performance. You should use an optimized image component like react-native-fast-image. It caches images so they don’t re-download, handles memory better, and provides more resize options.
People use phones everywhere: in buildings with thick walls, on subways, in the middle of nowhere. Your app will lose its connection. A good app doesn’t just crash or show a blank screen. It handles this gracefully.
The pattern involves queuing. When the user performs an action that needs the network (like posting a comment), you store that request locally if you’re offline. When the connection comes back, you send all the queued requests.
class RequestQueue {
constructor() {
this.queue = [];
this.isConnected = true;
}
// Add a new request to the queue
add(request) {
this.queue.push({
id: Date.now(),
action: request.action, // e.g., 'POST_COMMENT'
data: request.data,
timestamp: new Date(),
});
this.saveToStorage(); // Save to AsyncStorage
this.tryToProcess(); // Try to send it now
}
// Try to send everything in the queue
async tryToProcess() {
if (!this.isConnected || this.queue.length === 0) return;
// Work through the queue
for (const request of [...this.queue]) {
try {
await this.sendToServer(request);
// If successful, remove it from the queue
this.queue = this.queue.filter(r => r.id !== request.id);
this.saveToStorage();
} catch (error) {
// If it fails due to network, stop trying
if (error.message.includes('Network')) {
break;
}
// If it's a server error, we might also remove it or flag it
}
}
}
async sendToServer(request) {
// Your actual fetch or axios call here
const response = await fetch('https://api.yourapp.com/data', {
method: 'POST',
body: JSON.stringify(request.data),
});
if (!response.ok) throw new Error('Server error');
}
updateConnectionStatus(isConnected) {
this.isConnected = isConnected;
if (isConnected) {
this.tryToProcess(); // We're back online! Send the queue.
}
}
}
// Hook to listen for network changes
import NetInfo from '@react-native-community/netinfo';
// In your app setup
const requestQueue = new RequestQueue();
NetInfo.addEventListener(state => {
requestQueue.updateConnectionStatus(state.isConnected);
});
With this, a user can write a comment, tap “Post,” and even if they’re on airplane mode, the comment will appear in their local list. Later, when they get Wi-Fi, it will silently sync to the server. It feels magical and robust.
How do you know your patterns work? You test them. Testing in React Native involves checking your JavaScript logic and making sure your components behave correctly on different platforms.
For your components and logic, you use a testing library like Jest alongside React Native Testing Library. This lets you render components in a test environment and simulate presses or text input.
import { render, fireEvent, screen } from '@testing-library/react-native';
test('the login button calls the onPress function', () => {
// A mock function to spy on
const mockOnPress = jest.fn();
render(<LoginButton onPress={mockOnPress} />);
// Find the button and "press" it
fireEvent.press(screen.getByText('Log In'));
// Verify the mock was called
expect(mockOnPress).toHaveBeenCalledTimes(1);
});
test('platform-specific styling is applied', () => {
// Force the Platform.OS to be 'ios'
jest.mock('react-native/Libraries/Utilities/Platform', () => ({
OS: 'ios',
select: (config) => config.ios,
}));
render(<PlatformAwareButton />);
const button = screen.getByRole('button');
// Check for iOS-specific border radius
expect(button.props.style).toMatchObject({ borderRadius: 10 });
});
You also mock your native modules and external dependencies. This ensures your tests are fast and only test your code, not whether the phone’s GPS is working.
// In a __mocks__ folder or at the top of your test file
jest.mock('@react-native-async-storage/async-storage', () => ({
setItem: jest.fn(() => Promise.resolve()),
getItem: jest.fn(() => Promise.resolve('light')),
}));
jest.mock('react-native-device-info', () => ({
getModel: jest.fn(() => Promise.resolve('iPhone Simulator')),
}));
For the final, full integration, you need to run your app on real devices and simulators. Services like Firebase Test Lab or AWS Device Farm let you test on hundreds of real, physical phones in the cloud to catch platform-specific bugs you might miss on your own devices.
These patterns are not strict rules, but proven starting points. They solve the real, daily problems of building for two platforms at once. Component patterns keep your UI consistent yet correct. Navigation patterns make your app feel like a native citizen. State patterns keep your data in sync. Native modules open the full power of the device. Performance patterns keep everything smooth. Offline patterns build user trust. Testing patterns give you confidence.
You start with a View and a Text component. You add navigation to move between screens. You add state to make it dynamic. You bridge to native features to make it powerful. You optimize so it’s fast. You handle offline so it’s reliable. You test so it’s solid. Each pattern builds on the last, transforming your JavaScript into a complete, professional mobile application. That’s the practical journey of React Native development.
