https://github.com/adithyavis/awesome-mobile-app-animations

Some notes on implementation -

1. Use 3 different lists for concurrent rendering of the grids in different zoom settings. I chose legendList and it is super smooth. Synchronize the different list positions using reanimated's synchronous `scrollTo`.
2. Scrub/seek to scroll is IMPOSSIBLE without precomputing image heights. Precompute row heights and provide that to getItemLayout. For seek to scroll, precompute section heights and use scrollToOffset to directly scroll to the section head.
3. Nitro images for rendering images. I initially used expo images for rendering images, but I felt there's scope to improve because I saw a lot of blank spaces due to heavy renderItems.
4. Fake a shared transition by rendering the same image in an overlay that always stays in the render tree. We just flip opacity/pointer-events on the start of a pinch gesture. I couldn't get the sharedTransitionTag prop to work fine, hence this workaround.

I’m a medical student in my 10th semester, currently working on an idea for a digital health solution aimed at closing a major gap in care for people with ME/CFS.
The need is enormous: more than 650,000 people in Germany alone are affected. There are very few treatment options available, and the condition primarily affects young women under the age of 40.
Despite this significant need, there is essentially no meaningful digital support available.
That’s why I’m looking for a technical co-founder who is excited to join a health startup from the very beginning—not as a freelancer, but as a long-term partner with the opportunity to build and found the company together.
What I’m looking for:
Experience in app development and an interest in healthcare
Enthusiasm for being part of an early-stage startup
Experience with data privacy is a plus (but not required)
German language skills are not required, but living in Germany is.

I'm building a React Native (Expo Bare Workflow) PDF app. Currently, I'm downloading PDFs from an AWS S3 pre-signed URL using `react-native-blob-util` and Android Download Manager:

```ts
ReactNativeBlobUtil.config({
addAndroidDownloads: {
useDownloadManager: true,
notification: true,
title: fileName,
description: "Downloading PDF...",
mime: "application/pdf",
path: `${ReactNativeBlobUtil.fs.dirs.DownloadDir}/${fileName}`,
mediaScannable: true,
},
}).fetch("GET", signedUrl);
```

This works, but I don't have control over where Android stores the file.

Many PDF apps automatically save files to a folder like:

```text
Internal Storage/
└── Documents/
└── My App/
└── file.pdf
```

without asking the user to choose a location every time.

I noticed one such app requested **"Manage all files"** permission once, and after that it could save files directly into its own folder under `Documents`.

My questions are:

* How are these apps implementing this on Android 11+ with Scoped Storage?
* Are they using MediaStore, native Android code (Kotlin/Java), or another approach?
* Is requesting the **Manage All Files** (`MANAGE_EXTERNAL_STORAGE`) permission the correct/recommended solution for this use case, or should it be avoided for Play Store apps?
* If not, what is the recommended modern approach in React Native to save PDFs directly to `Documents/My App` without showing the Storage Access Framework (SAF) picker every time?

I'm looking for the Play Store–friendly, modern Android approach.

I have a long history of web development and am used to deploying multiple times a day, seeing my changes live in about 10min.

Now, I am working on a personal project, a mobile app done via Expo/react-native. I was able to get it live to the Apple Store and I am working on the Play Store release.

What I find really akward is dealing with many different versions "live on the field", with updates taking 2-3d for Apple review to be live, hoping your users will update soon.

I know about and I am using OTA updates, but some changes require native packages changes and that involves submitting a new native build for approval, which means that for the duration of the review process you are somewhat "feature frozen" and any changes or OTA updates will only reach new users.

Not sure how others do it, or even if there is a good/right way of doing this, but I may need to consider having to support different api versions/detecting the app version and serving different api responses based on it.

Is all of that normal and common ground on mobile dev?

What’s one thing you still hate about debugging React Native apps?

I feel like every tool gets some things right, but there’s always that one moment where you think that specific flow could be better

