DEV Community: Muhammad haris baig

React Native + Android 16: The SDK Upgrade That Looks Easy Until Your UI Breaks

Muhammad haris baig — Tue, 28 Jul 2026 20:38:43 +0000

Moving from target SDK 35 to 36 looks like a simple Gradle change. In a real React Native app, the build may be the easiest part.

If your React Native Android app is still targeting API 35, Android 16 (API 36) should be on your migration roadmap.

Google Play requires apps to target Android 16 (API 36) for updates starting August 31, 2026.

The configuration changes are relatively straightforward:

compileSdkVersion: 35 → 36
targetSdkVersion: 35 → 36
buildToolsVersion: 35.x → 36.x
Android Gradle Plugin: 8.7.x → 8.9.1+
Gradle: 8.9 → 8.11.1+
minSdkVersion: remained 24
No React Native major version upgrade was required just for this SDK bump

The first build succeeded.

Then the real work started.

The "Easy" SDK Upgrade

The first mistake teams can make is assuming:

"The app builds, so the migration is done."

Not quite.

An Android SDK upgrade can change platform behavior without changing a single line of your React Native JavaScript.

You may suddenly find:

Headers moving under the status bar
Notches overlapping content
Back buttons becoming difficult to tap
Keyboard behavior changing
Forms behaving differently
Existing navigation issues surfacing during testing

This is why I see target SDK migrations as behavioral migrations, not just build configuration changes.

Our approach was simple:

Get the app compliant with the new target SDK with the smallest possible change set.

We didn't combine the migration with a React Native upgrade, navigation rewrite, UI redesign, or complete safe-area refactor.

First make the platform migration. Then fix the platform-specific behavior it exposes.

The Real Breakage: Edge-to-Edge

The biggest issue we encountered was Android's edge-to-edge behavior.

With Android 16, edge-to-edge is enforced, and windowOptOutEdgeToEdgeEnforcement is no longer a reliable solution.

This changes an assumption many React Native apps have quietly depended on:

"The operating system will leave space for my content below the status bar."

With edge-to-edge, your application can draw behind system bars.

That's fine when the UI is intentionally designed for it.

It's a problem when your existing UI assumes the system will automatically keep content away from the status bar.

Our first symptoms were:

Headers partially hidden
Content underneath the notch
Back buttons becoming harder to tap
Authentication screens looking incorrect
Attempted fixes creating excessive spacing

At this point, the migration became more than an SDK upgrade.

It became a UI architecture problem.

Don't Fix Safe Areas Screen by Screen

The obvious solution is to add safe-area padding to every screen.

Be careful.

If your navigation container already handles the top inset and individual screens add their own safe-area padding, you can end up with:

Double padding
Large empty spaces
Misaligned headers
Inconsistent spacing

The approach that worked better for our architecture was to apply the Android top inset once at the root router/navigation layer.

Instead of every screen asking:

"Do I need to add status bar padding?"

We established a single responsibility:

The root navigation layer owns the Android top inset.

The principle is simple:

Insets should have one clear owner.

This makes the layout hierarchy easier to reason about and avoids solving the same platform problem repeatedly across individual screens.

Status Bar Color Is Part of the UI

Another issue appeared on authentication screens.

A fixed white status-bar filler looked fine on white screens.

Then we opened a colored authentication screen.

Suddenly, there was a white strip at the top.

The overlap was fixed.

The UI was still wrong.

The lesson is that system-bar handling isn't only about spacing. It's also about visual context.

When handling edge-to-edge, think about two questions:

Where should the content start?
What should appear behind the system bar?

An authentication screen may need a branded background, while the main application may use white.

A hardcoded white filler isn't a universal solution. Simply making everything transparent isn't necessarily the answer either.

This is another reason centralized root-level handling is easier to maintain than manually adding spacers across dozens of screens.

The Keyboard Problem: `adjustResize` Isn't Enough

The second major issue was keyboard behavior.

We had screens using the familiar combination of:

KeyboardAvoidingView
behavior="padding"
windowSoftInputMode="adjustResize"

Historically, this pattern has worked well for many React Native applications.

But edge-to-edge changes what you can expect from classic window resizing.

On Android 15+ / API 35+, and continuing into Android 16, relying solely on adjustResize is no longer sufficient in edge-to-edge scenarios.

The result can look like this:

User taps an input
        ↓
Keyboard opens
        ↓
Window doesn't resize as expected
        ↓
Content remains behind the keyboard
        ↓
KeyboardAvoidingView can't fully solve it

This isn't necessarily a React Native bug.

It's a change in how Android handles the application's window and system insets.

The solution we used was to handle the IME (keyboard) inset natively in MainActivity for SDK 35+:

Detect the keyboard using WindowInsets
Read the bottom IME inset
Apply the required bottom padding to the root content

The idea is straightforward:

Keyboard opens
      ↓
Android reports IME WindowInset
      ↓
MainActivity receives the bottom inset
      ↓
Root content gets bottom padding
      ↓
React Native UI moves above the keyboard

This is more reliable than trying to solve every form with increasingly complex ScrollView or KeyboardAvoidingView styles.

One recommendation from this migration:

Don't randomly change your layouts because the keyboard is covering content.

We tried layout-level approaches that technically moved the content but also disturbed centering and spacing.

If the UI was correct before the platform change, fix the platform behavior at the platform layer whenever possible.

What to Test After API 35 → 36

Don't stop after confirming that the app builds and installs.

Run a focused regression test.

System UI

Test:

Status bar and notch behavior
Edge-to-edge
Navigation bar
Back gesture
Header alignment
Touch targets near system bars

Keyboard

Test:

Login and authentication forms
Long forms
Multiple text inputs
Password fields
Keyboard opening and closing
Content near the bottom of the screen

Core Android Features

Test:

Push notifications
Deep links
Camera
Gallery
File selection
Permissions

Navigation

Test:

Nested navigators
Tab and stack navigation
Back button and gesture
Deep links into nested screens

Devices

At minimum, test:

Android 16 / API 36
One older supported Android version
A device with a notch or cutout

And run a quick iOS sanity check.

React Native shares JavaScript layout code across platforms, so Android-specific changes should not accidentally affect iOS.

The Biggest Lesson

Android SDK upgrades are becoming less about changing a number in Gradle and more about understanding how Android is evolving.

The API 36 migration is a good example.

The configuration change is relatively small.

The behavioral impact can be much larger.

The most important lesson from our migration was to avoid over-engineering the solution.

We didn't need to redesign the entire application.

We needed to identify where Android 16 changed existing assumptions and fix those assumptions at the correct layer.

For us, that meant:

Centralizing Android top inset handling at the root router
Avoiding duplicate safe-area padding
Matching system-bar backgrounds to the screen context
Handling keyboard IME insets natively for newer Android versions
Keeping the iOS safe-area path unchanged
Avoiding layout hacks that introduced new spacing problems

The goal wasn't to rewrite the app.

The goal was to make the smallest architectural changes necessary to keep the app stable on the new platform.

Five Takeaways

1. Target SDK upgrades are behavioral migrations.
A successful build doesn't mean your migration is complete.

2. Android 16 edge-to-edge needs intentional UI handling.
Don't assume the system will keep your content away from system bars.

3. Give insets one clear owner.
Centralized handling is usually safer than adding safe-area fixes to every screen.

4. Keyboard behavior needs platform-aware handling.
With edge-to-edge, don't rely blindly on adjustResize and KeyboardAvoidingView.

5. Keep the migration surgical.
Get Play compliance done first, then fix UI and runtime issues one by one.

Android 16 won't be the last platform change React Native developers have to deal with.

The engineers who handle these migrations well won't be the ones who simply know which Gradle value to change.

They'll be the ones who understand where JavaScript ends, where React Native begins, and where Android platform behavior takes over.

That's the real skill behind maintaining production-grade React Native applications.

Upgrading React-Native from Android SDK 34 35: Real Issues, Real Fixes, and What No One Tells You

Muhammad haris baig — Tue, 18 Nov 2025 18:36:21 +0000

Upgrading your React-Native app from Android SDK 34 to 35 should be simple. Google releases a new SDK → you update compileSdkVersion and targetSdkVersion → rebuild → ship update. Right?

Wrong.
The Android 35 upgrade is one of the most painful upgrades the community has faced since Android 28 → 29.
This article documents every issue I personally faced, how I fixed them, what other developers are reporting globally, and the ultimate fix almost no one talks about.
If you are upgrading your RN project to Android 35 - this guide will save you hours (or days) of debugging.

What I Upgraded

compileSdkVersion = 34 -> // upgrade to 35 targetSdkVersion = 35 -> // upgrade to 35 buildToolsVersion = "34.0.0" -> // upgrade to 35.0.0

I also added this to styles.xml (required for Android 15 / API 35 edge-to-edge changes):

<item name="android:windowOptOutEdgeToEdgeEnforcement">true</item>
My project is on:
React-Native 0.72.7
70+ libraries (Zego, Firebase, Notifee, Maps, FS, Vimeo, RN Config, etc.)
Kotlin code + Java code (important later)

The Nightmare Begins - AAPT2 Crash on Android 35

As soon as I attempted to build:

Execution failed for task :app:processProdDebugResources Android resource linking failed RES_TABLE_TYPE_TYPE entry offsets overlap actual entry data Failed to load resources table in android-35/android.jar

