DEV Community: Mrinal Maheshwari

React Native + Android’s 16 KB Page Size: What It Is, Why It Matters, and Exactly How to Get Your App Ready

Mrinal Maheshwari — Wed, 17 Sep 2025 18:10:19 +0000

Everything you need to know about React Native and Android’s shift to 16KB memory pages — performance boosts, migration steps, and Play Store rules.

If you ship React Native apps to Android, there’s a platform shift you can’t ignore: Android 15 introduces support for 16 KB memory page size. This brings measurable performance wins, but it also means some apps — especially those bundling native code (NDK/C/C++) — must be rebuilt or they won’t run on future 16 KB devices. The React Native team already added support in v0.77, so you’ve got a clear path. Let’s make sure you’re set up end-to-end.

Google has also tied this to a Play publishing rule: starting November 1, 2025, any new app or update targeting Android 15+ must support 16 KB pages. Don’t wait for the deadline — do the checks now and sleep better.

TL;DR for busy React Native devs

Upgrade React Native to 0.77+ (which explicitly calls out 16 KB support).
Upgrade AGP to 8.5.1 or higher (needed for proper 16 KB zip alignment of uncompressed libs).
Use NDK r27+ (prefer r28+ where 16 KB alignment is default). Otherwise, add the linker flags shown below.
Rebuild all native bits (yours and any SDKs shipping .so files). Pure Kotlin/Java apps are usually fine, but still test.
Test in a 16 KB environment (emulator or eligible Pixel). Verify with

adb shell getconf PAGE_SIZE → 16384.

Check Play Console > App Bundle Explorer for 16 KB compliance warnings.

What “page size” means (and why 16 KB helps)

Android (like every OS) manages memory in fixed-size “pages.” Historically that was 4 KB; Android 15 supports 16 KB pages on newer devices. Larger pages mean fewer address translations → less overhead → faster launches (3% on average, up to 30% in some cases), lower power draw, quicker camera starts, and even faster boot. Expect a small increase in memory use, but the overall experience improves.

How this affects React Native specifically

The React Native 0.77 release explicitly mentions Android 15 support & 16 KB page support. In practice:

If your app (or any dependency) includes NDK/C++ code, you must rebuild with 16 KB-compatible toolchains/flags.
Popular SDKs are updating; keep an eye on your dependency tree and update to their 16 KB–ready versions.

A practical migration plan (copy/paste friendly)

1) Bump your stack

React Native: 0.77 or newer.
Android Gradle Plugin (AGP): 8.5.1+. This ensures uncompressed shared libraries are aligned to a 16 KB zip boundary.
In your project’s gradle.properties / build.gradle versions matrix, target AGP ≥ 8.5.1.

NDK:

r28+ → 16 KB alignment by default (no extra flags).
r27 → enable flexible page sizes (flags below).
r26 or lower → add linker flags; for very old NDKs (≤ r22) there’s an extra common-page-size flag. Prefer upgrading.

2) Enable 16 KB alignment for native code (only if needed)

CMake (Gradle externalNativeBuild)

# CMakeLists.txt
target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")
# If you’re stuck on very old NDKs (≤ r22):
# target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,common-page-size=16384")

Gradle (CMake arguments) with NDK r27

android {
  defaultConfig {
    externalNativeBuild {
      cmake {
        arguments += listOf("-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON")
      }
    }
  }
}

ndk-build

# Application.mk (NDK r27)
APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true

# Android.mk (NDK r26 or lower)
LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"
# For ≤ r22 also add:
# LOCAL_LDFLAGS += "-Wl,-z,common-page-size=16384"

These snippets reflect the official guidance for different NDK versions.

3) Don’t rely on PAGE_SIZE = 4096

Search your native code (and any forks) for places that assume 4 KB (e.g., usage of PAGE_SIZE or hardcoded 4096). Replace with getpagesize() / sysconf(_SC_PAGESIZE), or refactor logic so it doesn’t depend on a fixed page size. Newer NDKs even undefine PAGE_SIZE in 16 KB mode to avoid misuse.

4) Align packaging and verify

With AGP 8.5.1+, uncompressed .so files are zip-aligned to 16 KB automatically.
Verify alignment on your built APK/AAB:

zipalign -c -P 16 -v 4 app-release.apk

You’re looking for a clean pass — no misaligned native libs.

5) Test in a real 16 KB environment

Options (pick one or more):

