Everything you've built in this course lives inside a browser. Components produce DOM elements, styles are CSS, events are DOM events, and storage is localStorage. This last lesson of the module makes the biggest leap yet: taking what you've learned outside the browser, into a mobile app that installs from a store and draws real native views. The good news is that most of what you know transfers intact — components, props, state, hooks, context, Redux, TanStack Query, the TypeScript types from the previous lesson; what changes is the presentation layer and the platform APIs. You're going to set up CicloUrbanoMovil with Expo, port BikeCard, StatusBadge and BikeList, understand why FlatList is not a map, navigate with Expo Router, and know exactly what code from the web project you can copy without touching a line. The goal isn't to master React Native in one lesson, but to understand the model, its limits, and what gets reused, so the leap is an informed decision.

1. What React Native is and how it differs from the alternatives
2. What's shared with React and what isn't
3. The architecture in one idea
4. Expo: creating CicloUrbanoMovil
5. Basic components and their web equivalents
6. Styles: StyleSheet and how it differs from CSS
7. Porting StatusBadge and BikeCard
8. BikeList with FlatList
9. What gets reused as-is from the web project
10. Navigation with Expo Router
11. Device capabilities
12. Platform differences and mobile accessibility
13. Debugging and testing
14. Publishing to the stores
15. Wrapping up the module and bridging to the final project

React Native is React with a different rendering target. The same React you know — the same reconciler, the same hooks, the same reconciliation from module 1 — but instead of producing DOM nodes it produces native views: a UIView on iOS, an android.view.View on Android.

That means a React Native <Text> isn't a <p> in disguise. It's a real UILabel, with the system's scrolling, the system's selection, the system's accessibility and the system's performance.

A comparison with the options usually on the table:

The row that decides between hybrid and React Native is the interface row. A hybrid app simulates the system's components with HTML and CSS: scrolling doesn't have the same inertia, forms don't behave the same, and users notice even if they can't say why. React Native uses the real components.

And to be honest about that shared percentage: the 85-95% is logic, not the whole interface. Navigation, spacing, gestures and several conventions differ between iOS and Android, and a well-crafted app addresses those differences instead of ignoring them.

This table is the mental map for the lesson.

What matters in this table is where the line falls: everything that's React is shared; everything that's web isn't. The distinction that separated server from client in 10-03 separates logic from presentation here, and it's just as useful for deciding where each thing belongs.

How it works internally, at the level of detail you need:

The idea in one sentence: your components describe the interface and the system paints real native views. You don't manipulate views; you describe what the current state should look like and React handles the rest. It's exactly the declarative model from module 1, with a different destination.

About the new architecture (enabled by default since React Native 0.76), you only need three names and what they solve:

• JSI (JavaScript Interface): lets JavaScript call native code directly, without serializing JSON messages across an asynchronous bridge. It removes React Native's historic bottleneck.
• Fabric: the new renderer, which enables synchronous operations and lets the interface respond within the same frame.
• TurboModules: native modules load when they're used, not all at startup, which reduces launch time.

You don't need more than that to work. What matters in practice is that React Native's classic performance problems — janky lists, animations that stutter — have improved a lot, and that the principles from module 8 (avoiding unnecessary renders, memoizing, virtualizing) are still valid and matter even more here, because a phone has less headroom than a laptop.

You can use "bare" React Native with the official CLI, but that means having Xcode and Android Studio configured from minute one, and managing native configuration by hand. Expo is the recommended way to start, and the one the official React Native documentation recommends.

The last command shows a QR code in the terminal. You install Expo Go on your phone, scan the code, and the app opens on the real device, with hot reload on save. No cables, no signing anything, no Xcode.

What Expo provides:

Structure of a freshly created project:

You'll recognize the app/ pattern: it's the same folder-based routing as Next.js. And notice that Expo's templates ship with TypeScript already configured, so everything from 10-04 applies directly.

We'll adapt the structure to the course's conventions:

There are no HTML tags: there are components imported from react-native.

The rule most people forget when starting out, and it's worth calling out:

On the web, any element can contain text. In React Native, only <Text> can. The reason is that text is measured and painted with the native typography engine, which is a different component from a container view. In exchange, <Text> can be nested and inherits styles, which is the only style inheritance that exists in React Native:

And for tappable elements, the current recommendation is Pressable, which gives you fine-grained control over states:

Notice style as a function that receives { pressed }: it's the substitute for CSS's :active, and it's a good example of how visual states get resolved here.

There's no CSS. Styles are JavaScript objects, grouped with StyleSheet.create:

Differences from CSS, and there are many worth keeping in mind:

The two differences that confuse people the most at first:

flexDirection: 'column' by default. In CSS, a flex container stacks in a row; here it stacks in a column, which is the norm for a vertical screen. If something shows up stacked when you expected it inline, this is why.

