Coder Legion - Recent posts tagged mobile-development

From C# Backend to Android: Why My First Mobile App in Kotlin Clicked

Mon, 12 Oct 2026 08:10:01 +0000

Moving from backend C# and enterprise patterns into native mobile development can feel like stepping into a whole new world. But after building my very first mobile app using Kotlin, the experience was a revelation—the syntax felt natural, the developer tooling was sharp, and the results were immediate.

Coming from a C# background, Kotlin doesn't feel foreign at all; it feels like an alternative timeline of modern object-oriented and functional programming.

Key Benefits That Stand Out for C# Developers

Familiar Null Safety: Just like C#'s nullable reference types, Kotlin barks at nullability at compile time. Using the ? operator and safe-call operators keeps runtime crashes like NullPointerException (the Java equivalent of NullReferenceException) off your production apps.
Coroutines vs. Async/Await: If you are used to C#'s async/await pattern and channels, Kotlin's coroutines feel instantly intuitive. They make non-blocking UI rendering, API fetching, and background processing clean, sequential, and easy to reason about.
Radical Conciseness with Data Classes: Where a C# record or class with properties can still require a few lines, Kotlin's data class automatically generates equals(), hashCode(), and toString() methods in a single line of code.
Extension Functions: Just like C# extension methods, Kotlin lets you add new behavior to existing classes without inheritance or boilerplate decorator wrappers.
Modern UI Development: Paired with Jetpack Compose (or Compose Multiplatform), Kotlin allows you to build declarative user interfaces—similar to modern Web or XAML/MAUI approaches—making responsive layouts for different device sizes straightforward.

Key Technical References for C# Developers

When diving deeper into Kotlin from .NET, the following official references and standards are worth bookmarking:

Language Specification & Core Standards:
Kotlin Standard Library API Reference (kotlin-stdlib): Provides core data structures, scoping functions (let, apply, also, run), and extension functions.
Kotlin Language Specification: Covers fundamental compiler behaviors, type inference, subtyping, and execution semantics.

Concurrency & Jetpack Tooling:
Kotlin Coroutines Specification & Guide: Formal reference for structured concurrency, flows, and channels.
Android Jetpack Compose Documentation: Official toolkit for building native Android UIs declaratively with Kotlin.

The Takeaway

Building that first mobile app proves that backend principles—clean architecture, strong typing, and smart asynchronous design—translate directly into mobile development. Kotlin bridges the gap perfectly, giving C# developers a powerful, highly productive stack for native mobile apps.

I built a habit tracker that doesn’t track anything

Tue, 29 Sep 2026 12:51:03 +0000

I get distracted easily.

And I have exactly the same problem with habits.

Every day brings a new urgent task. By the end of the day, there’s often neither the time nor the energy left for the things I actually wanted to do consistently.

At some point, I realized I didn’t need yet another habit tracker with a giant calendar, streaks, and progress charts.

I just needed to see one thing:

what matters today.

For example, I want to go to the gym three times a week.

If I’ve already been three times, why should the app keep showing me that workout for the rest of the week?

Or Portuguese. I only have time to study on Wednesdays and Fridays. So why would I want to see that task on Monday?

That’s why I built Yet Another Habit.

The app only shows the activities that are relevant today.

Not today? Don’t show it.

Already completed the required number of times this week? Don’t show it anymore.

Didn’t get to it today? Just skip it. The activity will come back on the next day when it actually matters.

And there’s one more thing I left out on purpose:

there are no stats.

No fancy charts, no streaks, no reports reminding you what a terrible person you’ve been for the last 27 days.

I think that when you’re building a habit, the process matters more than constantly measuring the result.

You open the app, see what matters right now, and focus on that.

I originally built Yet Another Habit just for myself, but eventually decided to share it and released it on the App Store.

🌱 Website: https://izebit.com/yet-another-habit/
App Store: https://apps.apple.com/br/app/yet-another-habit/id6809048979

Track. Don’t judge. Repeat.

Building Trucker Suite: When “One More App” Isn’t the Answer

Mon, 28 Sep 2026 21:56:30 +0000

For nearly eight years, I’ve worked as an over-the-road truck driver.

That means a normal workday can involve far more than simply driving from Point A to Point B. A commercial driver is constantly balancing Hours of Service, appointment times, detention, fuel, routing, parking, mileage, weather, traffic, pay, and the question that sits underneath all of it:
Can I actually complete this trip legally, safely, on time, and without destroying what the load is worth?

There are already applications that solve pieces of that problem.

There are truck-navigation apps. ELD systems. Fuel-price apps. Parking apps. Load calculators. Payroll tools. Detention trackers.

The problem I kept running into wasn’t necessarily that a tool didn’t exist.
The problem was that the tools didn’t understand each other.

That realization eventually became Trucker Suite.

It Started Much Smaller

Trucker Suite did not begin as some enormous transportation platform.

The first version was a collection of practical Android tools I wanted for myself.

DockClock tracks detention time and calculates expected detention pay.

LoadWorth helps evaluate what a load is actually worth instead of looking only at its headline pay.
Pay Week tracks completed work and gives the driver a running estimate of weekly earnings.
Each feature solved a real problem.

But eventually I noticed something important:

I was still treating them like separate applications.

That wasn’t how trucking actually worked.

If I spend another 90 minutes waiting at a shipper, the effect does not stop at DockClock.
That delay may reduce my available driving time.

That may change where I can legally stop for the night.

That shutdown could affect tomorrow’s delivery appointment.

A different shutdown location might require a different fuel stop.

Those changes can alter the mileage, cost, and ultimately the financial value of the trip.

One event can ripple through the entire load.

That became the bigger engineering problem.

From Utilities to a Decision System

The direction for Trucker Suite now revolves around an Active Trip model.

Instead of asking every feature to maintain its own isolated data, the trip becomes the central object.
Conceptually, a trip can contain information such as:

Trip
├── Origin
├── Destination
├── Pickup appointment
├── Delivery appointment
├── Loaded miles
├── Deadhead miles
├── Remaining HOS
├── Fuel state
├── Driver compensation model
├── Detention
├── Planned stops
└── Calculated risk/results

Then individual systems become services working against that shared state.

DockClock should not simply say:
You have been detained for 1 hour and 37 minutes.

It should eventually be able to trigger questions like:

Did the delay reduce the driver's available HOS?

Does the original shutdown location still work?

Can the delivery appointment still be reached legally?

Does a fuel stop need to move?

What happened to expected earnings?

Is the trip now at risk?

That is a much more interesting software problem than building another timer.

The Output I Actually Want

One of the goals is to reduce complicated operational information into something immediately useful.

For example:
TRIP STATUS: AT RISK

Remaining drive time: 3h 42m
Required drive time: 3h 31m
Appointment buffer: 11 min

Primary risk:
Current fuel stop adds approximately 24 minutes.

Recommended action:
Use alternate fuel location and continue to planned shutdown.

Projected appointment buffer after change:
37 minutes

Then imagine the driver adds another 60 minutes of detention.

The system recalculates.

TRIP STATUS: NOT FEASIBLE

Reason:
Remaining HOS is insufficient to reach planned shutdown
and preserve the delivery appointment.

Recommended action:
Notify dispatch of probable service failure and
recalculate after required rest period.

That is where I think Trucker Suite becomes substantially more useful.

It stops being a collection of calculators and starts becoming a decision-support system.

Why This Gets Technically Difficult

The funny part is that many individual calculations are not especially exotic.
Calculating mileage is straightforward.

Calculating remaining drive time is straightforward.

Calculating detention pay is straightforward.

The complexity comes from the relationships between them.

A delay changes time.

Time changes legal feasibility.

Legal feasibility changes routing options.

Routing changes fuel consumption and cost.

Fuel changes trip economics.

Trip economics can change depending on whether the driver is paid by mileage, percentage, hourly pay, or operates their own truck.

And not every input is reliable.

Traffic changes.

Parking fills up.

A receiver may take three hours instead of thirty minutes.

A road closes.

A driver gains HOS after a break.

Eventually this becomes less about finding one correct answer and more about evaluating risk under changing constraints.

That is the part of Trucker Suite I find most interesting as a developer.

Build the Brain Before the Integrations

It would be very easy to start integrating APIs immediately.

Traffic.

Weather.

Commercial routing.

Fuel prices.

ELD data.

Parking availability.

That would make the application look impressive quickly.

It would also be very easy to create an expensive pile of integrations without proving the core idea.
So I’m taking the opposite approach.

The calculation and decision layer should work with manually entered data first.

If the system cannot make a useful decision when I manually tell it:

Miles remaining: 312
Drive time remaining: 5h 48m
Appointment: 07:00
Current delay: 90 minutes
Fuel: 38%

then connecting an API that fills those values automatically will not magically make the system intelligent.

APIs should improve the quality and convenience of the inputs.

They should not be the product.

Designing for Replaceable Providers

Another architectural goal is keeping external services replaceable.

Instead of scattering vendor-specific logic throughout the application, I want integrations to eventually sit behind provider interfaces.

Conceptually:

HOSProvider
├── ManualHOSProvider
├── MotiveProvider
└── SamsaraProvider

RouteProvider
├── ManualRouteProvider
├── ProviderA
└── ProviderB

FuelProvider
├── ManualFuelProvider
└── LiveFuelProvider

That matters for two reasons.

First, API vendors change pricing, capabilities, and access rules.

Second, commercial drivers do not always control the technology their carrier uses.

A driver working for one company might have access to one ELD ecosystem while another driver has something completely different.

Trucker Suite still needs to function when automatic data is unavailable.

Building From the Driver’s Seat

I’m building Trucker Suite while still working as an OTR driver.

That is occasionally inconvenient.

It also gives me something extremely valuable: I live inside the problem I’m trying to solve.

When a dock delay destroys my original trip plan, I can look at that situation as both a driver and a developer.

When I have to decide whether cheaper fuel is actually worth leaving the route for, that becomes another system question.

When dispatch sends a load with an appointment that looks suspiciously tight, I can ask what information software would need to recognize the problem before the driver discovers it the hard way.

A lot of Trucker Suite’s roadmap has come from moments where I caught myself thinking:
“Why am I still doing this calculation in my head?”

What Comes Next

The immediate development target is deliberately narrow.

One trip.

One shared data model.

One analysis screen.

The driver enters the trip, HOS, appointment information, fuel state, and compensation information.

Trucker Suite evaluates it and produces:

FEASIBLE

AT RISK

NOT FEASIBLE

along with an explanation.

Then detention can be changed by 30, 60, or 120 minutes and the system recalculates the trip.
If that works well, the integrations can come afterward.

Commercial routing.

Live fuel.

ELD information.

Traffic.

Weather.

Parking.

But first, the software needs to prove it can reason about the trip.

The Bigger Lesson

Building Trucker Suite has changed the way I think about software products.

Sometimes the opportunity is not creating a brand-new category of data.

It is recognizing that users are already drowning in useful data that lives in separate systems.
The interesting problem becomes connecting those pieces in a way that produces a decision.

For Trucker Suite, the goal isn’t:

Put every trucking application into one screen.

The goal is:

Understand how the pieces affect each other well enough to help the driver decide what to do next.

That is a considerably harder product to build.

It is also the product I wish I had every time something goes wrong on the road.

How to Fix EAS Build Failed Errors in Expo

Tue, 11 Aug 2026 11:46:41 +0000

There is a particular kind of Expo error that I think almost every developer eventually runs into.

You make a change to your project, run your usual build command:

eas build

and instead of getting a nice .apk or .aab at the end, you get:

Build failed

And that's it.

Well, not really.

If you open the build logs, you get several hundred lines of output containing Gradle tasks, Android dependencies, warnings, stack traces, environment information, and somewhere in the middle of all of that is the actual reason your build failed.

I've been there more times than I'd like to admit.

The frustrating part is that "EAS Build failed" isn't really an error by itself. EAS is just telling you that something went wrong during the build. The actual problem can be a completely different issue.

It might be an Android dependency conflict.

It might be a missing environment variable.

It might be an invalid app.json configuration.

It might be a native package that doesn't work with your current Expo SDK.

Or it might be something as simple as a credentials problem.

So instead of trying random fixes, let's go through how I approach these failures and how to find the actual cause.

First: Don't Focus on "EAS Build Failed"

When you see:

Build failed

it's tempting to search for that exact phrase.

The problem is that thousands of completely different problems can end with the same message.

EAS Build is responsible for building your application. It isn't necessarily responsible for the thing that broke.

For example, your log might eventually contain:

Execution failed for task ':app:mergeDexDebug'

That's an Android dependency/build problem.

Or:

Could not resolve all files for configuration

That's pointing toward dependency resolution.

Or you might see something related to:

Missing environment variable

That's an environment/configuration problem.

And if you see something related to signing credentials, you're dealing with an entirely different category of failure.

The first thing I do is therefore ignore the generic "Build failed" message and find the first meaningful error underneath it.

1. Open the Full EAS Build Logs

Start by looking at the failed build in the EAS dashboard.

You can also list recent builds from your terminal:

eas build:list

Find the failed build and open its logs.

Don't just look at the last few lines.

The last line might say:

Build failed

but that doesn't tell you much.

Instead, search through the logs for terms such as:

ERROR
FAILURE
Error:
Caused by:
Exception
Could not
Unable to

The useful error is often somewhere above the final failure message.

For example, imagine the bottom of your log looks like this:

> Task :app:mergeDexRelease FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:mergeDexRelease'.

> com.android.builder.dexing.DexArchiveMergerException:
  Error while merging dex archives

BUILD FAILED

Build failed

The useful information isn't really:

Build failed

It's:

Execution failed for task ':app:mergeDexRelease'

and whatever caused the DEX merge to fail.

That distinction saves a lot of time.

2. Check Whether the Problem Is Actually Your Expo Configuration

One of the first things I check after an EAS build fails is the project's configuration.

Depending on your setup, this can include:

app.json
app.config.js
app.config.ts
eas.json

A small configuration mistake can prevent the native project from being built correctly.

For example, if you've recently changed:

{
  "android": {
    "package": "com.example.myapp"
  }
}

or added a plugin:

{
  "plugins": [
    "some-native-package"
  ]
}

and the build immediately started failing, that change is worth investigating.

The same applies to permissions, native configuration, app identifiers, and Expo config plugins.

If the failure started immediately after a configuration change, don't assume the EAS service itself is broken.

Look at what changed in your project first.

3. Check Your Expo SDK and Native Dependencies

This is one of the biggest sources of trouble I've encountered with Expo projects.

Expo SDK versions are tied to specific versions of React Native and a collection of native dependencies.

You can have a perfectly valid JavaScript project and still break the native build by installing a package that doesn't fit your current environment.

For example:

npm install some-package

looks harmless.

But if that package contains native Android or iOS code, it becomes part of your native build.

That's where things can get interesting.

Before randomly upgrading packages, check your project:

npx expo-doctor

This can identify common dependency and configuration problems.

If you're using Expo, I also recommend using Expo's package installation command when appropriate:

npx expo install package-name

rather than blindly installing a version with npm.

Expo can select a version that is compatible with your current SDK.

4. If the Error Mentions Gradle, Investigate the Android Build

Sometimes an EAS failure is actually an Android build failure hiding underneath Expo.

For example:

Execution failed for task ':app:mergeDexRelease'

or:

Could not resolve all files for configuration

or:

Duplicate class found

These are not really "Expo errors."

They're Android/Gradle dependency problems occurring during your Expo build.

This distinction matters because searching for:

EAS Build failed

will give you a huge number of unrelated results.

Searching for:

Execution failed for task mergeDexRelease React Native

is much more useful.

That's generally how I approach these logs: follow the most specific error rather than the generic EAS failure.

5. Check Your Environment Variables

Another surprisingly common cause of failed builds is an environment variable that exists locally but doesn't exist in EAS.

For example, your application might expect:

API_URL
SUPABASE_URL
SUPABASE_ANON_KEY

Your local development environment works because those variables exist in your .env file.

Then you create an EAS build and suddenly something breaks.

Why?

Because the remote build environment doesn't automatically have every variable from your local machine.

Check your EAS environment configuration:

eas env:list

Make sure the variables your application actually needs are available in the environment being used for the build.

This is especially important if the failure happens only on EAS while:

npx expo start

works perfectly locally.

6. Check Your EAS Build Profile

Your eas.json determines how your builds are configured.

A typical configuration might look something like:

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

If the problem only happens with one profile, compare that profile with the one that works.

For example:

eas build --profile preview

might work while:

eas build --profile production

fails.

That immediately gives you another clue.

The problem may not be your entire project. It may be something specific to the build profile.

7. Don't Ignore Credentials Errors

If the log mentions things such as:

credentials
keystore
provisioning profile
certificate
signing

don't start changing Gradle dependencies.

You're probably dealing with app signing or build credentials instead.

For Android, EAS can manage your app signing credentials for you.

You can inspect the credentials with:

eas credentials

If the error is specifically about signing, work through the credential configuration rather than treating it like a code or dependency problem.

This is one of those situations where identifying the category of the error is much more useful than knowing a particular command.

8. If It Worked Before, Ask What Changed

This is probably my favorite debugging question:

What changed immediately before the build started failing?

Don't underestimate how useful this is.

If yesterday you had:

EAS build → SUCCESS

and today you have:

EAS build → FAILED

something changed.

Maybe you:

installed a package
upgraded Expo
changed app.json
changed eas.json
modified environment variables
changed an Android dependency
added a config plugin
changed native code

Start there.

For example, if the failure appeared immediately after:

npx expo install some-package

I would investigate that package before touching ten unrelated parts of the project.

9. Clean Up Before Rebuilding

If you've already made changes trying to fix the problem, make sure you're not debugging an old local state.

For a native project, a clean build can sometimes help:

cd android
./gradlew clean
cd ..

For Expo projects using prebuild, you may also need to regenerate native projects depending on your setup.

But don't use cleaning as your first response to every error.

If the build is failing because a dependency is genuinely incompatible, cleaning won't magically make the dependency compatible.

It only removes cached/generated build artifacts.

The Most Important Part: Find the Root Error

This is the part that took me the longest to appreciate.

When a build log contains hundreds of lines, the error at the bottom isn't necessarily the error you need to fix.

For example:

Task :app:assembleRelease FAILED

is not particularly useful.

Neither is:

Build failed

The useful part might be 30, 50, or even 200 lines above it.

You might eventually find:

Duplicate class androidx.lifecycle.ViewModel

And suddenly the whole situation makes sense.

Or:

Could not resolve com.google.firebase:...

Now you're dealing with a dependency resolution problem.

Or:

Missing environment variable: API_URL

Now you know exactly where to look.

The final error tells you that the build stopped. The underlying error tells you why.

What If Your Error Doesn't Match Any Of These?

This is where things get much more frustrating.

You can search the exact error message and find ten different Stack Overflow answers.

One says to upgrade Gradle.

Another says to delete node_modules.

Another says to run expo prebuild --clean.

Someone else says to downgrade React Native.

And suddenly you're changing five different things without knowing which one actually matters.

I've made that mistake myself.

The problem with large React Native and Expo build logs is that they often contain a lot of information but very little prioritization.

You don't necessarily need another list of 15 possible fixes.

You need to know:

Which part of this particular log is actually causing the failure?

That's also the problem I wanted to solve with FixMyError.

Instead of manually digging through a huge React Native or Expo error log and trying to decide which line matters, you can paste the log into FixMyError and get a focused diagnosis aimed at identifying the most likely cause and the first fix worth trying.

It's particularly useful when your error doesn't fit neatly into one of the common categories above and you're staring at a wall of Gradle, Expo, or native build output wondering where to even start.

You don't need to use it for every error. If the log clearly tells you what's wrong, fix it and move on.

But when the useful information is buried somewhere inside a massive build log, that's exactly when a diagnostic tool becomes useful.

A Simple Workflow I Use Now

When an Expo EAS build fails, I don't immediately start changing dependencies or upgrading packages.

I go through this:

1. Find the actual failure

Don't stop at:

Build failed

Find the underlying error.

2. Identify the category

Is it:

configuration?
dependency?
Android/Gradle?
iOS/Xcode?
environment variables?
credentials?
native module compatibility?

3. Ask what changed

What did you install, upgrade, or modify immediately before the failure?

4. Check the full log

Don't assume the last error line is the root cause.

5. Run the relevant diagnostic tools

For example:

npx expo-doctor

and inspect your EAS configuration and dependencies.

6. Change one thing at a time

Don't simultaneously upgrade Expo, downgrade Gradle, delete node_modules, regenerate native projects, and change your dependencies.

If the build starts working afterward, you won't know what actually fixed it.

7. If the log is still unclear, diagnose the log itself

That's where a tool like FixMyError can save time.

Final Thoughts

An EAS Build failed message can look like a single problem, but it really isn't.

EAS is just the environment where the failure becomes visible.

The actual cause might be hiding in:

Expo configuration
native dependencies
Gradle
Xcode
environment variables
credentials
config plugins
or a package that isn't compatible with your current SDK

The biggest improvement you can make to your debugging process is to stop treating:

Build failed

as the error.

Treat it as the symptom.

Then work backward until you find the first specific failure that actually explains what happened.

And if you're staring at a huge build log and can't tell which of the hundreds of lines actually matters, that's precisely the kind of situation where having something analyze the error for you can be useful.

Happy debugging.

How to Fix `Execution failed for task ':app:mergeDexDebug'` in React Native

Tue, 04 Aug 2026 12:27:52 +0000

You make a small change to your React Native project, install a new package, or upgrade a dependency. Everything looks fine until you try to build your Android app.

Then Gradle stops with something like:

Execution failed for task ':app:mergeDexDebug'.

> com.android.builder.dexing.DexArchiveMergerException:
Error while merging dex archives

Or maybe you see:

Cannot fit requested classes in a single dex file

or:

Duplicate class found

At first glance, this error feels confusing because it happens during the Android build process, not inside your JavaScript or React Native code.

Your components are fine. Your logic is fine.

The problem is usually somewhere inside your Android dependencies.

In this guide, we will go through what causes mergeDexDebug failures, how to identify the real problem, and the fixes that actually work.

What Does `mergeDexDebug` Actually Mean?

When you build a React Native Android app, your JavaScript code is not the only thing being packaged.

Your project also includes native Android dependencies from:

React Native modules
Expo packages
Firebase libraries
AndroidX libraries
Third-party native packages

During the Android build, Gradle converts these Java/Kotlin dependencies into DEX files that Android can run.

The mergeDexDebug task is the step where Android combines those generated DEX files together.

When this step fails, it usually means:

there are too many methods to fit into one DEX file
two dependencies contain the same classes
dependency versions are conflicting

Cause 1: Your App Has Too Many Methods (64K Limit)

One of the most common reasons for this error is Android's method limit.

A single DEX file can only contain around 65,536 methods.

If your project includes many libraries, you can eventually exceed this limit.

The error usually looks like:

Cannot fit requested classes in a single dex file

or:

The number of method references in a .dex file cannot exceed 64K

This happens frequently in projects using packages like:

Firebase
Google Play Services
Maps
Analytics libraries
Multiple native modules

Fix: Enable Multidex

Open:

android/app/build.gradle

Find:

defaultConfig {
}

Add:

defaultConfig {
    multiDexEnabled true
}

Then add the multidex dependency:

dependencies {
    implementation 'androidx.multidex:multidex:2.0.1'
}

After that, clean your build:

cd android
./gradlew clean
cd ..

Then rebuild your app.

Cause 2: Duplicate Classes Between Dependencies

Another common reason is dependency duplication.

You may see something like:

Duplicate class androidx.lifecycle.ViewModel found in modules:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

and

androidx.lifecycle:lifecycle-viewmodel-ktx:2.6.1

This means two libraries are trying to include different versions of the same Android classes.

Gradle does not know which one should be used, so the build fails.

Fix: Align Dependency Versions

Check your Android dependencies.

You can inspect your dependency tree with:

cd android
./gradlew app:dependencies

Look for libraries that appear multiple times with different versions.

For example:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

androidx.lifecycle:lifecycle-viewmodel:2.6.1

The solution is usually to make all related dependencies use the same version.

After updating dependencies, run:

./gradlew clean

and rebuild.

Cause 3: A Recently Installed Native Package Introduced Conflicts

Sometimes the problem appears right after installing a package.

For example:

npm install some-native-library

Everything works until the next Android build.

This happens because native packages are not only JavaScript code. They also add Android dependencies.

A new package can introduce:

conflicting AndroidX versions
outdated libraries
duplicate classes

If the error appeared immediately after installing something new, that package is the first thing I would investigate.

How To Find The Real Cause Faster

Instead of guessing, get more information from Gradle.

Run:

cd android
./gradlew app:assembleDebug --stacktrace

The important part is usually not the final error line.

The useful information is often several lines above it.

Look for:

duplicate class names
conflicting library versions
dependency names

The last line often only says:

Execution failed for task ':app:mergeDexDebug'

but the actual reason appears earlier.

Clean Your Android Build Cache

After changing dependencies, Gradle may still use old build files.

Run:

cd android
./gradlew clean
cd ..

For React Native CLI projects:

npx react-native run-android

For Expo projects:

npx expo run:android

A surprising number of build problems disappear after a proper clean rebuild.

Preventing Future `mergeDexDebug` Errors

A few habits can save a lot of debugging time:

Keep dependencies updated

Old native dependencies are a common source of Android build conflicts.

Avoid installing unnecessary packages

Every native package increases the complexity of your Android dependency tree.

Check changes after adding native libraries

If your build breaks immediately after installing a package, don't start changing random Gradle files.

First check what dependency that package introduced.

Understand the error before applying fixes

A mergeDexDebug failure is not one single problem.

It is a symptom.

The real cause could be:

too many methods
duplicate classes
incompatible versions
a broken native dependency

Finding the cause is usually faster than trying random fixes.

Need Help Diagnosing React Native Errors?

Sometimes build errors are frustrating because the important clue is buried inside hundreds of lines of Gradle output.

That is exactly why I built FixMyError — a tool designed around the real debugging process developers go through.

You can paste your React Native or Expo error log and get a focused diagnosis that explains what is likely causing the problem and what fix is worth trying first.

Instead of searching through dozens of similar Stack Overflow answers, you can start with a clearer direction.

You can check it out here:

FixMyError

React Native Android build errors can look intimidating, but once you understand where the failure happens, most mergeDexDebug problems become much easier to diagnose.

The key is not memorizing commands.

It is learning how to read what Gradle is actually telling you.

Heisenbugs

Tue, 28 Jul 2026 16:39:58 +0000

This story is about the illusion we face when it comes to facing certain types of bugs, you look at it now it’s in one form, you check back and it’s changed completely so you end up like an idiot in front of the whole team.

How to Fix: "Namespace not specified" Gradle 8 Error in React Native & Expo

Thu, 09 Jul 2026 12:45:41 +0000

Fixing the "Namespace Not Specified" Error in React Native and Expo Android Builds

If you recently upgraded a project to React Native 0.73+ or bumped your Expo SDK to version 50+, you may have run into an Android build error that looks something like this:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':react-native-some-old-library'.

> Namespace not specified for group 'react-native-some-old-library'
  and version '1.0.0' as per the Android Gradle Plugin 8.0+ guidelines.

At first glance, it looks like something is wrong with your app. In most cases, it isn't.

The error is usually coming from an older dependency inside node_modules.

Here's what's actually causing it and how to fix it properly.

The Root Cause

Before Android Gradle Plugin (AGP) 8.0, Android libraries could define their package name inside AndroidManifest.xml.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.someoldlibrary">

Starting with AGP 8.0, that is no longer enough.

Every Android module is now expected to define a namespace inside its build.gradle file.

When you upgrade React Native or Expo, your Android tooling gets upgraded as well. The problem is that many older React Native libraries haven't been updated to follow the new requirement.

As soon as Gradle encounters one of those libraries, it stops during configuration and the build fails.

This started showing up much more frequently after Expo SDK 50 and newer React Native releases adopted newer Android tooling.

Before You Change Anything

Look closely at the error message.

Most of the time you'll see something like:

A problem occurred configuring project ':react-native-some-old-library'

That project name is usually the library causing the issue.

A common mistake is to start editing your app's own Gradle files. In most cases, the problem is actually inside the dependency listed in the error.

The Fix: Use patch-package

Since the problem comes from a third-party library, editing files directly inside node_modules isn't a real fix.

The next time you run npm install, your changes will be overwritten.

Instead, make the change once and save it using patch-package.

Step 1: Find the Package Name

Navigate to the library's manifest file:

node_modules/react-native-some-old-library/android/src/main/AndroidManifest.xml

Look for the package attribute:

<manifest
    package="com.someoldlibrary">

Copy that value.

You'll use it as the namespace in the next step.

Step 2: Add the Missing Namespace

Open:

node_modules/react-native-some-old-library/android/build.gradle

Find the android {} block and add the namespace at the top:

android {
    namespace "com.someoldlibrary"

    compileSdkVersion safeExtGet('compileSdkVersion', 34)

    defaultConfig {
        minSdkVersion safeExtGet('minSdkVersion', 21)
        targetSdkVersion safeExtGet('targetSdkVersion', 34)
    }

    // ...
}

Make sure the namespace exactly matches the package name from the manifest.

Step 3: Generate a Patch

From your project root, run:

npx patch-package react-native-some-old-library

This creates a file inside a new patches directory containing the modification you just made.

Commit that file to Git.

Step 4: Apply the Patch Automatically

Open package.json and add a postinstall script:

{
  "scripts": {
    "start": "expo start",
    "android": "expo run:android",
    "ios": "expo run:ios",
    "postinstall": "patch-package"
  }
}

Now whenever someone runs npm install—whether it's you, another developer, CI, or EAS Build—the patch gets applied automatically.

That's It

Clear any caches if needed and run your Android build again.

The build should now complete normally.

More importantly, you won't have to keep making the same edit every time node_modules gets reinstalled.

If you're working with older React Native dependencies, this is usually the cleanest way to handle AGP 8 namespace issues without waiting for the library maintainer to release an update.

How to Fix FCM "MismatchSenderId" in Multi-Environment Expo (EAS) Builds

Sat, 27 Jun 2026 09:03:38 +0000

How to Fix `MismatchSenderId` in Expo EAS Push Notifications Across Multiple Environments

If you are managing multiple environments (Staging, Preview, Production) in a React Native Expo app, setting up Firebase Cloud Messaging (FCM) can quickly turn into a credential nightmare.

You set up separate Firebase projects for each environment, download your config files, and configure your service accounts. Everything looks right. But when you test push notifications on your staging build, you hit a wall:

Error: MismatchSenderId

This error doesn't mean your code is broken. It means you've hit a structural limitation in how Expo EAS handles push credentials.

Here is exactly why this happens and how to architect a clean solution.

Why the Mismatch Happens

The MismatchSenderId error occurs because of a strict identity mismatch:

The device token was generated by Firebase Project A, but the notification payload was dispatched using credentials from Firebase Project B.

In a standard web or backend setup, this is easy to manage. But in the Expo ecosystem, you run into the EAS Project Limit:

Expo maps push notification service accounts per EAS Project, not per EAS Build Profile (development, preview, production).

When you run eas credentials or use the automated CLI prompts, EAS expects one default push notification Service Account (SA) key for the entire project.

If you try to reuse or attach the same service account across different Google Cloud/Firebase projects via IAM permissions, FCM will reject the cross-project token request, throwing MismatchSenderId.

Solution 1: Split Your EAS Projects (Recommended for Clean Automation)

If you want to rely on Expo's automated push notification infrastructure without overriding credentials constantly, the cleanest architectural fix is to separate your environments at the EAS project level.

Instead of one EAS project with multiple build profiles, initialize separate EAS projects in your ecosystem:

your-app-staging
your-app-production

Implementation Steps

In your app.json, dynamically switch the expo.projectId and expo.slug based on an environment variable during your build step:

{
  "expo": {
    "name": "Your App",
    "slug": "your-app-production",
    "extra": {
      "eas": {
        "projectId": "YOUR-PROD-PROJECT-ID"
      }
    }
  }
}

Link your staging build profile to your staging EAS project.

Run eas credentials for each project separately. This allows you to upload the staging FCM Service Account to your staging EAS project, and the production FCM Service Account to your production EAS project.

Solution 2: Bypass EAS and Route Tokens on Your Backend

If separating your EAS projects isn't an option and you need to keep everything under a single Expo App ID, you have to stop relying on Expo's unified push notification server and handle routing downstream.

Implementation Steps

Tag Tokens by Environment

When your app requests a push notification token using Expo.getExpoPushTokenAsync(), append the current build environment metadata before sending it to your database:

const token = await Expo.getExpoPushTokenAsync();

// Save to backend alongside the environment flag
await saveTokenToBackend({
  token: token.data,
  environment: process.env.EXPO_PUBLIC_APP_ENV // 'staging' or 'production'
});

Handle Routing on Your Server

On your backend infrastructure, do not use a single global Firebase initialization instance.

Initialize multiple Firebase Admin SDK instances using the respective service account JSON keys for each environment.

When triggering a notification, check the token's environment tag and dispatch it explicitly through the matching Firebase Admin instance.

Verification Checklist Before Your Next Build

Before you trigger your next EAS build, double-check that your native configuration files aren't bleeding into each other:

Config Plugins: Ensure your app.json or app.config.js uses a dynamic config plugin to load google-services.json (Android) and GoogleService-Info.plist (iOS) based on the target build profile. If your staging build accidentally bundles the production google-services.json, your token identities will instantly mismatch.
Sender IDs: Verify that the sender ID inside your bundled client-side Firebase config explicitly matches the project ID of the service account used by your notification server.

I actually built a quick web tool called Fix My Error to automate troubleshooting these kinds of React Native, Expo, and Gradle build traps. If you're stuck on a cryptic error log, feel free to drop it in there to grab the configuration fix.

Fskin alpha version is Live

Thu, 25 Jun 2026 08:39:15 +0000

Every Flutter dev has been here.
Design changed the primary color.
You open the codebase.
You update the hex.
You build.
You submit.
You wait. a full day for a color.

There’s a better solution now: Fskin

I built flutter_skin. Publish from a dashboard and the App updates on realtime No build. No review. No restart.

Alpha is live today.

How AI Chatbots and Voice Assistants Are Integrated Into Mobile Apps

Tue, 02 Jun 2026 12:04:07 +0000

Quick Overview

AI chatbots and voice assistants are now essential features in modern
mobile applications, not just extras.
Integration happens through NLP engines, cloud APIs, on-device ML
models, and conversational UI frameworks.
Key technologies involved include large language models (LLMs),
automatic speech recognition (ASR), text-to-speech (TTS), and intent
classification.
On-device processing is increasing because of privacy demands and
concerns about delays. Voice and chat interfaces are changing how
users navigate, search, and complete tasks in apps.
EEAT signals in this area come from real deployment patterns, not
just theoretical use cases.

You open a banking app and ask, "What did I spend on groceries last month?" Within seconds, you get a categorized breakdown with a chart—no menus, filters, or frustration. This seamless experience results from a well-designed system linking your input to a language model, data query, and mobile response generator. While most users don't think about what's behind this, for developers and product teams, understanding how AI chatbots and voice assistants integrate with apps is vital. This article explains how that works.

The Architecture Behind AI Chatbot Apps

The phrase "AI chatbot apps" includes a wide range of options, from a simple rule-based FAQ bot added to a customer service screen to a full conversational agent powered by a fine-tuned LLM with memory, tool-calling, and multimodal input. The architecture varies quite a bit depending on which end of that range you are developing.

At the basic level, most modern implementations follow one of two models:

Cloud-based inference: The app sends user input to a remote API (e.g., OpenAI, Anthropic, Google Gemini), receives a response, and displays it. Latency depends on network conditions, but the model
itself runs on a server.
On-device inference: The model runs locally using frameworks like Apple's Core ML, Google's ML Kit, or Meta's LLaMA.cpp. Latency is lower, and data stays on the device, but the model size is limited.

Most production apps today use a hybrid approach. Lightweight intent classification occurs on-device, while complex generation or retrieval-augmented responses are handled by the server.

For iOS and Android app development, the toolchain differs by platform. iOS developers use Core ML, Create ML, and the Speech framework for voice features. Android developers typically use TensorFlow Lite, ML Kit, and the SpeechRecognizer API. Both ecosystems now support streaming responses. This allows the UI to render text gradually rather than waiting for the model to produce a complete output. This detail significantly impacts perceived performance.

NLP Pipeline: From Raw Input to Structured Intent

When a user types or speaks a query, the app doesn't just send that raw string to a language model and call it finished. There is usually a processing pipeline in between.

Input normalization: Text is cleaned, lowercased, and free of
irrelevant characters. For voice input, the ASR engine, such as
Google's Speech-to-Text or Apple's SFSpeechRecognizer, converts
audio waveforms into text transcripts, handling noise, accents, and
filler words.
Intent classification: A lightweight classifier, often a fine-tuned
BERT variant or a distilled transformer, determines what the user
wants to do. Is this a navigation request? A data query? A
complaint? This step decides which downstream system gets involved.
Entity extraction: Named entities are pulled from the input, such as
dates, product names, account numbers, and locations. This turns
unstructured text into something a database or API can work with.
Fulfillment: The app sends the request to the right backend, whether
it's a database query, a third-party API call, or a generative
model, and retrieves a response.
Response generation and rendering: The output is formatted for the
mobile UI. This may include markdown rendering for a chat bubble, a
card component with structured data, or a spoken response created
using TTS.

This full pipeline is what top mobile app development companies have invested in heavily over the past two years, moving from static chatbot scripts to dynamic, context-aware systems that can handle multi-turn conversations and ambiguous inputs.

Voice Assistant Integration: The Technical Specifics

Voice assistants add complexity that text-only chatbots do not encounter. Audio can be chaotic. Latency can be a problem. Users expect quick feedback, even when the model is still processing.
Wake word detection is usually handled by a lightweight model that continuously listens for a trigger phrase while using minimal battery. Once the wake word is detected, a larger ASR model turns on.

Streaming ASR: It enables the app to start processing transcribed
text before the user has finished speaking. This allows the intent
classifier to run concurrently, reducing response time by hundreds of
milliseconds.
Voice Activity Detection: VAD identifies when the user has stopped
talking; this can be tricky in noisy places. WebRTC and Silero VAD
are two popular libraries for this task.
Text-to-speech: TTS technology has significantly improved. Neural TTS
systems like Amazon Polly, ElevenLabs, and Google WaveNet produce
speech that is hard to distinguish from human recordings. On-device
options are now fast enough for real-time playback, so spoken
responses can start before the generation is complete.

For navigation within apps, voice assistants utilize a slot-filling dialogue model. The assistant asks follow-up questions to complete a task when necessary information is missing. For example, saying "Book a ride" prompts: "Where to?" This approach keeps conversations focused on goals without expecting the user to provide all details at once.

Context Management and Memory in Conversational Apps

One of the toughest engineering challenges in deploying AI chatbot apps is maintaining context during a conversation and across sessions.

In a single conversation, context is managed using a sliding window of message history that is sent to the model with each new request. The challenge comes from token limits. Longer conversations exceed the model's input limits, so developers use strategies such as conversation summarization, which compresses earlier exchanges into a brief summary, or hierarchical memory, which stores key facts separately from the full transcript.

Across sessions, persistent memory needs careful design choices. Some apps keep user preferences, past queries, and behavioral patterns in a user profile database. This information is added to the model's context in each new session. This setup creates the feeling of a "remembering" assistant without needing the model itself to keep state.

Privacy regulations, such as the GDPR, India's DPDP Act, and the CCPA, limit how this memory can be stored, how long it can be retained, and what user consent is required. Responsible implementation requires detailed user controls over what the app remembers.

Conclusion

AI chatbots and voice assistants are now central in mobile apps, becoming the primary way users interact with features. Their integration involves technical decisions like cloud versus on-device processing, data management, and rule-based versus language-model systems. For developers, the goal isn't to add chatbots for popularity but to identify where conversational or voice interfaces genuinely improve user experience. They must then build effective pipelines to deliver on that promise. The technology exists; the challenge is in execution.

Frequently Asked Questions

1. How do AI chatbots work inside mobile apps?

They process user input through a pipeline involving intent classification, entity extraction, and fulfillment, then return a response from a rule-based system, database, or generative LLM in the chat UI.

2. Difference between rule-based and AI chatbots in apps?

Rule-based bots follow fixed decision trees and only handle pre-programmed inputs, while AI-powered bots use ML to understand natural language, making them more flexible but harder to deploy and monitor.

3. How are voice assistants integrated into Android and iOS apps?

iOS uses SFSpeechRecognizer and Core ML for ASR and on-device inference, while Android relies on SpeechRecognizer API and TensorFlow Lite; both support streaming responses to reduce latency.

4. What are the privacy concerns with AI chatbots in mobile apps?

Main concerns include data storage location, retention duration, and access rights. GDPR and India's DPDP Act require user consent and deletion rights. On-device inference is rising, keeping sensitive data off servers.

5. Can AI chatbots in apps work without an internet connection?

Yes, they can use on-device frameworks like Core ML or TensorFlow Lite, but these models are smaller and less capable than cloud-hosted LLMs. Most apps use a hybrid approach, handling simple tasks offline and routing complex queries to the cloud when connected.

Stop Turning the Mobile Web Into a Second-Class Platform

Thu, 21 May 2026 11:25:33 +0000

There is a long-term trend in the software industry that I think developers should pay more attention to:

We are slowly replacing the open mobile web with isolated app containers.

And I think this is a mistake.

