DEV Community: Yusuff Jokanola O.

Understanding OWASP M1 (2024): Improper Credential Usage in React Native/Expo and How to Mitigate It

Yusuff Jokanola O. — Fri, 31 Oct 2025 19:49:52 +0000

Improper Credential Usage (M1) tops the OWASP Mobile Top 10 (2024) because it hits the core of mobile security: protecting secrets and sensitive data. This vulnerability occurs when apps mishandle credentials — whether hardcoded API keys, tokens, or user authentication data — within insecure client environments.

For React Native and Expo developers, this issue is particularly severe. Since the JavaScript bundle ships with the app, anyone with basic reverse-engineering tools can easily peek into the source, exposing credentials you thought were “hidden.”

Let’s break down what this means for you — and how to fix it properly.

Understanding M1: The Risk of Client-Side Credential Exposure

Improper Credential Usage arises when developers treat the mobile client like a private backend. The problem? Your app code runs entirely on the user’s device, meaning anything embedded in it — even environment variables — can be extracted from the .apk or .ipa file.

Common M1 Scenarios

A. Hardcoded Application Secrets

These are non-user credentials that give wide access to your system:

Firebase Admin keys
Stripe secret keys
Private API keys
Database credentials

Many developers think .env files or libraries like react-native-dotenv keep secrets safe. They don’t. These variables are bundled into the final JS code — anyone with reverse-engineering tools can extract them in plain text.

B. Insecure Storage of User Credentials

On the other hand, storing sensitive user data (access tokens, refresh tokens, biometric keys, etc) in insecure storage like AsyncStorage makes it easily retrievable — especially on rooted or jailbroken devices.

Mitigation I: Protecting Application Secrets (Backend-for-Frontend Pattern)

Golden rule: Never embed app-level secrets in your mobile code.

The best solution is to isolate secrets using a Backend-for-Frontend (BFF) proxy or serverless orchestration layer.

Principle	Recommended Action
Architectural Isolation	Build a secure backend endpoint that your mobile app talks to. The backend makes the actual third-party API calls using stored credentials.
Serverless Ready	Use serverless functions (AWS Lambda, Google Cloud Functions, or Cloudflare Workers) for lightweight, scalable orchestration.
Secrets Management	Store sensitive keys in `AWS Secrets Manager`, `Google Secret Manager`, or encrypted environment variables — never in the app.
Client Update	Change your React Native code to call your secure proxy instead of external APIs directly.

This ensures your app remains a “dumb client,” relying on your backend for anything that needs secret keys.

Mitigation II: Protecting User Credentials (Expo SecureStore)

When user credentials must live on the device (like tokens for login sessions), they should be stored using hardware-backed secure storage, not in plain JS-accessible stores like AsyncStorage.

✅ Recommended Tool: `expo-secure-store`

Expo SecureStore is a unified interface over native OS storage systems — Keychain Services (iOS) and Android Keystore. These systems are designed by Apple and Google to safely store small bits of sensitive data like passwords, tokens, and encryption keys.

Platform	Underlying System	Description
iOS	Keychain Services	Data is stored in the device’s Secure Enclave — a hardware chip isolated from the OS. It requires user authentication (Face ID, Touch ID, or passcode) before access.
Android	Android Keystore System	Credentials are stored in an isolated keystore. Private keys never leave this secure hardware zone; even the app can’t read them directly. Data is encrypted with AES before being persisted.

📱 Example Implementation

import * as SecureStore from 'expo-secure-store';

// Save user token securely
async function saveUserToken(token) {
  await SecureStore.setItemAsync('userToken', token);
}

// Retrieve stored token
async function getUserToken() {
  return await SecureStore.getItemAsync('userToken');
}

This ensures your sensitive data lives in encrypted, OS-managed storage — not in plain JS memory or AsyncStorage. Learn more for detailed implementation

How Expo SecureStore Works with Keychain & Keystore

Behind the scenes:

On iOS, expo-secure-store communicates with the Keychain API, which stores your key-value pair inside the Secure Enclave chip. The OS encrypts it with a device-specific key, ensuring only your app (or authenticated user) can access it.
On Android, it interacts with the Keystore System, where a master key is generated inside the Trusted Execution Environment (TEE). This master key encrypts your stored values. Even if the device is compromised, attackers cannot export these keys.

This native integration means data is not only encrypted but hardware-isolated.

Final Thoughts

Improper Credential Usage (M1) isn’t just about bad code — it’s about architectural decisions. Every time a secret key or token sits in your mobile code, you’re one decompilation away from a breach.

TL;DR for React Native/Expo developers:

❌ Never hardcode secrets or rely on .env in the app.
✅ Route API calls through a secure backend proxy.
❌ Don’t use AsyncStorage for tokens.
✅ Use expo-secure-store or react-native-keychain to leverage native OS secure storage.

