DEV Community: Nour Abdou

React Native OTA Updates with Expo EAS: Step-by-Step Guide & Best Practices

Nour Abdou — Mon, 12 May 2025 17:25:41 +0000

Mobile app development has entered an era where agility and speed are paramount. Traditional methods, which require submitting new versions to app stores for review and awaiting user downloads, can lead to significant delays.

Over-the-air (OTA) updates provide a transformative solution by allowing you to push code changes directly to users’ devices, such as essential fixes, user interface improvements, and new features, thereby reducing downtime and enhancing the overall user experience.

In this article, we'll delve into how OTA updates work, discuss their benefits and challenges, and provide a step-by-step guide on implementing it within the Expo ecosystem.

In-Depth Analysis of OTA Updates: Capabilities, Benefits, and Limitations

📌 Capabilities of OTA Updates

Immediate Bug Fixes: Quickly resolve critical issues and deploy fixes without waiting for the app store review process. This minimizes downtime and reduces the risk of prolonged user impact.
Rapid Feature Delivery: Roll out new features in real time, enabling a more agile development cycle and gathering user feedback sooner. This accelerates the iterative process and improves overall product quality.
Swift UI/UX Tweaks (JS Side): Make minor adjustments to the user interface or experience directly in the JS bundle. Users receive these changes instantly on their next app launch, ensuring that the app stays up-to-date.
Instant Performance Improvements: Deploy performance enhancements immediately, directly benefiting the end-user experience without manual updates.

📌 Benefits of OTA Updates

Speed & Flexibility: Users get fixes and new features right away, and you can update as frequently as needed, improving your product continuously without waiting for app store reviews.
Enhanced User Experience: With OTA updates, users always have the latest version of your app. No need for them to do anything, which keeps the experience smooth and consistent.
Cost-Effective: By minimizing the need for frequent app store submissions, you save time, money and resources, freeing you up to concentrate on creating even better things.
Minimized Downtime: These updates happen silently in the background! So users can continue using the app without interruption, and they'll see the improvements the next time they open the app.

📌 Limitations of OTA Updates

Native Code Constraints: While OTA updates are great for JavaScript and assets, any changes that touches the native parts of your app still needs a full update through the app store.
Complexity in Rollback: While pushing updates is rapid, rolling back to a previous version with OTA can be more complex compared to regular app store updates. Proper version control is essential to mitigate this risk.
Initial Setup Overhead: Getting OTA updates up and running in the first place takes some careful setup and know-how. The initial setup can be time-consuming and may require ongoing maintenance to keep the update process smooth.
Limited Control Over User Update Timing: Since OTA updates are applied on the next app launch, users might continue using an older version for a while, which isn't ideal for urgent fixes.
Network Matters: The successful delivery of OTA updates depends on a reliable network connection. If the network is spotty, updates might be delayed or fail to download, leading to an inconsistent experience.
Security is Key: While OTA updates enhance security by enabling rapid patch deployment, they also require robust security measures to ensure the update process itself is not compromised.

Configure EAS Update

Prerequisites:

1- An Expo user account
2- Your React Native project for sure.
3- If your project is a bare React Native, it must use Expo CLI and extend the Expo Metro Config; 👉🏻 Installing Expo modules guide.
4- Your project must use the registerRootComponent function instead of registerComponent.

Now, follow these steps to set up EAS (Expo Application Services) Update:

1- Set up EAS Update

Install the Latest EAS CLI
EAS CLI is the command line app you will use to interact with EAS services from your terminal. Install it globally:

npm install --global eas-cli

Log in to Your Expo Account
If you are already signed in to an Expo account using Expo CLI, you can skip this step. If you are not, run the following command to log in:

- eas login
// then check whether you are logged:
- eas whoami

Configure Your Project
Navigate to your project directory in terminal, initialize EAS Update for your project by running:

eas update:configure

This command will update your app.json file with the runtimeVersion and updates.url properties, and add the extra.eas.projectId field if your project wasn't using any EAS services previously.

You'll see the following changes to your native projects:

➡️ Android
Inside the android/app/src/main/AndroidManifest.xml file, you'll see the following additions:

 <meta-data android:name="expo.modules.updates.EXPO_UPDATE_URL" android:value="https://u.expo.dev/your-project-id"/>
<meta-data android:name="expo.modules.updates.EXPO_RUNTIME_VERSION" android:value="@string/expo_runtime_version"/>

The EXPO_UPDATE_URL value should contain your project's ID.

Inside android/app/src/main/res/values/strings.xml, you'll see the expo_runtime_version string entry in the resources object:

<resources>
    <string name="app_name">MyApp</string>
    + <string name="expo_runtime_version">1.0.0</string>
</resources>

➡️ iOS

Inside ios/project-name/Supporting/Expo.plist, you'll see the following additions:

<key>EXUpdatesRuntimeVersion</key>
<string>1.0.0</string>
<key>EXUpdatesURL</key>
<string>https://u.expo.dev/your-project-id</string>

The EXUpdatesURL value should contain your project's ID.

2. Configuring a Channel

Manually

If you prefer not to use EAS Build for channel configuration, you can set the channel manually by updating both your AndroidManifest.xml and Expo.plist files.

➡️ Android Configuration

In your AndroidManifest.xml (located at android/app/src/main/AndroidManifest.xml), add the following meta-data tag:

<!--
  This meta-data tag configures the Expo Updates module.
  It tells the app to include a custom request header ("expo-channel-name")
  with every update check, ensuring that the correct update channel is used.
-->
<meta-data android:name="expo.modules.updates.UPDATES_CONFIGURATION_REQUEST_HEADERS_KEY" android:value="{&quot;expo-channel-name&quot;:&quot;your-channel-name&quot;}"/>

This line sets the custom channel (replace "your-channel-name" with your actual channel name) that the app will use when checking for updates.

➡️ iOS Configuration

For iOS, update your Expo.plist file (located at ios/your-project-name/Supporting/Expo.plist) with the following configuration:

<!--
  This configuration in Expo.plist sets up the request headers for updates.
  The key "expo-channel-name" is set to "your-channel-name", ensuring that the app
  contacts the correct update channel on your server.
-->
<key>EXUpdatesRequestHeaders</key>
<dict>
  <key>expo-channel-name</key>
  <string>your-channel-name</string>
</dict>

This ensures that the Expo updates module on iOS uses the specified channel.

➡️ Alternative: Configuring via app.json

If you prefer to let Expo generate this configuration automatically, you can set the requestHeaders property in your app.json. For example:

{
    "expo": {
        "updates": {
            // The URL where your app will fetch the OTA update manifest.
            // This is an Expo hosted URL
            "url": "<https://u.expo.dev/>...",

            // Enables or disables OTA updates for the app.
            // Set to true to allow updates; false will disable OTA functionality.
            "enabled": true,

            // Specifies the amount of time (in milliseconds) the app should wait
            // for an update to be downloaded before falling back to a cached version.
             // A value of 0 means the app will immediately use the cached update if available.
            "fallbackToCacheTimeout": 0,

            // Determines when the app checks for new updates.
            // "ON_LOAD" instructs the app to check for updates every time it launches.
            "checkAutomatically": "ON_LOAD",

            // Additional HTTP headers that will be sent when the app requests an update.
            // In this case, the "expo-channel-name" header is used to designate the update channel,
           // allowing you to manage different release streams (e.g., test vs. production).

            "requestHeaders": {
                "expo-channel-name": "your-channel-name"
            }
        }
    }
}

Explanation:

"url" points to your manifest endpoint.
"fallbackToCacheTimeout": 0 ensures that if the update isn’t immediately available, the app won’t wait.
"checkAutomatically": "ON_LOAD" instructs the app to check for updates each time it launches.
The "requestHeaders" property allows you to specify a channel (e.g., test or production).

Then run:

npx expo prebuild

This command will inject the proper configuration into both AndroidManifest.xml and Expo.plist.

Note: Typically, you might use two channels: test and production.

3. EAS Update Command Reference

Below is a list of commonly used commands for managing updates, channels, and branches.

