Vishaal KarthikMobile Engineer · React Native
India ·

I build mobile products and the systems behind them.

A great screen is the last 10% of the work. I spend my days on the other 90%.

See the workGet in touch

Illustrative site-audit form. Forms like it log site visits for ≈400 field users every day.

01 What I build

A mobile application is a system.

Mechatronics taught me that mechanics, electronics and code only work together. I read a mobile app the same way.

  1. Mobile productsInterfaces for real workflows.Dynamic forms and editable tables · Location-aware field workflows · Cross-platform interaction designLocation field
  2. Application architectureSystems that make the next feature cheaper.Component registry · Form and state architecture · 24 → 8 mobile layout systemMobile Grid & Canvas System
  3. PerformanceKeep heavy screens responsive.Virtualized long lists · Fast offline storage · Image and render optimizationRendering & offline storage
  4. Reliability & securityMake production behaviour explainable.Crash and breadcrumb investigation · Production monitoring · OWASP-mapped remediationVAPT remediation
  5. Platform & deliveryMove safely from commit to device.OTA delivery · React Native upgrades · Store and native build workflowsRelease & reliability
  6. Cloud & integrationsConnect the product to the world around it.API integration · Authentication flows · Push infrastructureSelected work
02 Selected work

Work I’m proud of.

Seven pieces of one large enterprise React Native app: what I built, why it was hard, and what I decided.

mobile-grid-system.caseArchitecture / Layout systems

Mobile Grid & Canvas System

A web layout should not have to be rebuilt to work on mobile.

DecisionTwo rendering paths over one: grid elements reflow into an 8-unit layout, while canvas cards keep their composition and either fit or scroll.

A mobile layout system that translates a web-first 24-unit grid into an 8-unit responsive grid with automatic row flow, plus separate Fit and Scroll rendering for canvas-like cards.

web grid to responsive mobile grid
24 → 8
fit or scroll for canvas-like cards
2 card modes
mobile-grid-system.case

01 / Architecture / Layout systems

Mobile Grid & Canvas System

A web layout should not have to be rebuilt to work on mobile.

Context

The product lets teams compose web layouts on a flexible 24-unit grid. Mobile consumes the same configuration, but has to interpret normal grid elements and canvas-like card components differently.

The problem

Normal elements need to become an 8-unit responsive layout that derives widths and automatically flows items across rows. Canvas-like cards are a separate problem: their positioned children form a composition that must either scale as a whole or remain scrollable.

Approach

  1. For normal elements, derive an 8-unit representation from the 24-unit source model and the available mobile width.

  2. Calculate each element’s mobile span, place it in the current row when it fits, and move it to the next row when it crosses the grid boundary.

  3. Adapt the row flow as available screen width changes without requiring a separately authored mobile layout.

  4. Treat canvas-like cards as a distinct rendering path because their children use controlled positions inside a composition.

  5. For a canvas card in Fit to Screen mode, calculate one scale from the available width and apply it to the complete internal composition.

  6. For a canvas card in Scroll mode, preserve the intended child dimensions and composition, then expose the overflow through a scrollable viewport.

What changed

  • Normal web-configured elements render as an automatic row-based mobile layout from the same source configuration.
  • Canvas-like cards preserve their internal composition through a dedicated Fit or Scroll strategy.
  • The two rendering paths solve different layout constraints without duplicating the complete layout definition for mobile.
  • 24 → 8 grid
  • Automatic row flow
  • Canvas composition
  • Card Fit / Scroll

24 → 8 web grid to responsive mobile grid

2 card modes fit or scroll for canvas-like cards

A

Standard mobile grid

Derived spans, then automatic row placement

responsive flow

Web configuration 24 units

A 9/24B 15/24C 18/24D 12/24
derive spanwidth + boundaryplace in row

Mobile layout 8 units

A 3/8B 5/8C 6/8D 4/8
  1. 0124-unit source
  2. 02derive mobile span
  3. 03check row boundary
  4. 04flow to next row
  5. 05render at screen width