This is a fatal AAPT2 crash that makes the entire build impossible.

I tried following:

✔ Deleted Android 35 platform
rm -rf ~/Library/Android/sdk/platforms/android-35
✔ Reinstalled using SDK Manager
✔ Invalidated caches
✔ Removed .gradle, build, intermediates
✔ Clean build / rebuild
✔ Reinstalled Android Studio
✔ Tried with Staging / Prod flavors

Nothing worked.
Why?

Because Android 35 ships a new resources table format, but AGP (Android Gradle Plugin) still ships an older AAPT2 binary that can't read it.

This is why the error mentions:

RES_TABLE_TYPE_TYPE entry offsets overlap actual entry data The Fix Almost Nobody Knows The build worked instantly when I added this to gradle.properties: android.aapt2Version=8.6.1-11315950

✔ Why it works (short version)

Android 35 requires a newer AAPT2, not the old one bundled with AGP 7.x.
Setting this line downloads a fresh AAPT2 build:
8.6.1-11315950
…which can parse Android 35's updated android.jar.

BAM - build succeeds.

✔ Why Google doesn't document it

Because the official "fix" is to upgrade AGP to 8.x - but RN 0.72 cannot yet use AGP 8 safely.
So this property is an internal escape hatch that allows RN developers to upgrade without rewriting their entire Android build configuration.

The Next Problem: NoSuchMethodError reversed()

After the build succeeded, the app crashed:

java.lang.NoSuchMethodError: No virtual method reversed()Ljava/util/List;

This happened because:
JDK 17+ ships List.reversed()
But many RN/Kotlin libraries compile against older Kotlin stdlib
When mixed, Dalvik cannot locate the JDK method → runtime crash

✔ How I fixed it
I replaced all occurrences of reversed() with: asReversed() This exists in older Kotlin stdlib and works everywhere. I patched my own Kotlin code AND created patches for: react-native-screens react-native-gesture-handler

Because these libs internally used reversed() as well.
I applied the patches using patch-package.
Expect MORE Errors While Upgrading - Common Issues (Community Reports)

Developers upgrading to 35 commonly see:
🔻 AAPT2 resource linking crash
🔻 "Execution failed for task :app:mergeDebugResources"
Caused by broken vector drawables under new validator.
🔻 Edge-to-edge mandatory updates
styles.xml must contain:
<item name="android:windowOptOutEdgeToEdgeEnforcement">true</item>
🔻 Kotlin / Java binary incompatibilities
reversed(), JDK 17 methods missing, etc.
🔻 Build tools mismatch
Build-tools 35.0.0 is still in preview so many users end up with partial installs.
🔻 Firebase / Notifee / React-Native-Maps needing updated peer versions
Especially with 35's new system location permissions.

🛠 6. Full Checklist for Upgrading React-Native from API 34 → 35
1️⃣ Update build configuration
android/build.gradle: compileSdkVersion 35 targetSdkVersion 35
2️⃣ Add required edge-to-edge rules
res/values/styles.xml: <item name="android:windowOptOutEdgeToEdgeEnforcement">true</item>
3️⃣ Fix AAPT2 crash
gradle.properties: android.aapt2Version=8.6.1-11315950
4️⃣ Upgrade Android Build Tools
SDK Manager → Install: Android SDK Platform 35 Build Tools 35.x.x

5️⃣ Fix Kotlin/JDK reversed() crash
Search project: reversed() Replace with: asReversed() Apply patches for: RN Screens Gesture Handler

6️⃣ Rebuild
cd android ./gradlew clean ./gradlew assembleDebug

🏁 7. Final Result
After applying:
✔ AAPT2 upgrade
✔ Edge-to-edge opt-out
✔ Kotlin reversed() fix
✔ Library patches
The project builds and runs on:
Android 15 emulator, Api 29 till api 35 builds fine
Physical Pixel device
Both debug and release
All staging / prod flavors

Zero crashes, zero resource failures.

🚨 The “10x Developer” Myth in the AI Era 🚨

Muhammad haris baig — Mon, 03 Nov 2025 19:16:36 +0000

Everyone’s chasing the “10x developer” dream right now.
Companies want to cut costs, hire fewer devs, and believe AI can multiply output. On paper, it sounds smart — one developer doing the work of five. But here’s the truth no one likes to talk about 👇

Yes, AI can help. It can speed up delivery. It can autocomplete code.
But it can’t care about your codebase. It doesn’t understand why clean, scalable, maintainable code matters in the long run.

Right now, developers are being pushed to hit impossible deadlines — tasks that took 3–4 days in the pre-AI era are now “expected” in a single day. Businesses only look at the end result, not the foundation. The problem?
When that foundation cracks, no AI can fix it.

