Coder Legion - Recent posts tagged mobileapps

How to give your AI Agent access to a Real iPhone

Thu, 29 Oct 2026 16:16:58 +0000

For a long time, mobile automation has been much easier to demonstrate on Android than on iOS. Android has ADB, emulators, and relatively accessible automation tooling. iOS has a different set of constraints, especially when you want to interact with a physical device and the apps installed on it.

But what if you could give an AI agent access to your actual iPhone, describe a task in plain English, and let it carry out the steps?

That's what we've been working on at Mobilerun.

Why iPhone automation is difficult

AI agents have become good at reasoning, writing code, and interacting with websites. Mobile apps introduce another layer of complexity.

An agent might need to navigate multiple screens, locate a button, enter information, handle a dialog, and verify that an action actually succeeded.

On iOS, automation is harder because of Apple’s restrictions, connection issues, and the setup needed to control a real iPhone.

Traditional automation often relies on predefined scripts or app-specific integrations. These work well when the workflow is known in advance, but they can be restrictive when you want an agent to handle different tasks dynamically.

An AI agent that can interact with a phone's UI has another option: it can observe the screen, decide what to do next, and perform the necessary interactions.

Instead of building a separate integration for every task, you can describe the outcome you want and let the agent work through the interface.

From a prompt to a real iPhone

With Mobilerun Cloud, you can connect your own iPhone through a Mac or Linux or Linux and make it available for automation.

The workflow is straightforward:

Connect your iPhone to your Mac or Linux or Linux using a USB cable.
Follow the setup instructions to connect it to Mobilerun Cloud.
Open your connected device and give your agent a task.
Watch the agent interact with the phone.

Once connected, you can issue a command and let the agent navigate the UI, tap controls, type text, and move between screens.

You don't need to build a dedicated automation script for every prompt.

Setup takes under two minutes in the supported configuration. You'll need an iPhone running iOS 27 or later and a Mac or Linux.

Follow the iPhone connection guide to get started.

What can you automate?

The interesting part isn't simply getting an AI to tap a button. It's being able to describe a task and have the agent work through the steps on a real device.

Here are a few examples worth exploring.

1. Messaging workflows

You could ask an agent to open Messages, find a conversation, and draft or send a message.

For example:

Open Messages, find my conversation with Maa, and send her a message saying I'll call her this evening.

This is a simple example, but it demonstrates the core idea: the task is described in natural language, and the agent translates it into UI interactions.

Always review messages and confirm the intended recipient before allowing an agent to send anything important.

2. Navigating apps

An agent could be asked to open an app, find a particular section, search for information, or navigate through a multi-step workflow.

Rather than specifying every tap in advance, you describe what you want it to accomplish.

3. Repetitive mobile tasks

Many mobile workflows involve repeating the same sequence of actions: opening an app, finding a record, updating information, or navigating through several screens.

These are useful places to experiment with agent-driven automation, particularly when the process is tedious to perform manually.

The exact tasks an agent can complete will depend on the app, the UI, permissions, and the reliability of the underlying automation.

Why use a real iPhone instead of a simulator?

Simulators are valuable for development and testing. They provide a controlled environment where you can reproduce scenarios and inspect application behavior.

Physical devices matter when you need to work with the actual hardware and software environment.

A real iPhone gives you access to the device you already own, including its installed apps and existing setup, subject to the permissions and capabilities available to the automation system.

This is useful for developers experimenting with mobile agents, teams testing real-device workflows, and anyone exploring what AI can do beyond a browser.

It doesn't mean simulators are obsolete. Both approaches have their place, depending on what you're trying to build or test.

Try it yourself

If you have an iPhone and a Mac or Linux, you can connect your device to Mobilerun Cloud and start experimenting.

Connect your iPhone: Read the setup guide
Try Mobilerun Cloud: cloud.mobilerun.ai
Explore Mobilerun: mobilerun.ai
Inspect the benchmark: iOSWorld results

We're curious to see what developers build with this.

What would you want an AI agent to do on your iPhone that you can't easily automate today?

That's probably the most interesting question to explore next.

Why Your Mobile App Works Perfectly Locally But Crashes Instantly in TestFlight