Android Emulator with a 16 KB Android 15 system image.
Eligible Pixel devices via “Boot with 16KB page size” developer option (Pixel 8/8a/9 family on Android 15 QPR builds).
Samsung Remote Test Lab on supported devices.

Confirm the environment:

adb shell getconf PAGE_SIZE
# Expect: 16384

Then run your full regression suite.

How to know if your app is actually impacted

If your app is pure Kotlin/Java with no native code anywhere (including SDKs), you’re likely already compatible; still test on 16 KB to be safe.
If you use React Native libraries that include native code (e.g., image processing, media, crypto, maps, analytics, etc.), you need to update those SDKs to 16 KB–ready builds and rebuild your app. The Play Console’s App Bundle Explorer highlights compliance issues.

Deadlines (pin these)

November 1, 2025 — Google Play requires all new apps and updates targeting Android 15+ to support 16 KB pages. If you miss this, your submission can be blocked.

Example: a typical React Native Android upgrade checklist

Upgrade React Native to 0.77 (or newer).
Upgrade AGP to 8.5.1+ and Gradle accordingly.
Update NDK to r28+ (best), otherwise apply the linker flags above.
Update all native SDKs in android/app/build.gradle and your package.json → run a full, clean rebuild.
Re-run ProGuard/R8 and ensure no native libs are stripped incorrectly.
Test on emulator/device running 16 KB mode → verify with getconf.
Check App Bundle Explorer for alignment and compatibility.

Troubleshooting: common “gotchas” I see

“App won’t install on a 16 KB device” → usually means one or more .so files are mis-aligned or still 4 KB-assumed. Re-check NDK version and flags; re — zipalign.
“Crash in native lib at startup” → grep for hardcoded 4096 or PAGE_SIZE. Replace with getpagesize() or remove the dependency.
“Third-party SDK not updated” → upgrade the SDK; if no update exists, contact the vendor or consider replacing it. The Play blog specifically calls out that many major stacks (including React Native) already provide compatible releases.
“CI builds okay, emulator still shows 4096” → you’re not booted into a 16 KB image/mode. Re-download the 16 KB emulator image or enable the device developer toggle, then re-check getconf.

Why you should do this now (not the week before Nov 1)

Beyond the Play rule, the perf wins are real: faster launches (avg ~3%, up to 30%), lower power draw (≈4.5%), quicker camera starts, and faster boot. These are platform-level gains that make your app feel snappier with zero feature work — once you rebuild correctly.

Handy references (keep these open)

Android practice guide: Support 16 KB page sizes — the canonical “how-to” with AGP/NDK specifics, flags, and testing steps.
React Native 0.77 release notes — confirms 16 KB support and Android 15 readiness.
Android Developers Blog (Play requirement) — dates, rationale, performance numbers, and Console guidance.
Android source docs (deeper system details about 16 KB ELF alignment, kernels, and product flags).

Final thoughts

This isn’t a “nice to have.” It’s the memory model your next wave of Android devices will use. The good news: React Native 0.77+ plus a modern AGP/NDK stack makes the migration pretty painless. Update, rebuild, test in 16 KB, and you’re done.

If you hit a weird edge case — especially around older NDKs or legacy SDKs — start by upgrading toolchains, then check alignment and any assumptions about PAGE_SIZE.

Happy shipping — and faster launches ✨

If this helped, you can Buy me a coffee ☕

🧠 How to Code Review Without Losing Your Mind (or Your Team’s Respect)

Mrinal Maheshwari — Mon, 28 Jul 2025 15:44:04 +0000

A no-nonsense guide to giving and receiving feedback that actually helps

👀 Why Code Reviews Matter

Code reviews are more than just nitpicking tabs vs. spaces. They’re about sharing knowledge, improving quality, and building trust. Whether you’re a fresh hire or the architect, the moment you click “Request Review,” you’re inviting someone into your thought process.

And when you’re the reviewer? You’re stepping into the code’s story, trying to understand not just what it does — but whyit was written that way.

Done right, code reviews elevate the whole team. Done wrong, they frustrate everyone and ship bugs.

🎯 The Goal of a Code Review Is Not Perfection

Let’s get one thing straight: your job as a reviewer is not to rewrite the code. It’s to improve it.

You’re looking for:

Correctness: Does it work as intended? Could it break something else?
Clarity: Can someone else understand this six months later?
Consistency: Does it follow project conventions?
Scalability: Will it still work when more users or data are added?
Security: Are there any obvious vulnerabilities or edge cases?