Securing credentials isn’t just a best practice — it’s what separates a secure app from a data breach headline.

Zero-Downtime Deployment: Master Over-the-Air (OTA) Updates in Expo React Native

Yusuff Jokanola O. — Fri, 24 Oct 2025 13:41:27 +0000

Have you ever wondered why web developers can push code changes and users see them instantly—yet in mobile apps, even a tiny text fix can take days waiting for Apple or Google’s approval? Every React Native developer has faced that frustration, especially when production bugs sneak in right after release.

That’s where Over-the-Air (OTA) updates come in. In simple terms, OTA updates let you deliver new JavaScript code, images, and other assets directly to users’ devices—without going through the app store review process. It’s like refreshing a web page, but for your mobile app. With Expo’s EAS Updates, this process becomes seamless, secure, and fully integrated into your deployment workflow.

In this guide, you’ll learn how to set up and use EAS Updates for your Expo React Native project, following a clear, step-by-step approach. By the end, you’ll be able to ship updates instantly, fix issues in minutes, and make deployment virtually painless.

Prerequisites

Before diving in, make sure you have the following essentials ready:

An Existing Expo Project: Your project must be configured to use EAS (Expo Application Services).
EAS CLI Installed: You need the EAS command-line tool.
```
npm install -g eas-cli
```
An Initial Native Build: A crucial point—OTA updates can only be pushed to an app that was originally built using eas build. You must have a native binary (.ipa or .apk) installed on your test devices or available to your users.
Expo Account: Logged in via the CLI (eas login).

Step 1: Configure Your Project for Updates

EAS takes care of much of the heavy lifting, but we need to ensure the configuration is explicit, especially regarding channels. Channels are how you target updates to different environments (e.g., preview, development, production).
To initialize EAS Update configuration run

eas update:configure

This command will update your app.config.js (or app.json) file with the runtimeVersion and updates.url properties.

1.1 Configure the update channel

The channel property on a build allows you to point updates at specific types of builds. For example, it allows you to publish updates to a preview build without impacting your production deployment.

If you are using EAS Build, eas update:configure will set the update channel property on the preview and production profiles in eas.json. Set them manually if you use different profile names.

// eas.json

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "environment": "development",
      "channel": "development"
    },
    "preview": {
      "distribution": "internal",
      "environment": "preview",
      "channel": "preview"
    },
    "production": {
      "environment": "production",
      "channel": "production"
    }
  }
}

Step 2: Integrate `expo-updates` (Optional but Recommended)

While Expo handles automatic updates in the background, you might want to add a user interface (UI) to check for and apply updates immediately. This is particularly useful in development or for critical fixes.

2.1 Install the Module

If it's not already installed, add the official updates module:

npx expo install expo-updates

2.2 Manually Check for Updates (Optional)

You can create a custom hook or function to check for updates when the app starts. This example shows how to use the useUpdates() hook in a functional component.

import { StatusBar } from 'expo-status-bar';
import * as Updates from 'expo-updates';
import { useEffect } from 'react';
import { Button, Text, View } from 'react-native';

export default function UpdatesDemo() {
  const {
    currentlyRunning,
    isUpdateAvailable,
    isUpdatePending
  } = Updates.useUpdates();

  useEffect(() => {
    if (isUpdatePending) {
      // Update has successfully downloaded; apply it now
      Updates.reloadAsync();
    }
  }, [isUpdatePending]);

  // If true, we show the button to download and run the update
  const showDownloadButton = isUpdateAvailable;

  // Show whether or not we are running embedded code or an update
  const runTypeMessage = currentlyRunning.isEmbeddedLaunch
    ? 'This app is running from built-in code'
    : 'This app is running an update';

  return (
    <View style={styles.container}>
      <Text style={styles.headerText}>Updates Demo</Text>
      <Text>{runTypeMessage}</Text>
      <Button onPress={() => Updates.checkForUpdateAsync()} title="Check manually for updates" />
      {showDownloadButton ? (
        <Button onPress={() => Updates.fetchUpdateAsync()} title="Download and run update" />
      ) : null}
      <StatusBar style="auto" />
    </View>
  );
}

Step 3: Build and Distribute the Native Container

Remember, OTA updates only change JavaScript and assets. If you change native code (e.g., add a new library or modify Podfile), you must create a new native build (.apk or .ipa).

Use the eas build command to create the initial app binary that contains the necessary update configuration.

# Build a preview binary for iOS
eas build --profile preview --platform ios
# Build a preview binary for Android
eas build --profile preview --platform android

Once this build is installed on the device, you are ready for the magic of instant updates.

Step 4: Publishing Your First OTA Update

Now for the moment of truth. You've fixed a typo, adjusted a style, or added a new feature that doesn't involve native module changes.

Instead of running a full, time-consuming native build, you run a single command: eas update.

4.1 The Command