Sooner or later, you’ll have to rebuild or refactor from scratch.
And that’s when reality hits — you can’t ship quality at speed forever.

It’s not about choosing between quality and quantity. It’s about balance.
Developers need to stand up and communicate that code quality is business value. A strong codebase is what keeps your product alive, scalable, and future-proof.

So yes — use AI. Use it to learn, build, and grow faster.
But never stop writing code that you’re proud of.
Because shortcuts always catch up.

Build Voice Messaging in React Native with Reusable Gists

Muhammad haris baig — Mon, 16 Jun 2025 11:38:37 +0000

Overview

Voice messaging is now a staple in chat experiences. Users expect to record, send, and play audio with ease — and developers deserve tools that don't fight back. That’s why I broke down a fully functional voice messaging system into simple, focused gists that you can plug into any React Native project.

No full-blown package. No bloated dependencies. Just modular code that works.

🔧 What the Feature Does
This voice message system includes:

Tap-to-record with visual timer
Cancel or send recording
Upload logic using your own backend (ZEGOCLOUD in my case)
Full-featured playback
Play/pause
Seek
Speed toggle (1x, 1.5x, 2x)
Auto-stop/reset

🔗 Gist-Based Breakdown

MicButton.js A recording button with timer display. Users can cancel, send, or re-record. Handles UI state + timer logic.

Starts recording on press-in
Tracks elapsed time
Sends file or cancels on tap
Reusable as a controlled component with props for recorder logic

Gits Link for MicButton 🔗

VoiceMessagePlayer.js An audio player with scrubber, speed control, and clean UI. Manages playback for local or remote audio files.

Fetches file path
Handles permission (Android/iOS)
Manages current playing state globally
Speeds: 1x, 1.5x, 2x
Seeks to any point in the track

Gist Link for VoiceMessagePlayer 🔗

Recorder Functions Async functions to:

Start recording (with platform-specific formats)
Stop recording and send it to your backend
Cancel and clean up listeners

Integrate these into your parent component and pass to MicButton.

Gist Link For Recorder Functions 🔗

sendVoiceMessage() — Gist Link Customizable logic to send the audio message over any provider (ZEGOCLOUD in this case).

Strips file:// prefix
Formats duration, file name, type
Builds a push config and sends the message

Example Workflow

<MicButton 
  startRecording={startRecording} 
  onStopRecord={onStopRecord} 
  recorderInstance={audioRecorderPlayer} 
/>

{message.type === 13 && (
  <VoiceMessagePlayer item={message} isSender={true} />
)}

This lets you drop recording and playback directly into any chat UI.

Why Gists, Not a Package?
🛠️ Devs can tweak each part without digging into node_modules
⚡ Faster adoption
📦 Packages are overkill when you just need a few focused files

If you’re building chat, customer support, or community apps — this will save you days. Take the gists, plug them in, and ship voice features users love.

Built for developers. Shared with developers.

Fixing Common Issues in Zego Call Kit for React Native Developers 💻🚀

Muhammad haris baig — Mon, 10 Feb 2025 20:12:44 +0000

Introduction 🛠️
If you're a React Native developer working with Zego Call Kit, you've likely encountered frustrating issues with no straightforward solutions available online. I faced two major problems while integrating @zegocloud/zego-uikit-prebuilt-call-rn and zego-callkit-react-native, and after much debugging, I found effective fixes that will save you a lot of time.

In this article, I'll walk you through these issues, their causes, and the solutions I implemented to resolve them using a patching technique. Hopefully, this will save you time and effort! ⏳

Issue #1: ZegoUIKit.kitLogInfo error apply of undefined ⚠️
Problem ❌
This issue originated from the @zegocloud/zego-uikit-prebuilt-call-rn library. When running my Android app, it would crash due to an undefined method kitLogInfo, while on iOS, it would just show a warning.

Root Cause 🧐
The kitLogInfo function was expected to be present in ZegoUIKitLogger, but it was missing in some versions of the library, leading to runtime errors.

Solution ✅
I resolved this by modifying the logging mechanism using a patch. The original problematic code looked like this:

import {ZegoUIKitLogger} from '@zegocloud/zego-uikit-rn';
const module = 'PrebuiltCall'
export const zloginfo = (...msg) => {
  ZegoUIKitLogger.logInfo(module, ...msg);
};
export const zlogwarning = (...msg) => {
  ZegoUIKitLogger.logWarning(module, ...msg);
};
export const zlogerror = (...msg) => {
  ZegoUIKitLogger.logError(module, ...msg);
};

I changed it to:


"use strict";
import { Platform } from "react-native";
import _zegoUikitRn from "@zegocloud/zego-uikit-rn";
const zloginfo = (...msg) => {
  if (_zegoUikitRn.default.kitLogInfo) {
    _zegoUikitRn.default.kitLogInfo('PrebuiltCall', ...msg);
  } else {
    console.warn(`kitLogInfo is not defined in ZegoUIKit in ${Platform.OS}`);
  }
};
export { zloginfo };

This ensures that if kitLogInfo is undefined, it falls back to a console warning instead of causing a crash. 🛠️

Issue #2: TypeError: Cannot read property 'prefix' of null, js engine: hermes 🐞
Problem ❌
This issue was coming from the zego-callkit-react-native library. On iOS, it threw a warning, but on Android, the app crashed abruptly.

Root Cause 🧐
The problem was in the following line:

const Prefix = ZegoCallKitNativeModule.prefix;

When using Hermes, ZegoCallKitNativeModule was sometimes null, causing an error when trying to access prefix.

Solution ✅
I fixed it by modifying this line to:

import { Platform } from 'react-native';
const Prefix = Platform.OS == 'ios' ? ZegoCallKitNativeModule.prefix : '';

This ensures that on Android, the app does not crash due to a null reference. 🛠️

Applying Patches for These Fixes 🩹
To ensure these changes persist across updates, I used the patch-package tool. Here's how I applied and committed these patches:

Step 1: Install patch-package 📦
yarn add patch-package postinstall-postinstall

Step 2: Make the Changes and Save the Patch 📝
npx patch-package @zegocloud/zego-uikit-prebuilt-call-rn npx patch-package zego-callkit-react-native

Step 3: Ensure Patch is Applied Automatically 🔄
Add this script to package.json:
"scripts": { "postinstall": "patch-package" }

Now, whenever a developer runs yarn install, the patches will be applied automatically. 🛠️

Step 4: Push Patches to GitHub 🚀
I committed the patches so that other developers on my team could use them:

git add patches/ git commit -m "Fix Zego issues with patch-package" git push origin main

Contributing to Open Source 🤝

I also created pull requests (PRs) to contribute these fixes upstream. If merged, we won't need the patches anymore. Here's my PR for @zegocloud/zego-uikit-prebuilt-call-rn:
🔗 PR #14 - Fix kitLogInfo Issue
Unfortunately, I couldn't find zego-callkit-react-native on GitHub, so I had to rely on patching for that one. 😕

Conclusion 🎯
``
If you're working with Zego Call Kit and facing these frustrating issues, I hope this guide helps you save time. Let me know if you encounter any other problems - let's work together to improve these libraries! 🚀
Feel free to share your thoughts in the comments or contribute to the PR to get these fixes merged! 🔥

🚀 DeepSeek AI: A New Challenger in AI Coding Assistants?

Muhammad haris baig — Wed, 29 Jan 2025 13:26:04 +0000

As a developer, AI coding assistants have become an essential part of my workflow - whether it's writing code, debugging, or optimizing logic. I've relied heavily on tools like Codium and ChatGPT, which have been instrumental in enhancing productivity.
Recently, I decided to put DeepSeek AI to the test, using my usual evaluation method: real-world coding tasks, including refactoring, logic corrections, and React Native improvements. I even challenged it with a complex Redux bug, where clearing the user's state was crashing the app. How did it perform compared to my go-to, ChatGPT? Let's dive in! 🔍

📝 Handling Standard Coding Tasks
ChatGPT:
✅ Delivered structured responses with concise explanations.
✅ Used modern ES6+ features for better readability.
✅ Ensured immutability where required.

DeepSeek AI:
❌ Provided a functional response but lacked code organization.
❌ Less emphasis on readability and best practices.
❌ Maintained much of the original structure without significant improvements.

🔥 Tackling a Complex Redux Bug
ChatGPT:
❌ Identified the issue and suggested a fix, but responses were more verbose.
❌ Provided additional explanations - helpful for learning but not strictly necessary.
❌ Suggested a similar solution but didn't highlight Immer's role in Redux Toolkit as clearly as DeepSeek AI.

DeepSeek AI:
✅ Quickly pinpointed the issue - improper state handling in the reducer.
✅ Offered a clear, concise fix and explained potential issues.
✅ Suggested using Object.assign and delete for safer state mutations.
✅ Response was detailed, actionable, and straight to the point.

⚖️ DeepSeek AI vs. ChatGPT: Strengths & Weaknesses
🔹 DeepSeek AI
✔️ Strengths: Concise, highly practical, and solution-focused. It understood the problem's context well and delivered an efficient fix.
❌ Weaknesses: Lacked in-depth explanations, which might be a downside for those who want to learn the underlying concepts.