✅ Example (Clarity):

// Less clear
const a = b * c - d;
// Better
const finalPrice = discount * quantity - couponValue;

✅ Example (Consistency):

If your team uses camelCase for function names:

// Inconsistent
function fetch_user_data() {}
// Consistent
function fetchUserData() {}

👂 Read the Code Before You Judge

Slow down. Don’t skim the diff and start commenting like you’re on Twitter. First, try to understand the problem the code is solving.

Read the PR description.
Check the related ticket or task.
Skim the changes as a whole before going line by line.

If the “why” isn’t obvious, ask. Clarification > Assumption.

💬 Feedback Isn’t War — It’s a Conversation

You’re not a linter. You’re a teammate.

Use neutral language:

Instead of: “This is wrong.”
Try: “Can you help me understand why this approach was taken?”

Use suggestions, not commands:

“Consider renaming this for clarity.”
“Would using a loop here improve readability?”

Don’t forget to praise good work:

“Nice use of forEach loop here.”
“Great job simplifying the logic!”

🧠 For the Reviewer: Be Kind, Be Curious, Be Clear

🧪 Test Locally if You Can: Don’t just rely on static diff views.
🧼 Review in Chunks: Don’t try to go through 500 lines at once.
📅 Review Promptly: A slow review delays everyone. Be respectful of people’s timelines.
🤔 Think Contextually: Don’t overcorrect. Some imperfections are okay if they don’t harm the outcome.

✅ Example (Security):

If you see this:

fetch(`https://api.example.com/user/${userId}`)

…ask if the API endpoint needs to be sanitized or authenticated. Even general codebases can leak private info if unchecked.

🙇 For the Author: Feedback Is a Gift (Yes, Really)

Don’t take it personally. Your code ≠ your worth.
Respond with openness: “Thanks for the catch!” goes a long way.
If you disagree, explain respectfully. Defending a decision is part of the collaboration process.

And always say thank you. They took time to review your work.

🧩 Tips for Teams to Make Code Reviews Smoother

✅ Define what must be reviewed (e.g. new features, infra changes).
🧾 Have a checklist (e.g. test cases, naming, error handling).
🧠 Keep PRs small. Big ones invite procrastination.
💬 Use PR templates to give context.
🙌 Encourage pair reviews occasionally — especially for juniors.
⏳ Timebox feedback sessions to avoid burnouts.

🛠️ Code Reviews Are Culture

More than a practice, code reviews reflect the culture of your team:

Is it safe to ask questions?
Are juniors encouraged to review?
Is feedback appreciated, or feared?

Great codebases come from great code review habits. And great habits come from teams that value respect, collaboration, and clarity.

👋 Coming Soon…

Love working with React Native? I’m writing a dedicated React Native Code Review Guide — from optimizing renders to catching native quirks before they hit production.

Stay tuned.

☕ Enjoyed this piece?

I write about team culture, software engineering, and dev life. If this helped you, consider buying me a coffee so I can keep writing honest, practical blogs.

How to Improve API Performance: Tips, Techniques & Best Practices

Mrinal Maheshwari — Sun, 15 Jun 2025 03:30:00 +0000

“APIs have been a real pain point for me. Even after delivering the product and pushing it to production, the APIs didn’t perform as expected. What should ideally take less than a second often ends up taking 4–5 seconds — and that’s frustrating, both as a developer and a user.”

I’ve been in that situation more than once — staring at network logs, wondering why a seemingly simple endpoint is taking ages to respond. After a lot of debugging, Googling, and diving into books on algorithms and software architecture, I started identifying patterns. Eventually, I collated a list of practical techniques that genuinely helped improve API performance.

In this article, I’m sharing those learnings — 15 real-world strategies that have worked for me across different projects. Whether you’re trying to fix a slow endpoint or just build more scalable APIs from day one, I hope these insights help you save time and headaches.

1. Optimize Database Access

Why it matters: Your API is only as fast as the database queries behind it.

How to implement:

Use indexes on frequently queried columns.
Avoid N+1 query problems (where fetching related records causes repeated database calls).
In Sequelize: use .include to load relationships.
In Prisma: use include to fetch relations in a single query.
Batch requests using IN clauses or union queries when possible.

Real life: If you’re querying user orders, fetch them with a single join rather than looping through user IDs and hitting the DB repeatedly.

2. Use Efficient Data Formats

Why it matters: Data serialization and size directly affect response time.

Alternatives to JSON:

Protocol Buffers (Protobuf): Small, fast, and language-neutral (commonly used with gRPC).
MessagePack: Binary format, compatible with many languages and frameworks.

When to use:

Use JSON for public or third-party APIs.
Use Protobuf or MessagePack in internal microservices for performance gains.

3. Reduce Payload Size

Why it matters: Every extra byte adds to the transfer time and processing load.

How to implement:

Only send required fields using field selection or select.
Avoid deeply nested JSON if not necessary.
Trim strings (no need to send 500-character bios in a list view).
Don’t return large blobs (e.g., images, files) directly — use URLs or S3 links.

4. Enable Compression

Why it matters: You can reduce response size by up to 90%.

How to implement:

In Express.js, use the compression middleware:

const compression = require('compression');
app.use(compression());

In NGINX:

gzip on;
gzip_types text/plain application/json;

Tip: Use Brotli for better compression than GZIP if your infra supports it.

5. Caching Strategies

Why it matters: Why calculate or fetch the same data again and again?

Caching layers:

Browser/Client: Use Cache-Control, ETag, and Last-Modified headers.
CDN: Use Cloudflare, Fastly, or AWS CloudFront to cache static responses.
Application: Cache DB queries or computed data using Redis.
Database: Materialized views or result cache.

6. Use Pagination & Filtering

Why it matters: Large data dumps kill bandwidth and frontend performance.

How to implement:

Add limit, offset, or cursor-based pagination.
Filter data server-side using query parameters (?status=active&type=premium).
Use fields query to return only requested fields.

Example (REST):

GET /users?limit=10&offset=20

Example (GraphQL):

query {
  users(first: 10, after: "cursor") {
    name
    email
  }
}

7. Asynchronous Processing

Why it matters: Long-running operations (e.g., image processing, email sending) should not block the response.

What to do:

Offload tasks to a queue: RabbitMQ, Redis, Kafka, or SQS.
Respond immediately with 202 Accepted.
Use webhooks, push notifications, or polling to notify clients when processing is complete.

Real world example:

// Enqueue job for PDF generation
await queue.add('generate-pdf', { userId: 123 });
res.status(202).json({ message: "Processing started" });

8. Connection Management

Why it matters: Poor connection handling leads to leaks, bottlenecks, and eventual crashes.

Tips:

Use keep-alive to avoid reconnecting repeatedly.
Enable connection pooling with DBs.
Set timeouts for DB, HTTP, and external APIs.

Example (PostgreSQL + pg-pool):

const pool = new Pool({
  max: 20,
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000,
});

9. Load Balancing

Why it matters: Distributes traffic, avoids server overload, improves uptime.

What you can use:

NGINX or HAProxy for simple round-robin or least-connections strategies.
Cloud providers (AWS ELB, GCP Load Balancer) for auto-scaling and health checks.
Use sticky sessions only if absolutely necessary.

10. Rate Limiting & Throttling

Why it matters: Protects your API from abuse and ensures fair usage.

How to do it:

Limit by IP, user ID, or API key.
Use sliding window or token bucket algorithms.
Return 429 Too Many Requests with a retry-after header.

Example (Express):

const rateLimit = require("express-rate-limit");
app.use(rateLimit({ windowMs: 60000, max: 100 }));

11. HTTP/2 or gRPC

Why it matters: More efficient protocol = faster response times.

Benefits of HTTP/2:

Multiplexing multiple requests over one connection.
Header compression.
Faster loading for clients making many requests.

gRPC advantages:

Uses Protobuf, extremely fast and compact.
Ideal for internal APIs, microservices.
Supports client-side codegen.

Setup: Use Envoy or NGINX as HTTP/2 proxy, or gRPC with Node, Go, Java.

12. Use CDN for Static Assets

Why it matters: Don’t make your server serve files — push them to the edge.

What to serve via CDN:

Images
PDF files
JS/CSS bundles
Videos

Tools: Cloudflare, AWS CloudFront, Vercel Edge, Netlify

Bonus tip: Use signed URLs for protected file downloads.

13. Optimize Server Code

Why it matters: Even fast APIs break if backend logic is inefficient.

Tips:

Avoid blocking operations (e.g., fs.readFileSync, long loops).
Use asynchronous patterns (async/await, Promise.all).
Profile your app using Node.js built-in profiler or tools like clinic.js.

14. Monitoring & Profiling

Why it matters: You can’t fix what you don’t measure.

Track:

Latency (average, P95, P99)
Error rates
Slow endpoints
Memory usage

Tools:

APM: Datadog, New Relic, Dynatrace
Logging: Winston, Pino, ELK Stack
Tracing: OpenTelemetry + Jaeger

15. Secure Without Bottlenecks

Why it matters: Don’t compromise speed for security, or vice versa.

How:

Validate JWTs efficiently using in-memory public keys.
Use lightweight middlewares for token validation.
Don’t do heavy DB lookups before authentication.

Final Thoughts

Improving API performance is a continuous process. Start by measuring, then fix the biggest pain points first. Whether you’re working with REST, GraphQL, or gRPC — these techniques are universal.

By applying even a handful of these best practices, you’ll create faster, more scalable, and user-friendly APIs.

🚀 Boosting React Native Performance with Caching — Made Simple

Mrinal Maheshwari — Fri, 13 Jun 2025 03:30:00 +0000

In this guide, we’ll break down what caching is, why it matters in React Native, and how to implement it with some handy tools and libraries.

🔍 Why Should You Care About Caching?

Mobile apps run on devices that have limited memory and storage — and let’s be honest, internet connections aren’t always reliable. Caching helps your app:

Load faster by avoiding repeated API calls
Work offline or in poor network conditions
Feel smoother by loading images and data locally

🧰 Types of Caching in React Native

Not all caching is created equal. Let’s look at the most useful types:

1. In-Memory Caching

This is the quickest way to cache data, storing it temporarily in the app’s memory.

Great for UI state or short-lived data
Libraries like Redux, Zustand, or React’s Context API can handle this
But remember: once the app closes, this data is gone

2. Persistent Caching

This is for data that should stick around, even after restarting the app.

Useful for login tokens, user settings, or cached API responses
Use tools like AsyncStorage or the faster, more secure MMKV
Keeps your app functional even without an internet connection

3. Image Caching

React Native doesn’t cache images well by default, which can cause slow load times and unnecessary data use.

Use react-native-fast-image for proper image caching and better performance
Especially useful for apps with lots of images (e.g. shopping, social media)

4. API Response Caching

Instead of hitting the server every time, cache API responses locally.

Helps reduce load on your backend
Makes screens load quicker
Tools like MMKV, React Query, or SWR can help manage this
Built-in support for stale data and revalidation

🔐 MMKV for Fast Persistent Caching

MMKV is a high-performance storage solution that’s great for caching data on the device.

📦 Install MMKV

npm install react-native-mmkv

⚙️ Setup MMKV

// storage.ts
import { MMKV } from 'react-native-mmkv'

export const storage = new MMKV()

export const setCache = (key: string, value: any) => {
  storage.set(key, JSON.stringify(value))
}

export const getCache = (key: string) => {
  const json = storage.getString(key)
  return json ? JSON.parse(json) : null
}

🔁 Caching API Responses

Let’s create a simple hook to fetch data and cache it using MMKV.

// useCachedFetch.ts
import { useEffect, useState } from 'react'
import axios from 'axios'
import { getCache, setCache } from './storage'

export const useCachedFetch = (url: string, cacheKey: string) => {
  const [data, setData] = useState<any>(null)
  const [loading, setLoading] = useState(true)
  useEffect(() => {
    const fetchData = async () => {
      const cached = getCache(cacheKey)
      if (cached) {
        setData(cached)
        setLoading(false)
        return
      }
      try {
        const response = await axios.get(url)
        setData(response.data)
        setCache(cacheKey, response.data)
      } catch (e) {
        console.error(e)
      } finally {
        setLoading(false)
      }
    }
    fetchData()
  }, [url])
  return { data, loading }
}

🧪 Usage

const { data, loading } = useCachedFetch('https://api.example.com/products', 'products')

if (loading) return <ActivityIndicator />
return (
  <FlatList
    data={data}
    renderItem={({ item }) => <Text>{item.name}</Text>}
  />
)

🖼️ Image Caching with react-native-fast-image

For static images or images fetched over the network, use react-native-fast-image to enable caching and performance boosts.

npm install react-native-fast-image

import FastImage from 'react-native-fast-image'

<FastImage
  style={{ width: 100, height: 100 }}
  source={{
    uri: 'https://example.com/image.jpg',
    priority: FastImage.priority.normal,
    cache: FastImage.cacheControl.immutable,
  }}
/>

⚠️ Gotchas & Best Practices