Thu, 11 Jun 2026 09:01:21 +0000

We’ve all been there. You spend weeks building a feature, testing it on your local simulator or a physical device running a development stream. Everything is butter. No lag, no warnings.

You confidently bundle the app, ship it to TestFlight, wait for Apple to finish processing, download it... and the moment you tap the app icon, it instantly flashes and closes. Hard crash.

Before you lose your mind or start blindly tweaking code, remember that production builds behave entirely differently than development environments.

Here are the four most common reasons your app dies the literal second it hits production, and exactly how to fix them.

1. The Missing Privacy Keys String (`Info.plist`)

If your app requests permissions for features like Location Services (maps, background location), the Camera, or the Photo Library, Apple requires you to explicitly state why in your Info.plist file using usage description keys (like NSCameraUsageDescription or NSLocationWhenInUseUsageDescription).

The Gotcha

In a local development environment, sometimes a framework will let a missing string slide, fallback to a default, or catch the exception gracefully.

The Production Reality

Apple’s iOS security layer will ruthlessly and instantly terminate the application binary on launch if your production code attempts to initialize a library requiring these permissions without the matching text string configured.

The Fix

Double-check your Info.plist (or your Expo app.json plugins). Make sure every single hardware or permission API your code imports has a clear, user-facing explanation string attached.

2. Missing Push Notification Entitlements

If your application includes code for push notifications (even if you haven’t fully wired up the backend yet), your binary needs specific clearance to launch.

The Gotcha

Local builds often bypass strict entitlement checks, or run using a wildcard development provisioning profile that covers everything loosely.

The Production Reality

When built for distribution, if your app contains code for handling remote notifications but the App Store Provisioning Profile doesn't explicitly have the Push Notifications entitlement enabled, the OS will trigger a fatal launch mismatch exception.

The Fix

Head to your Apple Developer Account under Identifiers, verify that your App ID has Push Notifications checked, and regenerate your production profile.

3. Dead Code Elimination & Aggressive Minification

When building locally, your JS bundling or native compilation keeps debug code, metadata, and helper functions intact.

When you build for production, optimization tools like ProGuard/R8 (for Android native engines) or aggressive tree-shaking strip away "unused" code to shrink the binary size.

The Gotcha

Sometimes, these optimization tools accidentally strip away native modules or reflection classes used by third-party packages, assuming they are dead code because they aren't explicitly referenced in the main thread.

The Production Reality

The app boots up, looks for a compiled native library or native method bridge, finds a missing reference, and triggers a fatal crash right during initialization.

The Fix

If you are using native dependencies, make sure your obfuscation/minify configuration files explicitly include rules to keep specific third-party library paths intact.

4. Broken Initialization Flow (Environment Variables)

How does your app determine its backend URL or third-party service tokens?

If you are relying on a local .env file that is git-ignored, those values might not be making it into your production build machine or CI/CD pipeline.

The Gotcha

The app builds successfully because the compiler doesn't care if a string variable is blank or null at build time.

The Production Reality

On launch, your application's root mounting sequence tries to parse an undefined API key or a null base URL during setup. If your code doesn't have a fallback check, it throws a fatal JavaScript or runtime error before the first screen even renders.

The Fix

Always verify that your build dashboard (like Expo Application Services, GitHub Actions, or local production scripts) has your production environment variables explicitly mapped before hitting compile.

How to Stop Guessing and Find the Proof

Stop guessing and changing random lines of code hoping for a miracle. Apple leaves an exact paper trail for immediate launch crashes.

On Your Test Device

Open up the TestFlight app on your iPhone, tap on the application name, scroll down to Crash Logs, and you can view or share the exact file.

Inside Xcode

Navigate to:

Xcode > Window > Organizer > Crashes

Apple aggregates logs directly from TestFlight users here, often highlighting the exact line of compiled code that triggered the crash (look for terms like SIGABRT or EXC_CRASH).

What's the absolute strangest "works locally, breaks in production" bug you've ever had to hunt down?

Let's talk in the comments!

The Feature Nobody Uses (But Nobody Deletes)

Mon, 23 Feb 2026 14:28:48 +0000