Manage updates

Create and Publish a New Update:

eas update --branch [branch-name] --message "Your update message"

Example:

eas update --branch version-1.0 --message "Fixes typo"

View a Specific Update:

eas update:view [update-group-id]

Rollback an Update

Rollback to a Previous Update:

eas update:rollback

Republish a Previous Update Within a Branch

Republish by Group ID:

eas update:republish --group [update-group-id]

Republish by Branch:

eas update:republish --branch [branch-name]

Examples:

eas update:republish --group dbfd479f-d981-44ce-8774-f2fbcc386aa
eas update:republish --branch version-1.0

Manage Channels and Branches

In EAS Update, a channel acts as the "distribution pipeline" that delivers updates to your app, while a branch represents the mode or version stream—such as test or production—from which updates are sourced.

By linking a branch to a channel, you control which updates reach specific user groups. For example:

A test branch connected to a test channel delivers updates to internal or beta testers.
A production branch tied to a production channel sends updates to live users. This separation ensures experimental changes stay confined to testing environments, protecting your production audience while enabling rapid iteration and feedback in development.

Channels:

View a Channel:

 eas channel:view production

List All Channels:

eas channel:list

Branches:

List All Branches:

eas branch:list

View a Specific Branch and Its Updates:

eas branch:view version-1.0

Delete a Branch:

eas branch:delete [branch-name]

Rename a Branch:

eas branch:rename --from version-1.0 --to version-1.0-new

4. Add a hook to check for updates

it's optional since you set "checkAutomatically": "ON_LOAD",.

import { useEffect } from "react";

import * as Updates from "expo-updates";

export function useisHasUpdates(): void {
  useEffect(() => {
    async function update(): Promise<void> {
      try {
        const { isAvailable } = await Updates.checkForUpdateAsync();
        if (isAvailable) {
          await Updates.fetchUpdateAsync();
        }
      } catch {
        console.error("Error; checking for updates");
      }
    }
    if (!__DEV__) {
     update();
    }
  }, []);
}

5. Create a build for your project

Generate a production build with the runtime version and channel name, APK for Android and TestFlight for iOS.

6. Make changes locally

After creating the build, you are ready to iterate on the project; make any desired changes to your project's JS, styling, or image assets.

7. publish an update

Use the eas update command, and specify a name for the channel and a message to describe the update, as we talked before.

📱 But how does publishing an update work?
When you publish an update with the eas update command, it generates a new update bundle and uploads it to the EAS servers.
then it locates the correct branch to publish a new update according to channel name. It is similar to how Git commit works, where every commit is on a Git branch.

8. Test

You can manually test the update by force closing and reopening a release build of your app up to two times to download and apply the update.
Updates for non-development builds are automatically downloaded to the device in the background when the app starts up and makes a request for any new updates. The update will be applied after it is downloaded and the app is restarted.

And Voilà, you are done now!! 🥂

In some cases more control of how updates are sent to an app may be needed, and one option is to implement a custom updates server that adheres to the specification in order to serve update manifests and assets. 👇🏻

Configure a Custom Expo Updates Server

You can set up your own custom Expo updates server to gain complete control over your app’s update distribution. Below are the implementation steps:

Implementation Steps

Create a Custom Server and Implement Update Endpoints

Initialize the Project:
Clone the official repository for the custom Expo updates server:

git clone https://github.com/expo/custom-expo-updates-server.git
cd custom-expo-updates-server

This repo contains a basic server implementation built with Next.js. The key API endpoints are located in:

pages/api/manifest.js – Handles the manifest file generation.
pages/api/assets.js – Serves the asset bundles.

These endpoints adhere to the Expo Updates protocol, allowing your app to fetch the latest update bundles.

Set Up EAS Update Code Signing

💡 Code Signing:
To ensure your updates are secure and verifiable, set up code signing by following the Expo documentation on EAS Update Code Signing.
This involves generating a signing certificate and configuring your server and app to use it, which protects your update bundles from tampering.

💡 Uploading Credentials Manually
To upload credentials from your local credentials.json file and have them managed by EAS, follow these steps:

Open your terminal at the root directory of your project.
Run the command:

eas credentials

When prompted, select the desired platform.
Choose the option: "Credentials.json: Upload/Download credentials between EAS servers and your local json".
Then select: "Upload credentials from credentials.json to EAS".
Repeat the process for another platform if needed by running the command again.

This approach ensures that your credentials are safely managed by EAS, streamlining your build and deployment process.

Configure Your React Native Mobile App

Update the Configuration in app.json

{
  "expo": {
    "updates": {
      // This can be an Expo hosted URL or your custom server's endpoint.
      "url": "https://your-custom-server.com/manifest/",
      "enabled": true,
      "fallbackToCacheTimeout": 0,
      "checkAutomatically": "ON_LOAD",

      // Path to the code signing certificate that is used to verify the authenticity
      // of the OTA update bundle. This file should be placed in your project’s directory.
      "codeSigningCertificate": "./certs/certificate.pem",

      // Metadata related to the code signing process.
      // "keyid" should correspond to the identifier of the signing key.
      // "alg" specifies the cryptographic algorithm used for signing (e.g., RSA with SHA-256).
      "codeSigningMetadata": {
        "keyid": "main",
        "alg": "rsa-v1_5-sha256"
      },
      "requestHeaders": {
        "expo-channel-name": "channel"
      }
    }
  }
}

Explanation:

The code signing fields secure your updates.

Tip: If you run npx expo prebuild after setting the requestHeaders property, the necessary configuration will be automatically injected into both AndroidManifest.xml and Expo.plist.

Add Scripts to Upload Update Bundles

{
  "scripts": {
    "expo-publish-alt": "node ./scripts/publish.js",
    "expo-rollback-alt": "node ./scripts/rollback.js"
  }
}

These scripts handle the uploading of new update bundles to your custom server. In this setup, while the publish script worked properly, the rollout (gradual update distribution) wasn’t implemented on the server side. After understanding channels and branches management, you may choose to migrate to EAS Update without relying on EAS Build if that better fits your workflow.

💾 Setting up a custom Expo updates server gives you granular control over update distribution, code signing, and rollout strategies. By manually configuring both your server and your React Native app, you can tailor the OTA update process to your specific requirements. However, as you refine your approach, you might find that the channel and branch management capabilities provided by EAS Update offer a more streamlined solution—especially if you decide not to use EAS Build.

📚 Additional resources:
👉 Expo OTA Updates Documentation

👉 Expo EAS Update Documentation

👉 Secure your update bundles by following best practices for Expo Code Signing for OTA Updates

👉 Custom Expo Updates Server Repository

Summary

Over-the-air (OTA) updates through Expo's EAS Update revolutionize mobile app development by enabling rapid deployment of bug fixes, performance optimizations, and new features, bypassing the delays of traditional app store reviews. By following best practices, such as effective channel and branch management, secure code signing, and rigorous testing, you can mitigate OTA limitations and deliver a seamless, high-quality user experience.

Happy Building! Great solutions power exceptional experiences. 🚀

React Native Under the Hood: How Your JS, iOS, and Android Code Run Together?

Nour Abdou — Sun, 27 Apr 2025 06:39:25 +0000

Ever wondered how React Native actually runs your code?
When working with React Native, it's essential to understand how JavaScript, iOS, and Android handle code execution and compilation.

Unlike native platforms that use compiled languages, JavaScript does not have a traditional build system but undergoes a different transformation process. You write JavaScript/TypeScript, but it controls native iOS and Android components.

It's a multi-stage process involving transpilation, bundling, JavaScript execution, communication, and native rendering.

The Flow

1- Development: Write TS code.
2- Build: TS -> JS (transpilation) -> JS Bundle (Metro).
3- Launch: Native app shell starts, loads JS bundle into a JS Engine (Hermes/JSC).
4- Execution: JS code runs, React determines UI structure.
5- Rendering: React instructions are sent via Bridge/JSI to native View Managers, which create/update native UI elements (UIView, android.view.View).
6- Interaction: User interacts with native UI elements -> Events sent via Bridge/JSI back to JS -> JS event handlers run -> State updates -> UI potentially re-renders (back to step 5).
7- Native APIs: JS calls Native Modules -> Bridge/JSI relays call to native code -> Native code executes platform API -> Result sent back via Bridge/JSI to JS.

