# reactnative-50-days is 50 React Native screens, one folder each

> The reactnative-50-days repository is a portfolio of React Native UI implementations, one directory per day of a self imposed challenge, covering onboarding carousels, animated tab bars, swipeable rows, floating action buttons, card decks and rating widgets. The README is explicit that these are challenge demos rather than hardened production components, and the licence is not stated.

**hewad-mubariz/reactnative-50-days** — 50 days React Native UI Challenge

- Repository: https://github.com/hewad-mubariz/reactnative-50-days
- Stars: 896 · Forks: 162
- Language: TypeScript
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/hewad-mubariz-reactnative-50-days

## One directory per day, and no shared library underneath

The repository is called reactnative-50-days and it holds the implementation of a 50 day UI challenge. The README says it contains the implementation of the React Native 50 Days UI Challenge, in which 50 different UI designs are created using React Native.

The repository layout explains the structure better than any description would. At the top level there is no src/, no package.json, no shared component library. There are roughly fifty directories, each named after the component it contains: BouncyOnboarding, circular-onboarding, dynamic-tabs, sticky-header, animated-cards, swipeable-rows, animated-loader, animated-shapes, dial-button, expandable-fab, audio-input-visualizer, blur-search, circular-progress, collapsible-card, direction-aware-tabs, expanding-list, fireworks, flash-cards, flippy-card, floating-button, flux-chart, glowy-Input, gooey-emojibar, gradient-rate, heart-progress-circle, micro-swipe-actions, noisy-clock, onboarding-steps, piechart, pixelated-image, playing-cards, radial-fab, rating-wave, ratings, refraction-shader, rolling-cube, rope-slider, runny-border, scan-to-pay, scroll-to-reveal, spinning-circle, split-button, time-slot, timer, todo-deck, wiggling-cards and more, including a directory with a space in its name.

Each directory is a self contained project rather than a module in a larger one. That is the defining characteristic of the repository and it explains both its value and its limits.

The value is that each folder is a complete, readable answer to a single interaction question. You can open animated-cards and see the whole approach to an expanding card list in one place, with the animation code next to the screen that uses it.

The limit is that fifty independent folders are fifty independent dependency setups, fifty sets of choices about libraries, and no shared abstraction to unify them. This is a portfolio of demonstrations, not a library, and the README describes the repository as an implementation of the challenge rather than as a package anyone should depend on.

## The README tells you not to ship these as they are

The most useful paragraph in the README is the heads-up, and it is worth reading before any of the day entries.

It says these are challenge demos, ideas plus motion, not hardened production components, and that animations and effects are not all optimized for every device. The advice is to profile on real hardware, tweak timings and trim work before shipping anything based on them.

That is a candid framing, and it comes from the author rather than from a reviewer, which is worth noting in a field where a lot of component repositories describe demos as production ready. It also tells you exactly what kind of reader this repository is for. If you are looking for a drop in tab bar or a swipeable row that handles accessibility, edge cases, gesture conflicts and screen sizes, this is the wrong repository, and the warning is the reason you would find out before shipping.

If you are looking for how a particular animation is built, the approach is the point. The components are interesting because they were built to be interesting, in a fixed time budget, one per day. That constraint produces a certain kind of code: focused on the visual effect, with the surrounding production concerns deliberately deferred.

There is also a sponsorship note near the top of the README, with a Buy Me A Coffee button, and the request for a star. That is normal for a personal portfolio repository and says something about the intent behind it. The repository is a record of the author's learning and a source of inspiration for other developers, which is a legitimate reason to publish fifty folders of demos.

## What the first ten days actually build

The day entries read like a catalogue of interaction patterns, and the first ten cover the ones every application ends up needing.

Day 1 is a bouncy onboarding component that slides its content either to the left or to the right, and day 2 is a circular onboarding that shows the onboarding screens using a circle with an animated dot indicator for the current screen. Both are about the entry flow.