B

Canvas-like card

Positioned children keep their internal composition

separate rendering path

Canvas card rendering only

Scale the complete composition

Canvas composition

ABC

Mobile viewport

complete composition visible
component-registry.caseArchitecture / Reusable systems

Component Registry

A new field type used to mean editing a giant switch. Now it means registering one component.

DecisionA lookup over branching: each component registers itself once, so the renderer no longer has to know which components exist in every context.

A self-registering registry that replaced a central conditional renderer: one rendering path for app mode, form mode and widgets. I proposed it, built it and led its adoption across the team.

files changed per new component
3 → 1
files migrated in the refactor
67
component-registry.case

02 / Architecture / Reusable systems

Component Registry

A new field type used to mean editing a giant switch. Now it means registering one component.

Context

The platform renders user-configured apps and forms, so the mobile client has to render many field and component types, in several different contexts.

The problem

Rendering decisions lived in one central renderer that knew too much: which components existed, which type mapped to which component, and how each context behaved. Every new component meant touching it, in every context.

Approach

  1. Introduce a self-registering registry that maps a type to its component. The lookup replaces the branching.

  2. Route app mode, form mode and widget rendering through the same registry, so a component is registered once and works everywhere it’s needed.

  3. Add an “Any Field” entry point: hand it a field definition and it renders whatever the registry resolves.

  4. Migrate the call sites across the codebase, then propose and lead the team-wide adoption.

What changed

  • Files touched per new component went from three to one.
  • One rendering path to test, debug and reason about.
  • App mode
  • Form mode
  • Widgets
  • Any Field

3 → 1 files changed per new component

67 files migrated in the refactor

Read the write-up ↗

Places to touch for a type: every context

AppRenderer.tsx

switch (field.type) {
  // 5 other cases…
  case 'date': return <DateField />
}

FormRenderer.tsx

switch (field.type) {
  // 5 other cases…
  case 'date': return <DateField />
}

WidgetRenderer.tsx

switch (field.type) {
  // 5 other cases…
  case 'date': return <DateField />
}

Simplified for clarity. The real refactor touched 67 files.

performance.casePerformance

Rendering & offline storage

The slowdowns show up exactly where users spend the most time.

DecisionTreat jank as several causes, not one: recycle list views, read storage synchronously, compress images, and batch input on large forms.

FlashList virtualization, MMKV storage and image compression across the heavy screens: long lists, large forms, image-laden records.

performance.case

03 / Performance

Rendering & offline storage

The slowdowns show up exactly where users spend the most time.

Context

Screens on a configurable platform get big: long lists, many live fields, images attached to records. The slowdowns show up exactly where users spend the most time.

The problem

Jank and slow storage rarely have one cause. Lists re-create views, images arrive heavier than they’re displayed, storage reads block, and high-frequency events trigger more rendering than the screen needs.

Approach

  1. Adopt FlashList for long lists, recycling views instead of creating new ones.

  2. Move offline storage to MMKV for fast synchronous reads and writes.

  3. Compress images to reduce payload and memory.

  4. Batch updates and debounce high-frequency input on large forms.

  • FlashList
  • MMKV
  • Image compression
  • Batching
vapt-remediation.caseSecurity / OWASP Mobile

VAPT remediation

A VAPT report is a list of findings. Each one has to become a change that ships.

DecisionRemediation inside normal delivery rather than as a separate project, with behaviour verified after each change, because every fix carries regression risk.

Turning a third-party VAPT report and a long Dependabot queue into shipped fixes: WebView hardening, dependency upgrades, secure configuration.

VAPT findings remediated
16+
Dependabot alerts resolved
200+
vapt-remediation.case

04 / Security / OWASP Mobile

VAPT remediation

A VAPT report is a list of findings. Each one has to become a change that ships.

Context

VAPT findings arrive as reports. Someone has to turn each one into a change that ships, without breaking the features that depend on the code being changed.

The problem