Not because native applications are inherently bad. Some categories absolutely need them: low-latency audio, advanced camera processing, heavy offline workloads, games, Bluetooth integrations, system-level services, etc.

But a huge percentage of modern mobile apps are not really “native applications” anymore.

They are portals to web content wrapped inside a native shell.

And yet, by moving users from the browser into apps, we lose many of the properties that made the web powerful in the first place.

The Mobile Browser Is More Powerful Than People Realize

On desktop, most developers understand the value of the browser immediately:

tabs
deep linking
bookmarking
extensions
history
multi-window workflows
interoperability
inspectability
copyable URLs
open standards

But on mobile, many companies push users toward applications even when the actual product experience is fundamentally web-shaped.

The result is fragmentation of workflows that the browser already solved decades ago.

A Browser Tab Is a Better UX Primitive Than Most Mobile Apps

This sounds controversial until you compare them directly.

In a browser:

I can open 20 conversations in separate tabs.
I can preserve reading state naturally.
I can bookmark specific content.
I can restore sessions.
I can share exact URLs.
I can use ad blockers.
I can use browser extensions.
I can search across tabs.
I can keep temporary research contexts alive for weeks.

In many mobile apps:

navigation state is fragile
deep linking is inconsistent
opening multiple contexts is awkward
content is trapped inside proprietary navigation systems
session management is opaque
there is no universal multitasking model

The browser already solved these problems with universal primitives.

Apps often reinvent them poorly.

Many Mobile Apps Are Just Embedded Websites

A lot of modern applications are effectively:

React Native shells
Electron-like architectures
WebViews
remote-rendered interfaces
thin API clients around server-driven UI

And that is fine technically.

But if the experience is fundamentally web-centric anyway, why are we abandoning the actual web platform?

Especially when the browser gives users:

portability
inspectability
interoperability
lower installation friction
better discoverability
easier sharing
less platform lock-in

The “App-First” Strategy Hurts the Mobile Web

This is the part that concerns me most.

When companies prioritize native applications aggressively, something predictable happens:

the mobile app becomes the primary platform
the mobile website becomes “good enough”
feature parity disappears
browser support stagnates
investment into web capabilities declines

Eventually the mobile web experience degrades into:

limited functionality
missing features
constant “Open in App” interruptions
intentionally degraded UX
broken navigation
artificial restrictions

This creates a feedback loop:

weaker mobile web → more users forced into apps → even less incentive to improve the web

That is dangerous long term.

We Are Accidentally Weakening the Open Platform

One of the biggest historical advantages of the web was openness.

A browser is a universal runtime.

A website can be indexed, linked, archived, shared, inspected, extended, and accessed without asking permission from a platform gatekeeper.

Apps move the industry toward:

closed ecosystems
proprietary distribution
platform dependency
duplicated implementations
reduced interoperability

The web was never perfect, but it created an environment where small teams could ship globally accessible software instantly.

That matters.

Especially for developers.

Progressive Web Apps Were Supposed to Bridge This Gap

PWAs are one of the most important ideas the industry produced in the last decade.

The promise was compelling:

installable web apps
offline support
push notifications
background sync
richer device APIs
app-like UX without abandoning the web

But mobile platforms still treat the browser as a second-class citizen in many areas.

And this directly affects innovation.

A Real Example: Voice Interfaces on Mobile Web

I built a voice-command-oriented web application.

On desktop Chrome, continuous speech recognition works surprisingly well. You can create fluid voice-driven workflows with near real-time interaction.

But on mobile, the experience degrades dramatically.

The browser often allows only short-lived microphone capture sessions for speech recognition workflows. Continuous recognition behavior is heavily restricted compared to desktop environments.

As a result:

recognition sessions restart constantly
UX becomes fragmented
latency increases
conversational interaction becomes unreliable

Meanwhile native apps can often access far more persistent audio capabilities.

This creates a structural imbalance:

developers are pushed toward native apps not because the web model is fundamentally wrong, but because the platform capabilities are artificially constrained.

And when users stop using the mobile web, platform vendors have even less incentive to improve it.

Browser Features Benefit Everyone

The browser ecosystem creates positive externalities.

When users rely on browsers:

browser vendors compete harder
standards evolve faster
accessibility improves
performance tooling improves
privacy tooling improves
extension ecosystems grow
cross-platform compatibility matters more

The web encourages shared infrastructure.

Apps encourage isolated silos.

Security and User Control Matter Too

Browsers also provide something increasingly rare:

user mediation

Permissions are usually:

visible
revocable
origin-scoped
standardized

Users can:

clear site data
inspect permissions
block trackers
isolate sessions
use privacy extensions
sandbox activity more predictably

Native mobile apps often request much broader persistent access with significantly less transparency around internal behavior.

Again, some applications genuinely need this access.

Many do not.

“But Native Apps Are Faster”

Sometimes yes.

But this argument is increasingly overstated for many categories.

Modern mobile browsers now support:

hardware acceleration
WebAssembly
IndexedDB
service workers
advanced caching
streaming APIs
GPU APIs
installable PWAs

For content-centric products, dashboards, social systems, productivity tools, knowledge platforms, AI interfaces, admin panels, marketplaces, and communication tools, the gap is often far smaller than people assume.

In many cases, the biggest differences are organizational priorities rather than technical impossibilities.

The Web Is Still the Most Important Software Platform Ever Created

The web won because it was:

linkable
composable
open
searchable
decentralized
low-friction

We should be extremely careful about replacing those properties with ecosystems built around opaque application containers.

Especially when many “apps” are already websites internally.

My Personal Rule

If a service can function well as a mobile website, I increasingly prefer using the website over installing the app.

Not because I hate apps.

But because every time we choose the browser:

we reinforce open standards
we increase pressure for better browser APIs
we support interoperable software
we encourage better PWAs
we reduce unnecessary platform fragmentation

And over time, that shapes the direction of the ecosystem.

Final Thought

I think developers underestimate how much collective user behavior influences platform evolution.

If users continuously abandon the mobile web in favor of closed app ecosystems, companies and platform vendors will naturally invest less into browser capabilities.

But if developers and users actively use and demand high-quality mobile web experiences, the opposite can happen:

better APIs
stronger PWAs
richer browser capabilities
more powerful web runtimes
less dependence on app stores
more open software ecosystems

The mobile web does not become stronger automatically.

It becomes stronger only if people continue using it.

What do you think?

Are mobile apps genuinely superior for most modern products, or are we underinvesting in the mobile web ecosystem?

5 React Native Errors That Cost Me Hours (And How I Finally Fixed Them)

Thu, 07 May 2026 19:35:56 +0000

5 React Native Errors That Cost Me Hours (And How I Finally Fixed Them)

When I started building my React Native app, I thought the hard part would be designing the app itself.

Turns out, debugging the environment was the real boss fight.

I spent hours — sometimes entire days — fighting build failures, version mismatches, Gradle issues, and errors that made absolutely no sense at first glance. Some of them looked impossible to solve unless you were already an Android engineer.

The worst part is that many tutorials online either skip these issues entirely or give solutions that don’t actually work.

So I decided to write the post I wish I had when I started.

These are 5 real React Native errors I personally ran into while building my app, and exactly how I fixed them.

1. Gradle TLS Handshake Failure

The Error

This one nearly made me quit for the day.

Every time I tried building the Android app, Gradle failed while downloading dependencies from Maven Central with SSL/TLS handshake errors.

The logs looked something like this:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Or sometimes:

Could not GET 'https://repo.maven.apache.org/...'

Why It Happened

At first I thought:

Maven Central was down
my internet was unstable
Java was broken
Gradle was corrupted

None of those were the real issue.

The actual problem was an environment variable called GRADLE_OPTS that was injecting custom SSL settings into Gradle.

It included flags like:

-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT

Curl requests worked perfectly, but Gradle kept failing because its SSL configuration was being overridden.

How I Fixed It

I removed the GRADLE_OPTS environment variable completely from both:

User Environment Variables
System Environment Variables

Then I restarted the terminal and rebuilt the project.

Immediately after that, Gradle downloads started working again.

What I Learned

Sometimes the problem is not React Native itself.

Sometimes the environment around it is sabotaging the build process.

And when debugging network-related Gradle errors, always compare:

browser behavior
curl behavior
Gradle behavior

If only Gradle fails, something in the Java/Gradle SSL configuration is probably interfering.

2. Expo and React Native Version Mismatch

The Error

This one caused random crashes, dependency warnings, and builds failing for reasons that seemed unrelated.

I had packages that technically installed correctly, but internally they were incompatible with my Expo SDK version.

Why It Happened

React Native ecosystems are extremely version-sensitive.

You cannot always:

install the latest package
upgrade random dependencies
mix versions freely

Expo SDKs expect very specific versions of:

React Native
React
Expo packages
Gradle plugins
Android tooling

Even a small mismatch can create chaos.

How I Fixed It

I stopped manually installing random versions and aligned everything with the Expo SDK requirements.

I rebuilt the Android folder using the correct setup and standardized the project around:

React Native 0.80.2
Expo SDK 53
AGP 8.6.1
Kotlin 2.0.21
Gradle 8.13

After everything matched properly, the project became dramatically more stable.

What I Learned

In React Native development, version consistency matters more than having the newest package.

A stable stack beats a cutting-edge stack every single time.

3. Android Build Files Breaking Everything

The Error

At one point, Android builds completely stopped working because of Gradle configuration problems.

The project would either:

fail immediately
fail during dependency resolution
fail during configuration phase

And the logs were massive.

Why It Happened

React Native Android builds rely on multiple interconnected files:

settings.gradle
build.gradle
gradle.properties
app-level Gradle configs

One incorrect line can break the entire build system.

I also learned that newer React Native versions have different setup requirements compared to older tutorials online.

Following outdated tutorials made things worse.

How I Fixed It

I rebuilt the Android configuration using the proper modern structure:

correct includeBuild setup
Expo autolinking configuration
AndroidX enabled
Hermes enabled
New Architecture configuration aligned correctly

I also stopped randomly changing Gradle files without understanding what they did.

That alone saved me future debugging time.

What I Learned

When debugging Android builds:

avoid panic-editing files
change one thing at a time
keep backups of working configs

And most importantly:
older React Native tutorials can become outdated very quickly.

4. Metro Bundler Cache Weirdness

The Error

Sometimes the app behaved as if my code changes didn’t exist.

I would:

modify files
save changes
rebuild the app

…and somehow the old behavior remained.

At first I genuinely thought I was losing my mind.

Why It Happened

Metro bundler caching can occasionally become inconsistent, especially after:

dependency changes
package upgrades
Android rebuilds
native configuration updates

The cache can preserve outdated state even after rebuilding.

How I Fixed It

I cleared everything:

Metro cache
node_modules
Gradle cache
build folders

Commands like these became lifesavers:

npx expo start --clear

And sometimes:

gradlew clean

After cleaning the environment properly, the app started reflecting changes correctly again.

What I Learned

Never underestimate caching problems.

If behavior makes absolutely no sense, clear the caches before wasting hours debugging imaginary problems.

5. The “Works on One Device but Crashes on Another” Problem

The Error

This one was incredibly frustrating because the app seemed completely fine at first.

It worked on one device.
Then suddenly:

crashed on another device
failed on Android builds
behaved differently after rebuilding

Sometimes the exact same code would work one day and fail the next after changing dependencies.

Why It Happened

The real issue was inconsistency between:

Gradle versions
Android Gradle Plugin versions
Kotlin versions
React Native requirements
Expo SDK compatibility

At one point, parts of the Android environment were aligned while others were outdated or incompatible.

React Native Android builds are surprisingly sensitive to tooling mismatches.

Even if the app compiles, hidden incompatibilities can still create unstable behavior.

How I Fixed It

I standardized the entire Android stack instead of fixing things one-by-one.

I rebuilt the project around a stable configuration:

React Native 0.80.2
Expo SDK 53
AGP 8.6.1
Kotlin 2.0.21
Gradle 8.13
compileSdk 35
targetSdk 35

I also cleaned and regenerated parts of the Android setup to remove leftover configuration issues from older versions.

Once everything matched properly, the builds became dramatically more reliable.

What I Learned

A lot of React Native debugging problems are actually ecosystem consistency problems.

You can spend hours trying to patch symptoms individually when the real fix is making the entire toolchain compatible from top to bottom.

Now whenever I hit strange Android issues, the first thing I check is:
“Are all my versions actually meant to work together?”

Final Thoughts

Before building this app, I underestimated how much software development is actually debugging.

Not writing code.
Not designing features.

Debugging.

But strangely enough, this process also made me improve faster than any tutorial ever could.

Every painful issue forced me to:

understand the stack better
read logs more carefully
stay patient under frustration
stop blindly copying fixes from random forums

And honestly, solving these problems feels more rewarding than writing simple features.

If you're currently fighting React Native errors that make no sense:
you're definitely not alone.

Sometimes one line of configuration can cost you six hours.

And sometimes the fix is deleting a single environment variable.

When a Button Should Do More Than Close

Thu, 07 May 2026 16:33:53 +0000

Some days in Flutter are not about huge refactors or dramatic crashes. Some days are about a button that says one thing and does another.

Today’s task looked harmless: clean up a few dialog buttons in an event-planning mobile app. The dialogs were already showing at the right moments. The UI looked fine enough. The copy was clear.

But then I tapped the buttons mentally and noticed the problem: most of them just closed the dialog.

That is not always wrong. Sometimes a dialog is only a nudge. Sometimes “Okay” really does mean “go away, I understand.” But if a button says “View Pending Tasks” and then only pops the modal, that is a tiny betrayal. Not catastrophic, not release-blocking, just one of those product papercuts that makes an app feel less intentional.

So the day became less about button styling and more about answering a deceptively annoying question:

The dialog was innocent

The dialog components themselves were simple Flutter widgets. A few icons, some copy, and an ElevatedButton at the bottom.

The original pattern looked roughly like this:

class DayDialog extends StatelessWidget {
  const DayDialog({super.key});

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () {
        Navigator.pop(context);
      },
      child: const Text("Let's Go"),
    );
  }
}

There is nothing technically broken about that. It compiles. It works. The dialog closes.

But the app had dialogs with stronger intent:

“It’s D-Day” should take the user to the event happening today.
“You’ve got tasks waiting” should take the user somewhere useful for those tasks.
“Missed something?” should open notifications.
“One step closer” might honestly just dismiss, because it is more encouragement than navigation.

That last distinction ended up mattering. Not every button needs to become a route change just because we are in a “make buttons useful” mood.

The first useful clue: don’t make the dialog smart

The tempting mistake would have been to import screens into every dialog and let the dialog figure out where to navigate.

That would work for about five minutes.

Then the dialog layer would start knowing about event models, notification screens, task picking rules, dashboard cache, route transitions, and probably someone’s lunch order if I looked away long enough.

The cleaner move was to keep the dialogs dumb and let the screen that shows them inject behavior.

So the dialog becomes callback-driven:

class DayDialog extends StatelessWidget {
  final VoidCallback? onLetsGo;

  const DayDialog({
    super.key,
    this.onLetsGo,
  });

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () {
        if (onLetsGo != null) {
          onLetsGo!();
          return;
        }

        Navigator.pop(context);
      },
      child: const Text("Let's Go"),
    );
  }
}

This is a small change, but it keeps the boundary clean:

The dialog owns presentation.
The home screen owns app state.
Navigation is decided where the relevant state already exists.

Flutter makes it very easy to blur those lines because BuildContext is everywhere. That convenience is lovely until every widget becomes slightly aware of the entire app.

D-Day was the easy one

The D-Day dialog had a nice property: the event it referred to was already known.

The home screen was computing the earliest upcoming event and storing it as a mapped event model. The D-Day eligibility check was based on that same event date. In plain terms, if the app says “your event starts now,” then the event to open should be the earliest event that made that condition true.

That gave us a clean action:

DayDialog(
  onLetsGo: () {
    final event = earliestEvent;
    Navigator.of(dialogContext).pop();

    if (event == null || !mounted) return;

    Navigator.of(context).push(
      MaterialPageRoute(
        builder: (_) => EventDetailsScreen(event: event),
      ),
    );
  },
);

There are two contexts here, and that is not accidental.

The dialog builder gives a dialogContext, which is the safest context for popping the dialog. The screen’s own context is then used for pushing the next route.

Could one context have worked? Probably. But “probably” is not my favorite navigation strategy, especially around dialogs. Flutter navigation bugs tend to wait until a specific route stack shape appears, then quietly ruin your afternoon.

The task dialog was less polite

The pending task dialog sounded simple:

Cool. Open pending tasks.

Except there was no single “pending tasks screen.” Also, tasks belonged to different events.

A dashboard task had enough information to know that it was incomplete and which event it belonged to, but the event details screen needed a fuller event model. So the app had two related but different pieces of state:

dashboard task summaries
full mapped events from the events response

That meant the button needed a selection rule.

We considered a few choices:

open the calendar, which is safe but broad
build a grouped pending tasks view, which is better UX but more work
open the event containing the next task needing attention

The last option felt like the best daily tradeoff. It makes the button do something concrete without inventing a new screen.

The rule became:

Find incomplete tasks.
Prefer the nearest upcoming incomplete task.
If all incomplete tasks are overdue, pick the most recently overdue one.
Find the event that owns that task.
Open event details.
If the event cannot be found, fall back to the calendar.

That sounds like a lot for one button, but it is really just product intent expressed as code.

TaskSummary? findTaskNeedingAttention(List<TaskSummary> tasks) {
  final pending = tasks.where((task) => !task.isCompleted).toList();
  if (pending.isEmpty) return null;

  final now = DateTime.now();

  final upcoming = pending
      .where((task) => task.date != null && !task.date!.isBefore(now))
      .toList()
    ..sort((a, b) => a.date!.compareTo(b.date!));

  if (upcoming.isNotEmpty) return upcoming.first;

  final overdue = pending.where((task) => task.date != null).toList()
    ..sort((a, b) => b.date!.compareTo(a.date!));

  if (overdue.isNotEmpty) return overdue.first;

  return pending.first;
}

The fallback mattered to me. Real mobile state is messy. Maybe the dashboard response has a task whose event is missing from the events response. Maybe caching gives you a slightly stale combination. Maybe the backend shape changes in some tiny way on a tired Tuesday.

In those cases, the app should still take the user somewhere useful instead of turning the button into a dead end.

The callback pattern held up

Once the dialog had a callback, the home screen could own the messy part:

PendingTasksDialog(
  onViewPendingTasks: () {
    final event = findPendingTaskEvent();
    Navigator.of(dialogContext).pop();

    if (!mounted) return;

    if (event == null) {
      openCalendarScreen();
      return;
    }

    Navigator.of(context).push(
      MaterialPageRoute(
        builder: (_) => EventDetailsScreen(event: event),
      ),
    );
  },
);

That made the dialog more reusable and the navigation more honest.

I also had to make sure the mapped event list was cached alongside the rest of the home state. Otherwise the behavior would work after a fresh fetch but fail or degrade after cached dashboard state restored. This is exactly the kind of small state detail that does not announce itself loudly. It just becomes a weird “works sometimes” bug later.

I do not enjoy future-me debugging “works sometimes.” Future-me is busy enough.

The button we left alone

The most interesting decision might have been the one where we did nothing.

There was a “One step closer” dialog shown after the user completed more tasks. The button said “Keep Planning.” At first, it looked like another candidate for navigation.

But after thinking through it, dismissing the dialog actually made sense.

That dialog is not saying “go inspect this exact object.” It is more like a little celebration. The user has made progress; the app is acknowledging it; closing the dialog returns them to whatever planning context they were already in.

Changing that button to navigate somewhere might have made the app feel jumpy. Useful is good. Over-eager is not.

This was a nice reminder that consistency does not mean every button does the same category of thing. It means every button does what its label and context imply.

Small Flutter details that mattered

A few practical details stood out:

Navigator.pop should close the dialog before pushing the next screen.
Use the dialog’s context to pop the dialog route.
Use the parent screen’s context to push the app route.
Check mounted before navigating after state-dependent callbacks.
Keep UI widgets dumb when the state lives somewhere else.
Cache all derived state needed by a callback, not only what the UI visibly renders.

None of those are groundbreaking. They are just the little edges that separate “it works in my test tap” from “this behaves reliably in the app.”

The quiet lesson

Today’s work started with dialog buttons and ended up being about intent.

A button label is a contract. If it says “View Notifications,” it should not merely close. If it says “View Pending Tasks,” it should make a reasonable decision about which task needs attention. If it says “Keep Planning,” sometimes the best behavior is simply to get out of the way.

The technical implementation was not huge: a couple of callbacks, a mapped event list, a task selection helper, and a fallback route. But the thinking behind it was the useful part.

Flutter gives us the tools to wire screens together very quickly. The harder part is deciding where the knowledge should live, what the user expects, and how much logic a tiny button deserves.