Day 3, dynamic tabs, is the most instructive of the early ones, and the README explains its mechanism. It is a customizable, dynamic and animated tab bar with a paginator, and the implementation uses a ScrollView with pagingEnabled set to true to mimic the behaviour of native tabs. That is the whole trick, and it is the kind of decision worth copying: rather than implementing a custom pager, it reuses the platform scroll physics and only drives the indicator with animation.

Day 4 is a sticky header that interpolates its content to the Y-axis origin based on a defined value, so the header content is a function of scroll position rather than a fixed element.

Day 5 is animated cards, a list of cards that expand when pressed and open a card detail screen. The cards are animated with React Native Reanimated, and the animations include moving the cards to their expanded positions, changing the opacity of the close button and translating the title. Day 6 is a customizable swipeable row component for lists, which reveals hidden actions on each row with a smooth swiping gesture.

Day 7 is an animated loader that interpolates its scale and border radius to adjust itself into a circular shape, and day 8 is an animated shape that rotates slightly to the right while interpolating the border radius and returning to the original.

Day 9 is a dial button, a custom circular menu with a central button surrounded by six selectable icons. Pressing the central button expands or collapses the menu with a smooth animation, each icon is positioned along the circumference of the circle, and an animated icon indicator highlights the current selection. The README notes it is built with React Native and the react-native-reanimated library.

Day 10 is the floating action button, a customizable circular FAB with an expandable menu of action buttons. When the main button is pressed it rotates and the action buttons appear in a circular arc around it. The entry for that day has a garbled title in the README, which is a small sign of how the text was written in a hurry.

## From the audio visualiser to the melting border, the effects get stranger

Days 11 to 17 show the challenge moving away from the components every app needs and towards effects that exist to be looked at.

Day 11 is a real-time audio waveform visualisation that updates as new audio data comes in, with a play and pause button for starting and stopping recording and a timer showing the elapsed recording time. That one is unusual in this kind of list because it has a real data source rather than a fixed animation, so the animation has to track an irregular input.

Day 12 is a card-flipping animation for both iOS and Android, described as smooth, interactive and customizable, and day 13 is an expandable list where each item expands to reveal more detail, with the expand and collapse button changing its text and rotating a chevron icon based on the current state of the list.

Day 14 is an interactive card deck with two primary states, stacked and spread, where each card is a flip component displaying suit and rank.

Day 15 is the runny border, an animated border effect for UI elements that creates a melting visual, and the README suggests two uses for it, as a distinctive design highlight on specific components and as an interactive loading indicator.

Day 16 is the star rating wave, where each star animates in sequence and fills as if liquid were being poured into it. It adds a half fill feature so that half ratings can be shown with a gradient effect.

Day 17 is the mood gauge, which turns a conventional mood selector into a gauge where each segment represents a different mood. The README text for that day is cut off mid sentence, and the repository listing shows a matching animated-gauge directory.

The pattern across these is consistent. Each day takes one visual idea and implements it with interpolation, rotation, scale or translation, and the README describes the effect in a sentence or two. The directory listing also shows entries beyond the ones documented in the visible text, including a refraction shader, a rolling cube, a rope slider, a pixelated image, a flux chart and a noisy clock, so the repository runs past the days the README excerpt covers.

## No install path, no package, and a licence that is not stated

What you cannot do with this repository is install it, and that is worth saying plainly at the start.

The README does not give an installation command, a package name, a dependency list or a build script for any of the fifty projects. There is no root package.json in the file listing, and no shared configuration. What each folder contains, and how it is built, is something you discover by opening it.

The only navigation the README offers for the code itself is the day entries, each of which is a short description plus a demo, and the demos are hosted outside the repository, as Google Drive image links and as videos in the repository's assets. The videos are attached to the repository's own asset URL space, so they are versioned with the code, while the earlier day demos point at Drive.

