Ga naar inhoud
·2 min

React Native bij VodafoneZiggo: lessen van een app voor 3M+ gebruikers

Wat ik leerde van het bouwen aan een enterprise cross-platform app voor miljoenen gebruikers. Over design systems, testcoverage en de realiteit van React Native in productie.

React NativeMobileEnterpriseDesign System

Tussen november 2024 en maart 2025 werkte ik als Senior Frontend Developer bij VodafoneZiggo aan een cross-platform mobiele applicatie die dagelijks door meer dan 3 miljoen actieve gebruikers wordt gebruikt. Dit zijn de lessen die ik meenam.

De schaal van het probleem

Een app voor 3 miljoen gebruikers bouwen is fundamenteel anders dan een app voor een paar duizend gebruikers. Elke beslissing — van state management tot animaties — heeft directe impact op de gebruikerservaring van miljoenen mensen.

De stack: React Native met Expo SDK, TypeScript, Redux Toolkit en Storybook voor het design system. Op papier eenvoudig. In de praktijk kom je constant grenzen tegen.

Design systems zijn geen luxe

Het eerste wat me opviel bij aanvang was het gebrek aan consistentie in de bestaande codebase. Dezelfde button, meerdere implementaties. Hetzelfde kleurenpalet, op tien verschillende plekken hardcoded.

We besloten vroeg om een volledig design system op te zetten in Storybook. Niet als bijproduct, maar als eerste prioriteit.

// Voorbeeld: een consistente Button component
interface ButtonProps {
  variant: 'primary' | 'secondary' | 'ghost';
  size: 'sm' | 'md' | 'lg';
  loading?: boolean;
  disabled?: boolean;
  onPress: () => void;
  children: React.ReactNode;
}
 
export const Button = ({ variant, size, loading, disabled, onPress, children }: ButtonProps) => {
  return (
    <Pressable
      style={[styles.base, styles[variant], styles[size]]}
      onPress={onPress}
      disabled={disabled || loading}
      accessibilityRole="button"
      accessibilityState={{ disabled: disabled || loading }}
    >
      {loading ? <ActivityIndicator /> : <Text style={styles.label}>{children}</Text>}
    </Pressable>
  );
};

Na drie maanden hadden we 100+ gedocumenteerde componenten. Het resultaat: nieuwe features bouwen ging letterlijk twee keer zo snel. Designers en developers spraken ineens dezelfde taal.

Testcoverage als fundament

Bij een app van deze schaal is 90%+ testcoverage geen nice-to-have — het is het minimale vangnet dat je verhindert om nachtenlang in productie te debuggen.

Onze aanpak:

Unit tests voor business logic

Redux reducers, selectors en utilities: 100% coverage. Hier wil je geen verrassingen.

describe('authSlice', () => {
  it('should handle login success', () => {
    const action = loginSuccess({ userId: '123', token: 'abc' });
    const state = authReducer(initialState, action);
    expect(state.isAuthenticated).toBe(true);
    expect(state.userId).toBe('123');
  });
 
  it('should clear state on logout', () => {
    const loggedInState = { ...initialState, isAuthenticated: true };
    const state = authReducer(loggedInState, logout());
    expect(state.isAuthenticated).toBe(false);
  });
});

Integration tests voor gebruikersflows

De meest waardevolle tests zijn die de kritische gebruikerspaden testen: inloggen, de kern van de app gebruiken, uitloggen.

it('should navigate to dashboard after successful login', async () => {
  const { getByTestId } = render(<App />);
 
  fireEvent.changeText(getByTestId('email-input'), 'user@test.com');
  fireEvent.changeText(getByTestId('password-input'), 'password123');
  fireEvent.press(getByTestId('login-button'));
 
  await waitFor(() => {
    expect(getByTestId('dashboard-screen')).toBeTruthy();
  });
});

Toegankelijkheid is geen afterthought

WCAG-standaarden gelden ook voor mobiele apps. In de praktijk betekent dit:

  • Alle interactieve elementen hebben accessibilityRole en accessibilityLabel
  • Kleurcontrast voldoet aan AA niveau (minimaal 4.5:1 voor tekst)
  • Touch targets zijn minimaal 44x44 punten
  • Schermlezer (TalkBack/VoiceOver) werkt door de hele app

We lieten dit automatisch controleren via SonarQube in onze CI pipeline. Elke pull request die een toegankelijkheidsprobleem introduceert, wordt geblokkeerd.

99.9% uptime: de realiteit

Een 99.9% uptime target betekent maximaal ~8.7 uur downtime per jaar. In de praktijk dwong dit ons tot:

  • Feature flags voor alle nieuwe functionaliteit — schakel features uit zonder deployment
  • Graceful degradation — als de API traag is, toon een gecachede versie
  • Remote config via Firebase — verander app-gedrag zonder een nieuwe release

De app store review cyclus maakt hotfixes onmogelijk. Dat verandert hoe je over risico nadenkt.

Wat ik meeneem

De grootste les: bij enterprise schaal is consistentie waardevoller dan innovatie. Een solide design system, hoge testcoverage en betrouwbare CI/CD-processen leveren meer waarde dan de nieuwste technologie.

En: 4.5 sterren in de app store zijn pas echt motiverend als je weet dat het jouw code is die die miljoenen gebruikers elke dag blij maakt.

Plan een gesprek