Use the --channel flag to target the specific channel defined in your eas.json (e.g., preview). remember will build for preview that is the reason where pushing to OTA to preview if you're pushing for production you will use production

# Deploy a new update to all users with the preview binary installed on android
eas update --channel preview --platform android --message "Fixing that embarrassing typo on the homepage. 😅"

# Deploy a new update to all users with the production binary installed on ios
eas update --channel production --platform ios --message "Fixing that embarrassing typo on the homepage. 😅"

4.2 What Happens Next?

Bundling: EAS bundles your latest JavaScript and static assets.
Upload: The bundle is uploaded to the Expo CDN (Content Delivery Network).
Assignment: The update is assigned to the specified branch (preview or production).
Deployment: When a user opens their existing app, it checks the EAS Update server, downloads the new JavaScript bundle in the background, and applies it upon the next app restart or manually via your expo-updates implementation.

Step 5: Testing the Deployed Update

To confirm your update works:

Make a Visible Change: Change a simple Text component in your app (e.g., change "Welcome" to "Welcome Back!").
Publish the Update: Run the eas update command from Step 4.
Test:
- Open your app on the device that has the native build from Step 3.
- Crucial: Close the app completely (kill it from the task switcher) and re-open it.
- You should see your new change instantly, without downloading anything from the App Store or installing !

Final Thoughts

Adopting EAS Updates transforms your deployment workflow. No longer are you beholden to slow review processes for minor fixes. You gain speed, agility, and a much better user experience by instantly delivering improvements.

While the freedom is great, remember: any change to native code still requires a full eas build and an App Store submission. For everything else—JS, assets, business logic—eas update is your new best friend! Happy instant deploying! 🎉

Improving Binary Security in Mobile Application: A Deep Dive into Obfuscation

Yusuff Jokanola O. — Fri, 17 Oct 2025 21:13:23 +0000

Introduction

Mobile applications increasingly serve as the gateway to critical business operations, making them high-value targets for reverse engineering and code tampering. This threat is formally recognized in the OWASP Mobile Top 10 (2024) risks. This category highlights M7: Insufficient Binary Protection enable attackers to extract secrets, reverse engineer proprietary logic, and repackage apps for malicious use.

In the context of React Native, this threat is especially relevant because the application’s core logic is bundled in JavaScript and then compiled into Hermes bytecode for performance optimization. While the use of Hermes offers a foundational layer of obfuscation through bytecode compilation, it is not a foolproof defense. Its output can still be decompiled or analyzed by determined adversaries (though advanced analysis techniques are beyond the scope of this article). Crucially, React Native apps also include several native files (Java/Kotlin on Android) and metadata that can reveal insights about the app’s internal structure, such as all the third-party packages in use. This information, when combined with the decompiled Hermes bytecode, can help attackers better understand the app’s architecture, identify potential weaknesses, and target specific vulnerabilities.

In this article, we’ll explore how Android reverse engineering affects React Native applications, why it remains a top-tier security concern, and outline key mitigation strategies—with a focus on implementing code obfuscation as an essential defense layer.

Prerequisites for Analysis

To practically understand and test the security posture of your application against reverse engineering, you must have the production-ready Android Package Kit (APK) file.

For React Native (Bare Workflow)

You will typically generate the APK directly using Android Studio or the command line.

For Expo (Managed Workflow)

The .apk file is produced after a release build (eas build --platform android). If you receive an Android App Bundle (.aab) file from your build service or Google Play Console, you must use the Google-provided bundletool to extract a Universal or device-specific .apk for analysis.

bundletool can be used to Converts .aab to .apk files for testing.

How Attackers/CyberSecurity Analyst Decompile Your App

Disclaimer: This section is for educational purposes only, intended to help developers understand and mitigate attack vectors. The techniques described are mimic standard practices used by security analysts and penetration testers to assess application security.

The standard process for reverse engineering an Android application involves several key steps, primarily centered around a tool called Apktool.

The Decompilation Process

Apktool is the go-to utility for unpacking and repacking Android APKs. It extracts the resources and decompiles the compiled code into a more readable format called Smali.

APK Acquisition: The attacker obtains the APK from an app store or directly from a compromised device.

Decompilation Command: After installing apktool run below command in your preferred terminal

Apktool Installation

apktool d app-release.apk

This creates a new directory containing the decompiled files.

Code Inspection: The attacker then navigates and analyzes the resulting files, which include the app's native code and resource structure.

Anatomy of a Decompiled App (Before Obfuscation)

In an unprotected (or minimally protected) React Native or Expo application, the directory structure and file contents offer clear signposts to an attacker.

Example Decompiled app directory

smali/ directory Contains .smali files, which are a human-readable assembly-like language derived from the app's native Java/Kotlin bytecode. Proprietary Logic: Function names, variable names, class structures, and API endpoint references are often intact and descriptive as shown in the image above.