Findings span very different layers: JavaScript libraries with known vulnerabilities, native configuration, WebView settings and transitive dependencies. Each fix carries regression risk.

Approach

  1. Map findings to OWASP Mobile Top 10 categories and use MobSF for static analysis of the app.

  2. Remediate vulnerable dependencies and verify behaviour after each change.

  3. Review and harden WebView configuration.

  4. Tighten configuration as part of normal delivery, not as a separate project.

What changed

  • 16+ third-party VAPT findings remediated.
  • 200+ Dependabot security alerts resolved.
  • OWASP Mobile Top 10
  • MobSF
  • WebView
  • Dependencies

16+ VAPT findings remediated

200+ Dependabot alerts resolved

dynamic-forms.caseProduct / Complex UI

Dynamic forms & editable tables

A form is a state machine with a keyboard attached.

DecisionModel the whole chain explicitly (fields, rows, cells, focus, validation, state, payload), because each layer is simple alone and the hard part is keeping them consistent.

The mobile side of configuration-driven forms and editable tables: fields, rows and cells, through focus and validation, into state and finally the API payload.

dynamic-forms.case

05 / Product / Complex UI

Dynamic forms & editable tables

A form is a state machine with a keyboard attached.

Context

On a no-code platform, forms and tables are defined by configuration. The mobile app doesn’t know in advance which fields exist, how many rows there will be, or how they nest.

The problem

Each layer (fields, rows, cells, focus, validation, state, payload) is simple alone. The difficulty is keeping all of them consistent while a user types, tabs, adds rows and pages through a table on a small screen.

Approach

  1. Model the chain explicitly: fields → rows → cells → focus → validation → state → payload.

  2. Manage cell focus and keyboard navigation so moving through a table on a phone is predictable.

  3. Validate at field and row level, and keep nested state consistent as rows are added, edited and paginated.

  4. Serialise state into the exact payload the API expects. That is the last step, and the one everything else exists for.

  • Dynamic fields
  • Focus management
  • Validation
  • Payload shaping
  1. Fields
  2. Rows
  3. Cells
  4. Focus
  5. Validation
  6. State
  7. Payload
#Item textQty numberStatus select
1
2
3requiredrequired
Page 1 / 1

POST /records2 errors

{
  "form": "site-audit",
  "rows": [
    {
      "item": "Valves",
      "qty": 12,
      "status": "open"
    },
    {
      "item": "Fittings",
      "qty": 4,
      "status": "done"
    },
    {
      "item": "",
      "qty": null,
      "status": "open"
    }
  ],
  "valid": false
}

row 3 · item required (+1 more)

This one is real. Type in the table. Arrow keys and Enter move between rows.

release-reliability.caseRelease engineering / Reliability

Release & reliability

Shipping a fix shouldn’t take longer than finding it.

DecisionOTA updates for JavaScript-only fixes and store releases kept for native change, so a fix no longer waits on store review.

A Stallion-based OTA pipeline for same-day fixes, a two-build architecture that keeps internal testing out of production, and Sentry and Grafana to triage what users report.

production hotfix turnaround
Days → same day
separate bundle IDs, Firebase projects and OAuth clients
2 builds
release-reliability.case

06 / Release engineering / Reliability

Release & reliability

Shipping a fix shouldn’t take longer than finding it.

Context

A production app used by many people across many configurations. When something breaks, the report is usually “it doesn’t work”, and a store release is days away.

The problem

Fixes waited on store review. Internal test traffic mixed with production signal. Errors arrived without the trail that led to them.

Approach

  1. Build an OTA update pipeline on Stallion so JavaScript-only fixes ship the same day; keep store releases for native change.

  2. Split internal testing from production with two builds: separate bundle IDs, Firebase projects and OAuth clients.

  3. Configure Sentry per environment, with sampling and breadcrumbs that explain what the user actually did.

  4. Monitor Sentry and Grafana logs to triage user-reported issues.