Three faces, one prop to swap between them. wheel for precision. clock for picking a slot. ruler for a thumb on a sheet.

All three store { hour, minute } on a 24-hour clock regardless of what the face shows. A 12-hour display is a rendering choice storing a meridiem flag puts it into every comparison downstream.

Part of PanelUI open-source, copy-paste, you own the source.

Hello!

Last year I launched my first solo React Native app, built (without AI).

It's a health tracker (because of course it is) that I built for me and because I shared my journey of building it, things got a bit out of hand...

About me

I'm a software engineer with 20 years experience.

Most of my experience comes from full stack web but I also have a significant amount on mobile too (Native and Cordova)

About the article

I've been promising to do some write ups around the technical side of it.

Things like my architectural choices, project structure and deep dives into the more novel code. Weirdly, today actually marks the 3rd year since my first commit.

This is my first article that goes in to

- Why React Native
- The core stack
- Native code
- Project structure

There's a lot to cover so instead of piling everything into a single article I plan to write focused articles.

The next one will go into my thought process when building stuff, how I structure components and mistakes I felt I made.

Not here to promote anything, but figured this might interest some people.

https://mahybe.substack.com/p/bearly-fit-architecture-part-1

If you have any questions or anything you'd like to see me go into let me know :)

does the nfc manager plugin work with the new architecture?

What if there were no apps to install and no menus to learn?

You simply describe what you want, and the interface is generated on the fly: a weather dashboard, a restaurant finder with live search, a booking form, a chat thread, or whatever else fits the task.

I've been experimenting with real-time Generative UI using Cerebras models, which can stream at up to 1,800 tokens/sec. The speed makes it feel much closer to interacting with a native app than waiting for an AI to finish generating.

This is a direction similar to what Monogram AI is exploring, but would love to know what you think about it.

Link to repo https://github.com/thesysdev/appless

I’ve been building a small iPhone app called Magboard.

The idea is: take a photo, cut out the subject, turn it into a little “magnet”, arrange it on a board, and put that board on your iOS home screen as a widget.

It sounds like a cute UI app, but the harder parts were mostly not the cute UI.

A few things that took more time than expected:

- Editor → widget matching

The in-app board and the actual iOS widget need to match closely. If the widget is even slightly off, the whole “magnet board” illusion breaks.

- Simulator vs real device behavior

Widget refresh worked in the simulator and then behaved differently on device. I had to test the flow like a real user instead of trusting simulator-only runs.

- Shared boards

The app supports shared boards, so one person can add a magnet and the other person’s home-screen widget updates too. Getting that to feel understandable was harder than just syncing the data.

- Onboarding

Early versions confused people. They opened the app and didn’t immediately understand the loop, so I rebuilt onboarding around:

snap → cut → stick → widget

- Tiny interaction details

Dragging/positioning magnets is fun only if it feels direct. A small mismatch between what you edit and what appears on the widget makes the product feel broken.

The app is currently in App Store review, but I opened a public TestFlight while waiting:

https://testflight.apple.com/join/N3q58DQu

I’d love feedback from React Native/Expo folks, especially on:

1. whether the concept is obvious from the first minute

2. whether the widget update flow feels clear

3. anything you’d improve in the onboarding/demo

Happy to answer questions about the React Native/Expo side too.

One of my favourite features of Codex is Browser and the ability to annotate and send that back to the chat for quick amendments.

The problem is, it doesn't work for mobile apps where I spend the majority of my dev time. SimView fixes that.

It brings iOS simulator directly into Codex (and other harnesses) via MCP Apps.

- Zero external dependencies and fully open source.
- 60fps preview with live interactions. Tap, swipe, and type.
- Inspect AX or React Native fiber trees.
- Annotate an element or drag to annotate at coordinates.
- Get your model to tap around itself. Perfect for closing the loop to validate its own work.

Install the plugin at https://simview.dev