Let's break down the execution and compilation flow for each part.

JavaScript (The Brains 🧠)

While JavaScript is typically an interpreted language, unlike natively compiled languages like Swift or Kotlin, React Native involves a form of "compilation" steps before your code actually runs on the device.
But In case your application is written in TypeScript benefiting from static typing, interfaces, and other TS features, the first step is:

📌 TypeScript to JavaScript Transformation (Build Time)

Before your code can run, it needs to be converted into JavaScript, which is what React Native's runtime environment understands. The TS compiler (tsc) is responsible for this.
During the build process (when you run npx react-native run-ios or run-android), tsc (often invoked implicitly by the Metro bundler) reads your .ts and .tsx files. It performs type checking and then removes all the TypeScript-specific syntax (like type annotations, interfaces, etc.).

➡️ Output: The output of this step is standard JavaScript code (.js) that is functionally equivalent to your TypeScript code, just without the type information.

Now, Your JS logic is transpiled and bundled by Metro during the build Time. If using Hermes, it's further compiled to optimized bytecode.
This final package runs within a dedicated JS environment on the device, communicating with the native side to control the app's UI and functionality:

📌 JavaScript Bundling (Build Time)

React Native uses Metro, a specialized JavaScript bundler, to handle this. Metro performs two key tasks:

Transpilation: Due to evolving JavaScript (ECMAScript) standards and the use of JSX, your code needs to be transformed into a version that the target JavaScript engine (e.g., Hermes) can understand. Metro uses Babel under the hood for this; Babel rewrites modern JavaScript syntax and JSX into compatible code, guided by React Native's specific Babel preset to match the capabilities of the engine being used.
Bundling: Metro bundles all your JavaScript files and dependencies into one (or a few) efficient JS files (bundles), optimized for loading at runtime (understandable for JS engine).

➡️ Output: The JS Bundle; This is typically a single .js file (e.g., index.bundle) containing all the application logic ready to be executed.

📌 Running the JavaScript (Runtime)

When you build your React Native app, a Native "shell" application is created for both iOS (using Objective-C/Swift) and Android (using Java/Kotlin). This shell contains the necessary native code to host React Native.

Execution JS Engine (JavaScriptCore vs. Hermes):

This native shell embeds a JS engine (a program that executes JS code). React Native can use different engines:

JavaScriptCore (JSC): Historically common, it's the engine used by Safari. It's also available on Android but less used now.
Hermes: An open-source JavaScript engine optimized by Meta specifically for running React Native appsand It's often the default for new React Native projects on both platforms.
A key advantage of Hermes is that during the app build phase, it pre-compiles the JavaScript bundle into bytecode.
This bytecode format allows for significantly faster app startup times (Time To Interactive - TTI) and reduced memory usage compared to interpreting raw JS or using Just-In-Time (JIT) compilation on the device.

➡️ So.. When you launch the app, the native shell starts the JS engine and loads the JS bundle created by Metro. Then, The JS engine starts executing your application's code, beginning with your entry point (usually index.js). React starts rendering your components in memory.

We'll talk now about Communication & Native Modules and Native Components.

iOS (Swift/Objective-C - The Looks & Feel on Apple🍎)

Unlike JavaScript, Swift and Objective-C are compiled languages. The iOS build system compiles source code (including the native parts of React Native itself and any native modules you add) into machine code before execution, ensuring optimized performance on Apple devices.

React Native for iOS relies on Xcode's build system, which uses Clang compiler (for Objective-C) and LLVM toolchain (for Swift) to convert human-readable source code into an optimized binary specific to the iPhone/iPad processor (such as .app bundle).

Here are the key steps:

Source Compilation: Swift and Objective-C files are compiled into machine code using Clang/LLVM.
Linking: All compiled code, system frameworks, and external libraries (from CocoaPods) are linked together.
Signing: Apple requires apps to be signed with valid certificates and provisioning profiles before they can be run on a device.
Packaging: The final binary (.ipa file) is generated, containing the app and its resources.

➡️ Result: This compiled code is packaged into the .app bundle that gets installed on the user's device. It runs directly on the hardware when the app starts.

Android (Kotlin/Java - The Looks & Feel on Android 🤖)

Similar to iOS (but a bit more layered process), Android uses a compiled build system, relying on Gradle, which automates the process of building, testing, and packaging an Android app.

React Native for Android compiles Java/Kotlin source code into Dalvik Executable (DEX) format, which is optimized for execution by the Android Runtime (ART).

Here are the key steps:

Source Compilation: Java/Kotlin files are compiled into .class bytecode files using the javac (for Java) and kotlinc (for Kotlin) compilers.
DEX Conversion: The compiled .class files (JVM Bytecode) are converted into .dex files (Dalvik Bytecode), optimized for the Android Runtime using the DEX compiler (d8).
Resource Processing: XML layouts, images, and other assets are bundled.
Linking: External libraries and dependencies (managed by Gradle) are linked.
Signing: Android requires apps to be signed with a valid keystore file.
Packaging: The final .apk or .aab file is generated for installation on devices.

➡️ Result: This compiled/optimized code is packaged into an .apk or .aab file for distribution.

📌 Communication: The Bridge / JSI (Runtime)

This is the core of how JavaScript interacts with the native platform. There are two main architectures:
1- The Bridge (Older Architecture):
The Bridge acts as a message broker between your JS code and the native iOS/Android platform.
It asynchronously sends serialized data (commands, UI updates) from JS to Native.
Then Native code executes these commands and sends results or user interaction events back to JS.
But, Its Asynchronous nature can lead to latency, serialization/deserialization overhead ("Bridge Tax"), and potential bottlenecks if too many messages are sent.

2- JavaScript Interface (JSI) (New Architecture - Fabric & TurboModules):
React Native's new architecture replaces the asynchronous Bridge with the JavaScript Interface (JSI).
JSI allows direct, synchronous calls between JavaScript and Native (via C++), eliminating serialization overhead.
This powers Fabric (a faster UI rendering system) and TurboModules (faster, lazy-loaded native modules).
The result is significantly improved performance, responsiveness, and better feature support.

For more about these architectures, Checkout my Article about How React Native works internally?

📌 Native Modules and Native Components (Runtime)

Native Modules Expose native platform APIs (like camera, geolocation, storage, Bluetooth, custom native code) to your JavaScript code.
When your JS calls NativeModules.MyCamera.takePicture(), the JSI translates this into a call to the corresponding native Objective-C/Swift (iOS) or Java/Kotlin (Android) method. The native code executes, and the result is sent back to JS.
Native Components (View Managers): These are the counterparts to React components like <View>, <Text>, <Image>, etc.
When React decides to render a <View>, it doesn't create an HTML <div>, but it sends instructions (via JSI) to the native side.

-> On iOS, a native "View Manager" receives these instructions and creates/updates an actual native UIView.
-> On Android, a native "View Manager" creates/updates an actual native android.view.View.

This ensures that your UI looks and feels native because it is using native platform UI elements. The layout logic (like Flexbox) is calculated (often on a background thread) and then applied to these native views on the main UI thread.

Running the application on the device

Testing is an essential part of the mobile app development workflow. Unlike web applications, which can be tested directly in a browser, mobile apps require simulators (emulators in Android) or physical devices for testing. Simulators allow developers to run and debug apps in a controlled environment that mimics real-world device behavior.
■ Android
You can interact with Android emulators using the following methods:

Android Studio AVD Manager: The built-in tool for managing Android emulators. You can create, configure, and launch virtual devices here.
Command Line (adb and emulator commands):
emulator -list-avds—lists all available virtual devices.
emulator @Pixel_6_API_34—launches a specific device.
adb devices—lists running emulators and connected physical devices. CLI tools such as Expo CLI or React Native Community CLI use these commands under the hood to provide a better developer experience.