Today, one tiny button deserved more than Navigator.pop(context).

Another one did not.

That balance was the actual feature.

Android CLI

Fri, 17 Apr 2026 12:07:23 +0000

Google has announced Android CLI, a new official command line tool for Android development aimed at agent based workflows outside Android Studio. The release is part of a broader set of agent tools that also includes Android Skills and the Android Knowledge Base. Google says these tools are meant to help agents work with official Android workflows, recommended patterns, and up to date guidance.

According to the announcement, Android CLI is designed to handle core terminal based Android tasks such as environment setup, project creation, SDK management, emulator management, and app deployment. Google highlights commands such as android sdk install, android create, android emulator, android run, and android update as the foundation of the new workflow.

Google also says that in its internal experiments, Android CLI reduced LLM token usage for project and environment setup by more than 70 percent and completed tasks 3 times faster than agents using standard toolsets alone. That performance claim comes directly from Google’s own announcement, so it should be viewed as an internal benchmark rather than an independent measurement.

Google also launched the Android Knowledge Base. Google says it can be accessed through the android docs command and is intended to give agents fresher, authoritative context from Android developer docs, Firebase, Google Developers, and Kotlin documentation. That is an important detail for teams using coding agents, because it gives Android a more official path for grounding AI generated output in current platform guidance.

Official announcement:
https://android-developers.googleblog.com/2026/04/build-android-apps-3x-faster-using-any-agent.html

Understanding Flutter Method Channels Through a Real Production Bug

Thu, 16 Apr 2026 15:48:54 +0000

Introduction

Flutter is amazing—until it isn’t.

Most of the time, you can build entire apps without ever touching native code. But the moment you hit a platform limitation, things get… interesting.

This blog isn’t just about Method Channels.

It’s about:

When Flutter abstractions break down
How to take control using native Android
And how to think about Flutter ↔ Native communication like a system, not a hack

Funny enough, this blog comes from a real bug I hit while building my app Anahad — a saadhna app that plays mantra chants.

And yeah… it broke in a very weird way.

The Real Problem (Why This Blog Exists)

I was building a saadhna app that plays mantra chants on loop.

Simple requirement:

Play audio
Loop it continuously
Run in the background (screen off)

I was using:

audio_service
just_audio
just_audio_background

Everything worked perfectly…

Until it didn’t.

The Bug

After ~940–960 loops on Android (specifically Android 12+):

Playback would stop silently
No crash
No exception
Only when the screen was off

Even after:

Disabling battery optimization
Proper background setup

Still broke.

The Weird Part

It consistently failed around the same loop range (~940–960).

Not 100. Not 500. Not random.

That kind of consistency usually means:

Something deeper is going on — not just app-level logic.

At This Point, Two Choices

Keep debugging blindly inside Flutter
Drop down to native Android and take control

I chose option 2, cz i never interacted with native code and wanted to explore it

Fun part, i had an android 11 device which wasn't having this bug at all, tested on other android 11 devices as well

Why Flutter Isn’t Always Enough

Flutter is great, but it abstracts away platform details.

That’s usually good—until you need:

Deep lifecycle control
System-level integrations
Debug visibility into platform behavior

Common cases where native is needed:

Background services
Media playback control
Hardware interaction
Platform-specific APIs
Performance-critical logic

In my case:

I needed more control over how Android handles long-running audio playback. Just to be absolutely sure that it was not the issue of the package that i was using

Understanding Method Channels (The Right Mental Model)

Before code, get this clear:

Dart is the client. Native Android is the server.

When you write:

platform.invokeMethod("play")

You’re essentially doing:

Dart → sends request
Android → receives it
Executes native logic
Returns response

Think of it like:

An internal API call inside your app

No HTTP. No network. Just a binary bridge.

Once you understand this, Method Channels stop feeling “magical”.

Architecture Overview

Flutter (Dart)
├── UI Layer
├── Service Layer (PlaybackService.dart)
└── State Management

        ↓↓↓ Method Channel ↓↓↓

Android (Kotlin)
├── MethodChannel Handler
├── PlaybackService (MediaSessionService)
└── ExoPlayer

Flow (Step-by-Step)

User taps "Play"
Dart calls invokeMethod("play")
MethodChannel sends message
Kotlin receives it
Native service executes logic
Result is sent back

The Native Side: Android (Kotlin)

Why MediaSessionService?

Instead of a basic service, we use:

MediaSessionService

Because it:

Integrates with system controls (lock screen, notifications)
Handles background playback more reliably
Works with audio focus and lifecycle events
Plays nicely with the Android system

PlaybackService.kt

class PlaybackService : MediaSessionService() {
    private var mediaSession: MediaSession? = null

    override fun onCreate() {
        super.onCreate()

        val audioAttributes =
            AudioAttributes.Builder()
                .setUsage(C.USAGE_MEDIA)
                .setContentType(C.AUDIO_CONTENT_TYPE_MUSIC)
                .build()

        val player =
            ExoPlayer.Builder(this)
                .setAudioAttributes(audioAttributes, true)
                .setHandleAudioBecomingNoisy(true)
                .setWakeMode(C.WAKE_MODE_NETWORK)
                .build()

        player.addListener(object : Player.Listener {
            override fun onPlayerError(error: PlaybackException) {
                Log.e("PlaybackService", "Error: ${error.message}", error)
            }
        })

        val callback = object : MediaSession.Callback {}

        mediaSession = MediaSession.Builder(this, player)
            .setCallback(callback)
            .build()
    }

    override fun onDestroy() {
        mediaSession?.run {
            player.release()
            release()
            mediaSession = null
        }
        super.onDestroy()
    }
}

The Flutter Side: Dart

Service Wrapper

class PlaybackService {
  static const platform =
      MethodChannel('com.theahambrahmasmi.anahad/playback');

  static Future<void> play(String url) async {
    await platform.invokeMethod('play', {'url': url});
  }

  static Future<void> pause() async {
    await platform.invokeMethod('pause');
  }

  static Future<Map<String, dynamic>> getStatus() async {
    final result = await platform.invokeMethod('getStatus');
    return Map<String, dynamic>.from(result);
  }
}

Kotlin: Method Channel Handler

class PlaybackMethodHandler(private val context: Context) {

    fun setupChannel(flutterEngine: FlutterEngine) {
        MethodChannel(
            flutterEngine.dartExecutor.binaryMessenger,
            "com.theahambrahmasmi.anahad/playback"
        ).setMethodCallHandler { call, result ->

            when (call.method) {
                "play" -> {
                    val url = call.argument<String>("url")
                    val intent = Intent(context, PlaybackService::class.java)
                    intent.putExtra("audio_url", url)
                    context.startService(intent)
                    result.success(null)
                }

                "pause" -> {
                    val intent = Intent(context, PlaybackService::class.java)
                    context.stopService(intent)
                    result.success(null)
                }

                else -> result.notImplemented()
            }
        }
    }
}

Real-World Insight: The Looping Problem

If you're building:

Meditation apps
Chanting apps
Ambient loop apps

Be careful.

Android may silently stop long-running playback after extended loops.

Even with:

Battery optimization disabled
Background services configured

Test aggressively:

500+ loops
Screen-off playback
Different OEM devices

This is not just Flutter—it’s often Android system behavior.

What About The Root Cause?

Short answer:

I don’t fully know yet.

And yeah — that’s intentional honesty.

What I do know:

It only happens on Android 12+
It triggers after long-running background playback
It happens silently (no crash, no logs)
It correlates with a high loop count (~950)

Current Hypotheses:

Doze / background execution limits
Audio focus or media session interruption
ExoPlayer internal behavior after prolonged looping
OEM-level process killing
Resource exhaustion over time

We’ll Be Updating This

Once I dig deeper and find the exact root cause, I’ll update this blog with:

What exactly broke
Why Android 12+ behaves this way
The proper fix (not just experimental ones)
What you should do in production

Because honestly?

Debugging something that breaks at the OS level is messy… and kinda fun.

Final Thoughts

I eventually moved back to just_audio because:

The problematic flow was no longer needed

So yeah…

This experimental fix wasn’t used in production.

But it gave me something way more valuable:

A deeper understanding of how Flutter actually works under the hood.

And honestly?

I’m not perfect. I didn’t fully solve it (yet).
But now I know one more thing than I did before.

And that’s what matters.

TL;DR

Flutter is great, but not enough for everything
Method Channels = internal RPC bridge
Native gives you control Flutter abstracts away
Android background behavior can be unpredictable
Sometimes… you won’t have all the answers immediately

If you're building something serious:

Don’t just rely on abstractions. Understand what’s underneath.

That’s where real engineering begins.

Flutter’s Execution Model — Explained Like a Human

Tue, 14 Apr 2026 08:50:35 +0000

If you’ve been building with Flutter for a while, you’ve definitely heard terms like AOT and JIT thrown around.

Maybe you know debug is slower than release.
Maybe you’ve wondered what actually ends up inside your APK.

But like… what’s really going on under the hood?

Let’s open it up properly — no buzzwords, no hand-wavy stuff. Just what actually happens to your code, when it happens, and why Flutter lowkey has a massive edge.

The Simplest Way to Think About It

Imagine you invited someone over for dinner.

AOT (Ahead of Time) is you cooking everything beforehand.
Full meal ready. Table set. Chef mode ON.

They walk in → boom, food’s already there.

But if they suddenly go:

“Actually I feel like pasta instead of rice…”

…yeah, you’re screwed XD
You’re starting from scratch.

JIT (Just in Time) is the opposite.

You’re like:

“Tell me what you want, I’ll make it right now.”

Flexible? Yes.
Fast? …depends how hungry they are ;)

Flutter basically looked at both and said:

“Why not use both where they make sense?”

And that’s exactly what it does.

Debug Mode — JIT and the Dart VM

When you run:

flutter run

Your code is NOT compiled to native machine code.

Yeah — surprise.

Instead, Dart takes a completely different route.

The Compilation Pipeline

Your Dart code first goes through something called the CFE (Common Frontend).

Sounds fancy, but it’s basically:

parsing your code
checking types
resolving imports

And then it produces something called a Kernel AST.

Think of it like:

not source code, not machine code… but a structured “meaning” of your program

This gets saved as .dill files (Dart Intermediate Language).

From here, the Dart VM takes over.

Tiered JIT — This Is Where It Gets Spicy

The Dart VM doesn’t just compile everything upfront.

Because that would be dumb.

Why compile everything when half your code might never even run?

So it uses tiers:

Tier 0 — “Just run it bro”

Runs in an interpreter
No compilation
Starts instantly

Downside? Slow af.

But meanwhile, the VM is silently watching:

what functions are called
what types are used
which paths are hot

Tier 1 — “Okay this seems important”

Once a function gets called enough times:

it gets compiled to native code
but not heavily optimized

Faster than interpreter, but still warming up.

Tier 2 — “Alright I know your patterns now”

This is where things get spicy!

Now the VM has enough data to go:

“Cool, I trust this pattern.”

So it starts making bold assumptions.

Example:

If add(a, b) has only ever seen integers…

It goes:

“I’m skipping type checks. We going full speed.”

But what if suddenly a double shows up?

Boom.

Deoptimization.

throws away optimized code
falls back
re-learns

No drama. Just adapts.

The Real Trick

Cold code → stays cheap
Hot code → gets optimized like crazy

You only pay cost where it actually matters.

Hot Reload — The Real MVP

This is where JIT absolutely flexes.

You change a widget color → hit save.

Here’s what happens behind the scenes:

Only changed code gets recompiled
Sent to Dart VM over WebSocket
VM patches functions in-place
Flutter re-runs build()

And here’s the crazy part:

Your app state stays exactly the same

scroll position? safe
form input? safe
counters? safe

Because state lives in memory (heap), and you’re only swapping instructions.

That’s why hot reload feels like magic.

Why Debug Mode Feels Slow

It’s not just JIT.

Debug mode has extra baggage:

No tree shaking → everything included
Assertions ON → extra checks
DevTools hooks running
No aggressive optimizations
Constant profiling

Basically:

Debug mode = comfort + visibility
Release mode = speed + violence

Release Mode — AOT and Native Code

Now things change completely.

flutter build apk --release

No VM games anymore.

This is full AOT mode.

The Compilation Pipeline (Again, But Different Ending)

Same start:

Dart → CFE → Kernel AST

But now instead of VM → it goes to:

gen_snapshot (AOT compiler)

Type Flow Analysis — The Big Brain Move

Unlike JIT, AOT cannot guess.

No safety net. No “fix later”.

So it does something called Type Flow Analysis (TFA):

traces every possible path in your app
figures out what types can exist where
removes anything unreachable

Now the compiler can actually be bold:

inline functions
remove dead code
skip dynamic checks
devirtualize calls

Result?

Extremely optimised native machine code

What’s Inside Your APK?

If you unzip it, you’ll see something like:

your_app.apk
├── lib/
│   ├── arm64-v8a/
│   │   ├── libapp.so        ← YOUR code (compiled)
│   │   └── libflutter.so    ← Flutter engine
├── assets/
├── AndroidManifest.xml
└── classes.dex              ← tiny Android entry point

That classes.dex?

Not your app logic.

It’s just Android saying:

“Okay Flutter, you take over now.”

After that:
-->Flutter engine loads libapp.so
--> CPU runs your code directly

No VM. No interpreter. No waiting.

Why Hot Reload Is Impossible Here

In release mode:

no Dart VM
no runtime patching
no WebSocket updates

It’s just static native code.

So yeah…

--> Want changes? Rebuild. Reinstall. Done.

Profile Mode — Quick Side Note

flutter run --profile

This is the middle ground:

AOT performance
but still profiling tools available

Use it when you want real performance numbers without debug slowdown.

Why Flutter Hits Different

This is where things get really interesting.

React Native:

JS runs in the engine
communicates via bridge
data serialized/deserialized
async overhead

Flutter:

Dart → native machine code
talks directly to rendering engine
draws everything itself

No bridge. No middleman.

Flutter literally went:

“We’ll just render everything ourselves.”

And honestly?

Yeah… kinda insane.

The Mental Model

If you take one thing away, let it be this:

Debug mode → Dart VM is alive

dynamic
patchable
flexible
hot reload

Release mode → Dart VM is gone

static
precompiled
fast af
no flexibility

Flutter gives you both.

JIT for development speed
AOT for runtime performance

Compilation never disappears.

It just moves to where it makes the most sense.

Why Many App Cost Calculators Still Miss the Real Work

Fri, 13 Mar 2026 14:30:00 +0000

Most app cost calculators look helpful at first.

They ask for a few inputs:

Platform
Number of screens
Complexity
Maybe a few features

Then they return a number.

The problem is not that calculators are useless. The problem is that many of them simplify the wrong part of the project. The visible part of an app is not always the part that decides the budget. That is why a lot of founders feel confused when they get different quotes for what sounds like the same product.

A short feature list may look like this:

Login
Profile
Payments
Notifications
Dashboard

That sounds simple enough. But behind those features sit questions like:

What backend rules are needed?
Does the app need admin tools?
How many user roles exist?
What happens when a payment fails?
What QA depth is included?
Who handles release work?
What is expected after launch?

If two teams answer those questions differently, they are not really pricing the same app. That is why one quote may look low and another may look high, even when both are based on the same screen list.

A lot of the budget difference usually comes from four areas.

1. Backend and Admin Work

The frontend gets most of the attention early because it is easy to picture.
But real products often need:

Dashboards
Roles and permissions
Logs
Exports
Support tools
Approval flows
Moderation actions

These parts often appear late in planning, even though they can add a lot of work.

2. QA Depth

Testing is often treated as a final step.
In practice, serious QA includes:

Device coverage
Regression testing
Edge cases
Re-checking after fixes
Release validation

If the product includes payments, subscriptions, messaging, or broader device support, the testing effort can increase quickly.

3. Integrations

Third-party tools always sound smaller than they really are. Payments, SMS, maps, analytics, storage, and notifications all create extra setup, testing, and failure handling work.

4. Release and Post-Launch Work

Launch is not the end of the technical effort.
Teams still need to deal with:

Environment setup
Build preparation
Submission steps
Review feedback
Crash monitoring
Updates
Ongoing fixes

That is why a calculator is only useful when it helps teams see what is behind the numbers. A better model would not just say, Your app costs X.

It should help people understand:

What is included
What makes the numbers move
What changes between MVP and a more complete version
Which feature choices affect time the most

That is the idea behind the calculator I’ve put together for USA startup teams.
It helps estimate:

Build hours
Budget range
Timeline
Feature impact
Maintenance planning

If you want the full guide and calculator, it is here.

How One Screen Holds the Entire Industry Hostage

Mon, 23 Feb 2026 21:41:54 +0000

Frameworks like React Native, Flutter, and MAUI keep promising to end the "write it twice" problem across mobile platforms. One codebase, every platform, native-quality results. Yet every time, the abstraction leaks. Then it floods so fast that bailing water is all you have time to do. I've been working with MAUI recently, and the experience crystallized a question I should have asked sooner: why am I not just building a website?

Once you pull that thread, it unravels fast. The web platform can do far more than the industry acknowledges. Most of what prevents universal web adoption is inertia, business incentives, or mental models rather than limits in the technology. On phones, the hardest of those limits trace back to one company's control of one screen.

The web can do the job. One company made sure you'd never trust it to.

This isn't an argument that native apps are obsolete or that local executables should disappear. There are good reasons to run code on your own hardware, and the pure thin-client terminal hasn't arrived yet. Maybe it shouldn't. But when teams default to native without questioning it, they accept costs and constraints on the client side that the backend abandoned years ago when it moved to the cloud.

What the Web Platform Can Actually Do

For the typical business application, on a phone, tablet, or desktop, the web platform already covers the core requirements:

Capability	Web Technology
Offline support	Service Workers, Cache API
Push notifications	Push API (iOS 16.4+, March 2023)
Camera, microphone, biometrics	getUserMedia, WebAuthn/Passkeys
Payment processing	Payment Request API (includes Apple Pay)
Home screen installation	Web App Manifest, standalone window
GPU-accelerated graphics and compute	WebGPU (all major browsers, Nov 2025)
Peripheral device access	WebUSB, WebSerial, WebBluetooth, WebHID (Chromium)
Local file access	File System Access API, Origin Private File System
Near-native performance	WebAssembly, Web Workers
Real-time communication	WebRTC

Most rows work in Safari on iOS today. The peripheral APIs and full local file access are Chromium-only. iOS delivers push only to a web app the user has added to the home screen, with no install prompt to help them do it. Safari also clears a site's stored data after seven days of Safari use without a visit unless it's installed, as WebKit's own blog documents. Feel is the other gap, since Safari's keyboard, viewport, and standalone-mode quirks take deliberate work, and they're Apple's to fix.

That list covers what most apps do. Most are thin clients over an API: authenticate a user, fetch data, display it, let the user interact with it. The web handles all of that with a single codebase on every platform with a browser, and the deployment model alone should give teams pause. No App Store review cycles, no waiting days for a critical bug fix to clear approval, no separate release pipelines for each platform.

What Genuinely Requires Native

These capabilities have no web equivalent.

Wearable integration and health data like Apple Watch complications, Wear OS tiles, HealthKit, and Google Health Connect require platform SDKs with no web alternative
Advanced augmented reality using LiDAR scanning, scene understanding, and body tracking exceeds what WebXR currently offers
Deep OS integration like Siri Shortcuts, Google Assistant routines, home screen widgets, and inter-app communication remains outside the web's reach
True background processing for geofencing, long-running background jobs, and persistent location tracking requires native APIs
Specific hardware access like NFC writing on iOS, advanced camera controls, and screenshot blocking are native-only capabilities

This list is relevant, but it's also narrow. Look at the apps on your phone and the software on your desktop, and count how many actually need any of these features.

Cross-Platform Frameworks Are the Wrong Answer

Cross-platform frameworks don't eliminate the two-codebase problem; they disguise it. React Native's JavaScript-to-native layer, Flutter's rendering engine, and MAUI's handler pattern each introduce their own category of bugs that don't exist in either native platform. You haven't removed the platform differences; you've added a third abstraction layer and still debug the two platforms underneath it.

The tech debt is unprojectable because you don't control the framework's roadmap. When Apple changes iOS, you wait for the framework to catch up. When the framework ships breaking changes, you're locked into an unplanned upgrade. When a critical bug sits in the issue tracker for months, your only options are workarounds or forks.

The original justification was that specialized native developers are expensive, so share code to reduce cost. AI code generation has lowered much of that barrier. A competent developer with AI assistance can get much further in Swift or Kotlin without years of platform experience, though lifecycle and accessibility details still take expertise. All the original disadvantages of cross-platform remain, and cheaper native still means two QA passes and two release pipelines. That duplication is an argument for the web, not for a framework.

Microsoft Opened Its Stack While Apple Closed Its Screen