How to Improve Obfuscation in Expo Apps

For React Native apps, particularly those built with the Expo Managed Workflow, you can leverage the powerful built-in tooling for advanced binary protection. The key is to enable and fine-tune ProGuard (or R8, the modern equivalent) through the expo-build-properties plugin in your app.json or app.config.js.

Configuration Steps

By default, Expo enables basic resource shrinking. For stronger protection, you must explicitly enable code obfuscation and resource compression for release builds, you can customize your app.config.js or app.json, by add expo-build-properties in your plugins

[
  "expo-build-properties",
  {
    "android": {
      // 1. **Crucial:** Enables R8/ProGuard for code obfuscation and shrinking.
      "enableProguardInReleaseBuilds": true,

      // 2. Optimizes the size of the final APK by compressing bundled assets.
      "enableBundleCompression": true, 

      // 3. Removes unused resources (like images or unused strings) to shrink size.
      "enableShrinkResourcesInReleaseBuilds": true,

      // 4. Advanced: Allows custom ProGuard rules for fine-tuning obfuscation.
      "extraProguardRules": "-dontwarn com.squareup.okhttp3.**\n-keep class com.myapp.secure.** { *; }"
    }
  }
],

Implementing extraProguardRules
The extraProguardRules property is powerful for fine-tuning the
protection: You can write specific rules to further obfuscate proprietary code or to prevent obfuscation on specific native modules that rely on introspection (reflection) to function correctly.

Best Practice: Always use a -keep rule for classes that are accessed dynamically (e.g., via reflection, JNI, or third-party SDKs) to prevent R8/ProGuard from renaming or stripping them, which would cause runtime crashes.

Anatomy of a Decompiled App (After Obfuscation)

After implementing robust obfuscation, the same directories and files become significantly less useful to the attacker, drastically increasing the time and effort required for reverse engineering.

Directory/File Post-Obfuscation State Impact on Attacker
smali/ directory File and function names are replaced with meaningless, single-letter or short, randomized strings (e.g., a1.smali, b.smali).
Deterrence: The attacker loses context. A file named a.smali provides no clues about its function, forcing manual, tedious analysis of the bytecode's flow and content.

NB
⚠️ Warning and Testing: You must thoroughly test your application after enabling or tightening obfuscation. Since some native packages (especially those using reflection) may be affected by renamed classes, rigorous regression testing across all functionalities is non-negotiable before deploying the secure build.

Final Thoughts

While basic, default obfuscation provides a minimal barrier, it may not deter a determined attacker targeting a high-value application. As the threat landscape evolves, and with attackers increasingly leveraging Large Language Models (LLMs) to accelerate the decoding of default binary encoding provided by frameworks, developers must respond with sufficient binary protection.

Obfuscation is a layer of defense, not a complete solution. When combined with other critical controls—such as Root/Jailbreak Detection, Runtime Application Self-Protection (RASP), Certificate Pinning, and proper Secret Management—a comprehensive strategy will significantly increase the cost and effort required for a successful reverse engineering attack, stretching the attacker's resources to their limit. For serious, commercially-sensitive projects, insufficient binary protection is a risk you simply cannot afford.

How to Prioritize Product Development: A Practical Guide for Startups and Beyond

Yusuff Jokanola O. — Mon, 22 Sep 2025 22:24:20 +0000

When it comes to product development, many teams—whether product managers, engineers, or even stakeholders—tend to get caught up in the excitement of new features. A feature may sound fantastic on paper, or research may suggest it could be a game-changer. Teams often rally behind these ideas with great enthusiasm. But here’s the critical question:

👉 Is that exciting feature really worth prioritizing over everything else?

This is where many organizations stumble. Bugs pile up, timelines stretch thin, and the “next big thing” in the backlog steals attention from what truly matters. In large corporations with deep pockets, chasing the wrong features might not be fatal. But in the startup world, burning cash on low-impact features is one of the fastest ways to fail.

So, how do effective leaders consistently make the right calls when it comes to prioritization?

The Myth: Customers Always Know What They Want

A common argument is to simply “listen to the customer.” And yes, customers are central—you’re building for them. But here’s the nuance: customers often don’t fully know what they want.

Imagine this scenario:

One customer requests five features.
With 100 customers, you might find only a 40% overlap.
That leaves you with 300 unique feature requests.

Not only is it impossible to build all of them, but many of these features will be used sparingly—maybe once every three months. Should you really burn resources on that?

The answer lies in a more systematic approach.

The Value-Cost Sieve: A Smarter Way to Prioritize

One powerful framework is the Value-Cost Sieve. Instead of chasing every shiny new feature, you categorize work into four buckets:

High-Value, Low-Cost

These are quick wins. They provide significant impact with minimal effort.
Example: Improving onboarding flow to reduce drop-offs.