🔹 ChatGPT
✔️ Strengths: Great for learning! Its detailed responses provide valuable insights into why a solution works.
❌ Weaknesses: Sometimes overly verbose, making it harder to extract the exact solution quickly.

🏆 My Verdict
For me, ChatGPT wins because of its detailed explanations, making it the best for learning, deep diving into solutions, and truly understanding problems. DeepSeek AI is promising, but it still needs time to evolve and refine its precision. That said, it's clearly in the race and could disrupt the competition at any moment.

💡 DeepSeek's Game-Changing AI Approach
DeepSeek isn't just about coding - it's shaking up AI computing and even challenging Nvidia.
Here's how they trained a model matching GPT-4 and Claude for just $5M (vs. the usual $100M+):
🔹 Smarter Math - Reduced memory usage by 75% using 8-bit precision without sacrificing accuracy.
🔹 Faster Reading - Processes entire phrases instead of one word at a time, making it twice as fast while keeping 90% accuracy.
🔹 Expert System - Activates only the relevant AI parameters, running smaller, task-specific models - cutting compute costs by 95%.

⚠️ A Nightmare for Nvidia?
Nvidia makes billions selling $40K AI chips with huge profit margins. Until now, companies had no choice but to buy thousands of them. But DeepSeek's breakthroughs mean high-end AI can run efficiently on fewer GPUs - or even standard gaming cards. If this trend continues, Nvidia's AI hardware dominance is at risk.

🔥 Final Thoughts
Both DeepSeek AI and ChatGPT are powerful, but they serve different purposes.
✅ For quick, no-fluff coding solutions: DeepSeek AI is a strong contender.
✅ For in-depth learning and problem-solving: ChatGPT remains my top choice.
AI is evolving fast - who do you think will dominate? Let's discuss! 👇

🚨 Error occurred prerendering page "/" ? Here's the Fix! 🚨

Muhammad haris baig — Fri, 17 Jan 2025 09:39:15 +0000

If you're trying out the new Next.js API routes and running into problems fetching data during npm run build, you're not alone. Many developers are encountering this issue because the API route behavior has slightly changed in Next.js. Even after hours of digging through the docs, the solution might not be obvious.

The Problem
By default, Next.js tries to optimize performance with static rendering and caching. This is great for speed but can cause issues when you're fetching dynamic data that changes frequently or needs to bypass caching during build time.

The Solution
To ensure your data fetching works as expected, you need to override Next.js' default caching behavior. Add these two lines to the top of your file where you're fetching the data:

export const dynamic = "force-dynamic";
export const fetchCache = "force-no-store";

Why This Works
dynamic = "force-dynamic": Forces the page to render dynamically instead of statically.
fetchCache = "force-no-store": Disables caching for your fetch calls, ensuring you're always fetching fresh data.

Example Code
Here’s how it looks in practice:

export const dynamic = "force-dynamic";
export const fetchCache = "force-no-store";

const getData = async () => {
  const res = await fetch("https://your-api-url/api/posts");
  if (!res.ok) throw new Error("Failed to fetch data");
  return res.json();
};

const Blog = async () => {
  const data = await getData();
  return data.map((item) => <div key={item.id}>{item.title}</div>);
};

export default Blog;

Final Step
After making this change, run npm run buildagain, and your problem should be solved! 🎉

Hope this saves you hours of debugging. Thank me later 🚀

How to Integrate Tabby in React Native: A Step-by-Step Guide

Muhammad haris baig — Sun, 22 Dec 2024 16:59:26 +0000

Integrating Tabby into your React Native app can be a seamless process, but there’s no comprehensive guide available online that provides a step-by-step approach. This article consolidates information from multiple sources to give you a clear roadmap for implementing Tabby in your React Native app.

Step 1: Install Tabby SDK
To get started, you need to install the Tabby SDK for React Native. Run the following command in your project directory:

npm i tabby-react-native-sdk

Step 2: Update Platform-Specific Configurations

iOS Configuration For iOS, make sure to update your Info.plist file with the following permissions:

<key>NSCameraUsageDescription</key>
<string>This allows Tabby to take a photo</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>This allows Tabby to select a photo</string>

You can customize the descriptions to suit your app.

Android Configuration For Android, add these permissions to your AndroidManifest.xml file:

<uses-permission android:name=”android.permission.CAMERA” />
<uses-permission android:name=”android.permission.READ_EXTERNAL_STORAGE” />
<uses-permission android:name=”android.permission.WRITE_EXTERNAL_STORAGE” />

These permissions ensure Tabby can access the necessary resources.

Step 3: Initialize Tabby in Your App
To initialize Tabby, add the following code to your app’s entry point (App.tsx or index.js):

import {Tabby} from 'tabby-react-native-sdk';