■ iOS
You can interact with iOS simulators via the following:

Xcode: Apple's built-in tool for running iOS apps on a simulated device. You can launch it via Xcode > Open Developer Tool > Simulator.
Command Line (xcrun simctl commands): ➡️ xcrun simctl list—lists available simulators. ➡️ xcrun simctl boot "iPhone 15"—boots a specific simulator. ➡️ xcrun simctl shutdown all—shuts down all running simulators.

Happy building!
Good Understanding leads to great experiences! 🚀

Fixing App Installation Issues on Older Android Versions: Multiple APKs & ABI Splitting

Nour Abdou — Sat, 01 Feb 2025 18:43:27 +0000

Are you facing issues with your app not installing on devices running Android versions lower than API 30? You're not alone! Many developers encounter problems when their app signing key is unexpectedly upgraded, causing compatibility issues with older Android versions. In this guide, we’ll walk you through a proven solution using Multiple APKs to ensure seamless distribution across different Android versions. Plus, we'll dive into ABI splitting to optimize performance and reduce APK size. Let’s fix your app installation issues and make your app more efficient than ever!

Problem statement

If your app is failing to install on devices running Android versions below API 30, you're not alone. The issue arises from an unexpected upgrade of the app signing key, preventing the rollout of new releases with a minSdkVersion lower than 30. Fortunately, you don’t need to create a new app on Google Play—there’s a way to resolve this issue while keeping your existing app listing and user base intact.

Proposed solution

Regarding Multiple APKs support

To successfully roll out a new release without creating a new app, we need to upload both an app bundle and an APK signed with the legacy key in every release. Google Play will automatically generate APKs signed with the new key for devices running Android R* (API level 30) and above, while older Android versions (API level 29 and below) will continue receiving updates through the legacy APKs.

This approach ensures seamless compatibility across different platform versions while maintaining a single app listing on Google Play.

How multiple APKs work

Using multiple APKs on Google Play allows you to maintain a single app entry while delivering different APKs to different devices based on compatibility. This approach provides several key benefits:

✅ Unified Product Details: You manage only one set of product descriptions, images, and metadata—keeping your app listing consistent.
✅ Consistent User Experience: Users see only one version of your app on Google Play, avoiding confusion between different APK variants.
✅ Unified Ratings & Reviews: All user reviews apply to the same app listing, regardless of which APK version is downloaded.
Seamless Updates: When a user upgrades their Android version, Google Play automatically provides the most compatible APK, ensuring a smooth transition.

This method simplifies app management while ensuring optimal performance across a wide range of devices.

API Level Considerations

The multiple APKs approach relies on the android:minSdkVersion and android:maxSdkVersion attributes in your app's manifest file. This allows you to serve different APKs based on a device’s Android version while maintaining a single app entry on Google Play.

Example Setup:

You can publish multiple APKs based on API levels, such as:

APK 1: Supports API levels 16 - 19 (Android 4.1.x - 4.4.4), using only APIs available from API level 16 or lower.
APK 2: Supports API levels 21 and above (Android 5.0+), using APIs available from API level 21 or lower.
👉 To learn how to configure APKs for different API levels, refer to Configure Product Flavors.

Versioning Rules for Multiple APKs

If an APK has a higher android:minSdkVersion, it must also have a higher android:versionCode to ensure proper updates through Google Play.

This ensures that when a device receives a system update, Google Play can offer the user the most compatible version of your app—because updates are based on an increase in the app’s version code.

For more details, refer to Rules for multiple APKs.

Avoid Using android:maxSdkVersion

⚠️ Avoid setting android:maxSdkVersion unless absolutely necessary. Android is designed to maintain backward compatibility, so properly developed apps using public APIs will work with future Android versions.

If you want to release a different APK for newer API levels, you don't need to specify maxSdkVersion—Google Play will automatically deliver the correct APK based on the minSdkVersion and versionCode.

Rules for multiple APKs

Before publishing multiple APKs for your application, it’s essential to follow these rules to ensure compatibility and smooth updates:

General Rules:

✅ Same Package & Signature: All APKs must have the same package name and be signed with the same key.
✅ Unique Version Code: Each APK must have a unique versionCode to differentiate it from other versions.
✅ Distinct Configurations: No two APKs should exactly match the same device configuration. Each APK should target a different device segment (e.g., API level, screen size, ABI).
✅ Higher API Level = Higher Version Code: An APK requiring a higher API level must have a higher versionCode.

Handling Overlapping APKs:

If multiple APKs differ only by API levels, or if they also use another distinguishing factor (e.g., screen size) but have overlapping filters, their versionCode values must increase in correlation with API levels.

Example Scenario:

Imagine you have an active APK for small - normal screen sizes with version code 0400, and you try to replace it with an APK targeting the same screen sizes but with version code 0300. This will cause an error, because users of the older APK would not be able to update the app due to the lower version code.

Why This Matters:

📌 Google Play delivers app updates only if the new APK has a higher version code than the one installed on a device.

📌 This rule ensures that if a device receives a system update, making it eligible for a higher API level, it will automatically receive the correct APK update with a higher version code.

Examples of Version Code Rules

To better understand how version codes should be assigned when using multiple APKs, consider the following scenarios:

1️⃣ API Levels Differ Only (Version Code Must Increase)

✅ If an APK for API levels 16+ (Android 4.1.x+) has a version code of 0400, then an APK for API levels 21+ (Android 5.0+) must have a version code of 0401 or higher.
📌 This ensures that devices receiving a system update to API level 21 will also receive the new APK update.

2️⃣ Overlapping Screen Sizes & API Levels (Version Code Must Increase)

✅ If one APK supports API level 16+ and small to large screens, while another supports API level 21+ and large to xlarge screens, the version codes must increase with API levels since large screens overlap.

📌 Because both APKs support large screens, a large-screen device that upgrades to API level 21 should receive the correct APK update.

3️⃣ No Overlapping Filters (Version Code Doesn’t Need to Increase)

✅ If one APK supports API level 16+ with small to normal screens, and another supports API level 21+ with large to xlarge screens, then version codes do not need to increase.

📌 Since there is no screen size overlap, no devices will transition between these APKs, so the version codes don’t need to be in sequential order.

Following these versioning rules ensures seamless updates and avoids compatibility issues when rolling out multiple APKs. 🚀

Assigning Version Codes

Each APK must have a unique versionCode to ensure proper ordering and flexibility for updates.

Since Google Play uses android:versionCode to determine whether an update is available, you need to carefully structure version codes when publishing multiple APKs.

Ordering Version Codes

📌 An APK requiring a higher API level must have a higher version code.

For example, if you release two APKs for different API levels:

The APK for API level 21+ must have a higher version code than the APK for API level 16+.
This guarantees that devices updating to a higher Android version receive the appropriate APK update.

Using a Version Code Scheme

To allow independent version updates for each APK (e.g., fixing a bug in one without updating others), use a structured versioning scheme:

✅ Leave space between version codes to allow updates without affecting all APKs.
✅ Embed the API level in the version code for clarity.

versionCode 21012
versionName '0.1.2'

//21: API level (constant)
//012: version name (incremental)

versionCode 30012
versionName '0.1.2'

//30: API level (constant)
//012: version name (incramental)

This approach ensures that updates are managed efficiently while keeping the versioning system clear and maintainable. 🚀

Split APKs Based on ABI

Why Split APKs Based on ABI?

Beyond supporting different API levels, splitting APKs based on ABI (Application Binary Interface) further optimizes performance and reduces app size.

📌 Why does this matter?

Android devices use different CPU architectures (armeabi-v7a, arm64-v8a, x86, x86_64).
Including binaries for all architectures in a single APK increases its size unnecessarily.
A device should only download the binaries it actually needs.

Implementing ABI Splitting
We can extend the multiple APKs approach by also generating separate APKs for different ABIs.

To enable ABI-based APK splitting, modify your build.gradle file:

android {
    splits {
        abi {
            enable true
            reset()
            include 'armeabi-v7a', 'arm64-v8a', 'x86', 'x86_64'
            universalApk false // Prevents generating a universal APK
        }
    }
}