What changed

  • Production hotfix turnaround went from days to same-day.
  • OTA (Stallion)
  • Two-build setup
  • Sentry
  • Grafana

Days → same day production hotfix turnaround

2 builds separate bundle IDs, Firebase projects and OAuth clients

  1. Application
  2. Events
  3. Breadcrumbs
  4. Transactions
  5. Errors
  6. Sentry
  7. Diagnosis
Sentry.init({
  dsn: DSN.production,
  environment: 'production',
  sampleRate: rates.production.errors,
  tracesSampleRate: rates.production.traces,
});
// real users: signal over volume

Breadcrumb trail

Illustrative trail and config. The decisions (environments, DSNs, sampling) are the real ones.

location-field.caseProduct / Field workflows

Location field

An address is a label. The coordinates are the value.

DecisionCoordinates as the durable value over the address, because an address can be missing or stale; the address is only the label resolved from them.

A production location field for dynamic mobile forms: address search, raw coordinates, a fixed-centre map picker and explicit offline, read-only and disabled states.

field users logging site visits each day
≈400
location-field.case

07 / Product / Field workflows

Location field

An address is a label. The coordinates are the value.

Context

Field workers use the mobile form builder to record site visits. The location field is part of a dynamic, configuration-driven form renderer used by roughly 400 people each day.

The problem

A location can arrive as an address, coordinates or a GPS reading. Addresses can be missing or stale, maps can be disabled or offline, and read-only data must still remain useful.

Approach

  1. Treat coordinates as the durable value and the address as a resolved label; keep coordinates visible whenever a location exists.

  2. Support address search and raw coordinate entry in one full-screen picker, with a fixed centre reticle for precise map selection.

  3. Keep coordinate entry usable when the map is disabled or tiles are unavailable, and explain the state instead of showing a broken map.

  4. Distinguish read-only from disabled: preserve useful actions and provenance for submitted values, while disabled fields explain why they cannot be changed.

  5. Cache static map snapshots by rounded latitude, longitude, zoom and size so long forms do not mount a live map for every field.

What changed

  • Shipped as a production workflow used by roughly 400 field users to log site visits each day.
  • react-native-maps
  • Google Places
  • Geocoding
  • Offline states

≈400 field users logging site visits each day

Supporting case studyPlatform / React Native

The React Native upgrade, one hop at a time.

Moving a large production app from 0.77 to 0.86 in controlled hops, and onto the New Architecture (Fabric / Turbo Modules), without a long-lived branch or a production incident.

DecisionIntermediate hops over one large jump, because a single jump puts every incompatibility on the table at once with no way to tell which change broke what.

in intermediate, verified hops
0.77 → 0.86
migration-related production incidents
0
rn-upgrade.case

CS / Platform / React Native

React Native upgrade

Changing the version is one line. Everything that depends on it is the project.

Context

A large, long-lived React Native codebase behind an enterprise no-code / low-code platform. Staying on older versions accumulates platform debt: OS requirements move, libraries drop support, native toolchains change underneath you.

The problem

A single large jump puts every incompatibility on the table at once: dependencies, native builds on both platforms, and behaviour changes, with no clear way to tell which change broke what.

Approach

  1. Upgrade incrementally through intermediate versions, so each hop has a small, explainable blast radius.

  2. Map dependency compatibility before each hop; upgrade or replace the libraries that block it.

  3. Work through native build issues on both platforms: Gradle and CMake configuration, native modules that fail to compile or link, and iOS-specific build changes.

  4. Preserve the existing architecture: the upgrade changes the platform, not how the app is structured.

  5. Verify Android and iOS at every hop, so the codebase stays releasable instead of living on a long-running branch.

What changed

  • Moved from 0.77 to 0.86 through verified intermediate hops.
  • Migrated to the New Architecture with zero migration-related production incidents.
  • Existing architecture preserved through the migration.
  • Incremental hops
  • Dependencies
  • Native builds
  • Android & iOS
  • New Architecture

0.77 → 0.86 in intermediate, verified hops

0 migration-related production incidents