High-Value, High-Cost

Strategic investments. They’re resource-heavy but deliver long-term gains.
Example: Building a recommendation engine that significantly boosts engagement.

Low-Value, Low-Cost

Consider only if resources allow. These may enhance UX or delight niche users but won’t move the needle.
Example: Adding cosmetic theme options.

Low-Value, High-Cost

Avoid at all costs. These are distractions disguised as opportunities.
Example: Building complex integrations that serve only a handful of customers.

By running every idea through this sieve, leaders can quickly filter noise and focus on features that align with both customer needs and business goals.

Why This Matters More in Startups

For established corporations, experimenting with features—even ones with low impact—rarely threatens survival. They have the budgets and buffers.

Startups, however, operate under tight constraints. Every sprint, every dollar, and every engineer’s hour needs to be maximized. Misplaced priorities can mean the difference between survival and shutdown.

Effective leaders know this instinctively. They ruthlessly eliminate distractions and guide their teams toward what creates real, compounding value.

Key Takeaway

Prioritization is not about rejecting ideas—it’s about systematically filtering them. By applying frameworks like the Value-Cost Sieve, you’ll:

Deliver what truly matters to customers.
Save time and money.
Keep your product roadmap focused and impactful.

The best leaders aren’t the ones who say “yes” to every exciting idea. They’re the ones who know what to say “no” to.

React Native CLI vs Expo CLI: Clearing Up Misconceptions

Yusuff Jokanola O. — Thu, 18 Sep 2025 11:04:16 +0000

When building mobile apps with React Native, one of the earliest choices developers face is whether to use Expo CLI or the bare React Native CLI workflow. For years, Expo carried the reputation of being a tool only good for prototypes, MVPs, or simple apps—while React Native CLI was considered the “serious” option for production.

That landscape has changed. Today, Expo has evolved into the recommended default for production apps, and many of the previous limitations no longer apply. But we still see people writing about this limitation till today, and even if you ask LLM like ChatGPT with React Native CLI vs Expo CLI it will still bring the same old limitation, which is why most people still include it in their article because the most likely generated part of their articles without their own personal experience input.

Let’s look at the current reality of the ecosystem.

1. Expo CLI: Then vs Now

Old perception: Expo was limited—you could only use what the Expo SDK provided, and if you needed custom native code, your only path forward was “ejecting” into a bare React Native workflow.

Now: The eject option has been deprecated and replaced with expo prebuild, which generates the same native projects (Xcode/Android Studio) you’d get with React Native CLI. From there, you can:

Add custom native modules.
Modify iOS and Android projects directly.
Still use Expo’s managed features like OTA updates, EAS builds, and the Expo SDK.

This means Expo offers up to 95% of the flexibility of bare React Native, with additional tooling that makes development and maintenance easier.

2. Bare React Native CLI: Where It Stands

Using React Native CLI directly gives you full control from day one:

You configure Gradle and CocoaPods manually.
You install and link all libraries yourself.
You manage upgrades manually (which can be painful for large projects).

While this offers maximum freedom, it also introduces overhead. You become responsible for CI/CD pipelines, OTA update solutions, and navigating complex upgrades. For apps with extremely specialized native requirements, this control is valuable—but for most teams, the tradeoff is high.

3. Advantages of Expo Beyond Development Speed

Expo isn’t just about fast prototyping anymore. It also brings post-development benefits that make it a strong choice for production apps:

Smoother upgrades: Expo maintains compatibility across the ecosystem, so upgrading React Native versions is often significantly easier than in bare projects.
EAS (Expo Application Services): Provides managed CI/CD pipelines, cloud builds, and app store submission without manual configuration.
OTA (Over-the-Air) updates: Ship instant fixes and feature updates without going through the app store review process. (While CodePush offered similar benefits, it has been deprecated, leaving Expo’s OTA as the modern solution.)
Rich SDK: Camera, notifications, sensors, biometrics, and more—all maintained and tested to work with React Native’s latest versions.

4. Official Recommendation

The React Native documentation itself now recommends starting with Expo for new projects:

“Yes. You can use React Native without a Framework. However, if you’re building a new app with React Native, we recommend using a Framework.

In short, you’ll be able to spend time writing your app instead of writing an entire Framework yourself in addition to your app.”
— React Native Docs: Environment Setup

The only time you should reach for bare React Native CLI from the start is if:

You already know Expo’s tooling won’t fit your project needs.
You have a strong team with the expertise and resources to maintain a fully custom setup.

For most developers and teams, Expo should be the default choice.

5. TL;DR

Expo is no longer just for prototypes—it’s fully production-ready.
Ejecting is gone; replaced by expo prebuild, which provides nearly the same flexibility as bare React Native.
Expo offers significant long-term benefits like easier upgrades, EAS, and OTA updates.
The React Native team recommends Expo as the default starting point for production apps.