Set a TTL (Time To Live) if the data can go stale
Don’t store sensitive info unless it’s encrypted
Clear cache when the user logs out or when data becomes irrelevant

📌 Conclusion

Caching is a simple but powerful way to make your React Native app feel lightning fast and reliable. With tools like MMKV and FastImage, you can easily implement smart caching strategies that keep users happy — even when their internet isn’t.

Happy Caching! 💙

❓Got Questions or Thoughts?

Here are a few things to think about (or ask your team):

What kind of data in your app could benefit the most from caching?
Are you currently using in-memory or persistent caching — or both?
How are you handling cache invalidation or stale data?
Are your current caching methods optimized for performance and security?
Could your app offer a better offline experience with smarter caching?

Feel free to share your caching strategies or challenges. Let’s learn from each other!

React Native Interview Deep Dive: 9 Questions That Reveal What Resumes Don’t

Mrinal Maheshwari — Thu, 12 Jun 2025 19:50:26 +0000

Q1. Have you used Class based components or functional components ?

is designed to gauge a candidate’s familiarity with different generations of React development. It helps me understand how long the candidate has been working with React & React Native, whether they’ve adapted to modern best practices (like hooks), and if they can maintain legacy codebases. Class-based components were standard before React 16.8, while functional components with hooks represent the modern approach. A well-rounded candidate typically has experience with both and can articulate the differences in lifecycle management, state handling, and code structure.

If developer goes as:

“Only class components” → Experience with legacy React, may need to learn hooks and functional patterns.
“Only functional components” → Likely newer to React, started after hooks were introduced.
“Both, but prefer functional” → Versatile and up-to-date with modern React practices.

Q2. How can you secure your mobile application data, be the data is in transit or rest ?

assesses a candidate’s understanding of mobile app security fundamentals. It evaluates their knowledge of securing sensitive information both while it’s being transmitted over networks (in transit) and when stored locally on the device (at rest). A strong answer would cover the use of HTTPS (TLS) for secure communication, SSL pinning to prevent man-in-the-middle attacks, and secure storage solutions like Keychain (iOS), Keystore (Android), or libraries like react-native-mmkv or react-native-keychain for encrypting data on the device. It also hints at the candidate’s awareness of compliance, data protection best practices, and their ability to build trustworthy, enterprise-grade applications.

If developer

Mentions HTTPS only → Basic awareness; needs more depth in securing data.
Includes SSL pinning and secure storage → Good understanding of both in-transit and at-rest protection.
Mentions encryption, platform APIs (Keychain/Keystore) → Strong grasp of mobile security and platform-specific practices.
Includes token handling, data minimization → Advanced level, with security-by-design mindset.

Q3. Have you worked with Typescript or JavaScript ?

helps assess a candidate’s proficiency with the core languages used in React Native development. It distinguishes whether the candidate has experience with JavaScript, the foundational scripting language, or TypeScript, the typed superset that adds static typing and better tooling. TypeScript is widely adopted in modern codebases for its scalability, maintainability, and early error detection. A candidate who has worked with both shows adaptability and a deeper understanding of development quality and tooling. The answer also indicates how comfortable the candidate is with types, interfaces, and advanced language features used in large-scale or enterprise-level applications.

Evaluation goes where he answers:

“Only JavaScript” → Basic familiarity, suitable for simpler apps or junior roles.
“Only TypeScript” → Likely has experience in more modern or enterprise projects.
“Both, prefer TypeScript” → Ideal candidate; adaptable with best practice knowledge.
“Both, but still learning TypeScript” → In transition, shows willingness to adopt modern tools.

Q4. Can’t perform a React state update on an unmounted component, what does this error/warning state ?

occurs when your code tries to update the state of a component after it has already been removed from the UI tree (unmounted). This typically happens when an asynchronous operation like a fetch, setTimeout, or subscription completes after the component has unmounted, leading to a memory leak or unnecessary state update. React throws this warning to help developers avoid side effects or crashes from manipulating non-existent components. Proper cleanup using useEffect’s return function or tracking component mount status can prevent this issue.

My interpretation goes:

“Not sure what it means” → Lacks experience with async operations or lifecycle management.
“It’s about updating state after unmount” → Has encountered and understood the issue.
“Mentions cleanup with useEffect” → Good grasp of React lifecycle and hook usage.
“Implements abort controllers or refs to check mounted status” → Advanced handling and prevention skills.

Q5. Have you worked with RestAPIs or graphAPIs as well, and which library or method you’ve used to call APIs ?