No cascade. A style set on the parent View is not inherited by the children. Each component carries its own. It can feel like a step backward, but it wipes out the most common class of CSS bugs in one stroke: the style that arrives from some ancestor nobody remembers. It's the same philosophy as the CSS Modules from module 2, taken to the extreme.

Styles are combined by passing an array, and the last one wins:

And CicloUrbano's theme variables move into a constants module, since there's no :root:

The as const from 10-04 makes each value a literal, which gives exact autocomplete when you use it.

This is where you see what actually changes. The props structure and the logic stay identical; only the presentation layer changes.

Compare it with the web version from 10-04: the Props type, the LABELS object and the signature are exactly the same. The only thing that changes is <span> → <View> + <Text>, and styles.badge from CSS Modules → StyleSheet. A Record<BikeStatus, string> still forces you to cover all three statuses.

The course's prop convention is followed to the letter: internal handler handlePress, outward-facing prop onSelect. What's platform-specific is Pressable instead of <Link>, accessibilityLabel instead of aria-label, and an explicit flexDirection: 'row' on the header.

Here's the most important conceptual difference in the lesson, and it connects directly to the virtualization from 08-01.

On the web you wrote this:

With 5 bikes it works fine. With 500 on a phone, the app freezes: 500 native views get created at once, memory gets consumed, and the UI thread runs out of headroom. A <ScrollView> with a map inside has exactly the same problem, because it also renders all of its children.

FlatList is a virtualized list: it only keeps the visible items and a few around them in memory, and it reuses views as you scroll.

The essential props:

Why FlatList isn't a map, in table form:

And this connects directly to module 8: virtualization, which was presented there as an advanced technique you had to add with a library, comes built in with React Native and is the default path. The reason is context: on a phone, that headroom isn't optional.

A performance tip that also comes from there: wrap BikeCard in memo and define renderItem with useCallback. While scrolling, FlatList re-renders frequently, and avoiding unnecessary renders shows up in smoothness far more visibly than on the web.

This is the practical question: how much code do you copy without touching it.

In a team maintaining both apps, that shared core gets extracted into a package (@ciclourbano/core) inside a monorepo. And notice the practical consequence of 10-04: types/domain.ts is the first thing that gets shared, because types have no dependencies and now both projects speak about the same verified domain.

The most common substitution, useLocalStorage:

The key difference: localStorage is synchronous and AsyncStorage isn't, so a third value shows up, loaded, indicating whether the preference has been read yet. It's the same dark-theme problem you dealt with in 10-01 with hydration, with a different cause.

Expo Router uses file-based routing, exactly like the App Router from 10-01. If you understood that, you already know this.

Equivalences with React Router, which you already know from module 6:

The tabs layout:

And a detail screen with a dynamic parameter:

Two mobile navigation concepts with no web equivalent:

• Stack: screens stack up and you go back with the gesture or Android's physical back button. The slide-in entry animation is part of the platform convention.
• Tabs: the bottom bar with the main sections. Each tab keeps its own stack and its own state when you switch between them, something that would have required explicit work on the web.

And notice that useBike is the exact same TanStack Query query from the web project: the data layer is reused intact.

This is the main reason a company like CicloUrbano would want a mobile app and not just a website. Three examples with real product sense:

Location: finding the nearest station.

Camera: scanning a bike's QR code to unlock it.

Notifications: warning that a booking ends in 10 minutes.

A warning about permissions and privacy. Each of these capabilities requires the user's explicit permission, and it can be denied. Three rules that aren't optional: (1) ask for the permission when you need it, not at launch, and explain why beforehand; (2) the app must work without it — if location is denied, show the list of stations sorted alphabetically; (3) declare the uses in app.json with clear text: Apple and Google reject apps with generic justifications, and background location gets special review scrutiny.

iOS and Android aren't the same, and a well-crafted app acknowledges that instead of forcing a single design.

The differences that stand out the most:

Accessibility. The concepts from module 3 carry over under different names, and on mobile they matter just as much or more, because VoiceOver (iOS) and TalkBack (Android) are very widely used:

Two rules specific to mobile: the minimum tappable area is about 44×44 points (use hitSlop if the visual element is smaller), and contrast must still meet the 4.5:1 ratio — CicloUrbano's colors already meet it.

Briefly, because you already have the concepts from module 9.

Debugging:

• Fast Refresh: on by default, keeps state on save.
• Dev menu: shake the device or press m in the Expo terminal.
• React DevTools: work the same, including the Profiler from 08-05.
• Expo debugger: network inspector, console and JavaScript breakpoints.
• console.log: shows up in the terminal running npx expo start.

Testing, with the same tools from module 9 and their equivalents:

The Testing Library API is nearly identical, and the guiding principle from 09-01 — test behaviour, not implementation — holds without change:

The visible difference: fireEvent.press instead of click, and getByText returns a React Native node instead of a DOM element. Role-based queries are still the preferred way, just like in 09-03, and for the same reason: if the element has no role, it has none for the screen reader either.

A summary of what it involves, because it changes how you plan releases.

What you need to know before committing to dates:

And the piece that changes the pace of work: over-the-air updates. With eas update, a change that only touches JavaScript — a copy fix, a style tweak, a logic bug — gets published without going through review:

Users get it on their next launch. What does require a new version and its review is any change to native code: a new library with a native part, a new permission, a changed icon or name. The rule, worth having written down as a team: JavaScript over the air, native code through the store.

Module 10 has taken React into five territories that didn't exist at the start:

• 10-01 · SSR with Next.js: the HTML arrives already built; the four rendering strategies; hydration and its mismatches; ciclourbano-web with the App Router.
• 10-02 · SSG and ISR: generate once and revalidate; generateStaticParams, revalidate, revalidateTag; the hybrid architecture pulled together.
• 10-03 · Suspense and RSC: the suspension mechanism, streaming, the 'use client' boundary and server actions.
• 10-04 · TypeScript: static analysis as the cheapest layer; the domain in types/domain.ts; components, hooks, events, Redux, Query and boundary validation with Zod.
• 10-05 · React Native: the same React, outside the browser.

And now the notice already given in 10-02 and 10-03, now for real:

Module 11 builds the final project with Vite + React Router, the CicloUrbano management app you've been building since the first module. Not with Next.js or React Native.

It's not a contradiction: it's the criterion this module has given you, put into practice. The final project is a private, sign-in-gated work tool with heavy interactive state, exactly the cell in the 10-02 table where CSR is the right answer.

What the final project will put into practice, module by module:

• Putting text outside a <Text>. Classic day-one mistake: <View>Hello</View> fails. All text goes inside Text.
• Expecting styles to be inherited. There's no cascade. Every component carries its own style; the only inheritance is Text nested inside Text.
• Forgetting flexDirection: 'row'. It stacks in a column by default. If something shows up stacked when you wanted it inline, this is why.
• Using ScrollView with .map() for data lists. It renders everything and freezes the app. Use FlatList from the start.
• Writing fontWeight: 600. It has to be the string '600'.
• Using px, rem or vh. Numbers are unitless. vh and rem don't exist; screen size is queried with useWindowDimensions().
• Copying useLocalStorage without adapting it. AsyncStorage is asynchronous: you have to manage the "not loaded yet" state.
• Asking for all permissions at launch. It annoys users and is grounds for store rejection. Ask when you need them, with context.
• Assuming the app works without permissions. Always design the fallback path for when they're denied.
• Testing only on an iOS simulator. Sizes, gestures, the back button and performance are all different on Android and on real mid-range devices.
• Tip: start with the shared logic. Copy types/, the pure utilities, the slices and the queries before writing a single screen. You'll immediately see how much is already done.
• Tip: think in gestures, not clicks. Swiping, long-pressing, pulling to refresh and the back button are part of the mobile language. Porting the web literally produces an app that feels foreign.

Exercise 1. This component, hastily ported from the web, has five React Native mistakes. Find them, explain each one, and rewrite it.

Exercise 2. Write StationsScreen for CicloUrbanoMovil: it fetches the stations with the TanStack Query query reused from the web project, shows them in a FlatList with "pull to refresh", handles the loading, error and empty-list states, and navigates to the detail screen on press. Also state which files from the web project you copied unmodified.

Exercise 3. CicloUrbano's team wants the app to show the nearest station first when it opens. Design the complete solution: what permission is needed and when to ask for it, what happens if the user denies it, where that logic should live so it can be tested, and what part can be reused on the web. Write the useNearestStation hook and explain your decisions.

Solution 1. The five mistakes:

1. onClick doesn't exist. In React Native it's onPress, and a View isn't tappable: you need Pressable or TouchableOpacity.
2. Loose text inside a View. {station.name} and the district line need to go inside <Text>.
3. padding: '16px'. Numeric values are unitless and unquoted: padding: 16.
4. display: 'flex' is redundant, and flexDirection: 'row' is missing: it stacks in a column by default, so the header wouldn't line up horizontally.
5. The types are missing (10-04), along with accessibilityRole/accessibilityLabel for the screen reader.

Solution 2.

Files copied unmodified from the web project:

• types/domain.ts — the domain entities.
• types/schemas.ts — the Zod schemas, including boundary validation.
• queries/stations.ts — the TanStack Query query; only the base URL gets adjusted, because localhost from a real phone points at the phone itself (you need the development machine's IP or an environment variable).

The only thing written from scratch is the presentation layer: FlatList instead of <ul>, ActivityIndicator instead of LoadingIndicator, and RefreshControl, which has no web equivalent.

Solution 3.

The decisions and their reasoning:

• When to ask for the permission: on entering the stations screen, not at app launch. The user understands why they're being asked because they're looking at a list of stations. In production it's also worth having a screen beforehand that explains it before triggering the system dialog, because on iOS you can only ask once.
• If it's denied: the list is sorted alphabetically and usingLocation stays false, so the UI can show a discreet notice with a link to settings. The core functionality doesn't depend on the permission.
• Where the logic lives so it can be tested: the calculation is in utils/geography.ts, a pure function sortByProximity(stations, lat, lon). It's tested with Vitest, no simulators or permissions needed, exactly like validateBooking in 09-02. The hook only orchestrates the permission, the fetch and the state.
• What gets reused on the web: sortByProximity as-is, and almost the entire hook structure; only expo-location gets swapped for navigator.geolocation. It's worth extracting a per-platform getPosition() and keeping the rest shared.
• The cancelled cleanup avoids updating state if the user leaves the screen while the location is still resolving: the same pattern from 05-02, applied here.

This lesson closes out Module 10 and, with it, the entire technical journey of the course before the project.

The essence of React Native is that it's React with a different rendering target: the same reconciler, the same hooks and the same declarative model from module 1, but producing real native views instead of DOM nodes. That's what sets it apart from the mobile web, from PWAs and from hybrid apps, which simulate the system's components inside a WebView and always feel like a website. From the new architecture, you only need to hold on to three names — JSI, Fabric and TurboModules — and their consequence: less of a bottleneck, faster startup, and the performance principles from module 8 more relevant than ever, because a phone has less headroom.

The line is clear: everything that's React is shared; everything that's web isn't. The DOM goes, HTML tags go, CSS with its cascade and selectors goes, localStorage goes, and so does React Router. What stays: components, props, composition, all the hooks, context, memo, Suspense, error boundaries, Redux Toolkit, TanStack Query and the types from 10-04.

In terms of tooling, you've set up CicloUrbanoMovil with Expo (npx create-expo-app, Expo Go, EAS Build and EAS Update), with Expo Router navigating by files just like the App Router from 10-01 — _layout.tsx, [bicicletaId].tsx, useLocalSearchParams, stacks and tabs. The interface is written with View, Text, Image, TextInput, Pressable, ScrollView, FlatList and SafeAreaView, with two rules to internalize on day one: all text goes inside Text and there's no style cascade. Styles are StyleSheet.create objects, in camelCase, with unitless numbers, Flexbox by default and flexDirection: 'column', with no selectors, no :hover and no media queries.

From porting CicloUrbano, what matters is how little changes: StatusBadge and BikeCard keep the same props structure, the same types and the same logic; only the presentation and the platform conventions (onPress, accessibilityLabel) get rewritten. And BikeList with FlatList — data, renderItem, keyExtractor — introduces the deeper lesson: FlatList isn't a map, but a virtualized list that keeps around fifteen items in memory instead of five hundred. The virtualization that was an advanced technique you had to add in 08-01 is the default path here.

And the balance sheet everything else builds on: copied without changes are types/domain.ts, the Zod schemas, validateBooking, availability, the Redux slices, the TanStack Query queries and the DOM-free hooks; adapted are useLocalStorage (to AsyncStorage, which is async), useWindowWidth and useOnlineStatus; and only the presentation layer and navigation get rewritten. On top of that core, mobile adds what the web can't give you — location, camera and notifications — under the one rule that governs all of them: ask for the permission when you need it, explain why, and make the app work if they say no. Rounding things out are the platform differences with Platform.select, mobile accessibility with accessibilityLabel and accessibilityRole, testing with Jest and @testing-library/react-native under the same principle from 09-01, and publishing with its golden rule: JavaScript over the air with eas update, native code through the store.

With this, Module 10 comes to a close. You started the module with an app that got downloaded to the browser and ran there, and you're finishing it knowing how to generate HTML on the server and at build time, decide which strategy each screen deserves, understand where each component runs and what crosses the server/client boundary, turn implicit contracts into verified types, and carry all of that knowledge onto a phone. You haven't learned five separate technologies: you've learned to choose.

And now it's time to prove it. Module 11: Project builds the complete CicloUrbano app from start to finish, with Vite and React Router — the right call for a private, interactive, sign-in-gated management tool, by the very criterion you applied yourself in 10-02. That's where the ten modules come together: setup and planning, the interface with its components and accessibility, state with context, Redux Toolkit and TanStack Query, testing across its four levels, and deployment to production. The next lesson is Setup and Planning.