Unless Expo’s solutions don’t meet your needs—and you’re ready to take on the complexity of maintaining everything yourself—you should start with Expo.

✅ Final Thoughts
The old “Expo vs React Native CLI” debate is outdated. Today, Expo is the recommended production pathway, and the limitations that once justified avoiding it are mostly gone.

Automating Expo Android Submission to Play Store Console with EAS Using GitHub Actions: A Step-by-Step Guide.

Yusuff Jokanola O. — Sun, 16 Feb 2025 11:22:34 +0000

Building and deploying an Android app can often be a repetitive and time-consuming task. Automating the submission process using GitHub Actions streamlines development workflows, reduces manual errors, and ensures consistent app releases. If you’re using Expo to develop your Android app, you’re in luck – Expo provides tools that integrate seamlessly with CI/CD pipelines.

In this guide, we’ll walk through setting up a GitHub Actions workflow to automate the submission of your Expo Android app.

To make sense of the post you may need to read my previous post Automate Your Expo Builds with EAS Using GitHub Actions: A Step-by-Step Guide (Android)

Prerequisites

React Native project
Must have created your first build How to create your first build
Must have submitted your android app first time How to submit expo app to stores

Step 1: Define Your GitHub Actions Workflow to build the app
Create a GitHub Actions workflow file in your repository at .github/workflows/android-submission.yml and paste the code below. If you’ve read the previous post, your workflow file should look similar to this. This code builds the .aab file for submission.

name: Android App Build

on:
  push:
    branches:
      - staging
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Setup repo
        uses: actions/checkout@v4

      - name: Setup node
        uses: actions/setup-node@v3
        with:
          node-version: 20.x
          cache: "npm"

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: "17"
          distribution: "temurin"

      - name: Setup Android SDK
        uses: android-actions/setup-android@v3

      - name: Setup Expo
        uses: expo/expo-github-action@v8
        with:
          expo-version: latest
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}

      - name: Install dependencies
        run: yarn install --frozen-lockfile

      - name: Build Android app
        run: eas build --platform android --profile production --local --output ${{ github.workspace }}/app-release.aab

NB:
If you notice, the key change from the previous article is the replacement of preview with production in the --profile setting. This means we’re now building for production instead of testing. For more details on configuring profiles Configure EAS Build with eas.json.

Step 2: Submitting the app
The command below should look familiar if you’ve submitted an Android app with Expo via the terminal. It takes the app you previously built and submits it directly to the store.

 - name: Submit to Google Play
        run: |
          eas submit -p android --profile production --path ${{ github.workspace }}/app-release.aab --non-interactive

Step 3: Test the Workflow

Push your changes to the staging (or specific branch you put in workflow) branch to trigger the workflow. Monitor the Actions tab in your GitHub repository to ensure the steps execute successfully. If the submission succeeds, your app will be uploaded to the Google Play Console and you should see it in your internal test.

Tips and Best Practices

Versioning: Ensure your version and versionCode in app.json or app.config.js are updated automatically using scripts or manual steps learn more.
Testing: Run unit, integration tests or e2e test before submitting ensure app stability learn more.

Thanks for reading till the end.

Next time, I'll cover automating build and submission of iOS app to the Apple store respectively. Stay tuned!!!.

Automate Your Expo Builds with EAS Using GitHub Actions: A Step-by-Step Guide (Android)

Yusuff Jokanola O. — Sun, 07 Jul 2024 20:55:40 +0000

Developers get 30 free builds each month (up to 15 iOS builds) with EAS Build. While this seems much at first glance, it can be quickly exhausted in a serious hobby project, let alone a professional environment.

Additionally, the queue for builds can be very long, sometimes taking up to 90 minutes or more before starting.

This wait can be problematic if you need to fix high-severity or security issues urgently. Local builds (--local) are an alternative, but the process is repetitive and unavailable to Windows users.

In this article, we will cover how to avoid these issues efficiently using GitHub Actions.

Prerequisites

React Native project
Must have created your first build Create your first build
An Expo user account

Step 1: Setup your project

Ensure you have your Expo project set up and configured for EAS Build. If not, you can check expo docs On creating your first build

Step 2: Get your Expo access token

You can generate expo tokens that will allow github action to access your account on your behalf. learn more

Step 3: Save this token to GitHub Secrets

In your GitHub repository, navigate to Settings > Secrets and variables > Actions and add the following secrets:

EXPO_TOKEN: your expo access token generated in step 2

Step 4: Create a New Workflow File
In your GitHub repository or locally, create a new directory .github/workflows and add a file named build-apk.yml (you can name this file whatever you want and in my case I created the file inside staging branch).

Enter your workflow name and trigger

name: Build APK with EAS

on:
  push:
    branches:
      - staging

NB:
You may not understand the above code but what you need to understand is the workflow runs when code is pushed to the branch name staging, you can replace it with a different branch.
Learn more about workflows.