Benefits of ABI Splitting
✅ Smaller APKs: Only the necessary binaries are included, reducing file size.
✅ Optimized Performance: Devices install APKs optimized for their specific CPU architecture.
✅ Faster Updates: Smaller file sizes mean faster downloads and installations.

ABI-Based Version Code Strategy
Each APK must have a unique versionCode to ensure proper updates. To achieve this, we can encode API level, version name, and ABI identifiers into the version code, following a structured approach.

Example Version Code Structure
To maintain proper ordering while allowing independent updates, we structure the versionCode as:

AACBBB

Where:
AA → API level (constant)
BBB → Version name (incremental)
C → ABI identifier

versionCode 210112
versionName '1.1.2'

// 21: API level (constant)
// 012: Version name (incremental)

versionCode 300112
versionName '1.1.2'

// 30: API level (constant)
// 012: Version name (incremental)

Modify your build.gradle to implement this structured versioning:

android.applicationVariants.all { variant ->
    variant.outputs.each { output ->
        def abiVersion = 0
        if (output.getFilter(com.android.build.OutputFile.ABI) == 'armeabi-v7a') {
            abiVersion = 1
        } else if (output.getFilter(com.android.build.OutputFile.ABI) == 'arm64-v8a') {
            abiVersion = 2
        } else if (output.getFilter(com.android.build.OutputFile.ABI) == 'x86') {
            abiVersion = 3
        } else if (output.getFilter(com.android.build.OutputFile.ABI) == 'x86_64') {
            abiVersion = 4
        }
        output.versionCodeOverride = defaultConfig.versionCode abiVersion * 1000 
    }
}

How this works:

The first two digits (AA) represent the API level.
The next last three digits (BBB) track the app version.
The third (C) uniquely identifies the ABI:
1 → armeabi-v7a
2 → arm64-v8a
3 → x86
4 → x86_64

API Level	Version Name	ABI	Final Version Code
21	0.1.2	armeabi-v7a	`211112`
21	0.1.2	arm64-v8a	`212112`
21	0.1.2	x86	`213112`
21	0.1.2	x86_64	`214112`

Conclusion
Using this structured approach ensures:
✅ Proper versioning for updates
✅ Consistent ordering of APKs
✅ Easy maintenance of separate APKs for API levels & ABIs

This method provides a future-proof way to manage multiple APKs efficiently! 🚀

📚 References

For you to dive deeper into the technical details of multiple APK support, versioning strategies, and ABI-based APK splitting.

Happy Solving - Great solutions lead to great experiences! ! 🚀

How React Native works internally?

Nour Abdou — Wed, 07 Dec 2022 07:17:46 +0000

You may built some applications using React Native or you've just started learning it!
Despite it is not a requirement to be effective with React Native, but for better developing experience, you should know the mechanics of React Native and what exactly happens in the low level code; that is what you are about to read here.

Introduction

React Native has been successfully adopted by hundreds of businesses worldwide, including Uber, Discord, Microsoft, and Facebook, and is used across a whole range of industries.

It is a JavaScript-based mobile app framework that allows you to build natively-rendered mobile apps for iOS and Android, using the same codebase.

Since Java and Objective C are strongly typed languages while Javascript is not, React Native can be considered as a set of components, where each component represents the corresponding native views and components.

For example, a native TextInput will have a corresponding RN component which can be directly imported into the JS code and used like any other React component. Hence, the developer will be writing the code just like for any other React web app but the output will be a native application.

Old React Native architecture & Threading Model

Architecture

There are three main parts:

Native side

Most of the native code in case of iOS is written in Objective C or Swift, while in the case of Android it is written in Java or Kotlin.

Javascript side (JS VM)

The JS Virtual Machine that runs all our JavaScript code. On iOS/Android simulators and devices, React Native uses JavaScriptCore, which is the JavaScript engine that powers Safari. JavaScriptCore is an open source JavaScript engine originally built for WebKit.

In case of debugging mode, the JavaScript code runs within Chrome itself (instead of the JavaScriptCore on the device) and communicates with native code via WebSocket. Here, it will use the V8 engine. This allows us to see a lot of information on the Chrome debugging tools like network requests, console logs, etc.

React Native Bridge

React Native bridge is a C++/Java Component which is responsible for communication between the Native and Javascript thread. Like a custom protocol used for message passing. It can be imagined as a bus where the producer layer sent some data for the consumer layer. The consumer could read the data, deserialize it and execute the required operations.

Source:`Hackernoon`

Threading Model

When a RN application is launched, it spawns up the following threading queues:

UI Thread/Main thread (Native Queue)

This is the place where the native code is executed. It loads the app and starts the JS thread to execute the Javascript code.
All the native modules lie in the startup, which means they will always be bundled if the user wants to access them. In other words, the native thread listens to the UI events like 'press', 'touch', etc. These events are then passed to the JS thread via the RN Bridge.

Shadow Thread

It is the place where the layout of your application is calculated using React library. This cross-platform framework handles this task with the help of Facebook’s own layout engine called Yoga. It transforms flexbox layouts, calculates them and sends them to the app’s interface. It is basically like a mathematical engine which finally decides on how to compute the view positions, to be passed back to the main thread to render the view.

JavaScript thread (JS Queue)

This is the place where main bundled JS thread runs; where the entire JavaScript code is placed and compiled. The JS thread runs all the business logic, i.e., the code we write in React Native. And when the app is bundled for production, the JavaScriptCore runs the bundle when the user starts the app.

Working process

In most cases, a developer would write the entire React Native application in Javascript.

At the first start of the app, the main thread starts execution and starts loading JS bundles.
The JS thread sends the information on what needs to be rendered onto the screen.
Then the Shadow thread uses this information to compute the layouts.
And then sends layout parameters/objects to the main(UI) thread.
Since only the main thread is able to render something on the screen, shadow thread should send generated layout to the main thread, and only then UI renders.

Old Architecture's Issues

The Old Architecture used to work by serializing all the data that has to be passed from the JS layer to the native layer using The Bridge.

The Bridge had some limitations:

It was asynchronous: one layer submitted the data to the bridge and asynchronously "waited" for the other layer to process them, even when this was not really necessary.
It was single threaded: JS used to work on a single thread, therefore the computation that happened in that world had to be performed on that single thread.
It imposed extra overheads: everytime one layer had to use the other one, it had to serialize some data. The other layer had to deserialize them. The chosen format was JSON, for its simplicity and human-readability, but despite being lightweight, it was a cost to pay.

Say an image file converted into base64 string!!!

New Architecture's Improvements

The New Architecture eliminate the bridge and let the UI be controlled directly from the JavaScript Interface (JSI) using native code. The JSI is an interface that allows a JavaScript object to hold a reference to a C++ and viceversa.

This idea allowed to unlock several benefits:

Synchronous execution: it is now possibile to execute synchronously those functions that should not have been asynchronous in the first place.
Concurrency: it is possible from JavaScript to invoke functions that are executed on different thread.
Lower overhead: there are no serialization taxes to pay, since the New Architecture don't have to serialize/deserialize the data
Code sharing: by introducing C++, it is now possible to abstract all the platform agnostic code and to share it with ease between the platforms.
Type safety: to make sure that JS can properly invoke methods on C++ objects and viceversa, a layer of code automatically generated has been added. The code is generated starting from some JS specification that must be typed through Flow or TypeScript.

New React Native architecture & Threading Model

Fabric Renderer

RN Fabric allows the UI thread (where UI is drawn) to be in sync with the JS thread (where the UI is programmed). In other words, it lets React talk to each platform and manage its host view instances!

The render pipeline can be broken into three general phases:

Render

React executes product logic which creates a React Element Trees in JavaScript; each element is a JS object that describes what should appear on the screen, and includes props, styles, and children.
From this tree, the renderer creates a React Shadow Tree in C++; which consists of React Shadow Nodes; each node is an object that represents a React Host Component to be mounted, and contains props that originate from JavaScript. They also contain layout information (x, y, width, height).