In the early 2000s, Microsoft was the villain. They owned the desktop, the browser, the runtime, and the development tools, and the DOJ antitrust case settled in 2001 was about exactly this: using a Windows monopoly to crush Netscape. Apple was the scrappy alternative making beautiful things for creative people, and when the iPhone launched in 2007 it felt like liberation from the carrier-controlled mobile landscape.

Microsoft lost mobile and Windows 8 alienated more and more desktop users. Their response was to stop trying to own the screen and instead to compete on the stack. .NET went open source, Visual Studio Code became the most-used editor in Stack Overflow's developer survey, and they acquired GitHub and kept it open. The company that once tried to kill Linux now ships a Linux kernel inside Windows.

Apple went the other direction. When the iPhone became the dominant computing device, Apple discovered what Microsoft had known in the 1990s: if you control the platform people depend on, you don't have to compete on openness. You compete on control.

I write .NET code for a living and I choose to do it on a Mac because the experience is genuinely better. Notice what that reveals about both companies though. Microsoft made it possible by building .NET and VS Code to run everywhere. Try the reverse: building an iOS app without a Mac, submitting to the App Store without Xcode, running Swift on Windows with the same support .NET has on macOS. You can't. Microsoft earns developers by being useful everywhere. Apple captures them by being mandatory for anyone who ships to an iPhone.

Apple's products deserve their loyalty. The Mac is excellent, the ecosystem integration is seamless, and users trust the brand for good reasons. That trust is exactly what makes the constraint on the iPhone so effective. When a company makes products this good, people don't scrutinize the walls. They assume the walls exist for good reasons.

But look at what Apple controls versus what they build. Siri has been outperformed by competitors for over a decade, and it doesn't matter because Siri doesn't need to be good; it needs to be on the iPhone. Owning the screen means you don't have to be the best at anything that runs on it. You just need to be good enough at the thing people hold, and everything else flows through you.

Apple doesn't compete on technology. They compete on constraint ownership. The phone is the aperture, and Apple controls the aperture.

The Walls Apple Built

Apple's walls around iOS are higher than anything Microsoft built around Windows in the 1990s, and they're more sophisticated because they're framed as user protection rather than vendor control. Windows in the 1990s never stopped anyone from installing Netscape's engine.

Outside the EU and Japan, every browser on iOS must use Apple's WebKit rendering engine. Chrome on your iPhone isn't really Chrome. It's a WebKit skin with Chrome's UI on top. Firefox, Edge, Brave: all WebKit underneath. So Apple alone controls what web capabilities exist on every iOS device, regardless of which browser icon a user taps.

On Chrome and Android, web apps can access APIs unavailable on any iOS browser, including Bluetooth, NFC, Background Sync, USB, and serial devices. Web push reached Chrome on Android in 2015 and iOS in March 2023. On Android, any website can request push permission.

In June 2020, as ZDNet reported, Apple declined to implement 16 Web APIs, citing "privacy and fingerprinting concerns." The concern isn't baseless, since a web page runs from any link while a native app gets Bluetooth and NFC only after store review and a deliberate install. Mozilla shares some of it. What sets Apple apart is reach. Firefox declining an API doesn't keep it off anyone's phone, because Chrome on Android ships these APIs behind permission prompts. Apple's refusal is the only one that binds every browser on the device.

The EU's Digital Markets Act forced Apple to permit other browser engines in 2024, and the response was revealing. Alongside that change, Apple attempted to remove PWA support entirely in the EU, converting installed web apps into simple bookmarks. Their justification was "complex security and privacy concerns." After an open letter from Open Web Advocacy gathered thousands of signatures and the European Commission sent formal inquiries, Apple reversed the decision within two weeks, as The Register reported. Home-screen apps came back still running only on WebKit.

Japan's smartphone law added the same requirement in December 2025, per Apple's developer page on changes to iOS in Japan. Even with engine choice required, as of early 2026 zero browsers have shipped a non-WebKit engine on iOS in the EU, according to Open Web Advocacy. The regulation exists on paper. The monopoly persists in practice.

The App Store generated approximately $27 billion in global commissions in 2024 on cuts of 15 to 30%, per Appfigures data reported by TechCrunch. A web capable enough to replace paying apps would let them leave the store, so the web stays capped. Free business tools pay Apple nothing, but they live under the same cap. The U.S. Department of Justice drew this connection in its March 2024 antitrust lawsuit, whose complaint cites the WebKit requirement as part of Apple's monopoly maintenance, as Open Web Advocacy's summary quotes.

Android doesn't have these restrictions. But it doesn't matter. Few product leaders will ship something that doesn't work on iPhones, because iPhone owners are too large and too valuable a share of most Western markets to give up. The most constrained major platform sets the ceiling for what anyone builds. Once a team must build an iOS app anyway, a matching Android app is the path of least resistance. The web rarely gets a fair trial on Android either, because the decision was made on iOS's terms.

The Circular Logic of "Users Prefer Native"

The most common justification for building native apps is market data, like eMarketer's, showing that users spend 88-92% of their mobile time in apps and only 8-12% in browsers.

Much of that time goes to social, messaging, video, and games, so it says little about a typical business app. As evidence of preference, it's circular reasoning dressed up as market research. Of course the native experience retains users better. The web version usually received a fraction of the investment, because teams don't fund a channel the platform caps. You cannot measure user preference when one option was deliberately hobbled by the platform owner and underfunded by the developer.

Framework adoption has the same circularity. Flutter and React Native adoption is growing, but teams reach for them to avoid writing two native apps. That problem exists largely because Apple won't let the web do on the iPhone what it already does on every other platform. A developer checks iOS web capabilities, finds background sync missing and Bluetooth unavailable, builds native instead, and that decision gets counted as evidence that the web isn't ready. The constraint creates the behavior that justifies the constraint.

Not all of the pull is Apple's doing. Habit, a persistent icon, and lock-in favor native even where Apple has no say. But on phones, in the markets that set the industry's defaults, the counterfactual has never been tested at scale because Apple has prevented it. The assumption that native is inherently superior has become so embedded that most teams skip straight to "which framework?" without ever stopping at "does this need to be an app?"

The closest tests come from companies that chose the web for business reasons. None is a controlled trial of web against native. The Financial Times left the App Store in 2011 and ran on the web alone for six years. It returned in 2017 with an app that sent new readers to the website to subscribe, as Talking Biz News reported, so the web stayed the product and the app became a convenience.

Android-dominant markets like India and Southeast Asia show what happens where Apple's cap matters least. Apps still lead there, partly on habit and on product playbooks written iOS-first. But companies like Flipkart and JioSaavn treat the web as a first-class product rather than a fallback. Flipkart rebuilt its mobile site as a PWA after a failed app-only experiment, while keeping its native app. Users spent three times as long on the PWA as on the old mobile site, per Google's web.dev case study.

Starbucks built a PWA 99.84% smaller than their iOS app, according to its developer NearForm. It told Google I/O it had doubled the number of people ordering through the web each day, as MSPoweruser reported. But Starbucks kept the native app too. That raises an important question I can't answer: did they keep it because native was genuinely better, or because no one was willing to ask "why do we still have this?"

The Anxiety That Predates Mobile

When the iPhone launched in 2007, Steve Jobs told developers to build web apps. The web genuinely wasn't ready, and the App Store arrived a year later. But the response to that gap matters more than the gap itself. Rather than rallying behind closing it, the industry built an entirely parallel native ecosystem.

That response follows a pattern that has repeated since the 1960s: every generation of computing produces a viable thin-client model, and the market keeps finding reasons to resist it. Mainframe terminals gave way to PCs. Sun's network computer was technically sound and commercially dead. Chromebooks were dismissed as laptops that couldn't work offline, even as every application was migrating to the browser. Each shift had cost and latency reasons, but a recurring anxiety rode along with them: if computation lives somewhere else, you lose control. Companies that profit from local-first computing have always been happy to amplify that fear.

The backend already completed the thin-client transition. Cloud won decisively, and few teams argue for on-premises-first anymore. Much desktop software has moved into the browser, but the phone is frozen at the same conceptual barrier that existed when the first PC replaced the first terminal. A native app over an API already keeps its data elsewhere, but it still ships its interface as installed code through a store. We accepted that our servers are someone else's computers. We haven't accepted that our applications could be someone else's rendering.

Cloud broke through partly because no single company controlled the server. The web can't break through until it works on Apple's phone, and Apple decides what works on Apple's phone.

Default to the Web and Go Native Only for a Documented Gap

Before committing to a native app, ask one question: "Do we have a specific, documented constraint that the web platform cannot satisfy?"

For most mobile software needs, the answer is no. Safari, like a framework, is a roadmap you don't control, and its quirks take work. But those quirks sit in an engine you can test directly, not in a translation layer over two platforms. Where Safari lacks a feature, a native supplement covers exactly that gap. It brings back store review and a second release pipeline, but only for the features that need them.

The immediate objection is discoverability, since an app outside the store seems invisible. But store search is often where users go to fetch an app they already heard about through web search, social media, ads, or word of mouth. The store is more of a checkout counter than a shopping mall. Google Play already supports Trusted Web Activities, which let PWAs appear as store listings. The Microsoft Store accepts PWAs directly. Deep links, QR codes, and social sharing put users straight into web experiences.

Retention is the harder objection. A home-screen icon and push drive return visits, and on iOS both need a manual install that Safari never prompts for. Where retention depends on them, that is the documented gap a native supplement covers.

The web app is your product. The native app, if you need one at all, exists only for the features that Apple won't let the browser handle.

Context	Recommendation
Business or enterprise tools	Web, with instant deploys, no store friction, and broad coverage
E-commerce, content, media	Web, unless wearable integration or advanced AR is core to the product
Field ops, inspections, data collection	Web installed to the home screen, with Service Workers for offline and sync on open; native if data must sync in the background or geofencing is required
Consumer app in Android-dominant markets	Web PWA, with first-class app experience and no store tax
Consumer app with iOS as the primary platform	Web first; go native for install and push only when retention depends on them
Wearable companion (Apple Watch, Wear OS)	Native required
Persistent background location tracking	Native required
Home screen widgets, Siri / Assistant routines	Native required
Advanced AR with LiDAR or body tracking	Native required

Cost, velocity, and agility shouldn't be values we only demand from our backend infrastructure. Native apps aren't going away, and they shouldn't. But we should stop accepting a status quo where one company's business model sets the ceiling for how the entire industry ships code.

Techniques for Performance Tuning in Mobile Apps

Fri, 20 Feb 2026 03:39:25 +0000

Performance tuning is essential for mobile applications, both for enhancing user experiences and ensuring efficient resource utilization. Here, we'll explore some practical techniques, particularly lazy loading and resource management, that every mobile developer should consider.

Lazy Loading: A Game Changer

Lazy loading is a strategy used to delay the loading of resources until they are actually needed. This can significantly improve the initial loading time of your app. For instance, if you have a list of images in a gallery, don’t load them all at once. Instead, load only those that are visible to the user. As they scroll, load additional images. This reduces memory usage and speeds up the rendering time.

Example: In a typical React Native application, you can implement lazy loading by using the FlatList component, which efficiently loads only the items that are currently visible. This not only enhances performance but also leads to a smoother user experience.

Efficient Resource Management

Managing resources effectively is key to optimizing performance. This includes images, memory usage, and even network calls.

Image Optimization: Images often take up the largest share of usage in mobile apps. Compress images and use formats like WebP to reduce file size without sacrificing quality. Tools like ImageOptim and TinyPNG can be useful.
Memory Management: Regularly monitor and clean up resources that are no longer needed. For example, if your app fetches data, ensure that objects are released from memory once they're no longer in use. Using tools like LeakCanary can alert you to memory leaks in Android applications.
Network Calls: Minimize the number of network requests. Consider batching requests together and using caching strategies. Libraries like Retrofit for Android and Alamofire for iOS allow for more efficient handling of network calls.

Profiling Tools

Using profiling tools can help you understand where the bottlenecks in your application lie. Use tools like Android Profiler or Instruments for iOS to monitor CPU, memory usage, and network activity in real-time. This can help you pinpoint where optimizations are needed most.

Conclusion

Optimizing mobile application performance isn’t merely a luxury; it’s essential for retaining users and providing a great experience. By employing techniques like lazy loading and efficient resource management, coupled with continuous profiling, you can ensure your applications not only perform well but also stand out in a crowded marketplace. Let's focus on enhancing performance today for a better mobile future.

How much does it take to “finish” an app

Fri, 06 Feb 2026 01:40:00 +0000

Quite strange equation, don’t you think? But in a developer’s world, math works in unexpected ways.

Six months ago, I decided to build the best EPUB reader for Apple devices. I started immediately and, in four months, I had a working prototype with about 90% of the functionality. Everything worked as expected. Without fear, I launched my first TestFlight.

I expected anything and everything, but not this: I slid back to 10% done.

Somewhere in 2025, I watched Sean Allen’s video on the “90/90 rule.” Now I truly know, what that second 90% means.

TestFlight revealed two truths to me:

Developers are always wrong
When you think you’re almost done, you’ve barely started

These two things forced me to rethink the app’s internals, design, and UI.

I spent the last two to three weeks working harder than in the previous four months. I spent nights fixing bugs, unifying the interface, working on promised features, and making sure, that basics are there (like a consistent close button: top-right X, always).

And even now, I’m not “finished.”

Since this series is about justRead.app development, here’s the latest state with tech details.

What was fixed

The killer problem was simple: the app was freezing and crashing. Something I didn’t experience in development, something TestFlight users experienced a lot.

justRead.app loads epub files from the cloud, often buried deep in subfolders (not yet downloaded). When folder with books is selected, it ran three heavy processes:

Analyze all the (sub)directories for epub files (no files downloaded)
Extract thumbnails and some accessible data from those files (still no files downloaded)
Parse metadata (downloading of files starts now)
Users saw a “frozen” app, they tried everything, then app then crashed. What was worse: on relaunch with a selected library, it repeated the exact same cycle with the exact same result for user.

The fix:

The app is running the same processes, but now in the background with clear user progress indicators. Users can read downloaded books while those three processes are running. Simple and completely avoided with better testing.

Smaller bugs got fixed too: streak calculations, read-time tracking, bookmark saves.

What was changed

Non-crashing users gave me around 20 ideas like:

Tap anywhere on a book row to open it (not just the cover)
Hide settings on book start
Load font manually from menu, not automatically from folder

I experimented with all the ideas, iterated on users feedback and implemented what was the best fit.

What was added

No breakage risk here. Those were added:

Statistics dashboard
Roadmap with user voting
Alphabet jump bar for libraries
Extra settings tweaks.

Plus about 50 other small things, like highlighting your current TOC chapter.

TestFlight #2

It’s live today.
This time, I’m expecting crashes, freezes, and issues.

As a user, why is this all important?

You want polished apps, no crashes, intuitive user interface. You are expecting a developer who cares about the app, because he uses it.

That’s why TestFlight matters. Apple enables it, testers refine the app and the users get app as polished as possible.

The voting roadmap builds on this: you shape justRead.app’s future, prioritizing what you want.

As a developer, why is this all important?

We build apps and systems because we love to.

Sean’s rule reminds us: the final 90% polish is the app.

Rush development and release, and you ship a prototype.

Deliver the app polished, and you create something users love.

That’s why 90% + 90 % makes 100%.

And to answer the question in the beginning: it does take a lot more than what you have planned. Even if you have years of experience in development.

_justRead.app is an epub reader for iPhone, currently in TestFlight.__
Peter
Reader, Developer, justRead.app Creator

Preserving Scroll Position and Cursor State During Navigation Transitions

Sun, 25 Jan 2026 16:57:20 +0000

Have you ever noticed the difference between a simply good app and one that feels "native," polished, and premium? Often it's not about design or animations, but about small details we take for granted until they break. One such critical detail is an app's ability to remember where you left off. You're reading a long article, minimize the app to respond to a message, come back a minute later, and boom - you're thrown back to the very beginning of the text. Annoying, right? Or you're writing a note, switch to the browser, come back, and the keyboard is hidden with the cursor lost. In this article, we'll break down how to technically implement scroll position and cursor state preservation in iOS apps properly. We'll go beyond banal advice and examine real scenarios with navigation, tabs, and asynchronous data loading, so your users never feel lost.

Why Losing Context Hurts

Let's be honest: users don't know terms like "controller lifecycle" or "memory unloading." But they can absolutely feel when an app behaves stupidly. Losing scroll position or cursor during navigation is exactly that kind of stupid behavior. It destroys the interaction flow.

Imagine you're working in a code editor on an iPad. You scroll a file to line 500, place the cursor in the middle of a complex function, then open the side menu to check the project structure. You close the menu - and bam! - you're back at line one. At this moment, the app transforms from a professional tool into a toy.

Another classic example is news feeds or product catalogs. The user has scrolled down through a hundred items, drilled into a product detail screen, tapped Back, and their list reloaded, throwing them back to the top. This isn't just inconvenient, it's wasting the user's time. In a world with cutthroat competition for attention, such UX mistakes are unforgivable. An app that doesn't remember my state feels like a cheap web wrapper, even if it's written in pure Swift.

The Foundation: State Restoration in iOS

Apple has long provided us with a powerful mechanism to solve these problems - UI State Restoration. But in my observations, many developers ignore it, preferring to reinvent the wheel by saving data in UserDefaults or singletons. I was guilty of this myself for a long time, until I understood how the system works under the hood.

The built-in mechanism is good because it's systemic. It triggers not only when you push a controller onto the navigation stack, but also when the system kills your app in the background due to memory pressure, and then the user relaunches it.

The cornerstone of the entire mechanism is the restorationIdentifier property.

// In viewDidLoad
self.restorationIdentifier = "MyDetailViewController"

If a controller (or any UIView) doesn't have this identifier set, the system won't even attempt to save its state. This is your entry ticket. Once the identifier is set, two methods from the UIStateRestoring protocol come into play, which every UIViewController already has:

override func encodeRestorableState(with coder: NSCoder) {
    super.encodeRestorableState(with: coder)
    // Here we encode what we want to save
    coder.encode(someImportantData, forKey: "dataKey")
}

override func decodeRestorableState(with coder: NSCoder) {
    super.decodeRestorableState(with: coder)
    // And here we retrieve it back
    if let data = coder.decodeObject(forKey: "dataKey") as? DataToRestore {
        self.someImportantData = data
    }
}

Sounds simple, but the devil is in the implementation details. State Restoration doesn't save your model data (that's what Core Data or files are for). It saves interface state, which helps display that data exactly as it was before the user left.

Saving Scroll Position (ScrollView Offset)

The most common case is UITableView or UICollectionView. When the user leaves the screen (for example, pushes the next controller), we want to remember the contentOffset.

Many try to save the offset in viewWillDisappear. This is a working strategy for simple transitions within the navigation stack, when the controller stays in memory. But if we're talking about full-fledged State Restoration (with app termination), it's better to use specialized methods.

Let's say we have a UITableViewController. Fortunately, UITableView and UICollectionView already know how to save a lot themselves, if they (and their cells!) have restorationIdentifier set. But sometimes we need more control, especially if the scroll view is complex.

I prefer an explicit approach. Let's create a structure to store our screen's state:

struct ListViewState: Codable {
    let contentOffsetY: CGFloat
    // Can add selected cell ID, etc.
}

Now in the controller:

class MyListViewController: UIViewController, UITableViewDelegate {
    
    @IBOutlet weak var tableView: UITableView!
    private let stateKey = "ListViewControllerState"

    override func viewDidLoad() {
        super.viewDidLoad()
        // Critical for the mechanism to work
        self.restorationIdentifier = "MyListVC"
    }

    // MARK: - State Restoration

    override func encodeRestorableState(with coder: NSCoder) {
        super.encodeRestorableState(with: coder)
        
        // Save current offset
        let state = ListViewState(contentOffsetY: tableView.contentOffset.y)
        do {
            let data = try JSONEncoder().encode(state)
            coder.encode(data, forKey: stateKey)
        } catch {
            print("Failed to encode state: \(error)")
        }
    }

    override func decodeRestorableState(with coder: NSCoder) {
        super.decodeRestorableState(with: coder)
        
        guard let data = coder.decodeObject(forKey: stateKey) as? Data,
              let state = try? JSONDecoder().decode(ListViewState.self, from: data) else {
            return
        }
        
        // HERE'S THE MAIN GOTCHA
        // You can't just set contentOffset right now.
        // The table data might not be loaded yet.
        self.restoreScrollPosition(to: state.contentOffsetY)
    }
    
    private var pendingScrollOffset: CGFloat?

    private func restoreScrollPosition(to offset: CGFloat) {
        // Save the offset "for later"
        self.pendingScrollOffset = offset
    }
    
    // Call this method when data is definitely loaded and table has redrawn
    func dataDidFinishLoading() {
        tableView.reloadData()
        
        if let offset = pendingScrollOffset {
            // Sometimes need to give the Layout engine time to work
            DispatchQueue.main.async {
                self.tableView.setContentOffset(CGPoint(x: 0, y: offset), animated: false)
                self.pendingScrollOffset = nil
            }
        }
    }
}