Jobs and Steps
Below code specifies the type of virtual machine to run the job: which is ubuntu-latest. you can specify macos-latest when building for iOS.

jobs:
  build:
    runs-on: ubuntu-latest

Steps Within the Job
This code is essential to get the code into the virtual machine.

steps:
      - name: Setup repo
        uses: actions/checkout@v4

Setup node
Uses a pre-built action to set up a Node.js environment

      - name: Setup node
        uses: actions/setup-node@v3
        with:
          node-version: 20.x
          cache: "npm"

Set up JDK 17
Uses a pre-built action to set up a Java environment

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: "17"
          distribution: "temurin"

Setup Android SDK
Uses a pre-built action to install and set Android SDK

  - name: Setup Android SDK
        uses: android-actions/setup-android@v3

Setup Expo
Uses a pre-built action to set up Expo

 - name: Setup Expo
        uses: expo/expo-github-action@v8
        with:
          expo-version: latest
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}

NB: You must save EXPO_TOKEN to Github secret you can go back to step 2 & 3 if you have not.

Install project depencies

 - name: Install dependencies
        run: yarn install --frozen-lockfile

Build Android App

  - name: Build Android app
        run: eas build --platform android --profile preview --local --output ${{ github.workspace }}/app-release.apk

Upload Build Artifact

      - name: Upload Build Artifact
        uses: actions/upload-artifact@v2
        with:
          name: app-release
          path: ${{ github.workspace }}/app-release.apk

Your build-apk.yml should have below content by now, make changes to your code and push to github.

name: Android App APK Build

on:
  push:
    branches:
      - new-features
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Setup repo
        uses: actions/checkout@v4

      - name: Setup node
        uses: actions/setup-node@v3
        with:
          node-version: 20.x
          cache: "npm"

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: "17"
          distribution: "temurin"

      - name: Setup Android SDK
        uses: android-actions/setup-android@v3

      - name: Setup Expo
        uses: expo/expo-github-action@v8
        with:
          expo-version: latest
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}

      - name: Install dependencies
        run: yarn install --frozen-lockfile

      - name: Build Android app
        run: eas build --platform android --profile preview --local --output ${{ github.workspace }}/app-release.apk
      - name: Upload APK artifact
        uses: actions/upload-artifact@v2
        with:
          name: app-release
          path: ${{ github.workspace }}/app-release.apk

You can download the Artifact (build file apk or aab) in the job detail's page.

NB: For medium or large-sized companies, it is advisable to use the Production or Enterprise subscription, as it includes many additional features that cater to their needs.

Final Thoughts

Employing GitHub Actions for building my projects has saved me a lot of time. Previously, I could only create 2-3 builds per day. Now, I can generate unlimited builds, eliminating repetitive and boring tasks from my workflow. This allows me to focus on what truly matters: building my project.

Thanks for reading till the end.

Next time, I'll cover automating builds and submission of android and iOS to the Play Store and Apple store respectively. Stay tuned!!!

How to convert existing nodejs/expressjs app from javascript to typescript, the painless way

Yusuff Jokanola O. — Sun, 10 Mar 2024 19:28:20 +0000

Converting a large Express.js application from JavaScript to TypeScript can be a challenging task. For many applications, this represents a significant portion of their technical debt, as the process may span many days, if not months, and new changes are typically not allowed during the conversion.

Imagine having to implement new features or hotfixes in such an application; it can be exceedingly difficult to keep up with ongoing changes during the conversion.

This is one of the primary reasons developers often hesitate to convert an extensive Express.js application from JavaScript to TypeScript.

In this article, we will explore the fastest and least disruptive way to convert a mid to large Express.js application from JavaScript to TypeScript.

Prerequisites

Nodejs ≥ v16.4.0 installed on your machine
Basic Understanding of javascript, typescript, nodejs/expressjs
Having expressjs application writing in javascript

Setup your expressjs application

clone the application and navigate to the root directory

git clone https://github.com/codateam/your-repo-name.git
cd your-repo-name

Javascript files before converted to typescript

Create bash script to automate file convertion from .js to .ts

Rename javascript to typescript file one by one main be boring and time consuming, especially in medium or large application with tons of files, automating the process will save a lot of time.

Create a bash script file convert-js-to-ts.sh in the root of your application and update with below code, you can read about bashs script if you aren't familiar or read about about BASH - Automatically rename file as its folder

#!/bin/bash

# Function to rename JavaScript files to TypeScript
rename_js_to_ts() {
  for file in "$1"/*.js; do
    if [ -e "$file" ]; then
      new_file="${file%.js}.ts"
      mv "$file" "$new_file"
      echo "Renamed $file to $new_file"
    fi
  done

  # Recursively process subdirectories, excluding node_modules
  for dir in "$1"/*; do
    if [ -d "$dir" ] && [ "${dir##*/}" != "node_modules" ]; then
      rename_js_to_ts "$dir"
    fi
  done
}

