react-native-header-view: five header designs in one package

A collection package, and the reason each header was split out

react-native-header-view is described as a collection of header views for React Native, and the README's account of how it reached version 1.0.0 explains the structure. The library got version 1.0.0 after more than 5k downloads, and it is separated by each header view, meaning the package contains the collection of each header view, and if you do not need all of them you can reach and install header views on their own repository. That is the design decision worth understanding before you install anything. There are five headers in the set: GorgeousHeader, AppleHeader, ModernHeader, ClassicHeader and ProfileHeader, and each of the first four has a linked repository of its own, with the README listing them under Options. The package itself is MIT licensed, the author is Kuray (FreakyCoder), and the homepage is freakycoder.com. The repository carries an example/ directory with a full React Native app, both android/ and ios/ folders, an App.tsx and its own package.json, which is the way to see the components working without reading the source.

The collection drags in all five headers as peer dependencies

The install is one npm command.

npm i @freakycoder/react-native-header-view

The README then flags peer dependencies as important and says you need to install them, listing five packages with a minimum version of 0.1.0 each.

"react-native-gorgeous-header": ">= 0.1.0",
"react-native-classic-header": ">= 0.1.0",
"react-native-modern-header": ">= 0.1.0",
"react-native-apple-header": ">= 0.1.0",
"react-native-profile-header": ">= 0.1.0",

The package.json in the repository adds the two framework peers, react at 16.x or newer and react-native at 0.55.x or newer, and lists react-native-elegant-header among the header peers, which the README's list does not mention, since Elegant was added later in the 1.2.0 release. So the practical cost of the collection package is that you install five header packages whether you use one header or five, plus React and React Native as peers. That is the tradeoff the README is offering to avoid by publishing each header separately, and the decision of which route to take is the first thing to settle.

Two of the headers need no configuration at all

The usage examples make a distinction between the minimal and the configurable headers. AppleHeader and ProfileHeader are imported and rendered with no props.

import { AppleHeader } from "@freakycoder/react-native-header-view";

<AppleHeader />;

import { ProfileHeader } from "@freakycoder/react-native-header-view";

<ProfileHeader />;

GorgeousHeader is the same idea with one handler, an onChangeText callback that receives the text typed into its search field.

import { GorgeousHeader } from "@freakycoder/react-native-header-view";

<GorgeousHeader onChangeText={(text) => console.log(text)} />;

For a developer who wants a header that looks done on first render, that is the whole API surface. The interesting design work in the library sits in the other two headers, which expose the full set of props.

ModernHeader and its icon and background props

ModernHeader starts simple and gets configured by passing style and behaviour props, with custom icon components injected as React elements rather than named assets.

import { ModernHeader } from "@freakycoder/react-native-header-view";

<ModernHeader
  text="Profile"
  rightIconType="Ionicons"
  backgroundColor="#fdfdfd"
  rightIconName="ios-settings"
  rightIconColor={colors.light.primary}
  leftIconComponent={your - icon - component}
  rightIconComponent={your - icon - component}
  leftIconOnPress={() => NavigationService.back()}
/>;

The shape is a title string, an icon family and icon name, a background colour, and slots for fully custom left and right components. The icon name follows the Ionicons naming convention with an ios- prefix, and the type prop selects the icon set, which is the pattern used by the icon packages in this ecosystem. Because leftIconComponent and rightIconComponent accept elements, you can put anything there, an avatar, a badge, a custom view, and the component only handles the layout and the tap handling.

ClassicHeader's hit slops and fully custom side components

ClassicHeader is the most explicitly configurable of the set. Its basic usage shows a title, a disabled right component, an empty left press handler, and hitSlops.

import { ClassicHeader } from "@freakycoder/react-native-header-view";

<ClassicHeader
  headerTitle="Header"
  rightComponentDisable
  leftComponentOnPress={() => {}}
  hitSlops={
    top: 30,
    bottom: 30,
    left: 30,
    right: 30
  }
/>

The hitSlops object is the touch target expansion on each edge, which is how a header can offer a tappable back arrow area larger than the icon itself. The advanced form swaps in React elements for both sides.

import { ClassicHeader } from "@freakycoder/react-native-header-view";

<ClassicHeader
  headerTitle="Header"
  leftComponent={
    <TouchableOpacity onPress={() => {}}>
      <Icon name="ios-arrow-back" type="Ionicons" size={30} color="blue" />
    </TouchableOpacity>
  }
  rightComponent={
    <TouchableOpacity onPress={() => {}}>
      <Icon name="github" type="AntDesign" size={30} color="purple" />
    </TouchableOpacity>
  }
/>;

The library does not bundle the icon component, so the Icon import comes from your own icon dependency, which is worth noting when you plan the install.

GorgeousHeader's props describe a search-and-title layout

The props table for GorgeousHeader shows the scope of the configuration, and it is worth reading as a description of the layout. The title defaults to Order and the subtitle defaults to Healthy food can keep you fit, which is a leftover from the design this component came from. Beyond that there are props for a search icon asset, styles for the title text, the subtitle text, the search bar container and the search input, and styles for the hamburger menu image together with its source asset. The pattern is consistent across the library: style props for each visual element, asset props where an icon can be replaced, and behaviour props for the interactions. The defaults are deliberately visible, so a component can be dropped in and then adjusted one piece at a time. The README's props tables are cut off in the version available here, so the full lists for the remaining components are in the project documentation rather than in the repository.

A five year gap in the release history

The version history is the thing to weigh before adopting this. The recent releases are 1.2.0, published on 2021-09-20 with ElegantHeader added, 1.1.1 on 2020-10-14 which brought ProfileHeader and a main path fix, and 1.0.0 on 2020-08-23 which separated the header views and marked the library as version 1.0.0. The last push to the repository was on 2026-06-29, so the branch still receives commits, but no release has been published since 2021-09-20. The declared peer range is react at 16.x or newer and react-native at 0.55.x or newer, which is permissive, but a permissive range is not the same as a component tested against current React Native versions. The repository also carries a CHANGELOG.md, an .eslintrc.js and a babel.config.js, and the code is styled with prettier, so the source follows a modern JavaScript toolchain even though the published versions have not moved recently. The practical question is whether the components you want still render correctly on the React Native version your app uses, and the example/ app is the fastest way to find out.

Editorial conclusion

react-native-header-view fits a React Native team that wants a polished header with search, avatars and icons already laid out, and that does not want to design and animate one from scratch. It does not fit a project that wants a single dependency tree, since the collection package requires all five header packages as peer dependencies, and it does not fit a team that needs recent React Native support, because the last release is 1.2.0 from 2021-09-20. Before you adopt it, decide between the collection and the individual packages, check that the peer dependency versions in package.json still resolve against your React Native version, and read the props tables, because the components are configurable to the point where the defaults do most of the work.

Frequently asked questions

Official sources

1. kuraydev/react-native-header-view on GitHub
2. License: MIT
3. Project website
4. README
5. Releases