Lesson 1 of 15
Components & layout
Cross-platform building means writing your UI once and having it run on both iOS and Android — and the unit you build with is the component. This lesson is about composing components into a layout that works across platforms and screen sizes. Unlike the web (one screen shape, roughly), mobile UIs run on hundreds of devices — different sizes, notches, and two platforms — so a layout can't assume pixels; it must be built to adapt. Let's build layouts that travel. Let's compose components that work everywhere.
Components are the building blocks — on both platforms
ONE CODEBASE, BOTH PLATFORMS — a cross-platform framework (React Native here) maps
your components to REAL NATIVE UI on each platform:
function ProfileCard({ name, bio }) {
return (
<View style={styles.card}> // a container (native view on both)
<Image source={{ uri: avatar }} style={styles.avatar} />
<View style={styles.body}>
<Text style={styles.name}>{name}</Text>
<Text style={styles.bio}>{bio}</Text>
</View>
</View>
);
}
- You write ONE component tree; it renders as native UIKit views on iOS +
Android views on Android. No per-platform rewrite for normal UI.
- BUILD FROM SMALL, REUSABLE COMPONENTS — a Card, an Avatar, a Button — and
COMPOSE them into screens. The same discipline as React on the web.
- Layout is done with nested Views (containers) + Flexbox (next lesson) — NOT
absolute pixel positions. This is what lets ONE layout fit MANY screens.
THE PAYOFF: one component library -> your whole app, on both platforms.
The promise of cross-platform is write the UI once, run it on both platforms — and the unit you write is the component. A cross-platform framework (React Native here) maps your components to real native UI: a View becomes a native container on each platform, a Text becomes a native text view, and so on — you don't rewrite the UI per platform. The discipline is the same as React on the web: build from small, reusable components (a Card, an Avatar, a Button) and compose them into screens, so one component library powers your whole app on both platforms. Layout is done by nesting container Views and letting Flexbox size and arrange them (next lesson) — not by absolute pixel positions — and that is precisely what lets one layout fit many screens. Get comfortable thinking in components: it's the foundation the rest of cross-platform building stands on.
Composing a layout that adapts
A SCREEN = COMPOSED COMPONENTS INSIDE A SAFE, SCROLLABLE FRAME:
function FeedScreen() {
return (
<SafeAreaView style={{ flex: 1 }}> // avoid notch / status bar / home indicator
<Header title="Feed" />
<ScrollView contentContainerStyle={{ padding: 16 }}>
<PostCard {...post1} /> // reusable components, composed
<PostCard {...post2} />
<PostCard {...post3} />
</ScrollView>
</SafeAreaView>
);
}
CROSS-PLATFORM LAYOUT RULES:
- WRAP screens in SafeAreaView (or safe-area insets) — iOS notches/home indicator
+ Android status bars differ; SafeAreaView keeps content clear of them on BOTH.
- Use flex: 1 to FILL available space (instead of fixed heights) so it adapts to
any screen size.
- Make long content SCROLLABLE (ScrollView / a list) — content that fits a big
phone overflows a small one.
- Size with FLEX + PERCENTAGES + spacing, not hard-coded pixel widths, so the
layout stretches/shrinks to the device.
- Compose: a screen is Header + content + maybe a footer, each its own component.
A screen is composed components inside a safe, scrollable frame. Three cross-platform habits make a layout adapt instead of break: wrap screens in SafeAreaView (or use safe-area insets) so content stays clear of iOS notches / home indicator and Android status bars — which differ per device and platform; use flex: 1 to fill the available space instead of fixed heights, so the layout grows and shrinks with the screen; and make long content scrollable (a ScrollView or a list) because content that fits a big phone overflows a small one. Size things with flex, percentages, and spacing — not hard-coded pixel widths — so the layout stretches and shrinks to the device. And keep composing: a screen is a Header plus content plus maybe a footer, each its own component, reused across screens. Build this way and one layout genuinely serves the whole range of phones — and both platforms — without per-device tweaking.
The mistake beginners make
The first mistake is hard-coding pixel sizes and positions — giving views fixed widths/heights or absolute positions as if there were one screen, so the layout looks right on your phone and breaks (overflows, clips, leaves gaps) on others. Build with flex, percentages, and spacing so it adapts. The second mistake is forgetting the safe area — putting content at the very top/bottom, where it collides with the notch, status bar, or home indicator on some devices; wrap screens in SafeAreaView. The third mistake is not making content scrollable — a screen that fits a large phone cuts off on a small one because it can't scroll; use a ScrollView or list for anything that might overflow. And not composing into reusable components — repeating the same card markup instead of a Card component, which makes the app inconsistent and hard to change. Compose reusable components, size with flex (not pixels), respect the safe area, and make content scrollable.
Your turn
Your turn
- Build a reusable component: make a Card (or PostCard) component from nested Views, an Image, and Text, styled to look good — then render several of them, passing different props. Confirm one component powers many instances.
- Frame the screen safely: wrap the screen in a SafeAreaView with flex: 1 so content clears the notch/status bar/home indicator on both platforms, and fills the available space.
- Make it scrollable: put your cards inside a ScrollView (with content padding) so the screen works on a small phone where the content would otherwise overflow.
- Size with flex, not pixels: lay out a row (e.g. avatar + text) using flexDirection/flex and spacing rather than fixed pixel widths, and check it still looks right if you imagine a narrower or wider screen.
- Compose a screen: assemble a Header component + your scrollable list of cards into a FeedScreen, so the screen is built from reusable pieces you could reuse elsewhere.
Key points
- Cross-platform building = write the UI ONCE as components and it renders as real NATIVE UI on both iOS and Android (a View -> native container, Text -> native text) — no per-platform rewrite for normal UI.
- Build from small, reusable components (Card, Avatar, Button) and COMPOSE them into screens — the same discipline as React on the web; one component library powers your whole app on both platforms.
- Layout uses nested Views + Flexbox + spacing/percentages, NOT absolute pixel positions — that is exactly what lets ONE layout fit MANY screen sizes.
- Adapt to devices: wrap screens in SafeAreaView (clear the notch/status bar/home indicator on both platforms), use flex: 1 to fill space, and make long content scrollable (ScrollView/list) so it doesn't overflow small screens.
- The mistakes: hard-coding pixel sizes/positions (breaks on other devices), forgetting the safe area, not making content scrollable, and not composing reusable components (inconsistent + hard to change).
Q&A · 0
Enrol to ask questions and join the discussion.
No questions yet — be the first to ask.