Commit

After a React Shadow Tree is fully created, the renderer triggers a commit. This promotes both the React Element Tree and the newly created React Shadow Tree as the “next tree” to be mounted. This also schedules calculation of its layout information.

Mount

The React Shadow Tree, now with the results of layout calculation, is transformed into a Host View Tree.
The host here represent the platform (e.g. Android, iOS). On Android, the host views are instances of android.view.ViewGroup, android.widget.TextView, etc. which are the building blocks of the host view tree. The size and location of each host view are based on LayoutMetrics calculated with Yoga, and the style and content of each host view are based on information from the React Shadow Tree.

Threading Model

React Native renderer is designed to be thread safe. Every update in React creates or clones new objects in the renderer instead of updating data structures. This allows the framework to expose thread safe and synchronous APIs to React.

The renderer uses three different threads:

UI Thread/Main thread

The only thread that can manipulate host views.

JavaScript thread

This is where React’s render phase is executed.

Background thread

Thread dedicated to layout.

Conclusion

In this article we had conceptual overview of how React Native's internals work. From the old school to the current one, which brings an improvement in startup time, and developer experience, with improved interoperability between all threads.

References

RN Guide. reactnative.guide. Available from: here
How RN works?. geeksforgeeks.org. Available from: here
RN Architecture. reactnative.dev. Available from: here
Why A New Architecture?. reactnative.dev. Available from here

Express + Typescript + Mongoose boilerplate

Nour Abdou — Sat, 03 Dec 2022 19:22:27 +0000

Build REST API with Express + Typescript + Mongoose boilerplate

🏛 simple starter for newbies.

⚛️ My main goal is a simple and easy starter for new learners. I like you to be focused on the correct learning path and not spending hours in choosing the right project structure.

✨ Features

Beautiful Code as simple as possible.
Clear Structure inspired by MVC Model.
Local4ization implemention.
Authorization CRUD example.

📎 Available on Github: express-typescript-mongoose-boilerplate

Table of Content

Introduction
- Backend development
- About API
Express + Typescript + Mongoose boilerplate
- About NodeJS
- ExpressJS
- MongoDB
- Localization with I18n

Introduction

You will know a bit about backend development frameworks and how to do so using ExpressJS & MongoDB with typescript.

Backend development

Any app or web service has two broad parts: the frontend (client side) and the backend (server side).

The backend development is the part that you can’t “see”. It is the internal work including stuff like the server, the database, etc.

Before dive in the backend dev tools, there are things you should be comfortable with, such as: Networks, Internet, Databases, Computer server.
A networks is a collection of connected devices and computers; The Internet is the network of all networks; the database is where we store data in a well defined, accessible way and it has many types.
Server is a computer program or device that provides a service to another computer program and its user/client.

Tools used in backend development

scripting languages: PHP, Javascript, Ruby, etc.
programming languages: python, java, etc.
frameworks: NodeJS, Laravel, Django, flask, etc.
databases: MongoDB, MySQL, etc.

About API

(Application Programming Interface)
An API is a set of programming code that enables data transmission between one software product and another. It also contains the terms of this data exchange The API defines endpoints, and valid request and response formats.

Types

Open APIs

Open APIs, also known as external or public APIs, are available to developers and other users with minimal restrictions. They may require registration, and use of an API key, or may be completely open.

Internal APIs

Internal APIs are designed to be hidden from external users. They are used within a company to share resources. They allow different teams or sections of a business to consume each other’s tools, data and programs.

Partner APIs

Partner APIs are technically similar to open APIs, but they feature restricted access, often controlled through a third-party API gateway.

API specifications/protocols

Remote Procedure Call (RPC)

This protocol specifies the interaction between applications based on the client-server architecture.

Service Object Access Protocol (SOAP)

SOAP is a lightweight protocol for exchanging structured information in a decentralized, distributed environment. It is mostly used with enterprise web-based software to ensure the high security of transmitted data.

Representational State Transfer (REST)

The term REST was introduced by computer scientist Roy Fielding in a dissertation in 2000. Unlike SOAP, which is a protocol, REST is a software architectural style with six constraints for building applications that work over HTTP, often web services.
REST is considered a simpler alternative to SOAP, which many developers find difficult to use because it requires writing a lot of code to complete every task and following the XML structure for every message sent. REST follows another logic since it makes data available as resources. Each resource is represented by a unique URL, and one can request this resource by providing its URL.

gRPC

gRPC is an open-source universal API framework. With gRPC, the client application can directly call methods from a server application located on a different computer as if it was a local object. This makes it easier to create distributed services and applications.

GraphQL

The need for faster feature development, more efficient data loading due to increased mobile adoption, and a multitude of clients, made the developers look for other approaches to software architecture. GraphQL, initially created by Facebook in 2012 for internal use, is the new REST with organizations like Shopify, Yelp, GitHub and Coursera using it to build APIs.
GraphQL is a query language for APIs. It allows the client to detail the exact data it needs and simplifies data aggregation from multiple sources, so the developer can use one API call to request all needed data. Another special feature of GraphQL is that it uses a type system to describe data.

Express + Typescript + Mongoose boilerplate

simple starter for newbies.

My main goal with this project is a simple and easy starter for new learners. I like you to be focused on the correct learning path and not spending hours in choosing the right project structure.

Features

Beautiful Code as simple as possible.

Clear Structure inspired by MVC Model.

Localization implemention.

Authorization CRUD example.

project structure



src\

    |--mvc


        |--models\              # Mongoose models (data layer)

        |--routes\              # Views routes

        |--controllers\         # Route controllers (controller layer)

        |--middlewares\         # Custom express middlewares

    |--helpers\             # Utility functions

    |--app.js               # Express app

    |--init\                # Init Express app

        |--locales\             # translation maps

        |--db.ts                # Init DB Connection

        |--localize.ts          # Init localization

        |--routes.ts            # Init Routes

        |--thApp.ts             # Express app

|--index.ts             # App entry point

about NodeJS

Node.js is an open source, cross-platform runtime environment for developing server-side and networking applications, built on Google Chrome's JavaScript Engine (V8 Engine). Node.js was developed by Ryan Dahl in 2009.

about Express

Express is a minimal and flexible Node.js web application framework that provides a robust set of features to develop web and mobile applications. It facilitates the rapid development of Node based Web applications.
Some of the core features of Express framework:

Allows to set up middlewares to respond to HTTP Requests.
Defines a routing table which is used to perform different * * actions based on HTTP Method and URL.
Allows to dynamically render HTML Pages based on passing arguments to templates.

More Info about Express Available from here

about MongoDB

MongoDB is a document database designed for ease of application development and scaling.

MongoDB stores data as JSON documents.

The document data model maps naturally to objects in application code, making it simple for developers to learn and use.

The fields in a JSON document can vary from document to document. Compare that to a traditional relational database table, where adding a field means adding a column to the database table itself and therefore to every record in the database.

Documents can be nested to express hierarchical relationships and to store structures such as arrays.

Then

A collection is a group of documents.

If you are familiar with relational databases, you can think of a collection as a table. But collections in MongoDB are far more flexible. Collections do not enforce a schema, and documents in the same collection can have different fields.

creating a db in mongoose: here

Localization with I18n

Most frameworks leave it to you how translations are being loaded. You are responsible to detect the user language, to load the translations and push them into the framework.

I used i18next which is an internationalization-framework written in and for JavaScript.
with i18next-http-middleware

References:

Basic Concept Of Back-end Web Development. Available from: here
Types of APIs. Available from: here
What is an API. Available from: here
Node.js tutorial. Available from: here
MongoDB. Available from: here

Happy Learning ..
Happy Building ...

How to implement CRUD Concept in daily life?

Nour Abdou — Tue, 15 Nov 2022 13:26:58 +0000

One way to stay productive is to cultivate the mindset that makes the best use of your resources, your time, your energy, your efforts and connecting your knowledge.

CRUD refers to the four basic operations a software application should be able to perform – Create, Read, Update, and Delete; create data, have access to the data in the UI by reading the data, update or edit the data, and delete the data. CRUD apps consist of 3 parts: an API, a database, and a user interface (UI).