Notice the pendingScrollOffset. This is a key moment when working with async data. If you try to restore contentOffset in decodeRestorableState when your table has 0 rows, the scroll will simply reset to 0. You must apply the saved offset only after the data is received and reloadData() has executed.

Hunting for the Cursor in UITextView

With text editors, things get even more interesting. Here we need to save not only scroll, but also cursor position (or text selection). This is handled by the selectedRange property of UITextView.

The problem is that cursor position is inextricably linked to keyboard focus. If during state restoration we simply set selectedRange but don't make the text field active (becomeFirstResponder), the user will see the text, possibly even scrolled to the right place, but without the cursor and keyboard. They'll have to tap again. This isn't the "seamless" experience we're aiming for.

Here's how I typically approach solving this in an editor controller:

class EditorViewController: UIViewController {
    
    @IBOutlet weak var textView: UITextView!
    private let selectionKey = "EditorSelectionRange"
    private let textKey = "EditorTextContent" // If text isn't saved in model

    override func viewDidLoad() {
        super.viewDidLoad()
        self.restorationIdentifier = "EditorVC"
        // Important: the textView itself also needs an ID if we want
        // the system to help us with scroll
        self.textView.restorationIdentifier = "EditorTextView"
    }
    
    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        // If we restored state and should show keyboard
        if shouldRestoreFocus {
            textView.becomeFirstResponder()
            shouldRestoreFocus = false
        }
    }

    // MARK: - State Restoration

    override func encodeRestorableState(with coder: NSCoder) {
        super.encodeRestorableState(with: coder)
        
        // Save range. NSRange encodes perfectly.
        let range = textView.selectedRange
        if range.location != NSNotFound {
             coder.encode(NSValue(range: range), forKey: selectionKey)
        }
        
        // Save whether this field had focus
        coder.encode(textView.isFirstResponder, forKey: "wasFirstResponder")
    }

    private var shouldRestoreFocus = false

    override func decodeRestorableState(with coder: NSCoder) {
        super.decodeRestorableState(with: coder)
        
        // Restore text (if needed)
        // textView.text = ...

        // Restore range
        if let value = coder.decodeObject(forKey: selectionKey) as? NSValue {
            let range = value.rangeValue
            // Critical moment: need to ensure range is valid for current text
            if range.upperBound <= textView.text.count {
                textView.selectedRange = range
                
                // Often need to force scroll to cursor,
                // as automatic scroll might not work during restoration
                textView.scrollRangeToVisible(range)
            }
        }
        
        // Remember if we need to restore focus
        shouldRestoreFocus = coder.decodeBool(forKey: "wasFirstResponder")
    }
}

I deliberately moved becomeFirstResponder() to viewDidAppear. Calling it in decodeRestorableState or viewDidLoad is often premature, since the view hierarchy isn't fully ready yet, and the system might ignore the keyboard request. Plus, keyboard appearance changes the UITextView insets, which can affect scroll. By doing this in viewDidAppear, we let the interface "settle."

Tabs, Modals, and App Backgrounding: A Unified Strategy

Developers often implement different mechanisms for different navigation types. For UINavigationController they use viewWillDisappear to save offset. For tab bar - UITabBarControllerDelegate methods. For app backgrounding - they subscribe to UIApplication.didEnterBackgroundNotification notifications.

This is a path to code duplication and bugs. I'm a proponent of a unified strategy.

The State Restoration mechanism described above (encodeRestorableState/decodeRestorableState) works perfectly for the "kill and resurrect" app scenario.

But what about simple navigation within a live app? Switching tabs or push/pop controllers. Here State Restoration in its pure form doesn't quite fit, since it's about "cold restart."

For "hot" navigation I prefer using lifecycle methods viewWillDisappear and viewWillAppear as the most reliable triggers.

Leaving the screen (viewWillDisappear): This is the perfect place to save current "ephemeral" state (scroll, focus) to a local controller variable or associated ViewModel. Doesn't matter why the screen is disappearing - new one being pushed, tab switching, or modal presenting. This method will be called.
Returning to screen (viewWillAppear / viewDidAppear): Here we check if there's saved state and apply it.

Example for "hot" saving in a list:

class HotListViewController: UIViewController {
    @IBOutlet weak var tableView: UITableView!
    
    // Store offset right in controller for quick transitions
    private var lastScrollOffset: CGPoint?

    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)
        // Leaving? Remember where we were.
        lastScrollOffset = tableView.contentOffset
    }
    
    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)
        
        // Returned? If there's something to restore, and data hasn't changed critically.
        if let offset = lastScrollOffset {
            // Important: check table isn't empty, otherwise crash or glitch
            if tableView.contentSize.height > offset.y {
                 tableView.setContentOffset(offset, animated: false)
            }
        }
    }
}

This approach works great when switching tabs in UITabBarController. Controllers in tabs usually aren't unloaded from memory, so the local lastScrollOffset variable will hold the value indefinitely, as long as the app session is alive.

If you're using custom navigation where controllers are recreated, you'll need to save this "hot" state somewhere external - for example, in a navigation service or global state storage tied to screen ID.

Testing: Breaking What We Built

The biggest mistake when implementing these features is improper testing. Simply minimizing the app with the Home button and reopening it is not a State Restoration test. In this case, the app simply "sleeps" in RAM, and when awakened, all views and controllers remain in place untouched. No decodeRestorableState is called.

To test for real, you need to simulate system actions:

Simulating memory pressure: In iOS Simulator, select Debug -> Simulate Memory Warning from the menu. If your controller is deep in the navigation stack or in an inactive tab, and it's "heavy," the system might unload it (call didReceiveMemoryWarning, and then possibly free its view). When returning to it, the restoration mechanism should trigger.
App termination in background: This is the main test.
- Launch the app from Xcode.
- Minimize it (go to Home Screen).
- In Xcode, press the "Stop" button (square). This kills the process, but as if the system did it in the background (saving state), not like a crash.
- Launch the app again from the icon on simulator/device (not the Run button in Xcode, otherwise the saved state will be wiped).
- If you did everything right, the app should launch not from scratch, but restore the controller hierarchy and their state, including scroll and cursors.

Common Pitfalls: Asynchronicity Is My Enemy

I've touched on this before, but I'll repeat it, as this is the most frequent cause of bugs.

The Problem: You saved contentOffset.y = 2000. When the app launches, decodeRestorableState fires, and you dutifully try to do tableView.setContentOffset(CGPoint(0, 2000)). But at this moment, your ViewModel has just started an asynchronous network request for data. The table is empty. Its contentSize is zero. Setting the offset is either ignored or gets reset to zero at the first data reload.

The Solution: Never restore scroll position (or text cursor) until the content is ready.