# Check if a directory is provided as an argument
if [ -z "$1" ]; then
  echo "Usage: $0 <directory>"
  exit 1
fi

# Check if the provided path is a directory
if [ ! -d "$1" ]; then
  echo "Error: '$1' is not a directory."
  exit 1
fi

# Call the function to rename files
rename_js_to_ts "$1"

Remember to make this script executable by executing the below command in your terminal.

chmod +x convert-js-to-ts.sh

Execute the script in your commandline

./convert-js-to-ts.sh .

Typescript files after convertion

Installing required typescript dependencies

Below are the typescript required for my project (yours maybe different).

yarn add -D typescript ts-node @types/node @types/express @types/mongoose @types/multer @types/passport @types/passport-jwt @types/passport-local @types/passport-local-mongoose @types/socket.io @types/winston

Generating tsconfig.json by enter below command in your terminal

npx tsc --init

Modify your tsconfig.json file

 {
  "compilerOptions": {
    ...
    "outDir": "./dist"
    ...
  }
}

remove .js from all your import code search .js" and click on replace " in vscode or your preferred editor

Running TypeScript in Node with ts-node

npx ts-node src/index.ts

if you're unable to get it work with ts-node you can using concurrently,

package.json

...
 "scripts": {
   "start": "node dist/server",
   "dev": "concurrently \"npx tsc --watch\" \"nodemon -q dist/server.js\""
  },
...

Start your application

yarn run dev

NB: The project can be deployed when you're still fixing types errors and new features can be implemented in typescript

Final Thoughts

Converting a large Express.js application to TypeScript is a significant undertaking, but with proper planning and automation, you can streamline the process.

Keep in mind that each project is unique, so adapt the steps and script to fit your specific requirements.

Thanks for reading.

DEV Community: Yusuff Jokanola O.

Understanding OWASP M1 (2024): Improper Credential Usage in React Native/Expo and How to Mitigate It

Understanding M1: The Risk of Client-Side Credential Exposure

Common M1 Scenarios

A. Hardcoded Application Secrets

B. Insecure Storage of User Credentials

Mitigation I: Protecting Application Secrets (Backend-for-Frontend Pattern)

Mitigation II: Protecting User Credentials (Expo SecureStore)

✅ Recommended Tool: expo-secure-store

📱 Example Implementation

How Expo SecureStore Works with Keychain & Keystore

Final Thoughts

TL;DR for React Native/Expo developers:

Zero-Downtime Deployment: Master Over-the-Air (OTA) Updates in Expo React Native

Prerequisites

Step 1: Configure Your Project for Updates

1.1 Configure the update channel

Step 2: Integrate expo-updates (Optional but Recommended)

2.1 Install the Module

2.2 Manually Check for Updates (Optional)

Step 3: Build and Distribute the Native Container

Step 4: Publishing Your First OTA Update

4.1 The Command

4.2 What Happens Next?

Step 5: Testing the Deployed Update

Final Thoughts

Improving Binary Security in Mobile Application: A Deep Dive into Obfuscation

Introduction

Prerequisites for Analysis

For React Native (Bare Workflow)

For Expo (Managed Workflow)

How Attackers/CyberSecurity Analyst Decompile Your App

The Decompilation Process

Anatomy of a Decompiled App (Before Obfuscation)

How to Improve Obfuscation in Expo Apps

Configuration Steps

Anatomy of a Decompiled App (After Obfuscation)

Final Thoughts

How to Prioritize Product Development: A Practical Guide for Startups and Beyond

The Myth: Customers Always Know What They Want

The Value-Cost Sieve: A Smarter Way to Prioritize

Why This Matters More in Startups

Key Takeaway

React Native CLI vs Expo CLI: Clearing Up Misconceptions

1. Expo CLI: Then vs Now

2. Bare React Native CLI: Where It Stands

3. Advantages of Expo Beyond Development Speed

4. Official Recommendation

5. TL;DR

Automating Expo Android Submission to Play Store Console with EAS Using GitHub Actions: A Step-by-Step Guide.

Prerequisites

Automate Your Expo Builds with EAS Using GitHub Actions: A Step-by-Step Guide (Android)

Prerequisites

How to convert existing nodejs/expressjs app from javascript to typescript, the painless way

Prerequisites

Setup your expressjs application

Create bash script to automate file convertion from .js to .ts

Execute the script in your commandline

Installing required typescript dependencies

Generating tsconfig.json by enter below command in your terminal

Modify your tsconfig.json file

Running TypeScript in Node with ts-node

Start your application

Final Thoughts

✅ Recommended Tool: `expo-secure-store`

Step 2: Integrate `expo-updates` (Optional but Recommended)