Tabby.setApiKey('__API_KEY_HERE__');

The Tabby.setApiKey() method sets your API key, allowing your app to authenticate with Tabby's backend services.

Replace API_KEY_HERE with your Tabby API key.

Step 4: Create the Payment Flow

Define the Payment Data In your cart screen, set up the payment data required by Tabby:

const customerPayment = {
  amount: 340.0,
  currency: 'SAR',
  buyer: {
    email: 'successful.payment@tabby.ai',
    phone: '+971500000001',
  },
};

const myTestPayment = {
  merchant_code: 'your merchant code',
  lang: 'en',
  payment: customerPayment,
};

The customerPayment object defines the buyer's payment details, such as amount, currency, and contact information. The myTestPayment object includes merchant-specific details like merchant_code and preferred language.

Create a Session Trigger Button
Add a button to your UI to trigger the session creation process

<Button title="Proceed with Tabby" onPress={createCheckoutSession} />

This button triggers the createCheckoutSession function when pressed, initiating the payment process.

Implement the Session Creation Logic
Handle the button press with the following function:

const createCheckoutSession = async () => {
  try {
    const {sessionId, paymentId, availableProducts} =
      await Tabby.createSession(myTestPayment);
    navigation.navigate('TabbyWebViewScreen', {
      url: availableProducts[0].webUrl,
    });
  } catch (error) {
    if (error.response) {
      console.error('Response:', error.response);
      console.error('Status:', error.response.status);
      console.error('Data:', error.response.data);
    }
    console.error('Error creating Tabby checkout session', error);
  }
};

The Tabby.createSession() method creates a checkout session with the payment data. If successful, the response includes session details like sessionId and the checkout URL. The user is then navigated to a new screen (TabbyWebViewScreen) to complete the payment.

Step 5: Create a Tabby WebView Screen
Set up a new screen to display the Tabby checkout flow:

import React from 'react';
import {View, StyleSheet, Button} from 'react-native';
import {useNavigation, useRoute} from '@react-navigation/native';
import {TabbyPaymentWebView} from 'tabby-react-native-sdk';

const TabbyWebViewScreen = () => {
  const navigation = useNavigation();
  const route = useRoute();
  const {url} = route.params;

  const handlePaymentResult = message => {
    switch (message) {
      case 'authorized':
        console.log('Payment Authorized');
        navigation.goBack();
        break;
      case 'rejected':
        console.log('Payment Rejected');
        navigation.goBack();
        break;
      case 'close':
        console.log('Checkout Closed');
        navigation.goBack();
        break;
      case 'expired':
        console.log('Session Expired');
        navigation.goBack();
        break;
      default:
        break;
    }
  };

  return (
    <View style={styles.container}>
      <View style={styles.webViewContainer}>
        <TabbyPaymentWebView
          url={url}
          onBack={() => navigation.goBack()}
          onResult={handlePaymentResult}
        />
      </View>
      <Button title="Go Back" onPress={() => navigation.goBack()} />
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: 'white',
  },
  webViewContainer: {
    marginTop: 50,
    height: '95%',
    backgroundColor: 'blue',
  },
});

export default TabbyWebViewScreen;

The TabbyPaymentWebView component loads the checkout URL and displays it in a web view.
The handlePaymentResult function handles the payment outcome (e.g., authorized, rejected, or expired) and redirects the user accordingly.
A “Go Back” button allows users to return to the previous screen.

Step 6: Handle Payment Results
The handlePaymentResult function manages user redirection based on payment outcomes:

authorized:Payment was successful.
rejected: Payment was declined.
close: User closed the checkout process.
expired: Session expired.
Use these outcomes to guide the user experience in your app.

Additional Resources

Tabby React Native SDK

Tabby Documentation

Tabby React Native Example

Explore these links to dive deeper into Tabby features and advanced use cases.

Custom Apple Pay Integration in React Native with Native

Muhammad haris baig — Mon, 16 Dec 2024 11:17:44 +0000

Why Build Custom Solutions Over Libraries in React Native?

While libraries simplify integrations in React Native, they often come with limitations:

Deprecated Libraries: Updates and support can cease, leaving projects vulnerable.
Feature Limitations: Libraries may not meet all use cases.
Flexibility: Custom solutions offer more control for unique requirements.
Custom native modules ensure scalability and precision. Here’s how to integrate Apple Pay natively in React Native for iOS.

Why Use Apple Pay in React Native?

Apple Pay enables secure, seamless payments with encrypted card details. A React Native integration aligns with Apple’s security standards while enhancing the user experience.

Note: Before proceeding, you must create a Merchant ID and configure your project in Xcode. Follow Apple’s official documentation to complete prerequisites.