In decodeRestorableState, only decode the parameters and save them to temporary properties of the controller.
Wait for the data loading to complete.
Call reloadData().
Only after this (sometimes it's useful to wrap in DispatchQueue.main.async to let the layout cycle pass) apply the saved parameters.

If you're using reactive frameworks like RxSwift or Combine, this is convenient to do in a subscription to data updates, right after new data has been passed to the diffable data source or table reload has been called.

Careful attention to state preservation is what distinguishes a mature product from an MVP. It's care for the user that they may not consciously notice, but will definitely feel its absence if you decide to cut corners on this.

DevLog 20260122: Some Notes on MAUI, Unity, and Building "Map-Like" App Across Platforms

Fri, 23 Jan 2026 03:06:32 +0000

I've been meaning to write about this topic for a while.

MAUI looks great on paper. In fact, it has looked good on paper for years. Microsoft went a long way through UI and application frameworks: VBA, WinForms, MFC, WPF, Silverlight, UWP, Blazor, and now MAUI. Each iteration promises unification, abstraction, and better productivity over platform differences.

My first attempt at MAUI felt deceptively easy. I gave up shortly after.
So did the second attempt.

This time was different: I had a concrete delivery target. Giving up was no longer an option.

The Problem: A "Map-Like" Feature

The concrete requirement was simple to state but not easy to implement well: an app with a map-like feature. Not a full GIS stack, but something that looks and behaves like a map - large static textures, panning, zooming, overlays, and user interaction. No library - we are going to implement things from ground up.

My first instinct was to go cross-platform. After years of writing platform-locked GUIs that die the moment requirements change, I had no interest in repeating that mistake.

After surveying a wide range of options - inside and outside the C# ecosystem - I narrowed the choices down to:

Unity
Godot
MAUI

I tried Unity first.

Unity: Smooth Onboarding, Rough Reality

Unity deserves credit where it's due. It was the first mobile platform I ever used seriously, and I had already developed an Android game with it years ago.

Coming back with significantly more experience in C#, general software engineering, and game development, the onboarding felt excellent. The editor is mature, the documentation is decent, and the mental model is comprehensible.

Within about three days, I felt comfortable again - comfortable enough to implement the prototype. The implementation itself was straightforward (details skipped here), but the result was not.

On an actual Android device, performance was terrible. Given time pressure, I didn't fully chase down the root cause. A few hours of profiling and hypothesis testing later, I made the call to bail. Whether the issue was overdraw, batching, UI layout, or just the wrong API for the task didn't matter anymore - the risk was too high. (Oh, did I mention the build size was gigantic?)

I would have liked to include some demo code - at least the Unity version - but time didn't allow for it. That will have to wait for another post or a future amendment.

MAUI: Dry, and That's a Compliment

Rewriting the same idea in MAUI worked. Not "worked eventually" - it worked immediately and predictably. (Actually I tried Expo before MAUI, which was very smooth, then I looked at the hundreds of dependencies, and quietly reconsidered)

That forced me to rethink a long-held assumption (something I had from the CG world): engines optimized for real-time rendering should be good at texture-heavy workloads. In practice, frameworks optimized for application UIs are often better at static or semi-static content - especially when the interaction model looks more like "pan and zoom" than "render 60 FPS no matter what."

MAUI was dry. I wasn't excited to see its "mobile-like" layout on a Windows screen, and I still am not.
But dry was exactly what the project needed.

The Hidden Cost

That said, this experience didn't magically make me like MAUI - and that reminds me of Blazor.

The core issue in both cases is structural. These frameworks attempt to abstract over domains whose constraints diverge in important, non-accidental ways. The abstraction holds only as long as the application stays within a relatively narrow envelope of complexity.

MAUI Issues

Cross-platform inconsistencies are everywhere, not edge cases.
iOS AoT compilation and trimming can cause things to silently stop working.
Many behaviors that should be easily configurable (for example, disabling the Flyout) require platform-specific code.
Debugging failures caused by trimming or linker behavior is disproportionately painful.

Blazor Issues

Refactoring is far harder than it should be.
Large component trees quickly become rigid.
Abstractions that feel elegant early on tend to resist change later.

In both cases, the abstraction breaks - and when it does, you're often forced to drop down into platform-specific or framework-specific escape hatches that defeat the original promise.

These frameworks scale poorly in complexity, not because they are badly designed, but because they attempt to simplify domains that fundamentally resist unification. (Well, honestly in the case of MAUI I do think there are some design issues)

In general, MAUI is slightly better, because it's at least well encapsulated - just write platform-specific codes.

Some Takeaways

Game engines are not automatically good UI frameworks. Application frameworks may outperform engines for static, interaction-heavy visuals. In this particular case I haven't tried Godot, but I suspect the same issue wouldn't happen to Godot.
"Write once, run anywhere" really means "debug everywhere." And don't expect MAUI can save you effort because platform-specific behaviors are everywhere and it took me lots of time to back trace which seemingly trivial change many commits ago caused the entire application to break; Or, just turn off the magic MtouchUseLlvm.
MAUI is an OK choice for simple cross-platform mobile apps in C#.
Unified frameworks seem to trade short-term velocity for long-term friction. In the perfect world, I will use Swift for iOS.

In general, I wish framework developers make it clear their limitations so decision making can be made upfront.

Coderive Programming Language - Feature Proposal (Broadcasting main() - Package executable main)

Sat, 27 Dec 2025 11:25:52 +0000

Complete Broadcast Feature Rules

Core Concept:

One broadcasted main() per package that any file in the package can execute.

Rule 1: Broadcast Declaration

Only one file per package can declare a broadcast.

// File: app.cod (the broadcaster)
unit my.app (main: BusinessLogic)  // ✅ Only one per package

BusinessLogic {
    share main() {
        outln("Running business logic...")
    }
}

Rule 2: Execution Priority

When executing any .cod file:

Priority Order:

File's own main() (if exists) → runs immediately
Package broadcast main() (if declared) → loads and runs it
Error → no entry point found

Rule 3: Broadcasted Main is Execution-Only

Broadcasted main() methods cannot be called from code.

· ❌ Not from other files
· ❌ Not from same file
· ❌ Not from same class
· ✅ Only executable by interpreter as entry point

Rule 4: Any File Can Trigger Execution

Any file in the package can execute the broadcasted main().

Complete Examples

Example 1: Standard Package

File Structure:

myapp/
├── logic.cod       # Broadcasts main()
├── dev.cod         # Executes broadcast
├── test.cod        # Executes broadcast
└── prod.cod        # Executes broadcast

Code:

// File: logic.cod (broadcaster)
unit my.app (main: AppLogic)

AppLogic {
    share main() {
        outln("App running...")
        // Business logic here
    }
}

// File: dev.cod (executor)
unit my.app
// No main() → will execute AppLogic.main()

// File: test.cod (executor with local main)
unit my.app

TestRunner {
    share main() {  // Local main wins (Priority 1)
        outln("Running tests...")
    }
}

// File: prod.cod (executor)
unit my.app  
// No main() → will execute AppLogic.main()

Execution Results:

$ cod dev.cod
> App running...           (Runs broadcast)

$ cod test.cod
> Running tests...         (Runs local main, overrides broadcast)

$ cod prod.cod  
> App running...           (Runs broadcast)

Example 2: Library with Demo

File Structure:

mathlib/
├── library.cod     # Main library logic
├── demo.cod        # Example usage
└── benchmark.cod   # Performance test

Code:

// File: library.cod
unit math.lib (main: MathLibrary)

MathLibrary {
    // ❌ Cannot be called (broadcasted)
    share main() {
        outln("Math Library v1.0")
        showExamples()
    }
    
    // ✅ Can be called
    share add(a: int, b: int) -> int {
        return a + b
    }
    
    // ✅ Can be called
    share showExamples() {
        outln("2 + 3 = " + add(2, 3))
    }
}

// File: demo.cod
unit math.lib

Demo {
    // Local main overrides broadcast
    share main() {
        math := MathLibrary()
        outln("Demo: " + math.add(5, 7))
    }
}

// File: benchmark.cod  
unit math.lib
// No main() → executes MathLibrary.main()

Execution:

$ cod library.cod
> Math Library v1.0
> 2 + 3 = 5

$ cod demo.cod
> Demo: 12                 (Local main runs)

$ cod benchmark.cod
> Math Library v1.0        (Runs broadcast)
> 2 + 3 = 5

Example 3: Web Application

File Structure:

webserver/
├── server.cod      # Main server logic
├── dev.cod         # Development mode
├── prod.cod        # Production mode
└── health.cod      # Health check (special)

Code:

// File: server.cod
unit web.app (main: WebServer)

WebServer {
    // Execution-only entry point
    share main() {
        loadConfig()
        setupRoutes()
        startServer()  // Blocks forever
    }
    
    // Callable methods
    share loadConfig() { ... }
    share setupRoutes() { ... }
    share healthCheck() -> bool { ... }
}

// File: dev.cod
unit web.app
// Could set: DEBUG=true, PORT=3000
// Then runs WebServer.main()

// File: prod.cod
unit web.app  
// Could set: PORT=80, WORKERS=4
// Then runs WebServer.main()

// File: health.cod
unit web.app

HealthMonitor {
    // Special case: doesn't start server, just checks
    share main() {
        server := WebServer()
        healthy := server.healthCheck()  // ✅ Can call this
        outln("Healthy: " + healthy)
    }
}

Execution:

$ cod dev.cod
> [Starts server in dev mode]

$ cod prod.cod  
> [Starts server in production mode]

$ cod health.cod
> Healthy: true           (Runs local HealthMonitor.main())

Example 4: Error Cases

Multiple Broadcasts (Error):

// File A: 
unit my.pkg (main: App1)  // ❌ ERROR: Already declared in File B

// File B:
unit my.pkg (main: App2)  // First one wins? Error?

Calling Broadcasted Main (Error):

// File: caller.cod
unit my.app

Caller {
    share test() {
        AppLogic.main()  // ❌ ERROR: Cannot call broadcasted main()
    }
}

No Entry Point (Error):

// File: empty.cod
unit my.app
// No local main, no package broadcast

$ cod empty.cod
Error: No executable main() found

Package 'my.app' has no broadcast entry point.
Add to any file: unit my.app (main: ClassName)

Rule Summary Table:

Scenario What Happens Example
File has main() Runs local main test.cod runs tests
File has no main(), package has broadcast Runs broadcasted main dev.cod runs AppLogic.main()
File has no main(), no broadcast Error empty.cod fails
Trying to call broadcasted main() Error Caller.test() fails
Multiple broadcasts in package First wins? Error? Design decision needed

Key Benefits:

Consistency: One way to run the package
Flexibility: Files can override with local main()
Separation: Logic vs execution points
Tooling: Different files for different purposes
Clarity: Explicit broadcast declaration

Philosophy:

"One canonical way to run the package, accessible from anywhere in the package, overrideable when needed."

This is clean, practical, and elegantly simple!

Actual Run of Coderive Language for Lazy Array and Loop

Fri, 26 Dec 2025 11:56:28 +0000

Real Run of Coderive

Real Code of Coderive

Coderive Language - 50ms for 1 Quintillion Elements in a Loop

Mon, 22 Dec 2025 03:54:21 +0000

Author: Danison Nuñez
Project: Coderive
Project Type: Programming Language
Highlight: Formula-based Execution

Coderive - Iterating Through 1 Quintillion in a Loop

Subtitle: How a phone interpreter achieves what supercomputers cannot

The Impossible Loop:

// In any other language, this would be computational suicide
for i in [0 to 1Qi] {  // 1,000,000,000,000,000,000 iterations
    arr[i] = i * i
}

Traditional Reality:

· Python: MemoryError at array creation
· Java/C++: Theoretical 31 years (with 8 exabytes of RAM)
· NumPy/TensorFlow: Immediate crash
· GPU Computing: 80GB VRAM limit exceeded

Coderive's Reality: 50 milliseconds.

The Magic Behind It:

NaturalArray: Virtual arrays that store formulas, not data
Runtime Pattern Detection: Transforms loops to mathematical expressions
Lazy Evaluation: Computes only what's accessed
Formula Storage: LoopFormula, ConditionalFormula, MultiBranchFormula

Technical Deep Dive:

// What you write:
for i in [0 to 1Qi] {
    if i % 2 == 0 {
        arr[i] = i * i
    } elif i % 3 == 0 {
        arr[i] = i * i * i
    } else {
        arr[i] = i
    }
}

// What Coderive creates internally:
arr.addMultiBranchFormula(
    conditions: [i%2==0, i%3==0],
    expressions: [i*i, i*i*i],
    elseExpr: i,
    range: [0, 1Qi]
)

The Optimization Pipeline:

User Code → Pattern Detection → Formula Creation → Lazy Evaluation
     ↓           ↓                ↓                  ↓
   O(n)        O(1)             O(1)              O(1) per access

Complete Pattern Coverage:

· ✅ Simple Transformations: arr[i] = f(i) → LoopFormula
· ✅ Binary Decisions: if-else → ConditionalFormula
· ✅ Multi-way Branches: if-elif-else → MultiBranchFormula
· ✅ Partial Updates: if-only with implicit else preservation

Real-World Impact:

// Process every pixel in 8K video (≈33 million frames)
for frame in [0 to 33M] {
    for pixel in [0 to 7680*4320] {  // 33 million frames × 33 million pixels
        if brightness > 128 {
            pixels[pixel] = 255
        } elif brightness > 64 {
            pixels[pixel] = 128
        } else {
            pixels[pixel] = 0
        }
    }
}
// Traditional: Impossible
// Coderive: Seconds, not centuries

The Secret Sauce:

· No data movement (arrays stay virtual)
· No parallel programming (formulas are inherently parallel)
· No memory management (O(1) memory complexity)
· No specialized hardware (runs on Java 7)

Conclusion: Coderive doesn't just make loops faster—it redefines what's computationally possible on commodity hardware.

Check Coderive now at:

[http://github.com/DanexCodr/Coderive][1]

Coderive - A New Programming Language of 2025

Sun, 21 Dec 2025 05:02:05 +0000

Author: DanexCodr
Project: Coderive
Project Type: Programming Language

While AI takes the spotlight, Coderive solves computational impossibility

In a landscape dominated by AI integrations and web frameworks,Coderive emerges as a fundamentally different kind of programming language for 2025. Instead of chasing the latest AI trend, Coderive addresses a more profound problem: breaking computational complexity barriers that have limited programmers for decades.

The Core Innovation:
Coderive introduces"Formula-Based Computing" - a runtime optimization system that transforms traditional O(n) operations into O(1) mathematical formulas. Where other languages iterate, Coderive calculates.

Syntax That Speaks for Itself:

// Traditional languages would crash or take millennia
arr := [0 to 1Qi]  // 1 quintillion elements - virtual, not allocated

// This runs in 50ms, not 31 years
for i in [0 to 1Qi] {
    if i % 2 == 0 {
        arr[i] = i * i          // "even" squares
    } elif i % 3 == 0 {
        arr[i] = i * i * i      // "multiple of 3" cubes  
    } else {
        arr[i] = i              // everything else
    }
}

Why 2025 Needs Coderive:
· Big Data Without Big Infrastructure: Process trillion-row datasets on phone hardware
· Mathematical Clarity: any[] and all[] replace confusing &&/|| operators
· Runtime Intelligence: Pattern detection happens as code executes, no pre-compilation needed
· Three World System: Scripts, Methods, and Modules for different abstraction levels

The Quantifier-First Design Philosophy:
Abandoning traditional boolean operators,Coderive embraces a more expressive syntax:

// Crystal clear intent vs traditional &&/|| confusion
if all[scores >= 60, !isFailed, attempts < 3] { proceed() }
if any[isReady, hasBackup, forceMode] { execute() }

Performance That Defies Convention:
Operation Coderive Python/Java/C++
Process 1 quintillion elements 50ms Never completes
Memory for 1 quintillion array O(1) 8EB (impossible)
Conditional classification O(1) O(n)

Available Now:
Coderive v0.4.0 runs on Android/Java 7+, proving that revolutionary computation doesn't require cutting-edge hardware. It's a language for the algorithmic future, available today.

Check it out now at: https:// github.com/DanexCodr/Coderive

Ready to Build Your App? Let’s Team Up Remotely

Tue, 02 Dec 2025 04:46:20 +0000

If you’re building a mobile app in 2025, you already know the vibe: everything moves fast, users expect smooth experiences, and the market punishes anything that feels mid. That’s exactly where a solid mid-level mobile app developer steps in—someone who’s got enough battle scars to avoid rookie mistakes but still hungry to experiment, iterate, and deliver.

A mid-level dev typically knows their way around Android (Java/Kotlin) or iOS (Swift), understands API integration, state management, debugging, performance tuning, and can take a feature from idea → wireframe → shipped build without needing hand-holding. They’re also the ones who think about things like offline support, clean architecture, accessibility, and making sure your app doesn’t drain someone’s battery like a crypto miner.

Right now, I’m open for remote collaboration on mobile app projects—whether you're a startup validating an idea, a founder trying to scale your product, or a business looking to modernize your tech. If you need someone who builds clean, maintainable, scalable apps without the corporate-level chaos, I’m your person.

If you’ve got a requirement—big, small, prototype, or full product—feel free to reach out. Let’s build something users won’t just download, but actually love using.

Coderive - A mobile-first programming language created entirely on a phone

Fri, 14 Nov 2025 03:15:57 +0000

Coderive - A Mobile-First Programming Language Created Entirely on a Phone

In the world of compiler development and programming language design, we often imagine teams of engineers working in high-tech offices with powerful workstations. But what if I told you that a fully-featured programming language with a sophisticated compiler pipeline was built entirely on a mobile phone? Meet Coderive - a groundbreaking project that challenges our assumptions about where and how serious software development can happen.

The Vision Behind Coderive

Coderive represents a bold vision: "To have the very first Filipino-made mobile-first production-ready self-hosting programming language." This isn't just another programming language - it's a statement about accessibility, innovation, and breaking down barriers in software development.

Development Against All Odds

The developer, DanexCodr, created Coderive using only a smartphone and a carefully curated set of mobile development tools:

· Java NIDE - A fast Java 7 compiler for Android
· Quickedit - For code editing
· Termux - Providing a Linux environment
· AI Assistants - DeepSeek and Gemini for debugging and problem-solving

This constrained environment forced creative solutions and optimized the entire development process for mobile-first workflows.

Technical Architecture: Sophisticated Under the Hood

Despite its mobile origins, Coderive boasts a surprisingly sophisticated technical architecture:

Dual-Parser System

Coderive features not one, but two independent parsing systems:

· ANTLR-based parser for robust, grammar-driven parsing
· Manual recursive backtracking parser for flexibility and mobile optimization

This dual approach ensures parsing reliability while maintaining performance on mobile devices.

Advanced Compilation Pipeline

The compilation system demonstrates remarkable technical depth:

// From CompilationEngine.java
public void compileFullPipeline(ProgramNode ast, String outputFilename, boolean disassemble) {
    BytecodeProgram bytecode = compileToBytecode(ast, disassemble);
    compileToNative(bytecode, outputFilename);
}

The pipeline compiles through multiple stages: source → AST → bytecode → native assembly, supporting both interpretation and native compilation.

Innovative Register Allocation

One of Coderive's most impressive features is its "future-cost predictive register spilling" system. The register allocator doesn't just use simple LRU - it predicts which registers will be needed soon and makes intelligent spilling decisions:

// From RegisterSpiller.java - Advanced spill heuristic
private int estimateNextUseDistance(String register, int currentPc, List<BytecodeInstruction> bytecode) {
    // Complex lookahead analysis to predict register usage patterns
    // This goes far beyond typical academic register allocators
}

Language Features That Shine

Coderive isn't just technically impressive - it introduces several innovative language features:

Multi-Return Slots

share interactiveDemo {
    ~| formula, operation  // Declare return slots
    local calculate(int a, int b, string op) {
        if op == "+" {
            ~ formula a + b      // Return multiple values
            ~ operation "addition"
        }
    }
}

Expressive Smart For-Loops

The language supports complex loop patterns that would be verbose in other languages:

// Various supported step patterns
for i by 2 in 1 to 10          // Simple step
for i by *2 in 1 to 100        // Multiplicative step  
for i by i-=5 in 100 to 1       // Compound assignment step
for i by *+2 in 1 to 1000      // Combined operator step

Clean, Modern Syntax

Coderive reduces boilerplate while maintaining readability:

unit sample.program get {
    cod.Math  // Clean import system
}

share main() {
    output "Welcome to Coderive!"
    // Implicit class and method structure
}

The Compilation Output: Professional Grade

Despite being built on a phone, Coderive generates professional-quality assembly code:

    .text
    .global calculate
calculate:
    stp x29, x30, [sp, #-16]!
    mov x29, sp
    sub sp, sp, #64
    // Advanced register allocation in action
    stp x19, x20, [x29, #-16]
    stp x21, x22, [x29, #-32]
    // ... sophisticated ARM64 assembly
    mov x0, x21  // Return value
    ret

Why Coderive Matters

Democratizing Compiler Development

Coderive proves that you don't need expensive hardware or institutional backing to create sophisticated programming tools. A smartphone and determination are enough.

Filipino-Led Innovation

In a field dominated by Western institutions and large tech companies, Coderive represents important representation and demonstrates that innovation can come from anywhere.

Mobile-First Mindset

While others treat mobile as a secondary platform, Coderive embraces it as primary, leading to optimizations and approaches that desktop-focused tools might miss.

AI-Paired Development Methodology

The project showcases how AI assistants can accelerate complex development tasks, potentially changing how individual developers approach large projects.

Current Status and Future

Coderive is already remarkably functional:

· ✅ Full interpreter with complete language features
· ✅ Native code generation for ARM64 and x86_64
· ✅ Advanced register allocation with spill optimization
· ✅ Complex control flow and loop patterns
· Ongoing improvements to string handling and type system

The project welcomes community involvement and discussion through GitHub Discussions.

Conclusion: Redefining Possible

Coderive stands as a testament to what's possible when passion meets persistence. It challenges our assumptions about:

· Where serious development can happen (anywhere with a phone)
· Who can create programming languages (anyone with vision)
· How we approach tool development (mobile-first from day one)

In the words of the project's motto: "Built with passion and persistence on and for mobile devices — proving that innovation knows no hardware boundaries."

Coderive isn't just another programming language; it's a demonstration that the future of software development might be more mobile, more accessible, and more diverse than we ever imagined.

Happy coding to derive your visions!

Explore Coderive: (GitHub Repository)

Building “R U Ready” – My Flutter Dating App Development Journey

Tue, 04 Nov 2025 11:59:38 +0000

I’ve been working on a new project called R U Ready, a full-featured Flutter dating app, and it’s been one of the most technically enriching experiences in my Flutter journey.

The goal is to build a real-time, scalable, and intuitive dating platform using Flutter + Firebase as the core stack. I started with a modular architecture to ensure clean separation between UI, logic, and data layers — applying principles of Clean Architecture and MVVM for maintainability.

Key modules include:

Authentication Layer using Firebase Auth (Email/Mobile)

Profile Management with dynamic Firestore data binding

Swipe Engine built with custom animation controllers for smooth profile transitions

Chat System using Firestore real-time streams and optimized query listeners

App Theming & State Management implemented via Provider and ChangeNotifier for reactive UI updates

Throughout the process, I’ve learned how to fine-tune Firestore query performance, implement pagination, handle context-safe navigation, and optimize rebuilds using widget lifecycle awareness.

Currently, I’m focusing on extending the architecture for Reels and Group Chat features while integrating AdMob monetization and in-app upgrades.

Every commit teaches me something new about building production-grade apps with Flutter.

Phone Agent in Action!

Thu, 28 Aug 2025 11:00:09 +0000

Hi everyone,

a quick demo what our Agent can do on our cloud!

Check out our frame work GitHub if you want to try it!

Leave us a star if you like it or give us feedback!

Great apps balance a consistent brand identity with respect for the native UI/UX of iOS and Android.

Sat, 23 Aug 2025 10:16:11 +0000

The Bilingual App: Speaking Fluent iOS and Android Without Losing Your Identity

Have you ever downloaded an app and, within the first few seconds, had the strange feeling that something was... off? Maybe the buttons were in the wrong place, the navigation felt clumsy, or the simple act of going back a screen was counterintuitive. Often, this sense of the digital "uncanny valley" happens when an application was designed for one platform and simply "ported" to another without care.

In the pursuit of efficiency, driven by cross-platform frameworks like React Native, Flutter, and Kotlin Multiplatform, a tempting siren call emerges: create a single design, a single flow, a single experience, and deploy it everywhere. But this approach, while saving time in the short term, often results in an app that feels like an awkward tourist—functional, but clearly a stranger in a foreign land.

The real challenge—and the mark of a truly excellent app—is finding the perfect balance. How can we build a consistent user experience that reinforces our brand, yet also speaks the native "dialect" of both iOS and Android, respecting the usability that users of each platform already know and love?

The Seductive Trap of "One Design to Rule Them All"

The promise of "write once, run anywhere" often translates to "design once, deploy everywhere." The result is frequently one of two problematic scenarios:

The iOS Clone on Android: The app on Android has tab bars at the bottom, "back" carets in the top-left corner, and no support for the system back gesture. It works, but it screams "I don't belong here" to any experienced Android user.
The Android Clone on iOS: The app on an iPhone has a "hamburger menu" (Navigation Drawer) for primary navigation, shadows and elevations typical of Material Design, and alerts that don't look like native iOS alerts. Again, it's functional, but it feels like a poorly adapted web app.

Both scenarios break a fundamental rule of UX: the principle of least astonishment. Users shouldn't have to learn a new interaction language just to use your app.

The Core Principle: The Brand's Soul vs. the Platform's Body Language

The solution is not to build two completely different apps, nor is it to create an identical clone. The solution is to think of your app as having two parts: its soul (the brand) and its body language (the platform).

What to Keep Consistent (Your App's Soul):
These are the elements that define your identity and ensure that, no matter the device, the user knows they are in your application.

Brand Identity: Colors, logos, primary typography, and custom iconography. Your color palette and headline font should be the same.
Core User Flow: The logic and steps to complete a fundamental task (e.g., posting a photo, buying a product, booking a flight) should be conceptually the same.
Terminology and Content: The words you use to describe features and the tone of voice in your copy should be consistent. A "Pin" on Pinterest is a "Pin" on both platforms.
Key Functionality: The core features offered by your app should be the same, ensuring experience parity.

What to Adapt (Your App's Body Language):
These are the elements that make your app feel "at home" on each platform. It's your way of showing respect for the user's ecosystem.

Navigation Patterns: How users move between the main screens.
Native UI Controls: The look and behavior of elements like buttons, switches, date pickers, and alerts.
Gestures: How users physically interact with the screen (e.g., the "back" gesture).
System Integrations: How your app interacts with the OS (e.g., share sheets, notifications, permissions).

A Tale of Two Platforms: Practical Examples

Let's see how this duality applies to specific components:

iOS: The gold standard is the tab bar (UITabBar) at the bottom of the screen. It's persistent, always visible, and provides quick access to the main sections.
Android: While the bottom navigation (BottomNavigationView) has become very popular and is now a common pattern (similar to iOS), the side navigation drawer is still a viable option for apps with many top-level navigation sections. The choice here depends on your app's complexity, but the implementation of each should follow Material Design guidelines.

The Decision: Consider using bottom navigation on both platforms for brand consistency, but ensure that the implementation of each (animations, spacing, behavior) is native to the platform.

The Ubiquitous "Back" Button

iOS: Back navigation is almost always contextual. There's a "Back" button in the top-left corner of the navigation bar, and the universal gesture is swiping from the left edge of the screen.
Android: Back navigation is a universal system concept. Whether through a gesture (swiping from the left or right edge) or a system bar button, Android has a "back" action that works system-wide. Your app must respond to this action. Placing a "Back" button in the top-left corner is common, but it should complement, not replace, the system's behavior.

The Decision: On iOS, implement the edge-swipe gesture. On Android, ensure your navigation stack responds correctly to the system's "back" event.

Controls and Components

Switches: iOS has its iconic, rounded design. Android (Material Design) has a distinct design with a "track." Use the native component for each.
Date Pickers: iOS is famous for its spinning "wheels" or the newer compact calendar picker. Android uses a prominent calendar dialog. Forcing one style onto the other is one of the most jarring UX violations.
Alerts and Dialogs: Each platform has its own style for alerts, action sheets, and context menus. Using the native components ensures they are readable, accessible, and behave as the user expects.

Typography and Touch Targets

iOS: Uses the San Francisco (SF) font family.
Android: Uses the Roboto font family.

While you should use your brand font for headlines, using the system's default font for body text and UI elements can make your app feel much more integrated. Additionally, each platform has specific guidelines for minimum touch target sizes to ensure accessibility.

How to Achieve Balance: A Practical Strategy

Start with an Agnostic Design System: Design your brand components (colors, typography, primary buttons) without a specific platform in mind. This is your app's "soul."
Identify Platform-Specific Components: During the design phase, explicitly mark which components should use their native implementation (date pickers, alerts, etc.).
Design Separate Navigation Flows: Create the navigation map for iOS and Android separately, even if the screens are the same. Think about how the user will move through each ecosystem.
Test on Real Devices: Don't just rely on emulators. The tactile feel, gestures, and performance can only be truly evaluated on real hardware, with real users from each platform.

Conclusion: Be a Gracious Host in Both Homes

The best apps don't force users to adapt to them; they adapt to their users. They understand that while the brand and core functionality should be consistent, the way that functionality is presented and accessed must respect the local "language."

Being a "bilingual app" means being a gracious host. You welcome your iOS and Android guests into a home with your unique decor and personality (your brand), but you serve them on plates and with utensils they already know how to use (the platform conventions).

This respect for the user's familiarity and intuition is what builds trust, reduces frustration, and ultimately, turns a functional app into an experience that users love and return to.

Why I Started Creating Models in My Flutter Project

Wed, 20 Aug 2025 18:01:17 +0000

When I was building my music app in Flutter, I began with the “quick and dirty” way of handling data. You know that vibe coding flow — fetch some JSON, dump it in a Map<String, dynamic>, and just wire it up to the UI. It felt fast at first, but it quickly turned into a mess.

Take this example: I was fetching playback data from my service and passing it around like this:

class PlaybackWidget extends StatelessWidget {
  final Map<String, dynamic> playbackData;

  PlaybackWidget({required this.playbackData});

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text("Now playing: ${playbackData['title']}"),
        Text("Artist: ${playbackData['artist']}"),
        Text("Mode: ${playbackData['playbackMode']}"),
      ],
    );
  }
}

It worked. But every time I typed playbackData['title'], I felt uneasy. One typo like playbackData['titel'] and boom — runtime error. On top of that, the widget didn’t tell me what kind of data it really expected. Was playbackMode a string? An enum? A number? I had to keep it all in my head.

Switching to Models

After wrestling with this a few times, I finally decided to create a proper model for my playback data.

enum PlaybackMode { repeat, shuffle, normal }

class Playback {
  final String title;
  final String artist;
  final PlaybackMode playbackMode;

  Playback({
    required this.title,
    required this.artist,
    required this.playbackMode,
  });

  factory Playback.fromJson(Map<String, dynamic> json) {
    return Playback(
      title: json['title'],
      artist: json['artist'],
      playbackMode: PlaybackMode.values.firstWhere(
        (e) => e.toString() == 'PlaybackMode.${json['playbackMode']}',
      ),
    );
  }

  Map<String, dynamic> toJson() {
    return {
      'title': title,
      'artist': artist,
      'playbackMode': playbackMode.name,
    };
  }
}

Now my widget looked much cleaner:

class PlaybackWidget extends StatelessWidget {
  final Playback playback;

  PlaybackWidget({required this.playback});

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text("Now playing: ${playback.title}"),
        Text("Artist: ${playback.artist}"),
        Text("Mode: ${playback.playbackMode.name}"),
      ],
    );
  }
}

Suddenly everything felt safer. Autocomplete worked, I didn’t worry about typos, and my code told me exactly what kind of data I was dealing with.

What I Learned

Models might look like “extra code” at first, but in reality, they save time and mental energy. Instead of juggling raw maps everywhere, you give your app a solid data structure to lean on.

In my case, once I switched to models in my music app, my code got way easier to maintain. Adding new fields, refactoring, or passing data between widgets stopped being a headache.

So if you’re just hacking away in Flutter and think models are overkill — trust me, they’re not. Future-you will thank present-you for adding them.

How I Paid Off a Little Technical Debt in My Flutter Music App

Fri, 15 Aug 2025 12:08:11 +0000

So here’s the story.
I was facing a technical debt kind of issue in my Flutter music app — my MusicPlaybackService was doing two jobs:

Talking to the audio engine (audio_service + just_audio) to play/pause/skip.
Acting like a ChangeNotifier to update the UI about song lists, current song, etc.

Why this was bad

At first, it felt convenient.
"Why not just let one class handle everything, right?"

But here’s the problem with one giant class doing multiple jobs:

Unnecessary widget rebuilds: Even small playback state changes could cause the entire UI to refresh.
Harder debugging: Was a bug coming from the UI or the audio engine? You never know without digging deep.
Tight coupling: Any change in playback logic risked breaking the UI.
Poor testability: Couldn’t mock or test the UI without pulling in the full audio player.

The Refactor

I split the responsibilities like this:

Before:

MusicPlaybackService
   ↳ Handles playback (play/pause/skip)
   ↳ Stores allSongs, currentSong
   ↳ Notifies UI of changes

After:

MusicPlaybackService   → Only handles audio playback logic
PlaybackProvider       → Holds UI-facing state & notifies widgets

How the new structure works

MusicPlaybackService → Talks to the background audio handler, keeps pure playback logic. No notifyListeners() here.
PlaybackProvider → Watches the service, stores the current song list, play state, etc., and only notifies the UI when something UI-relevant changes.

Benefits I noticed immediately

Fewer unnecessary rebuilds → smoother scrolling, faster tab switches.
Easier debugging → I instantly know whether an issue is in the audio engine or UI.
More modular code → I can swap playback logic without rewriting UI state.
Better testing → I can mock the provider without worrying about actual audio playback.

Lesson learned

If your service class is doing too much — step back and split the responsibilities.
It’s like having a drummer who’s also trying to do the vocals and mix the sound live. Eventually… something’s going to be off-beat.

UI issues are beautiful.....

Fri, 25 Jul 2025 10:29:26 +0000

Ever had your Flutter screen layout shift or break when your text changes length?

The Problem

In my music player screen, long song titles caused the UI to push down — shifting the seek bar & controls, or worse, throwing an overflow error.

Here’s how the screen was built without LayoutBuilder:

// Problematic layout
return Padding(
  padding: const EdgeInsets.all(20),
  child: Column(
    children: [
      const SizedBox(height: 80),
      AnimatedBeatCircle(size: 300, isPlaying: true),

      // Title (may be 1 or 2 lines)
      Text(
        mediaItem.title,
        maxLines: 2,
        overflow: TextOverflow.ellipsis,
      ),

      const SizedBox(height: 10),
      // Seek bar + playback controls follow
      ...
    ],
  ),
);

Issue:

If the title is short → empty space.
If it’s long → seek bar/control buttons shift or overflow.
UI feels unstable between different songs.

The Fix: Use LayoutBuilder + Expanded

By wrapping the layout in a LayoutBuilder and explicitly splitting the screen into:

Top (flexible): Beat circle, title, artist

Bottom (fixed): Seek bar, playback controls

We pin the bottom UI and allow the top to adapt safely.

// Fixed layout
return LayoutBuilder(
  builder: (context, constraints) {
    return Column(
      children: [
        Expanded(
          child: Padding(
            padding: const EdgeInsets.all(20),
            child: Column(
              children: [
                AnimatedBeatCircle(size: 300, isPlaying: true),
                const SizedBox(height: 20),
                Text(
                  mediaItem.title,
                  maxLines: 2,
                  overflow: TextOverflow.ellipsis,
                ),
                Text(mediaItem.artist ?? ''),
              ],
            ),
          ),
        ),

        // Bottom stays pinned no matter what
        Padding(
          padding: const EdgeInsets.symmetric(horizontal: 20.0),
          child: Column(
            mainAxisSize: MainAxisSize.min,
            children: [
              Slider(...),
              Row(...), // duration labels
              Row(...), // controls
            ],
          ),
        ),
      ],
    );
  },
);

Result:

Layout is predictable
Playback controls stay pinned
UI looks great no matter how long the song title is!

One wrong activity caused me 10+ hours of debugging

Tue, 22 Jul 2025 10:48:31 +0000

The music app I vibe coded is working fine but I wanted to improve it. So I decided to add some extra features like playing in the background so that I can control playback from notification bar. Cool right ?

I also wanted to refactor my code because It would give me huge pain if I scale it just from here. I started working on it, I fixed all errors of refactoring but when I say

flutter run

It gives me an error which forced me scratch my head for days.

The Activity class declared in your AndroidManifest.xml is wrong...

Now I'm trying to fix things in xml file which I needed to actually make change in MainActivity.kt . The only thing I needed to replace below code

class MainActivity: FlutterFragmentActivity() {}

with this

class MainActivity: AudioServiceFragmentActivity() {}

Finally I'm a bit relieved. I did learn a lot as I actually reverse engineered code, refactored so much just to find answers. Now I really need a break lol.....................

Dynamic Interfaces with Server-Driven UI for Mobile

Sun, 20 Jul 2025 18:59:37 +0000

In today’s software industry, apps need to be able to quickly adapt to a variety of factors, such as user experience, new features, bug fixes, and more. Furthermore, these items need to be submitted to the App/Play Store, as far as it is concerned mobile apps, where it is reviewed and then made available for users to install. This takes a little time. However, the main point I want to highlight is the need for the user to update the app, most of the time. This can usually be mitigated by automatic updates in the app stores, but at the development level, it is still necessary to submit to the approval process in the app stores. This disadvantages exists because most applications today have their user interface hard-coded into the client application — and that’s okay. But there is another approach that helps solve many of these problems: Server-Driven UI, and in today’s article I’m going to talk about this way of creating more dynamic and personalized interfaces.
Understanding Server-Driven UI (SDUI)

Grossly simplified, the Server-Driven UI is an architectural approach where the user interface structure, layout and content are determined by the server rather than being hard-coded in client application. In a traditional mobile app, the representation of the UI is created into the app. The SDUI reverses this responsibility, allowing the interface to update dynamically and server-side changes to be instantly reflected in the app, all without updating the app via the App/Play Store.

Imagine that you are developing a mobile application that needs to display a campaign to users. This feature changes the content and layout quite a bit, and this depends on the time and users we want to reach. With the traditional approach, each change in the layout means a new deploy. In this context, SDUI emerges as a solution, as it sends a different screen and content, such as title, subtitle, padding and action dynamically.

Similarly, server-driven UI is a great option for A/B testing, an experimentation technique that aims to compare different versions of an element to determine which performs best based on a metric, such as clicks and time spent on screen. In this way, the server can send different versions of the UI to groups of users to test design hypotheses.

In both scenarios, we can use the execution flow, where the application makes an HTTP request to the server to request a canvas interface. After that, the server responds with a JSON representing a UI, which the application then needs to translate into a native component and render it.

SDUI Implementation Benefits

Quick updates: Change the UI without having to release a new version of the app.
Dynamic customization: Different users can see different screens without changing the app code.
Easier A/B experiments: You can test different layouts just by changing what the server.

SDUI Implementation Challenges

Parser: The app needs to be able to understand and build the interface from the data. - Such a parser can be quite complex to implement.
Performance: It may be a bit slower to build the screen (especially if the JSON is large).
Less control: If the server fails or sends wrong data, the UI may break.

Building dynamic interfaces with SDUI in Flutter

Here I bring a simple example in Flutter using SDUI. I will implement a simple parser for widgets, responsible for converting JSON content into widgets, dynamically. I also show a piece of code that renders the user interface. But before that, it is better to show what a JSON would look like:

{
 "type": "screen",
  "components": [
    {
      "type": "text",
      "text": "Special Promotion!",
      "style": {"fontSize": 24, "fontWeight": "bold"}
    },
    {
      "type": "button",
      "text": "Buy now",
      "style": {
        "backgroundColor": "#6200EE",
        "textColor": "#FFFFFF"
      },
      "action": {"type": "navigate", "url": "/screen/checkout"},
    }
  ]
}

The parser:

import 'package:flutter/material.dart';

class SDUIParser {

  SDUIParser();

  Widget parse(Map<String, dynamic> json) {
    final type = json['type'];

    Widget widget;

    switch (type) {
      case 'text':
        widget = Text(
          json['text'] ?? '',
          style: TextStyle(
            fontSize: (json['style']?['fontSize'] ?? 16).toDouble(),
            fontWeight: json['style']?['fontWeight'] == 'bold'
                ? FontWeight.bold
                : FontWeight.normal,
          ),
        );
        break;

      case 'button':
        widget = ElevatedButton(
          onPressed: () {
            print('Navigate to: ${json['action']?['url']}');
            // code to implementation
          },
          child: Text(json['text'] ?? ''),
        );
        break;

      default:
        widget = const SizedBox.shrink();
    }

    return widget;
  }
}

The main program:

void main() {
  final parser = SDUIParser();

  runApp(MaterialApp(
    home: Scaffold(
      body: Center(
        child: parser.parse(json), // this json comes from the server
      ),
    ),
  ));
}

I confess that the first time I saw this approach, it seemed like a hack, but now that I’ve studied it, I’ve realized how much sense it makes and how it helps with customization and deployment. This approach has opened my mind to possibilities that I can’t explore with hard-code, and I believe that SDUI is much more complex than the traditional approach, mainly because of the parser, and this can open up gaps for bad implementations, like any other approach. It’s a big challenge, but given its benefits, it’s worth trying in complex applications.

Did you get a better understanding of Server-Driven UI? Do you have any questions or find any errors? Let me know, comment below. See you later!

Building Scalable React Native Apps with Nucleux and Supabase

Tue, 15 Jul 2025 03:35:09 +0000

Combining Supabase's powerful backend services with Nucleux's atomic state management creates a clean, scalable architecture for React Native applications. This guide shows you how to structure authentication and API services using class-based stores that naturally organize your application logic.

The Architecture Pattern

We'll build a three-layer architecture that separates concerns cleanly:

ApiService: Handles Supabase client configuration and lifecycle
SessionStore: Manages authentication state and user sessions
Auth Component: Provides the user interface for authentication

This pattern leverages Nucleux's dependency injection to create a clean separation where each layer has a single responsibility.

Setting Up the API Service

First, create a centralized API service that manages the Supabase client:

// src/services/ApiService.ts
import AsyncStorage from "@react-native-async-storage/async-storage";
import { createClient, SupabaseClient } from "@supabase/supabase-js";
import { Store } from "nucleux";
import { AppState, NativeEventSubscription, Platform } from "react-native";
import "react-native-url-polyfill/auto";

if (
  process.env.EXPO_PUBLIC_SUPABASE_URL === undefined ||
  process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY === undefined
) {
  throw new Error("Missing critical environment variables");
}

class ApiService extends Store {
  public apiClient: SupabaseClient;
  private appStateSubscription: NativeEventSubscription;

  constructor() {
    super();

    this.apiClient = createClient(
      process.env.EXPO_PUBLIC_SUPABASE_URL || "",
      process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY || "",
      {
        auth: {
          storage: AsyncStorage,
          autoRefreshToken: true,
          persistSession: true,
          detectSessionInUrl: false,
        },
      }
    );

    this.appStateSubscription = AppState.addEventListener("change", (state) => {
      if (state === "active") {
        this.apiClient.auth.startAutoRefresh();
      } else {
        this.apiClient.auth.stopAutoRefresh();
      }
    });
  }

  destroy() {
    this.appStateSubscription.remove();
    super.destroy();
  }
}

export default ApiService;

Key Benefits:

Centralized Configuration: Single place to manage Supabase setup
Lifecycle Management: Properly manages token refresh based on app state

Creating the Session Store

The SessionStore handles all authentication logic while staying completely decoupled from UI concerns:

// src/stores/SessionStore.ts
import ApiService from "@/services/ApiService";
import { Session, Subscription } from "@supabase/supabase-js";
import { Store } from "nucleux";

class SessionStore extends Store {
  public session = this.atom<Session | null>(null);
  public initialized = this.atom<boolean>(false);

  private apiService = this.inject(ApiService);
  private authSubscription: Subscription;

  constructor() {
    super();
    
    this.getSession();
    
    this.authSubscription = this.apiService.apiClient.auth.onAuthStateChange(
      (_, session) => {
        this.setSession(session);
      }
    ).data.subscription;
  }

  private async getSession() {
    try {
      const { data: { session } } = await this.apiService.apiClient.auth.getSession();
      this.setSession(session);
    } finally {
      this.initialized.value = true;
    }
  }

  private setSession(session: Session | null) {
    this.session.value = session;
  }

  public async signIn(email: string, password: string) {
    return this.apiService.apiClient.auth.signInWithPassword({
      email,
      password,
    });
  }

  public async signOut() {
    return this.apiService.apiClient.auth.signOut();
  }

  destroy() {
    this.authSubscription.unsubscribe();
    super.destroy();
  }
}

export default SessionStore;

Architecture Highlights:

Dependency Injection: this.inject(ApiService) automatically provides the API client
Atomic State: Only components using session or initialized re-render when these values change
Event Handling: Supabase auth changes automatically update the atomic state
Clean API: Simple methods for sign in/out that any component can use

Building the Auth Component

Finally, create a simple authentication component that consumes the session store:

// components/Auth.tsx
import SessionStore from "@/stores/SessionStore";
import { useStore, useValue } from "nucleux";
import React, { useState } from "react";
import { Alert, StyleSheet, Text, TextInput, TouchableOpacity, View } from "react-native";

export default function Auth() {
  const sessionStore = useStore(SessionStore);
  const session = useValue(sessionStore.session);
  const initialized = useValue(sessionStore.initialized);

  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [loading, setLoading] = useState(false);

  const handleSignIn = async () => {
    if (!email || !password) {
      Alert.alert("Error", "Please fill in all fields");
      return;
    }

    setLoading(true);
    try {
      const { error } = await sessionStore.signIn(email, password);
      if (error) Alert.alert("Error", error.message);
    } finally {
      setLoading(false);
    }
  };

  const handleSignOut = async () => {
    const { error } = await sessionStore.signOut();
    if (error) Alert.alert("Error", error.message);
  };

  if (!initialized) {
    return <Text>Loading...</Text>;
  }

  if (session) {
    return (
      <View style={styles.container}>
        <Text style={styles.title}>Welcome back!</Text>
        <Text>Signed in as: {session.user.email}</Text>
        <TouchableOpacity style={styles.button} onPress={handleSignOut}>
          <Text style={styles.buttonText}>Sign Out</Text>
        </TouchableOpacity>
      </View>
    );
  }

  return (
    <View style={styles.container}>
      <Text style={styles.title}>Sign In</Text>
      
      <TextInput
        style={styles.input}
        placeholder="Email"
        value={email}
        onChangeText={setEmail}
        autoCapitalize="none"
        keyboardType="email-address"
      />
      
      <TextInput
        style={styles.input}
        placeholder="Password"
        value={password}
        onChangeText={setPassword}
        secureTextEntry
      />
      
      <TouchableOpacity 
        style={[styles.button, loading && styles.buttonDisabled]} 
        onPress={handleSignIn}
        disabled={loading}
      >
        <Text style={styles.buttonText}>
          {loading ? "Signing In..." : "Sign In"}
        </Text>
      </TouchableOpacity>
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 20, justifyContent: "center" },
  title: { fontSize: 24, fontWeight: "bold", marginBottom: 20, textAlign: "center" },
  input: { borderWidth: 1, borderColor: "#ddd", padding: 12, marginBottom: 10, borderRadius: 5 },
  button: { backgroundColor: "#007AFF", padding: 12, borderRadius: 5, marginTop: 10 },
  buttonDisabled: { opacity: 0.5 },
  buttonText: { color: "white", textAlign: "center", fontWeight: "bold" },
});