There’s a feature in a lot of apps that nobody uses.
But nobody deletes.

It’s usually something like:
•A notification that keeps coming, even after you turned it off
•A screen you never visit but can’t remove
•A setting you don’t understand and never touch
•A reminder that made sense once, but not anymore

People don’t complain about it.
They just ignore it.

But for the team, it stays.

Because removing it feels risky.
Because it might affect someone.
Because no one knows what depends on it.

So it stays.

And it costs money.
Extra checks. Extra fixes. Extra time.
Every release.

This is what app maintenance really is.
Not fixing bugs.
Living with old decisions.

While writing about app maintenance costs in the US for 2026, one thing stood out:
Most maintenance isn’t work. It’s hesitation.

Teams don’t keep features because users love them.
They keep them because deleting feels harder than maintaining.

What’s one feature in an app you use that you’ve ignored for so long it’s basically invisible now?

Your App Goes Offline. Does It Panic, Lie, or Handle It Gracefully?

Mon, 23 Feb 2026 09:10:00 +0000

Most developers think about offline mode last - when the app is already done, designs are signed off, and the PM is breathing down your neck about the deadline. The result? Users see a white screen, a frozen spinner, or worse - silently lost data. This article is about building honest UX for no-network states: from the psychology of anxiety to exponential backoff code, from visual error language to conflict resolution strategies. All of it applies to any mobile or web app that operates under unstable connectivity - which is most of them.

The Psychology of Offline States

There's a pattern I've seen in usability tests over and over: a user taps "Send," nothing happens, they tap again - and again. Ten seconds later they either close the app or start getting angry. That's not a network problem. That's an uncertainty problem.

Uncertainty breeds anxiety. Anxiety breeds avoidance. The user doesn't know whether their message went through, whether the document saved, whether the transaction completed. The brain interprets the system's silence as a threat: "Something went wrong, and I have no idea what." That's exactly why well-designed offline UX isn't a technical problem - it's an anxiety management problem.

There are three states worth distinguishing: the system is working normally, the system is slow or unstable, the system is fully offline. Each one needs its own visual response. Conflate them and you confuse the user even further. If you show the same indicator for a slow connection as for no connection at all, the user has no idea whether to keep waiting or give up.

One more thing that often gets overlooked: people tolerate waiting much better when they understand why and have a rough sense of how long. This is well-established in queue research and loading UX. Offline is no different. "No internet" is already better than a blank screen. "No internet - your data is saved locally and will sync when the connection is restored" - that's trust.

Visual Language for Offline States

Rule one: don't hide things. I've seen interfaces that simply disabled buttons when there was no network and offered zero explanation. The user stares at a grayed-out button and thinks: is this a feature? A bug? Why now?

The offline state needs to be explicit. A banner at the top of the screen in a neutral color - not red; red signals an error, not an environmental condition - a status bar indicator, a subtle UI change - all of these work. The core rule: UI elements that are unavailable because of missing connectivity should be visible but clearly disabled, with an explanation. Not hidden - disabled, with a tooltip or inline message.

A solid practice for mobile apps is showing connection state in the toolbar or navigation bar. On iOS you can observe NWPathMonitor and update the UI reactively:

import Network

final class NetworkMonitor: ObservableObject {
    private let monitor = NWPathMonitor()
    private let queue = DispatchQueue(label: "NetworkMonitor")

    @Published var isConnected: Bool = true

    init() {
        monitor.pathUpdateHandler = { [weak self] path in
            DispatchQueue.main.async {
                self?.isConnected = path.status == .satisfied
            }
        }
        monitor.start(queue: queue)
    }
}

In SwiftUI this plugs in trivially via @EnvironmentObject, letting any screen react to connectivity changes without tight coupling.

On the iconography front: I prefer the SF Symbol wifi.slash on iOS - users read it instantly. On the web, the same idea applies with SVG icons, but don't overdo animation. A pulsing offline icon gets annoying within thirty seconds. A static one just informs.

Queueing Actions for Later Sync

This is where the real engineering begins. When a user does something offline - likes a post, creates a task, edits a document - that action needs to be stored somewhere and executed later. A simple in-memory array won't survive an app restart. You need a persistent store: Core Data, SQLite, or at minimum UserDefaults for simple cases.