Steps to Create a Custom Apple Pay Module
1. Create a Swift Module
Add an ApplePayModule.swift file to your iOS project:

Payment Request Parameters: Define merchant ID, supported networks, and payment details.
Can Make Payments: Check device capability with PKPaymentAuthorizationController.canMakePayments().
Request Payment: Present the Apple Pay sheet and handle authorization using React Native callbacks (RCTPromiseResolveBlock/RCTPromiseRejectBlock).

2. Bridge the Module

Use ApplePayModule.m to bridge Swift and React Native, exposing methods like canMakePayments and requestPayment to JavaScript.

3. Create a Hook

The useApplePay hook consolidates Apple Pay operations, feel free to add currencies and countries.

Key Functions:

canMakePayments: Validates device compatibility.
requestPayment: Handles the payment flow.
handleApplePay: Combines the above for a seamless user experience.
Centralized logic for checking availability and managing payments.
Comprehensive error handling.

4. Use the Custom Module
Here’s a React Native component example leveraging the module:

Conclusion
Custom native modules are ideal when libraries fall short or become deprecated. A native Apple Pay integration:

Ensures a secure payment flow.
Aligns with Apple’s standards.
Offers control and flexibility for unique project needs.
This approach equips you with a robust, scalable solution for seamless payments in React Native apps.

Simple Yet Handy React Native Hooks

Muhammad haris baig — Tue, 06 Aug 2024 19:10:41 +0000

React Native developers often encounter common tasks that require repetitive code, such as fetching data. To streamline this task, here is a custom hook: useFetch. This hook is not only simple and easy to use but also cater to edge cases, making your development process smoother.

useFetch Hook
The useFetch hook simplifies the process of fetching data from an API, managing the loading state, and handling errors gracefully. It even checks for network connectivity before attempting a fetch, ensuring your app remains robust in various conditions.

Usage Example

const { data, loading, error } = useFetch('https://jsonplaceholder.typicode.com/users');

Effortless Parallax in React Native

Muhammad haris baig — Mon, 05 Aug 2024 11:46:21 +0000

Hey everyone! If you're searching for a painless and straight forward solution to your parallax issues, look no further! I've got a perfect, easy-to-digest solution for creating a parallax effect with a sticky header, a hide-able parallax view, and a scrollable container that activates once the parent scroll is finished.

The Problem:

Creating a parallax effect in React Native can be tricky, especially when trying to synchronize scrolling between a parent view and nested views. Common issues include the parallax view not hiding correctly, the child scroll view not activating at the right time, and the sticky header not behaving as expected.

The Solution:

The following code solves these problems by using a combination of React Native and react-native-reanimated to manage the scroll events efficiently. The solution ensures that the sticky header remains in place, the parallax view hides as the user scrolls up, and the nested scroll view becomes scrollable when the parent scroll is completed.

Here's the Code:

You can copy and paste the following code to get started:

How It Works:

Sticky Header: The header changes color based on the scroll position, remaining visible at the top of the screen until the user scrolls to the bottom of the parent view.
Parallax View: The parallax section hides as the user scrolls up, creating a smooth transition effect.
Scrollable Container: The nested scroll view becomes scrollable only after the parent scroll view reaches the bottom, ensuring a seamless user experience.

This solution effectively manages the scrolling behavior between the parent and child views, providing a smooth and visually appealing parallax effect. Feel free to use and modify the code as needed for your projects!

Happy coding! 🎉

Please consider sharing your experiences and improvements in the comments below. Let's keep the learning going!

DEV Community: Muhammad haris baig

React Native + Android 16: The SDK Upgrade That Looks Easy Until Your UI Breaks

The "Easy" SDK Upgrade

The Real Breakage: Edge-to-Edge

Don't Fix Safe Areas Screen by Screen

Status Bar Color Is Part of the UI

The Keyboard Problem: adjustResize Isn't Enough

What to Test After API 35 → 36

System UI

Keyboard

Core Android Features

Navigation

Devices

The Biggest Lesson

Five Takeaways

Upgrading React-Native from Android SDK 34 35: Real Issues, Real Fixes, and What No One Tells You

🚨 The “10x Developer” Myth in the AI Era 🚨

Build Voice Messaging in React Native with Reusable Gists

Fixing Common Issues in Zego Call Kit for React Native Developers 💻🚀

🚀 DeepSeek AI: A New Challenger in AI Coding Assistants?

🚨 Error occurred prerendering page "/" ? Here's the Fix! 🚨

How to Integrate Tabby in React Native: A Step-by-Step Guide

Custom Apple Pay Integration in React Native with Native

Simple Yet Handy React Native Hooks

Effortless Parallax in React Native

The Keyboard Problem: `adjustResize` Isn't Enough