Read the write-up
areavN+1vN+2vN+3target
Dependencies✓✓✓
Android build✓✓✓
iOS build✓✓
Native modules✓✓
JS API changes✓✓
Architecture✓✓✓✓

$ upgrade target - done

✓ dependencies: peer dependency conflict

✓ android build: Gradle / CMake configuration

✓ js api changes: deprecated API usage

✓ architecture: behaviour drift check

Open issues
0
Releasable
Yes, every hop

Illustrative model of the strategy. Areas are real, counts are not.

  1. 01

    Incremental strategy

    Intermediate versions instead of one jump: build, run the critical flows, fix, then move on.

  2. 02

    Dependency compatibility

    A compatibility map before every hop; libraries upgraded or replaced when they blocked it.

  3. 03

    Native build failures

    Gradle, CMake and linking errors worked through hop by hop, not all at once.

  4. 04

    Android and iOS

    Two platforms moving at different speeds, both verified at every step.

  5. 05

    Native modules

    Modules that stopped compiling or linking under new versions and Turbo Modules.

  6. 06

    Release risk

    The app stayed releasable at every hop, never frozen behind the migration.

03 Experience

From features to ownership.

Jan 2023 - Present

Software Engineer

Workhall · Coimbatore

The iOS and Android app of an enterprise no-code / low-code platform, from one React Native codebase.

  1. 01 Features

    Shipping product features across iOS and Android.

  2. 02 Systems

    Building the reusable pieces other features stand on.

  3. 03 Architecture

    Shaping how the app is structured, built and released.

  4. 04 Ownership

    Code quality, security remediation, reviews and hiring.

Scope today

  • React Native development
  • Mobile architecture
  • Performance
  • Security / VAPT
  • Release engineering & OTA
  • Observability
  • Code & solution-design reviews
  • Technical interviewing
04 Credentials

Trained, and certified.

Education2019 - 2023

9.42/ 10 CGPA

Department Rank Holder

B.E. Mechatronics Engineering

Thiagarajar College of Engineering, Madurai

  • AWS Certified Cloud PractitionerAmazon Web Services· 2024
  • Microsoft Azure FundamentalsMicrosoftAZ-900· 2025
  • Oracle Generative AI ProfessionalOracle· 2025
  • Oracle Multicloud ArchitectOracle· 2025
  • Google Data Analytics Professional CertificateGoogle· 2021
  • Google IT Support Professional CertificateGoogle
05 Side projects

Projects & open source.

Some shipped, some still being built, one running live on this page. Drag the windows around.Swipe through the bench.

bench / 8 items
iOS · Androidnpm / rn-rich-text-editorOpen source

rn-rich-text-editor

A rich text editor component for React Native, built on WebView: formatting, lists, headings, media, smart paste, read-only mode and keyboard handling.

  • Also authored react-native-geocodex (600+ downloads), lightweight geocoding and reverse geocoding on the OpenStreetMap API.

11,000+ downloads

  • React Native
  • WebView
  • Open source

npm GitHub

Rich text, natively in React Native. Smart paste keeps formatting.

npm i rn-rich-text-editor
CLIaudit-rn - zshCLI tool

v0.1 shipped

audit-rn

OWASP-mapped static analysis CLI for React Native security.

  • Three AST-based checks: M1 hardcoded secrets, M8 insecure WebView, M9 sensitive keys in AsyncStorage.
  • Built with @babel/parser and @babel/traverse.
  • TypeScript
  • Babel AST
  • OWASP Mobile
  • CLI

npx audit-rn ./src

3 findings · OWASP Mobile Top 10

src/api/client.tsM1

// TODO: move to envconst API_KEY = 'a7f3c9e1b2d84f06';

AST VariableDeclarator › StringLiteral

A secret compiled into the JS bundle can be pulled out of any install.

Example output on sample files.

iOS · Androidkalibr.appSide project

In development

Kalibr