But persistence is only half the problem. The other half is idempotency.

Idempotency means that executing the same operation multiple times produces the same result. This is critical for a sync queue, because we never actually know whether the request reached the server before the connection dropped. If an operation isn't idempotent, retrying it might create duplicates or corrupt data.

In practice, this is solved two ways. First - assign a client-generated UUID to each operation and send it in the Idempotency-Key header. The server stores this key and on a duplicate request returns the same response without re-executing the operation. Second - design operations as PATCH with specific fields rather than POST with a full object, or use event sourcing on the server side.

Conflicts are their own story. If a user edited a document offline while another user changed the same document on the server, you have a conflict. The resolution strategies break down like this.

Last Write Wins is the simplest approach and often the wrong one. One side's changes get thrown away. Fine for non-critical data like settings, not fine for much else.

Merge - for structured data like text or lists, you can apply a three-way merge: base, client version, server version. This is exactly how Git works. CRDT (Conflict-free Replicated Data Types) is the more powerful variant, used by Figma and Linear for collaborative editing.

Ask the User - when automatic merging isn't possible, show both versions and let the user decide. Bad if it happens constantly, but sometimes it's the only honest option.

I try to design the queue as a state machine: each action has a status of pending, syncing, synced, or failed. This simplifies both the UI state display and the retry logic considerably.

Showing "Pending" vs "Failed" - Different States Deserve Different Treatment

This distinction gets ignored surprisingly often. "Waiting to send" and "failed to send" are fundamentally different situations from the user's perspective. The first requires no action. The second requires a decision.

For pending, a subtle indicator works fine: a gray checkmark, a clock icon, a small badge. The user needs to understand that their action was recorded but hasn't synced yet. No need to shout about it - a quiet signal is enough.

For failed, you need explicit feedback. A red icon, an inline error message, and - critically - the ability to cancel. If a user sent a message, it didn't go through, and they see a failed status, they need a "Cancel" or "Try Again" button right there. Without it they're stuck: the action appears to have happened, but it hasn't.

Undo for failed states works on the principle of "soft deletion": the action stays in the queue but gets marked as cancelled. That's simpler than rolling back state. For chats and feeds - show failed messages in gray with an error icon and a retry button next to them. This is a pattern users already know from WhatsApp and Telegram. No need to reinvent it.

Auto-Retry with Exponential Backoff

The naive retry implementation is a loop with a fixed interval. The problem: if a thousand clients lose connectivity simultaneously - say, the office WiFi goes down - they all come back online and hammer the server in sync. That's a thundering herd, and it can take a backend down.

Exponential backoff with jitter solves this. Each subsequent attempt waits twice as long as the previous one, and random jitter spreads the requests across time. Here's an implementation in Swift using async/await:

enum RetryError: Error {
    case maxAttemptsReached
    case cancelled
}

func withExponentialBackoff<T>(
    maxAttempts: Int = 5,
    baseDelay: TimeInterval = 1.0,
    operation: @escaping () async throws -> T
) async throws -> T {
    var attempt = 0

    while attempt < maxAttempts {
        do {
            return try await operation()
        } catch {
            attempt += 1
            guard attempt < maxAttempts else {
                throw RetryError.maxAttemptsReached
            }

            let delay = baseDelay * pow(2.0, Double(attempt - 1))
            let jitter = TimeInterval.random(in: 0...delay * 0.3)
            try await Task.sleep(nanoseconds: UInt64((delay + jitter) * 1_000_000_000))
        }
    }

    throw RetryError.maxAttemptsReached
}

Usage:

let result = try await withExponentialBackoff {
    try await apiClient.syncPendingActions()
}

For the Combine stack this looks different, but the idea is the same - .retry() in Combine doesn't support delays out of the box, so you need a custom operator or a flatMap with Deferred + Future and DispatchQueue.asyncAfter.

One important detail: retries need to stop when the user explicitly cancels an action, or when the app goes to background. Otherwise you're burning battery and burning data for nothing. I usually tie the retry lifecycle to the task's lifetime in the queue and cancel the Task on controller or view model deinitialization.

