Mobile Apps in the Age of AI Assistants

In July, Apple and Google both shipped their on-device AI systems. iOS 18 launched with Apple Intelligence. Android 15 launched with Gemini integration tighter than before.

User behavior shifted. Now people expect AI in their apps. Not as a feature. As a default.

I watched this happen in real-time in an internal Slack. A designer said "why do I have to click six times to file this expense? Why can't I just tell the app about it?"

That's the new user expectation.

The Shift Nobody Talks About

There's a thing that happens when users get used to AI assistants. It's not that they love AI. It's that they lose patience for UI.

Three years ago, users were fine with traditional interfaces: buttons, forms, navigation menus. You learned the app's flows.

Now users have ChatGPT and Claude in one app switcher. They can ask those systems anything, get answers in seconds. So when they come back to a traditional app that makes them click five buttons to accomplish one task, it feels broken.

This is true even for business apps. A field rep with ERP access through a mobile app: they used to click: view inventory, select warehouse, select item category, scroll to find item.

Now they expect: "Show me Component X in Warehouse 3" as a voice command or text query.

That's not a cosmetic preference. It fundamentally changes how apps need to be designed.

Three Layers of AI in Mobile

Most companies are adding AI to mobile apps wrong. They're bolting a chatbot onto the side of an existing UI.

The good implementations I'm seeing have three distinct layers:

First layer: Natural language interface on top of existing flows. The app still has all its traditional UI (buttons, navigation), but you can also just ask the app to do things in English. "Send this to my manager" triggers the normal review workflow but bypassed all the clicking.

Second layer: Context-aware assistance. The app watches what you're doing and proactively suggests actions. You're in the purchasing screen and you've entered Component X three times this week. The app suggests "do you want to set up recurring orders?" That's AI understanding context.

Third layer: Autonomous action. The app can actually make decisions and take action without waiting for you. You upload a receipt. The app classifies it, extracts the data, files the expense, and just tells you it's done.

Most apps are trying to skip straight to layer three. That's how they fail.

What We're Building For One Client

We have a logistics client. Field reps using mobile app to manage shipments. Previously: navigate to shipments, select customer, view shipment history, find the one you need, update it.

Now: natural language layer on top. "Show me all pending shipments for Acme Corp" returns the same data, but skip the navigation.

We added a second layer: as the rep reviews shipments, the app watches. If the rep marks three consecutive shipments as "overweight," the app learns there's a weight classification problem. It suggests "should we update the weight classification for these items?"

Third layer (coming next month): if a shipment contains items from three different vendors, and we have a consolidation discount available, the app can flag that for the user. Not required, but suggested.

That progression—from natural language to context-aware to semi-autonomous—that's how you do AI in mobile without breaking things.

The Design Problem

Here's what I'm noticing: the designers who thrive in this environment are the ones who can think about modality, not just UI.

An app doesn't have a button-based interface anymore. It has:

• Visual interface (traditional UI)
• Voice interface (speak commands)
• Conversational interface (chat)
• Gesture interface (swipes, long-presses that trigger AI)

And all four need to accomplish the same task in their own way.

Most design systems aren't built for that. They're built for one primary interface (buttons) with voice as an accessibility afterthought.

The companies doing this well are redesigning their entire design system around "what are the core tasks?" and then figuring out how to accomplish each task through each interface.

The Implementation Headache

There's a technical debt here that people don't talk about. Every app I've worked on that added AI started with a monolith: all the business logic tangled with the UI.

To add natural language interfaces, you need to untangle that. You need to separate the intent (what the user wants to do) from the implementation (how the UI makes it happen).

That's a big refactor. Most companies don't want to do it.

But the ones that do? Their apps end up cleaner, faster, and easier to maintain.

The Privacy Question

Here's where on-device AI gets interesting. A field rep updates their app with sensitive shipping info. That data can be processed locally (on-device classification, local caching, local sync scheduling).

The data doesn't need to go to cloud unless it's a complex query that requires server-side reasoning.

For regulated industries (finance, healthcare, logistics), this is huge. You can comply with data residency requirements. You can guarantee that sensitive data doesn't leave the phone.

Most cloud-first AI systems can't make that guarantee.

What We're Doing

By September, we're launching an "AI Assistant Framework" for iOS apps. Plug in your business logic, define your key tasks, and the framework generates: natural language interface, contextual suggestions, and semi-autonomous action recommendations.

The goal: make it easy for developers to add AI to their apps without rebuilding from scratch.

But here's the real insight: the hardest part of adding AI to mobile apps isn't the AI. It's redesigning the app so that the business logic is separable from the UI.

The apps that solve that first get to add AI easily. The ones that don't are stuck.

So if you're building mobile apps right now, do yourself a favor: separate your business logic from your UI layer. You're going to need that separation anyway. And when you do, adding natural language interfaces becomes trivial.