is designed to evaluate a candidate’s experience with backend communication, data fetching strategies, and tooling preferences. It helps assess whether the candidate has worked with traditional RESTful APIs or GraphQL, which is more flexible but requires schema understanding. Additionally, asking about the method or library (like fetch, axios, Apollo Client, etc.) reveals their hands-on familiarity and ability to manage networking, error handling, and data flows within React Native apps. It also indirectly touches on their understanding of performance, pagination, and security in API interactions.

Interpretation goes like:

“Only REST using fetch” → Basic experience, suitable for simpler use cases.
“REST with axios” → More practical; likely understands interceptors and async flows.
“Worked with GraphQL using Apollo Client” → Advanced usage with state & schema management.
“Mentioned caching, token handling, retries” → Strong grasp of real-world API concerns.

Q6. Have you worked on native side of react native, if yes which functionality developed and why ?

evaluates a candidate’s depth of experience beyond JavaScript, specifically their ability to bridge native Android (Java/Kotlin) or iOS (Swift/Obj-C) modules with React Native. It’s a strong indicator of whether the candidate can build or integrate custom native functionality that isn’t available via existing JS libraries — something often needed in performance-critical or platform-specific cases. This question also reveals their understanding of the React Native bridge, JSI, permissions, native module lifecycle, and communication between native and JS layers.

This helps me in getting in depth knowledge and experience of developer as:

“No native work yet” → Pure JS experience; good for UI or feature work but limited in low-level customization.
“Integrated native SDKs (e.g., camera, maps)” → Practical native linking experience.
“Built custom modules using bridge/JSI” → Advanced skill set; can solve platform-level gaps.
“Handled permissions or platform-specific UI” → Shows initiative in user experience and device integration.

Q7. Do you know the concept of jailbreak or rooting a device, if yes how can we prevent the same?

assesses a candidate’s awareness of mobile security threats and their ability to protect sensitive app data from compromised environments. Jailbreaking (iOS) or rooting (Android) gives users full control over their device’s OS, often bypassing security restrictions. While this can be useful for advanced users, it poses significant risks for apps handling sensitive data (e.g., fintech, health, enterprise apps). The question evaluates whether the candidate understands how to detect rooted/jailbroken devices and implement preventive or defensive measures to mitigate the risk.

Example Interpretation

“Not familiar with jailbreak/rooting” → Lacks security awareness; may be risky for sensitive app development.
“Knows what it is but not how to handle it” → Basic awareness; needs upskilling in mobile security.
“Mentions root detection libraries or platform checks” → Good understanding; can prevent app from running on compromised devices.
“Uses obfuscation, integrity checks, and secure storage” → Advanced security mindset with layered defense approach.

Q8. What is props drilling and how can we avoid that?

evaluates a candidate’s understanding of state and data flow management in React or React Native apps. Prop drilling refers to the process of passing data from a parent component to deeply nested child components via intermediate components that do not need the data themselves. This makes code harder to maintain and understand, especially in large applications. The question also tests whether the candidate knows alternative approaches to simplify or optimize state sharing across components.

Evaluation matrix goes with response:

“Not sure what it is” → Lacks understanding of component communication patterns.
“Explains passing props through multiple levels” → Basic understanding of prop drilling.
“Mentions useContext or Redux to avoid it” → Good grasp of global state and context-based solutions.
“Uses tools like Zustand, Jotai, or component composition” → Advanced; explores modern alternatives to manage shared state cleanly.

Q9. At the end goes the coding question which helps me understand

🧠 What This Question Evaluates

Practical Implementation Skills
It shows how well the candidate can translate concepts into working code under light pressure.
Problem-Solving Approach
You get insight into how they break down requirements, structure components, and debug.
Code Quality & Best Practices
You can assess naming conventions, component structure, state management, and how clean or readable their code is.
Tool Familiarity
You see what tools or libraries they naturally reach for (useState, FlatList, axios, redux, etc.)
Depth Beyond Theory
It filters out candidates who only have surface-level knowledge but can’t implement real-world tasks.

Interpretation:

“Struggles to start or needs constant guidance” → Lacks hands-on experience or confidence.
“Completes the task, but messily” → Knows the basics, needs refinement in structure or practices.
“Implements clean, functional solution with edge cases handled” → Strong coding skills and thought process.
“Adds extra features, optimizations, or error handling” → Excellent candidate with product mindset.

Comments are open, and so is the conversation 👇