Why This Architecture Works

1. Clear Separation of Concerns
Each layer has a single responsibility, making the code easier to test and maintain.

2. Automatic Reactivity
Components automatically re-render when authentication state changes, without manual subscription management.

3. Reusable Business Logic
The SessionStore can be used across multiple components without duplicating authentication logic.

4. Type Safety
TypeScript ensures you catch authentication-related bugs at compile time.

5. Easy Testing
Each store can be unit tested independently of React components.

The Result

This architecture gives you a robust foundation for React Native apps that need authentication. The SessionStore becomes the single source of truth for authentication state, while the component layer focuses purely on user interface concerns.

Want to explore more patterns? Check out the complete Nucleux documentation and see how this same approach scales to complex applications with multiple data stores and API services.

Ready to build your next React Native app? Try combining Nucleux with Supabase for a powerful, type-safe development experience.

After facing weird permission issues, I built my own music app in 6 hours.

Mon, 14 Jul 2025 06:13:19 +0000

Ever noticed how even the simplest apps want access to everything?
I just wanted to play music — not hand over my call logs.

Even lightweight music players come loaded with creepy permission requests. Contacts? Call data? Overlay access? Just to hit play on a song?

It didn’t sit right with me.
So I decided to build my own.

1: Why I Chose to Build My Own Music App

I’ve always had a very specific music taste — mostly soulful tracks, spiritual sounds, and some of 90s nostalgia.

Sure, I could stream them on Spotify or YouTube like everyone else. But I’ve always preferred keeping my own MP3 collection — offline, in my control, with zero interruptions.

The real issue began when I started noticing how these music apps behave.

They demand weird permissions.
They push random ads. That I understand, I'm fine with it.

Last week, I finally snapped. I figured — why not just make my own app?

I’d been meaning to learn mobile development anyway, so this felt like the perfect excuse.

After checking out a few frameworks, I settled on Flutter — lightweight and flexible. My laptop isn’t built for Android Studio (tried that once, it basically gave up), so I kept things minimal.

Set up took an hour or two. I plugged in my phone, enabled developer mode, and got my first “Hello World” up and running.

From there, it just flowed — I picked up Dart, started testing small things with help from AI, and slowly began to see my idea take shape.

2: Only Building What I Actually Needed

Once I had the basics working, I tested it out with a single MP3 file. Just dropped it into the assets folder and tried playing it through the app. It worked.

That small win gave me the push to go further.

Next up — scanning local storage for all my saved music files. I added logic to pull out MP3s from the phone’s directories, and once that was done, I layered in the essentials:

Play / Pause

Skip

Auto-play

Total duration

Current time tracking

No recommendations. No suggestions. No sneaky tracking.
Just clean, simple playback — the way I wanted it.

The UI is still very barebones, and honestly, that’s fine for now. I’m slowly working on polishing it up. But I’m clear on one thing:
It’ll stay lightweight. No junk. No shady permissions.

Just a music player that respects your privacy — and plays your songs.

3 : What’s Next

For now, I’m just refining the app to suit my personal use. Clean UI, maybe dark mode, and a couple of nice-to-have touches that I actually care about. I might upload it to the Play Store at some point — not because I want to compete with big apps, but just to share something that feels simple and respectful of users.

Honestly, building this was fun. More than that, it felt right. I got to learn, create, and finally use an app that doesn’t ask me for things it shouldn’t.

But now I’m curious…
Have you ever felt weird giving an app permission to read your call logs just to play music?
What problems have you run into?
And hey — do you still listen to local MP3s, or are you all-in on streaming?

Is It Still Worth Becoming a Mobile Developer in 2025?

Sun, 29 Jun 2025 08:03:49 +0000

Apply to see if you’d be a good fit for my mentorship program: https://training.devlaunch.us/kenny

I’ve been building mobile apps for 9 years, and in this video I break down whether mobile development is still a smart path in 2025. We’ll talk about how the industry has changed, how hard it is to land a job today, and what I’d do if I were starting from scratch. Whether you're coming from web, backend, or starting fresh, this should give you some real clarity.

Coder Legion - Recent posts tagged mobile-development

From C# Backend to Android: Why My First Mobile App in Kotlin Clicked

Key Benefits That Stand Out for C# Developers

Key Technical References for C# Developers

The Takeaway

I built a habit tracker that doesn’t track anything

Building Trucker Suite: When “One More App” Isn’t the Answer

How to Fix EAS Build Failed Errors in Expo

First: Don't Focus on "EAS Build Failed"

1. Open the Full EAS Build Logs

2. Check Whether the Problem Is Actually Your Expo Configuration

3. Check Your Expo SDK and Native Dependencies

4. If the Error Mentions Gradle, Investigate the Android Build

5. Check Your Environment Variables

6. Check Your EAS Build Profile

7. Don't Ignore Credentials Errors

8. If It Worked Before, Ask What Changed

9. Clean Up Before Rebuilding

The Most Important Part: Find the Root Error

What If Your Error Doesn't Match Any Of These?

A Simple Workflow I Use Now

1. Find the actual failure

2. Identify the category

3. Ask what changed

4. Check the full log

5. Run the relevant diagnostic tools

6. Change one thing at a time

7. If the log is still unclear, diagnose the log itself

Final Thoughts

How to Fix `Execution failed for task ':app:mergeDexDebug'` in React Native

What Does mergeDexDebug Actually Mean?

Cause 1: Your App Has Too Many Methods (64K Limit)

Fix: Enable Multidex

Cause 2: Duplicate Classes Between Dependencies

Fix: Align Dependency Versions

Cause 3: A Recently Installed Native Package Introduced Conflicts

How To Find The Real Cause Faster

Clean Your Android Build Cache

Preventing Future mergeDexDebug Errors

Keep dependencies updated

Avoid installing unnecessary packages

Check changes after adding native libraries

Understand the error before applying fixes

Need Help Diagnosing React Native Errors?

FixMyError

Heisenbugs

How to Fix: "Namespace not specified" Gradle 8 Error in React Native & Expo

Fixing the "Namespace Not Specified" Error in React Native and Expo Android Builds

The Root Cause

Before You Change Anything

The Fix: Use patch-package

Step 1: Find the Package Name

Step 2: Add the Missing Namespace

Step 3: Generate a Patch

Step 4: Apply the Patch Automatically

That's It

How to Fix FCM "MismatchSenderId" in Multi-Environment Expo (EAS) Builds

How to Fix MismatchSenderId in Expo EAS Push Notifications Across Multiple Environments

Why the Mismatch Happens

Solution 1: Split Your EAS Projects (Recommended for Clean Automation)

Implementation Steps

Solution 2: Bypass EAS and Route Tokens on Your Backend

Implementation Steps

Tag Tokens by Environment

Handle Routing on Your Server

Verification Checklist Before Your Next Build

Fskin alpha version is Live

How AI Chatbots and Voice Assistants Are Integrated Into Mobile Apps

Quick Overview

The Architecture Behind AI Chatbot Apps

NLP Pipeline: From Raw Input to Structured Intent

Voice Assistant Integration: The Technical Specifics

Context Management and Memory in Conversational Apps

Conclusion

Frequently Asked Questions

1. How do AI chatbots work inside mobile apps?

2. Difference between rule-based and AI chatbots in apps?

3. How are voice assistants integrated into Android and iOS apps?

4. What are the privacy concerns with AI chatbots in mobile apps?

5. Can AI chatbots in apps work without an internet connection?

What Does `mergeDexDebug` Actually Mean?

Preventing Future `mergeDexDebug` Errors

How to Fix `MismatchSenderId` in Expo EAS Push Notifications Across Multiple Environments