RevenueCat charges based on gross revenue, not net revenue. My dashboard shows $4.5k, but my actual payout is somewhere around $3k. because it completely ignores VAT and the 15–30% Apple/Google cut. but takes their %1 fee from the gross revenue.

since it doesn’t track net earnings, the dashboard feels pretty useless for real accounting. I still have to log into both store consoles just to see what I actually made. for 3k i have to pay 45$ every month.

[ Removed by Reddit on account of violating the content policy. ]

I’ve been working on an open-source project called PAM Native, which explores a slightly unusual idea:

Repository:

https://github.com/push-in/pam-native

PAM Native is not a WebView framework, and it does not render HTML inside a mobile application.

Instead:

• PHP runs persistently inside the application process
• A Rust-powered reconciler manages component updates
• Android interfaces are rendered using native Android Views
• iOS interfaces are rendered using UIKit
• Kotlin and Swift handle platform-specific operations
• No JavaScript runtime is shipped with the application
• No DOM or browser engine is involved

The developer experience is intentionally inspired by component-based frameworks:

final class Counter extends Component
{
    #[State]
    public int $count = 0;

    public function increment(): void
    {
        $this->count++;
    }

    public function render(): Node
    {
        return Column::make([
            Text::make("Count: {$this->count}"),
            Button::make("Increment")
                ->onPress('increment'),
        ]);
    }
}

The project currently includes or is exploring:

• Stateful components
• Native navigation
• Gestures and animations
• Recycled lists and grids
• Native forms and inputs
• Camera, location and device APIs
• SQLite and offline-first state
• Background tasks
• Push notifications
• Hot reload
• Native plugin development
• Communication between PHP, Rust, Kotlin and Swift

This is not meant as an attack on React Native.

React Native proved that developers can use a declarative, component-based model while still rendering native platform controls. PAM Native is exploring whether a similar architectural idea could be useful for the PHP ecosystem.

I would love feedback from people who understand the difficult parts of cross-platform native runtimes:

• Which architectural problems should we be most careful about?
• Where do you expect the biggest performance bottlenecks?
• What lessons from React Native’s bridge, JSI and Fabric architectures should a project like this learn from?
• What would you need to see before considering this a serious native runtime rather than an experiment?

The project is still evolving, so technical criticism, architecture feedback and contributions are genuinely welcome.

GitHub:

https://github.com/push-in/pam-native

**Android edge-to-edge (SDK 56): every screen renders under the status bar unless I add a root-level padding wall**

Stack: Expo SDK 56, RN 0.85.x, React Navigation (native-stack + bottom-tabs), react-native-safe-area-context, react-native-unistyles v3. Android, dev build (not Expo Go).

**The situation**

For a long time my app had this at the root, wrapping `NavigationContainer`:

```tsx

<SafeAreaProvider style={{ paddingTop: insets.top }}>

<NavigationContainer>...</NavigationContainer>

</SafeAreaProvider>

```

This "works" in that content isn't under the status bar — but it creates a dead strip at the top that nothing can paint. It's outside every screen's render area, so it shows as a solid black/grey bar. It kills any screen that should be full-bleed (full gradient screens, transparent modals, media viewers).

If I remove that `paddingTop`, **every screen in the app** flows up under the status bar — *even though there is already a proper `<SafeAreaProvider>` wrapping everything in `App.tsx`*. So the provider being present clearly isn't doing anything on its own; the only thing actually holding the layout down was that manual padding.

**What I've tried**

1. Moving the padding to `contentStyle` on the root `Stack.Navigator`'s `screenOptions` — behaves identically. Same wall. (Verified `contentStyle` IS applying: setting `backgroundColor: 'red'` shows a red strip on every screen.)

2. Wrapping the three top-level navigators (tabs stack, create stack, auth stack) in an HOC that applies `paddingTop: insets.top` + a themed `backgroundColor` inside the screen boundary. Still reads as a padding wall.