Assume that the data is your ideas or tasks, with crud:

Create (a task/idea)
Read (view/read the task/idea)
Update (the task/idea)
Delete (delete the task/idea)

Create (a task/idea)

write down your thought as it pop up to the UI (your mind): a topic to think about deeply, projects ideas, business ideas, monthly/yearly goals or references to a specific to-do list, job applications, useful links, and so on.

Use a notebook for quick ideas/tasks or the Quick Notes on your Mac, that's designed to be a quicker way to jot down things on your Mac without having to go in and out of the main Notes app (keep it in local storage until you call the api to create on database later).

In order to have everything stored and reachable easily (DB), use Notion, ClickUp or any other tool you prefer and use a suitable template which makes it a lot easier to store and sort everything.

Read (view/read the task/idea)

categories your notes to tasks, business idea, projects, to-dos, and so on. So you can review your notes weekly. Or schedule a session to review your ideas in deep.

Update (the task/idea)

During your review sessions, you may change priorities if needed, or add description or a link to a note or a thought.
or even change note category, like from business idea to a to-do list 😍.

Delete (delete the task/idea)

After thinking deeply in a though or doing research on a business idea, you may find it worthless!
So here delete it permanently or just archive it into the forgotten land.

Simple, right? 😌

So Here we go, a productive mindset inspired by CRUD operations which are so fundamental in our tech world.

Thanks for reading 😃

Book recommendation: Clean Code

Nour Abdou — Sun, 13 Nov 2022 20:13:54 +0000

Clean Code: A Handbook of Agile Software Craftsmanship

Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.

Introduction

Even though I read the Clean Code book a while ago and there are a lot of reviews already available, I couldn't resist writing about it a bit.

The Clean Code book makes you feel like why didn’t you come across it before. It's all about writing high quality code, and how to judge the quality of code. With magic points, Encouraging the reader to write natural language code which is understandable by human brain smoothly, with any syntax of any language you use in you project.

As you can't see the right thing without knowing the wrong, the book presents a code that is ugly, hard to read, understand and maintain, then Uncle Bob led the way step by step to refactor that code and transform it into clean, readable, understandable and maintainable code.

Clean Code

No doubt about that messy code can work as long as it does what it's intended to do without logical errors. But this broken windows mentality leads to waste countless hours and resources to update or modify the code.

However, the book gathers thoughts on good code and its various attributes from a number innovators and authors such as Kent Beck, Bjarne Stroustrup, Dave Thomas, etc.

To make the code easy to read, it gives you the golden advice of using intention-revealing names. emphasize to NOT use member prefix such as _ or m_.

And for functions and methods, they should be small and cohesive. It also suggests using single level of abstraction to facilitate reading code from top to bottom.

Single level of abstraction Principle (SLAP); it means that every function / method in your codebase should deal with just one level of abstraction and do one thing, just like Single Responsibility Principle (SRP) mentioned in my previous article about SOLID Principles

In order to explain yourself, you should write good comments that focus on intent and is not redundant and misleading.

Discussing error handling, it encourages use of exceptions rather than return codes or error codes. It prohibits use of checked exceptions as it violates open/closed principle (one of SOLID principles, read here). It also discourages returning or passing null.

It pays great attention to unit testing and test-driven development (TDD) which is one of the main phases of the development cycle.

Fun thing that the book includes a lot of blank pages with "This page intentionally left blank"; they are after each chapter; to make you stop and think little more longer.

Annoying thing for me that the book contains large number of code examples (that I skip sometimes 😅🥹), which is wonderful for sure to clarify rules and advices and so on.

Conclusion

It's a must-read book for programmers, some of the outcomes of reading it, the ability to:

Write good code and clean bad code.
Differentiate between good and bad code.
Increase your code readability.
Build reusable entities.
Get used to explain yourself by good comments.
Build elegant functions and components.
fit error handling to your code logic.
Unit test for a shorter dev cycle.
Practice TTD.

Thanks for reading! 😄

SE SOLID Principles For React/ React Native

Nour Abdou — Sat, 12 Nov 2022 11:16:39 +0000

Clean Architecture = Debt-free software.

Table of content:

Introduction
SOLID principles
Conclusion
References

Introduction

The best practices and good software design principles emerge and conceptualize to avoid repeating mistakes amap, and SOLID is unquestionably one of the more influential ones.

The tell-tale signs of poor architecture

The design of many software applications begins as a vital image in the minds of its designers. At this stage it is clean and elegant.
However, there are four primary symptoms that tell us that our designs are rotting:

Rigidity; the tendency for software to be difficult to change.
Fragility; the tendency of the software to break in many places every time it is changed.
Immobility; the inability to reuse software from other projects or from parts of the same project.
Viscosity; comes in two forms: viscosity of the design (When the design preserving methods -for making a change- are harder to employ than the hacks), and viscosity of the environment (when the development environment is slow and inefficient).

Also, if our designs are failing due to the constant rain of changing requirements, it is our designs that are at fault. We must somehow find a way to make our designs resilient to such changes and protect them from rotting.

Background

The SOLID principles were first introduced by the famous Computer Scientist Robert J. Martin (a.k.a Uncle Bob) in his paper [1] in 2000. But the SOLID acronym was introduced later by Michael Feathers.

The SOLID acronym stands for:

Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

SOLID principles

So, as Dr. Milan Milanović Mentioned in a post 𝗛𝗼𝘄 𝗧𝗼 𝗕𝗲𝗰𝗼𝗺𝗲 𝗔 𝗚𝗿𝗲𝗮𝘁 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿?, you should learn 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 concepts, such as: Software architecture, Design patterns & SOLID, etc.
And HERE WE GO... 😍

1. What is the Single Responsibility Principle (SRP)?

There should never be more than one reason for a class to change.

This means that an entity (function/module/component) should do only one thing, changes should not impact the overall system.

⚛ In React world:

Every component should solve a specific problem!
To ensure that our components are small and single purpose, we can:

Separating Data Processing Logic From the Code

One of the possible strategies is to create a custom hook for data fetching and filtering logic outside the component.

Separate the Code of Data Fetching to Make it Reusable

like making two separate hooks for Fetching data & Filtering data.

Decompose UI Components

Let's say we have a profile screen contains the following sections:
Main info, Settings, Details, etc.
Here, separate the code of the screen into different components for each section.

So, the same component should NOT holds state, fetches data, and renders the result. These are more responsibilities than it should have, and it will be very fragile after multiple changes.

2. What is the Open-Closed Principle (OCP)?

Software entities should be open for extension, but closed for modification.

In other words, it means the ability to add new functionality without touching the existing code for the entity to prevent the risk of creating potential bugs.

⚛ In React world:

It’s related to Kent C. Dodds’s “apropcalypse”:

Unfortunately, truly maintainable, flexible, simple, and reusable components require more thought than: “I need it to do this differently, so I’ll accept a new prop for that.”

Seasoned React developers know this leads to nothing but pain and frustration for both the maintainer and user of the component.

Assume that you have an Input component, for now its props are: the label text, value & onChange func. These props can grow into large set of props, such as: icons, multiple custom labes, custom styles, focus & blur funcs, help & error texts, and so on.

So the right way to start an extensible component is to use composition from the beginning; separate components for Input container, Input box, Label, Icons, Helping/error text, etc.

<InputContainer ...props>
    <InputLabel ...props />
    <InputPreAddon ...props />
    <Input ...props />
    <InputPostAddon ...props />
</InputContainer>

This way, the Input component would be closed for modifications (no need for adding too much extra props) and open for extension (adding more components on need)

3. What is the Liskov Substitution Principle (LSP)?

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

A parent should be substitutable for its child without any problem, in order to strengthen consistency so that parent and children can be used in the same way without any errors.

⚛ In React world:

The main takeaway from this principle is to use TypeScript. You can easily swap components if they share the same contract; like when two components use the same exact Props Interface.
Whenever a component uses another component, it shouldn’t break its functionality (or create any surprises), here's how:
when a component has "string" prop, but you pass it as an object! obviously the code is perfectly fine without compilation error, BUT the application is crashing!

