React Native og Expo: Mobilutvikling med webutvikler-bakgrunn

Som webutvikler med React-erfaring var React Native det naturlige steget inn i mobilutvikling. Da jeg bygget Sparkels — en mobil prototype for personlig utvikling — valgte jeg Expo som fundament. Det var en beslutning som sparte uker med oppsett og lot meg fokusere på produktet i stedet for build-konfigurasjoner.

Denne guiden handler om hva som faktisk fungerer når du kommer fra webverdenen, hvor abstraksjonen lekker, og hvorfor Expo har blitt standarden for React Native-utvikling.

Overgangen fra web til mobil

Mye av det du kan fra React overføres direkte. Komponentmodellen er den samme. State management fungerer likt. Hooks er identiske. Men det er noen fundamentale forskjeller som biter deg tidlig.

Det finnes ingen DOM. Du bruker ikke <div> og <span> — du bruker <View> og <Text>. Alt tekstinnhold må wrappe i en <Text>-komponent, ellers krasjer appen. Det virker opplagt, men det er overraskende lett å glemme når du har skrevet web-kode i årevis.

CSS fungerer ikke slik du tror. React Native bruker en CSS-lignende subset via JavaScript-objekter. Flexbox er standard layout-modell, men default flex direction er column i stedet for row. Det finnes ingen cascading — stiler arves ikke fra foreldre til barn. Ingen media queries. Ingen pseudo-selektorer.

Navigasjon er en helt annen verden. På web har du URL-er og en router. På mobil har du en stack av skjermer, tab-barer, og drawer-navigasjon. React Navigation er de facto-standarden, og det tar tid å internalisere mentale modellen.

Hvorfor Expo endrer spillet

Før Expo var det å starte et React Native-prosjekt en øvelse i frustrasjon. Xcode-oppdateringer som brøt bygget. CocoaPods-konflikter. Android SDK-versjoner. Gradle-feil som ingen forstår.

Expo abstraherer bort alt dette. Du kjører npx create-expo-app, og du har en fungerende app på under ett minutt. Expo Go-appen lar deg teste på en fysisk enhet uten å kompilere noe som helst.

OTA-oppdateringer er kanskje den viktigste funksjonen. Med expo-updates kan du pushe JavaScript-oppdateringer direkte til brukernes enheter uten å gå gjennom App Store-review. For Sparkels betydde dette at vi kunne fikse bugs og iterere på UI umiddelbart.

EAS Build fjerner behovet for lokale build-maskiner. Expo sine skyservere kompilerer iOS- og Android-binærene for deg. Du trenger ikke engang en Mac for å bygge iOS-apper — noe som er en gamechanger for team med variert maskinpark.

Sparkels: Fra idé til prototype

Sparkels var et mobilprosjekt for personlig utvikling — en prototype der brukere setter mål, sporer fremgang, og får motiverende påminnelser. Expo var perfekt for dette stadiet: vi trengte rask iterasjon, push-notifikasjoner, og en pen UI uten å investere måneder i oppsett.

Navigasjonsstrukturen var enkel men effektiv — en tab-basert layout med en stack navigator for detalj-skjermer:

import { createBottomTabNavigator } from '@react-navigation/bottom-tabs';
import { createNativeStackNavigator } from '@react-navigation/native-stack';

const Tab = createBottomTabNavigator();
const Stack = createNativeStackNavigator();

function HomeStack() {
  return (
    <Stack.Navigator screenOptions={{ headerShown: false }}>
      <Stack.Screen name="Feed" component={FeedScreen} />
      <Stack.Screen name="GoalDetail" component={GoalDetailScreen} />
    </Stack.Navigator>
  );
}

function AppNavigator() {
  return (
    <Tab.Navigator screenOptions={{ tabBarActiveTintColor: '#6C5CE7' }}>
      <Tab.Screen name="Hjem" component={HomeStack} />
      <Tab.Screen name="Mål" component={GoalsScreen} />
      <Tab.Screen name="Profil" component={ProfileScreen} />
    </Tab.Navigator>
  );
}

Denne strukturen gir en kjent mobil-navigasjonsopplevelse: tabs for hovedseksjoner, og en stack innen hver tab for å drille ned i detaljer.

Plattformspesifikk styling

En av de subtile utfordringene med React Native er at iOS og Android har forskjellige design-konvensjoner. Skygger fungerer forskjellig. Statusbaren oppfører seg forskjellig. Scroll-oppførsel er forskjellig.

Platform-API-et lar deg håndtere dette elegant:

import { Platform, StyleSheet } from 'react-native';

const styles = StyleSheet.create({
  card: {
    backgroundColor: '#fff',
    borderRadius: 12,
    padding: 16,
    marginVertical: 8,
    ...Platform.select({
      ios: {
        shadowColor: '#000',
        shadowOffset: { width: 0, height: 2 },
        shadowOpacity: 0.1,
        shadowRadius: 8,
      },
      android: {
        elevation: 4,
      },
    }),
  },
});

iOS bruker shadow*-properties mens Android bruker elevation. Det er en liten detalj, men den type plattform-bevissthet gjør forskjellen mellom en app som føles native og en som føles som en webside i en wrapper.

Når du bør gå ekte native

Expo og React Native er utmerkede verktøy, men de har klare begrensninger.

Tung native funksjonalitet. Hvis appen din er sentrert rundt kamera-prosessering, AR, eller komplekse animasjoner som krever tilgang til Metal/Vulkan, vil du slite. React Native sitt bridge-lag legger til latens som merkes i sanntidsapplikasjoner.

Ytelse i store lister. FlatList er god, men for lister med tusenvis av elementer og kompleks rendering, vil du treffe veggen raskere enn med native RecyclerView/UICollectionView.

App-størrelse. En minimal Expo-app er rundt 25 MB. En tilsvarende native Swift-app kan være under 5 MB. For de fleste apper spiller dette ingen rolle, men det er verdt å vite.

For Sparkels var ingen av disse problemene relevante. Vi bygget en innholdsbasert app med standard UI-mønstre. Expo lot oss fokusere på brukeropplevelsen i stedet for build-systemer, og det var den riktige avveiningen for et prototype-prosjekt.

Avsluttende tanker

React Native med Expo er den raskeste veien fra webkompetanse til en fungerende mobilapp. Det er ikke perfekt — du gir opp noe ytelse og native kontroll. Men for de fleste applikasjoner, spesielt i prototyp- og MVP-fasen, er trade-off verdt det.

Mitt råd: start med Expo. Når du treffer en vegg, bruk expo prebuild for å ejecte til bare workflow. Og hvis du oppdager at hele appen din er native kode uansett — da er det kanskje på tide å vurdere Swift eller Kotlin direkte.