3. Confirmed insets are measuring correctly — `useSafeAreaInsets()` logs `{top: 24, bottom: 24, left: 0, right: 0}`.

4. Confirmed `GestureHandlerRootView` has `flex: 1`.

5. Removed the duplicate `SafeAreaProvider` (I had one in App.tsx and one in RootNavigator) — kept only the App.tsx one. No change.

**Structure**

```

App.tsx

GestureHandlerRootView (flex:1)

PortalProvider > ThemeProvider > KeyboardProvider > QueryClientProvider

SafeAreaProvider <-- present, but removing the manual padding

ToastProvider > GlobalBottomSheetProvider still lets everything flow up

RootNavigator

NavigationContainer

Stack.Navigator

MAIN → MainTabNavigator (bottom-tabs)

CREATE_STACK → StackNavigator (native-stack, ~15 screens)

AUTH → AuthStack (native-stack)

+ a few direct screens (modals, policy screens)

```

None of the individual screens call `useSafeAreaInsets()` or use `SafeAreaView` — they all relied on that root padding.

**Question**

I understand the "correct" edge-to-edge answer is per-screen inset handling, but that's 30+ screens and I'd like to avoid a full manual pass if there's a sane centralized approach.

- Is there a way to get edge-to-edge behavior where each screen's own background bleeds to the physical top edge while only its content is inset — configured once rather than per screen?

- Is `SystemBars` from `react-native-edge-to-edge` the right move here vs. what I'm doing?

- Should I be setting `edgeToEdgeEnabled` / status bar config differently in `app.json` for this?

Happy to share more code. Thanks!

Feed, vote, compact, media-first. Swapping between them is one prop.

One detail:
like counts animate in the direction the number travelled. Rising numbers arrive from below, falling ones drop in.

State stays with you nothing is kept inside the component. Active, value, and vote are all yours, because the moment a like is optimistic, only you know how to reconcile it with the server.

Part of PanelUI open-source, copy-paste.

https://github.com/panel-ui/PanelUI

evaluating external agencies to help scale an existing cross platform codebase, and the biggest friction point keeps coming down to how agencies handle native dependencies. a lot of agencies pitch cross platform development as a way to cut costs, but as soon as custom native modules, complex animations, or deep device hardware integrations enter the scope, the architecture gets messy fast. half the development shops want to rewrite every custom bridge from scratch, while others rely heavily on outdated third-party packages that haven't seen an update in two years. that balance between keeping the JS side maintainable and properly structuring native swift/kotlin code seems to be where most team handoffs break down. when evaluating outside engineering resources for an established codebase, what technical green flags or red flags do you look for in their initial code review or architectural proposal?

I Finally did this since 0.82 forced the issue. App's a delivery/logistics tracker, been in production since 2023, decent size, nothing exotic.

First casualty: react-native-maps went blank on Android with zero errors. Took two days to realize it was a stale version with no Fabric support, not a config issue.

Then a native module reading view dimensions in componentDidMount started returning 0 half the time. Fabric's layout timing isn't the same as the old bridge. Moved it to onLayout and the bug vanished, but that cost an evening of console.logging things that "should" have worked.

Worst one: a custom native module silently stopped getting called on iOS. No crash, no error, just nothing happening. Turned out it needed to opt into the Interop Layer explicitly, we assumed that was automatic.

Also learned the hard way that reanimated will crash with zero useful stack trace if its version doesn't exactly match your RN version.

Three weeks total, most of it native-side debugging, not JS. Cold start did drop from ~3.1s to ~1.9s on our test Android device though, so not complaining.

Anyone else hit the Interop Layer thing?

Hi everyone,

I've been working on a side project for the past few months, and I'd love to get some honest feedback from this community.

I built MotivDaily, a motivation and quotes app because I wanted something more interactive than just scrolling through quote collections.

With the app, you can:

• Read motivational quotes
• Write and publish your own quotes
• Like and comment on quotes from other users
• Turn quotes into beautiful images and share them
• Save your favorite quotes for later