SSL Pinning in React Native

Mrinal Maheshwari — Wed, 11 Jun 2025 20:32:11 +0000

What is SSL Pinning?

SSL pinning, also known as certificate pinning, is a security technique used to ensure that a client only trusts a specific server certificate and not any imposters or fake certificates. This technique helps to prevent man-in-the-middle (MITM) attacks, where an attacker intercepts communication between a client and a server and intercepts the SSL certificate, allowing them to read and modify the data being transmitted.

In SSL pinning, the client is pre-configured with the expected SSL certificate or public key of the server. When the client establishes a connection with the server, it verifies the server’s certificate against the expected certificate or public key. If the certificates match, the connection is established, otherwise, the connection is terminated.

This technique helps to ensure that the communication between the client and server is secure and free from tampering, even if an attacker tries to intercept the communication and present a fake certificate.

Overall, SSL pinning provides an additional layer of security for sensitive information transmitted over the internet. It is commonly used in mobile and web applications to protect sensitive information such as login credentials, financial transactions, and personal data.

Types of SSL Pinning:

Certificate Pinning: In this method, the client is pre-configured with the expected X.509 certificate of the server. When the client establishes a connection with the server, it verifies the server’s certificate against the expected certificate.
Public Key Pinning: In this method, the client is pre-configured with the expected public key of the server. When the client establishes a connection with the server, it verifies the server’s public key against the expected public key.
Subject Public Key Info (SPKI) Pinning: In this method, the client is pre-configured with the expected SPKI of the server. When the client establishes a connection with the server, it verifies the server’s SPKI against the expected SPKI.
Hash Function Pinning: In this method, the client is pre-configured with the expected hash of the server’s certificate or public key. When the client establishes a connection with the server, it calculates the hash of the server’s certificate or public key and verifies it against the expected hash.

Each of these methods provides a different level of security and is suited for different use cases. For example, certificate pinning provides the highest level of security, but it is also the most rigid and difficult to manage. Public key pinning, on the other hand, is more flexible and easier to manage, but provides a lower level of security.

In general, SSL pinning should be used in conjunction with other security measures, such as SSL encryption, to provide a comprehensive security solution.

Implementing SSL Pinning in React Native (Public Key Pinning)

Extract public key of a certificate

Before we set up our SSL pinning logic, we first need to retrieve the public key of our server’s certificate. Open a terminal session and enter the command below, replacing the server domain name with yours.

First, we need public key of server certificate.
Open Terminal and enter command below, but don’t forget to change domain name (google.co.in) with your server’s domain name.

openssl s_client -servername google.co.in -connect google.co.in:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

openssl s_client -servername google.co.in -connect google.co.in:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

After this you will get output similar to the one given below. Do copy the base64 key from the end of output:

...
verify return:1
depth=0 CN = *.google.co.in
verify return:1
Xthc0lj4iC4WT3stvwXerl89af709USBG3S5qJVz4fA=

Android:

The implementation on android is easy as Android already exposes the method for SSL Pinning. Under the hood React Native uses OKHttp and it comes with SSL Pinning support.

We are not creating our own OkHttpClient builder instead we are using public method exposed on React Native OkHttpClientProvider which returns OkHttpClientBuilder . So that if any changes done be React Native in future we need not change anything in our code.

In onCreate() method of MainApplication.java add the code

OkHttpClientProvider.setOkHttpClientFactory(new SSLPinnerFactory());

Your code will look something like this

iOS:

For implementing SSL Pinning in React Native for iOS we will use library called TrustKit add this line in your Podfile

pod 'TrustKit'

Open the Project in Xcode and in AppDelegate.m and make changes in your code like this

By setting the kTSKSwizzleNetworkDelegates key to YES, TrustKit will then perform method swizzling on the App's NSURLSession and NSURLConnection delegates in order to automatically perform SSL pinning validation against the server's certificate chain, based on the configured pinning policy. This allows deploying TrustKit without changing the App's source code.

By setting the kTSKSwizzleNetworkDelegates key to YES, TrustKit will then perform method swizzling on the App's NSURLSession and NSURLConnection delegates in order to automatically perform SSL pinning validation against the server's certificate chain, based on the configured pinning policy. This allows deploying TrustKit without changing the App's source code.

To read full getting started guide regarding TrustKit refer this guide

This completes the implementation of SSL Pinning in React Native using Public Key Pinning method.

Suggestions, recommendations and requests for any topic is welcome in comments.

Happy coding!