Now we'll see the importance of using TypeScript; If you want to pass anything that’s not a valid component to render (like rendering object on Text component), we will get a Type error. 😉

And now, component that want to use another component need to follow its contract so that they don’t create any unexpected behavior.

4. What is the Interface Segregation Principle (ISP)?

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

Classes should not be forced to implement a function they do no need in order to reduce unexpected bugs when the Class can't execute an action

⚛ In React world:

To remove unnecessary code from a component, We split actions into smaller sets so it only perform the actions it requires.

In other words, We need to pass only the relevant information to the children components.

if you have a user object contains personal info & social accounts

const user = {
  name : "user name",
  age : "60",
  address : "user address",
  facebook : "Facebook user", 
  linkedIn : "linkedIn user"
}

However, it uses two components: PersonalDetails & SocialAccounts to show the details

return <>
        <PersonalDetails user={user} />
        <SocialAccounts user={user} />
 </>

So the PersonalDetails component doesn't need socials and the SocialAccounts component doesn't need personal details to function so it’s clearly violating the Interface Segregation Principle.

To solve the issue, you can break down user object with new keys and pass the appropriate parts to the respective components only

const user ={

  personalDetails : {
     name : "user name",
     age : "60",
     address : "user address"
  },
  socialAcounts : {
     facebook : "Facebook user", 
     linkedIn : "linkedIn user"
  }
}

5. What is the Dependency Inversion Principle(DIP)?

Depend upon abstractions, [not] concretions

The principle states:

High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces).
Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

We want our classes to be open to extension (OCP), so we have reorganized our dependencies to depend on interfaces instead of concrete classes.

⚛ In React world:

One Component shouldn’t directly depend on another Component, but rather they both should depend on some common abstraction.
OR
No component or function should care about how a particular thing is done

Let's say you would want your app to make use of a payment gateway like Stripe.
You should depend on an Interface Payment component (which does NOT care about how online payment done) instead of concrete Stripe Payment component, so you can switch easily to another gateway in the future.

Conclusion

In Software development, the SOLID principle works as a guideline for developers.

In this article, we’ve seen how by having some flexibility with interpretations of SOLID principles, we managed to apply them to our React Flow & Logics and make it more clean, maintainable and robust.

You should keep these principles in mind. But it’s important to remember, that you as a software developer should draw your own conclusions based on your own research.
Thus, make sure you understand their definitions and what they do, then if you think they could be beneficial to your projects, try the methodology!

Frameworks are temporary but concepts are permanent

Hope SOLID principles are clear to you now. 😍

References

Robert C. Martin, Design Principles and Design Patterns. Available from: here
Yiğit Kemal Erinç, The SOLID Principles of Object-Oriented Programming Explained in Plain English [Internet]. freecodecamp. Available from: here
Joel Olawanle, SOLID Principles for Programming and Software Design [Internet]. freecodecamp. Available from: here
Josué Rodríguez, SOLID Principles Series. dev. Available from: here
Anuupadhyay, How To Use Single Responsibility Principle in ReactJS?. geeksforgeeks. Available from: here
Eduardo Moniz, Applying SOLID to react. medium. Available from: here
Mohammad Faisal, How to Apply Interface Segregation Principle in ReactJS. medium. Available from: here

Solution of "Could not resolve all artifacts for configuration ':react-native-iap:classpath'"

Nour Abdou — Thu, 10 Nov 2022 09:39:20 +0000

Error

Issue Scenario:

After updating react-native-iap to resolve this issue on google play:
We've detected that this app uses an unsupported version of Play Billing. Please upgrade to Billing Library version 4 or newer to publish this app

The following error will raised for old RN version:
Could not resolve all artifacts for configuration ':react-native-iap:classpath'.
Could not resolve org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.0.

Solution

1- Add the following to `android/build.gradle`

buildscript {
    ext {
        ...
        kotlinVersion = '1.5.0' //<-- add this
    }
    ...
    dependencies {
       ...
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlinVersion" //<-- add this

    }
}

2- To prevent `app:debugRuntimeClasspath` error

add this line to android/app/build.gradle

android {
    ...
    defaultConfig {
        ...
        missingDimensionStrategy ('store', 'play') //<-- add this
    }
    ...
}

If the following error raised:

Execution failed for task ':react-native-iap:compilePlayDebugKotlin'. >Compilation error.
change kotlinVersion in step-1.

Happy Coding 😍
Happy Building 😌

Solution of Android resource linking failed in React Native

Nour Abdou — Tue, 08 Nov 2022 16:33:30 +0000

ERROR

Android resource linking failed error raises by some forms like:

AAPT: error: resource android:attr/lStar not found
error: method does not override or implement a method from a supertype @Override
AAPT: error: resource android:attr/lStar not found.

EXPLANATION

It often raises due to transitive dependencies for old RN projects.

However, upgrading react-native version is broken. because each installed package with npm or it's dependencies could be using newer version of react-native or even the latest one.
(check this 'com.facebook.react:react-native:+' in android/app/build.gradle)
So, endless problems can bomb when you try to change packages to your current RN version.

Any way, upgrading existing projects is expensive Dude! 😌

SOLUTION

Don't change versions...
Add the following block to the end of android/build.gradle file

subprojects {
    configurations.all {
        resolutionStrategy {
            force 'com.facebook.react:react-native:${YOUR_RN_VERSION}'
        }
    }
}

And that's it! 😃

Happy Coding 😍
Happy Buildin 😌

DEV Community: Nour Abdou

React Native OTA Updates with Expo EAS: Step-by-Step Guide & Best Practices

In-Depth Analysis of OTA Updates: Capabilities, Benefits, and Limitations

📌 Capabilities of OTA Updates

📌 Benefits of OTA Updates

📌 Limitations of OTA Updates

Configure EAS Update

Prerequisites:

1- Set up EAS Update

2. Configuring a Channel

Manually

3. EAS Update Command Reference

Manage updates

Create and Publish a New Update:

Rollback an Update

Republish a Previous Update Within a Branch

Manage Channels and Branches

4. Add a hook to check for updates

5. Create a build for your project

6. Make changes locally

7. publish an update

8. Test

Configure a Custom Expo Updates Server

Summary

React Native Under the Hood: How Your JS, iOS, and Android Code Run Together?

The Flow

JavaScript (The Brains 🧠)

📌 TypeScript to JavaScript Transformation (Build Time)

📌 JavaScript Bundling (Build Time)

📌 Running the JavaScript (Runtime)

Execution JS Engine (JavaScriptCore vs. Hermes):

iOS (Swift/Objective-C - The Looks & Feel on Apple🍎)

Android (Kotlin/Java - The Looks & Feel on Android 🤖)

📌 Communication: The Bridge / JSI (Runtime)

📌 Native Modules and Native Components (Runtime)

Running the application on the device

Fixing App Installation Issues on Older Android Versions: Multiple APKs & ABI Splitting

Problem statement

Proposed solution

Regarding Multiple APKs support

How multiple APKs work

API Level Considerations

Rules for multiple APKs

Assigning Version Codes

Split APKs Based on ABI

📚 References

How React Native works internally?

Table Of Contents:

Introduction

Old React Native architecture & Threading Model

Architecture

Native side

Javascript side (JS VM)

React Native Bridge

Source:Hackernoon

Threading Model

UI Thread/Main thread (Native Queue)

Shadow Thread

JavaScript thread (JS Queue)

Working process

Old Architecture's Issues​

New Architecture's Improvements

New React Native architecture & Threading Model

Fabric Renderer

Render

Commit

Mount

Threading Model

UI Thread/Main thread

JavaScript thread

Background thread

Conclusion

References

Express + Typescript + Mongoose boilerplate

Introduction

Backend development

Tools used in backend development

About API

Types

Open APIs

Source:`Hackernoon`

Old Architecture's Issues

1- Add the following to `android/build.gradle`

2- To prevent `app:debugRuntimeClasspath` error