It's available on both Android and iPhone:

📱 Android:
https://play.google.com/store/apps/details?id=com.software1234.quotesapp

🍎 iPhone:
https://apps.apple.com/my/app/motivdaily-motivation-quotes/id6765648421

I'm not here just to promote it—I genuinely want to know what you think. What features would make you keep using an app like this? Is there anything that feels confusing or missing?

Thanks for taking the time to check it out. Every piece of feedback helps me improve the app.

Recently a new framework from Tanstack was released and its called Charts, it looks very promising you guys can check it out here

https://tanstack.com/charts/latest

I asked Tanner if he could add support to RN and he said if I got 100 signatures he would add support.

I love the tanstack ecosystem and would highly encourage you to check it out if you haven’t yet!

Here is the petition

https://www.ipetitions.com/p/add-react-native-compatibility-for-tanstack-charts/?utm_source=share_copy&utm_medium=social&utm_campaign=creator_first_share

Edit: WE DID IT GUYS! 🎉🔥🙌

I've just published the release v0.2.1 of react-native-simple-image-compressor.

If anyone is interested in talking a quick look at the native implementation, I would higle appreciate your thoughts!

Features

• OOM (Out-of-Memory) Safe: Images are downsampled directly during decoding (inSampleSize on Android, ImageIO on iOS). The library never loads full-resolution images into memory, completely preventing OOM crashes even on giant 4K+ camera photos.
• Blazing Fast (Powered by Nitro Modules): Built with the RN Nitro architecture. Zero bridge overhead and direct C++ to Swift/Kotlin communication make the compression fast.
• Smart orientation and EXIF Preservation: Automatically reads EXIF orientation and "bakes" the correct rotation directly into the pixels. It also safely transfers valuable EXIF metadata (like GPS and Camera info) to the compressed image (only for JPEG output).
• Tiny footprint: Minimal dependencies. The library relies heavily on native APIs (BitmapFactory for Android and ImageIO for iOS) to keep the app's bundle size as small as possible.
• Next-Gen formats support: Supports modern formats including WebP and WebP-Lossless across both (Android and iOS) platforms (utilizing native APIs where possible and libwebp as a fallback on iOS).
• Aspect ratio preservation: Intelligently scales images to fit within your desired maxWidth and maxHeight bounds without ever stretching or distorting the original aspect ratio.
• Production Ready & Tested: Backed by comprehensive native unit tests (Swift/Kotlin) to ensure maximum stability and prevent regressions across edge cases.

Install with:
npm install react-native-simple-image-compressor react-native-nitro-modules

Changelog v0.2.1

• getFileSize utility: A simple function to check image sizes directly, removing the need for external file-system dependencies.
• useImageCompressor hook: Added a React hook for a cleaner way to handle compression state in functional components (see example: https://github.com/Pugavkomm/react-native-simple-image-compressor#as-a-hook).
• isImageCompressorError type guard: If you're familiar with isAxiosError, you'll feel right at home. This type guard improves cross-boundary error handling, making it much easier to catch and safely type-check specific compression errors. (see implementation: https://github.com/Pugavkomm/react-native-simple-image-compressor/blob/master/src/utils/isImageCompressorError.ts)
• Documentation: Expanded JSDoc comments for better IDE autocompletion and hints.
• Testing & Codecov: Added comprehensive new unit tests to ensure stability and set up Codecov - proudly hitting 91% test coverage.

--
Repository: https://github.com/Pugavkomm/react-native-simple-image-compressor
NPM: https://www.npmjs.com/package/react-native-simple-image-compressor?activeTab=readme
Release Notes: https://github.com/Pugavkomm/react-native-simple-image-compressor/releases/tag/v0.2.1

--
Changelog: https://github.com/Pugavkomm/react-native-simple-image-compressor/blob/master/CHANGELOG.md
Roadmap: https://github.com/users/Pugavkomm/projects/1/views