The licence field on the repository is recorded as unknown, and the README does not state a licence either. There is no LICENSE file in the top level listing. That is a real constraint on use. The author invites people to read the code, star the project and take inspiration from it, and the components are presented as demonstrations, but nobody has been granted a licence to copy code into a commercial product. For an engineer who wants to lift a component, the safe path is to treat the code as reference and write your own version, which is what the README's own advice about profiling and trimming is nudging you towards anyway.

On maintenance, the repository is not archived and the last push was on 2026-04-30, so the code is not being worked on day by day any more, and there are no GitHub releases. A challenge repository is a snapshot by nature: fifty days of work, published, with whatever state each day was left in.

## The alternative is a maintained component library or the animation library itself

There are two other ways to get the same result, and the difference in approach is instructive.

The first is a maintained component library. A library that ships a tab bar, a swipeable row, a bottom sheet and a rating widget comes with the unglamorous work handled: accessibility labels and roles, reduced motion support, RTL layout, keyboard and focus behaviour, safe area insets, and the version compatibility matrix with React Native itself. It also comes with a set of API decisions you did not make. The fifty folders in this repository make the opposite trade, since each interaction is solved exactly as the author solved it on that day, with none of the surrounding work done.

The second is to build on the animation library directly. Several of the entries are built with react-native-reanimated, so the approach used in this repository is to drive the effect with interpolated values and shared values rather than with the older built-in Animated API. A team that already uses react-native-reanimated can read how these components structure their worklets and their state, and reimplement the specific effect it needs with full control over the library's own primitives.

The difference in approach between the two routes is where the work goes. Taking a component from a library means conforming to its API, its props and its release cadence. Taking an approach from this repository means copying an idea, rewriting it, and owning every edge case yourself, which is more work and gives more control.

For a learning project, an interview exercise, or a product where one specific interaction is the point and everything else is standard, the second route is the better fit. For anything with broad surface area across screens, the first route is usually cheaper than the bugs you would otherwise inherit.

## Conclusion

Adopt reactnative-50-days as a source of implementation ideas and reference code if you are building React Native interfaces and want to see how a particular interaction was solved, and if you are willing to read the code and port the approach rather than drop the component in. Do not adopt it as a dependency, because the repository publishes no package, no releases and no stated licence, and do not adopt the components as they are, because the README itself warns that they are demos whose animations and effects are not optimized for every device. Before you build on any of it, read the source in the folder you care about, check which animation library it uses, and profile the result on real hardware, then rewrite the timings and trim the work as the README advises.

## FAQ

### What is the reactnative-50-days repository?

It is the implementation of a 50 day React Native UI challenge, with 50 different UI designs built in React Native. Each design lives in its own top level directory, such as BouncyOnboarding, dynamic-tabs, swipeable-rows and expandable-fab, and there is no shared library or root package.

### Can I use these components in a production app as they are?

The README warns against it, saying these are challenge demos rather than hardened production components, that animations and effects are not optimized for every device, and that you should profile on real hardware, tweak timings and trim work before shipping anything based on them.

### Which animation library do the components use?

Several of them are built with react-native-reanimated. The dial button is described as built using React Native and the react-native-reanimated library, and the animated cards are animated with React Native Reanimated as well.

### How is the dynamic tabs component implemented?

It is a customizable, dynamic and animated tab bar with a paginator, and the implementation uses a ScrollView with pagingEnabled set to true to mimic the behavior of native tabs, with an animated indicator driving the active tab.

### What licence applies to the reactnative-50-days code?

The repository licence field is recorded as unknown and the README does not state one, and there is no LICENSE file in the top level listing. The repository has no GitHub releases, and the last push was on 2026-04-30.

## Sources

- [hewad-mubariz/reactnative-50-days on GitHub](https://github.com/hewad-mubariz/reactnative-50-days)
- [Issues](https://github.com/hewad-mubariz/reactnative-50-days/issues)
- [README](https://github.com/hewad-mubariz/reactnative-50-days/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hewad-mubariz-reactnative-50-days