The maximum number of attempts is a product policy question. For critical transactions - payments, medical data - more attempts and an explicit notification when they're exhausted. For non-critical stuff - analytics, logs - fewer attempts and a silent fail.

Testing Offline Scenarios

This is where most teams cut corners, and it shows in production. Testing offline isn't "turn off WiFi and see what happens." It's a systematic check of every state transition.

On iOS there's Network Link Conditioner - a tool in [Additional Tools for Xcode](https://developer.apple.com/download/all/?q=Additional Tools). It lets you simulate different network qualities: 100% packet loss, high latency, unstable connectivity. Installs as a system extension on Mac or directly on a device via Settings for real hardware. I use the "100% Loss" profile for full offline testing and "Very Bad Network" for degraded connectivity - these are genuinely different UX situations.

On Android the equivalent is adb shell with network state commands:

# Disable mobile data
adb shell svc data disable

# Disable WiFi
adb shell svc wifi disable

# Turn them back on
adb shell svc data enable
adb shell svc wifi enable

For web - Chrome DevTools, Network tab, throttle to "Offline" or set up a custom profile.

But beyond tooling, methodology matters. You need to test specific scenarios: what happens if connectivity drops mid-load? Mid-form submission? What if the user closed the app while a pending action was sitting in the queue, then reopened it? What if the auth token expired during the offline period?

That last one is particularly nasty. The user comes back online, the queue starts syncing, gets a 401 Unauthorized, and now there's a conflict between "need to retry" and "need to refresh the token first." This needs to be tested explicitly and handled explicitly in code. I'd genuinely love to hear how others approach this one in the comments.

Unit tests for queue logic are worth writing against a mock network layer that lets you control success and failure. XCTest makes this straightforward through protocols and dependency injection - no URLSession directly in production code.

When to Warn Users About Data Loss

This is the most painful scenario, and it demands honesty. If data might be lost - warn the user. Before it happens, not after.

Two typical cases. First: a user tries to exit an unsaved document while offline. The classic "Save / Don't Save / Cancel" dialog isn't enough here - you need to say explicitly: "You have unsaved changes. They can't be synced right now and will only be stored locally." That's more honest.

Second: when the sync queue has grown large enough that you can't guarantee all data will survive a cache clear or app update. This calls for a proactive notification - not necessarily a push, but at least an in-app banner on the next launch.

A separate case is critical data that simply shouldn't be stored locally at all: medical records, financial transactions, legally binding signatures. My view is that for these, the right UX is to block the action entirely when there's no network, and explain clearly why. Yes, it's inconvenient. But a lost transaction or a missynced medical record is incomparably worse.

The general principle I work by: users should have the ability to make an informed decision. If we can't guarantee data integrity - say so explicitly and give them a choice: wait for connectivity, save a local copy at their own risk, or cancel the action. Silence here isn't neutral. It's a lie.

A well-implemented offline mode is one of those places where an app either earns long-term user trust or loses it for good. A lost message, a forgotten form, a silent interface on the subway - it all accumulates. The investment in offline UX pays off not in metrics but in reputation.

AI features shouldn’t exist without a Reset button

Fri, 06 Feb 2026 14:20:20 +0000

Most apps don’t get users wrong because the tech is 'bad.'
They get users wrong because they get users too early.

You do one thing once, and the app decides:
'Cool. This is who you are now.'

But real life doesn’t work like that.

You searched 'how to sleep better' for two nights → now your feed is sleep content forever
You watched a breakup reel → now every suggestion is heartbreak and 'healing'
You clicked one expensive bag out of curiosity → now the app thinks you’re a luxury shopper
You were consistent in the gym for 2 weeks… then got sick → now you get 'need motivation?' every day

This is what I mean by context shift.
People change week to week. Sometimes day to day.

The mistake isn’t personalization.
The mistake is treating a moment as a permanent identity.

If an app is going to 'learn' me, it should also let me correct it.

A Reset button isn’t a nice-to-have. It’s basic fairness.

Reset should mean:

Reset recommendations (feed/topic assumptions)
Reset notification behavior (frequency + timing + topics)
Reset 'interests' the app inferred from 1–2 actions