A calm daily perception calibration app: 90 seconds a day.

  • Results shown as levels of blur, not scores. No leaderboards.
  • Randomised micro-tests (reaction, colour discrimination, focus, memory, contrast, wide focus) on a seeded RNG, so everyone shares the daily challenge.
  • Scored against your own baseline, not raw numbers: “Perception Weather”, from Sharp to Foggy.
  • A 30-day Fingerprint with drift detection.
  • React Native
  • Skia
  • Reanimated
Day 12+5%vs. your baseline

30-day Fingerprint · sample data · drag to scrub

iOS · Androidbloom.appSide project

In final development

Bloom

A privacy-first menstrual health tracker.

  • All processing on-device, no cloud accounts. Sensitive data stays local by design.
  • Cycle prediction, symptom and mood tracking, personalised insights.
  • React Native
  • Expo
  • On-device storage
Webrecycler.demoLive demo

Cell recycling, visualised

How FlashList-style lists stay fast: a thousand items, a handful of views. The badges are real. React reuses the same DOM nodes as you scroll.

  • Virtualization
  • Recycling
  • Performance
view 1Item #1
view 2Item #2
view 3Item #3
view 4Item #4
view 5Item #5
view 6Item #6
view 7Item #7
view 8Item #8
view 9Item #9
view 10Item #10
Items
1,000
Views mounted
10
Rebinds
0

Scroll the listScroll the page to move the list

Desktopnook - desktopSide project

Concept / early build

Nook

A desktop companion that gets you to take real breaks.

  • An animated avatar companion that lives near the taskbar.
  • Cinematic fullscreen break overlays and guided break activities.
  • Plant/pet gamification, ambient time-of-day and weather effects, rich sound design.
  • Spring animations and a calm palette.
  • Tauri 2
  • React
  • Desktop (Windows / macOS / Linux)
Weborbis - webSide project

Orbis

An interactive geography learning platform built around a 3D globe.

  • React
  • Three.js
Webhearth.appSide project

Hearth

A calendar for families, teams and friends: recurring events, drag-to-reschedule and an avatar showing who added each event.

  • React 19
  • TypeScript
  • Supabase
  • Also builtYouTube Educational FilterA Manifest V3 Chrome extension that filters YouTube down to educational and useful content.Chrome MV3 · JavaScript

06 / WritingCurated here · 10 in the archive

Writing

Notes on mobile engineering, with the occasional detour into AI. Published on Medium and in Stackademic, JavaScript in Plain English, AI in Plain English and Developers Global.

Follow on Medium

FeaturedEngineering / React Native

What 3 Years of React Native Taught Me That the Docs Never Will

OEM quirks, native modules, 16KB page sizes and locale-specific date crashes. Lessons from shipping production apps.

Three and a half years ago, I read the React Native docs top to bottom and thought I understood mobile development. I didn’t. What actually matters only reveals itself after your first production crash at 2 AM, your first furious enterprise client, and your first week debugging an issue that turned out to be a Samsung-specific OEM override.

17 May 20269 min readPublished in Stackademic

Read the article

Engineering notes4 of 10

  1. Engineering / React NativeThe React Native Upgrade I Didn’t Want to Do in One Shot0.77 to 0.86 as a series of controlled hops: third-party libraries, native build failures and the Android migration underneath.5 minin Stackademic Case: React Native upgrade
  2. ArchitectureFrom a Giant Switch to a Component Registry in React NativeWhen the renderer knows too much: moving component lookup out of one central switch.3 minin JavaScript in Plain English Case: Component Registry
  3. Platform / AndroidTarget API 36: The Android 16 Change That Caught Us by SurpriseThe Android 15 edge-to-edge opt-out was only ever a temporary escape hatch.3 minin Stackademic
  4. React Native / AIHello AI: Meet React NativeWiring ChatGPT into a React Native app: setup, use cases and what to watch out for.3 minin Stackademic

Older pieces cover AI and security.

View all 10 articles

07 / Contact

Have something worth building?

Open to conversations about mobile architecture and React Native work.