Because 'clear watch history' or 'delete search' doesn’t fix the real thing:
the hidden profile the app built in the background.

Here are the arguments I keep hearing:
Argument 1: 'Users won’t use Reset, so why add it?'
My take: If users don’t use it, fine, but the people who need it REALLY need it.

Argument 2: 'Reset will reduce engagement.'
My take: Short-term engagement isn’t the goal. Long-term trust is.
No one stays in an app that feels pushy or misunderstood.

Argument 3: 'The algorithm should just be smarter.'
My take: Even smart systems guess wrong. The Reset button is a safety valve for bad guesses.

If you were designing this, what would you choose?

Pick one (and explain why):
A) A big Reset personalization button
B) 'Why am I seeing this?' on every recommendation
C) A 7-day expiry on assumptions unless the user confirms
D) A 'mute topic' control (forever)

My vote: C + A together.
Because context changes and users deserve an easy way to get back to 'normal.'

What’s your pick - A/B/C/D?

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

Your App Feels Smart, So Why Do Users Still Leave?

Mon, 02 Feb 2026 15:00:00 +0000

I opened Spotify to focus.

It played a playlist I used during a breakup… two years ago.

Technically, that’s personalization.
Emotionally, it’s tone-deaf.

This is what a lot of mobile apps are doing with AI right now.

They remember a moment but miss the context shift.

Spotify didn’t ask:
“Is this still who you are?”

It assumed permanence from a single signal.

And that assumption shows up everywhere in apps:

One late-night session turns into daily notifications
One skipped workout becomes “need motivation?”
One feature click becomes your entire personality

The app feels confident.
The user feels misunderstood.

Why this matters (ground it):

The problem isn’t bad AI.
It’s premature certainty.

Most AI systems in mobile apps:

Lock in too early
Personalize before habits stabilize
Automate before trust exists

So instead of feeling helpful, they feel pushy.

Instead of “this app gets me,” users think:
“Why is this still happening?”

While writing about AI features for mobile apps in 2026, I kept seeing the same pattern:
The most damaging AI isn’t the obvious stuff.
It’s the subtle misreads that quietly erode trust.

Some AI features genuinely help at certain stages.
Others should wait, even if they sound impressive.

I broke this down clearly here:
Which AI features actually belong at each app stage, and which ones to delay
(Link in comments)

What’s one recommendation or “personalized” feature you’ve ignored so many times it’s basically invisible now?

Coder Legion - Recent posts tagged mobileapps

How to give your AI Agent access to a Real iPhone

Why iPhone automation is difficult

From a prompt to a real iPhone

What can you automate?

1. Messaging workflows

2. Navigating apps

3. Repetitive mobile tasks

Why use a real iPhone instead of a simulator?

Try it yourself

Why Your Mobile App Works Perfectly Locally But Crashes Instantly in TestFlight

1. The Missing Privacy Keys String (Info.plist)

The Gotcha

The Production Reality

The Fix

2. Missing Push Notification Entitlements

The Gotcha

The Production Reality

The Fix

3. Dead Code Elimination & Aggressive Minification

The Gotcha

The Production Reality

The Fix

4. Broken Initialization Flow (Environment Variables)

The Gotcha

The Production Reality

The Fix

How to Stop Guessing and Find the Proof

On Your Test Device

Inside Xcode

The Feature Nobody Uses (But Nobody Deletes)

Your App Goes Offline. Does It Panic, Lie, or Handle It Gracefully?

The Psychology of Offline States

Visual Language for Offline States

Queueing Actions for Later Sync

Showing "Pending" vs "Failed" - Different States Deserve Different Treatment

Auto-Retry with Exponential Backoff

Testing Offline Scenarios

When to Warn Users About Data Loss

AI features shouldn’t exist without a Reset button

If an app is going to 'learn' me, it should also let me correct it.

If you were designing this, what would you choose?

How much does it take to “finish” an app

What was fixed

The fix:

What was changed

What was added

TestFlight #2

As a user, why is this all important?

As a developer, why is this all important?

Your App Feels Smart, So Why Do Users Still Leave?

Why this matters (ground it):

1. The Missing Privacy Keys String (`Info.plist`)