5 AI Changes App Builders Should Know

Builder brief

Format

guide

Stack

Flutter

Reading time

9 min

AI app development changed quickly again this summer. Frontier models became less expensive, coding agents became more capable, and the mobile platforms moved serious AI workloads closer to the device.

If you have been away from mobile development for a few months, this is the short version of what changed, what is real today, and what is worth testing in your next app.

The five-minute summary

Change	Why an app builder should care
GPT-5.6 pricing moved down	Cloud AI features can be tested at a lower cost, but model routing and budgets still belong on the server
Claude Opus 5 launched	Coding agents are becoming more useful for long, multi-step implementation work
Apple expanded Foundation Models	iOS apps can combine on-device, private-cloud, open-source, and third-party models behind a more consistent Swift interface
Android introduced hybrid inference	Apps can begin routing work between Gemini Nano on the device and Gemini models in the cloud
Expo expanded its AI tooling	Agents can build, inspect, run, and debug more of a real native app workflow

The larger pattern matters more than any individual announcement: the winning AI app architecture is becoming hybrid. Use the device for privacy, offline behavior, latency, and frequent lightweight tasks. Use the cloud for larger context, stronger reasoning, and work that needs current information. Use a coding agent to accelerate development, but keep product judgment, testing, security, and release ownership with the team.

1. GPT-5.6 changed the cloud-AI cost conversation

OpenAI released the GPT-5.6 model family in July and updated its announcement on August 21 with a temporary price reduction of more than 20% for GPT-5.6 Sol. Earlier updates also reduced the prices of the smaller Terra and Luna models.

For app teams, lower model prices do not mean that every screen needs a chatbot. They make narrow, useful features easier to test:

• turning an unstructured note into a typed record;
• summarizing a long support conversation;
• classifying feedback before it reaches an admin dashboard;
• generating a first draft that a person reviews;
• using tools to complete a multi-step workflow on the server.

The architecture rule has not changed: never place a provider API key inside a mobile bundle. Route paid cloud inference through your backend, authenticate the user, enforce per-feature limits, and log enough metadata to understand cost and quality without storing sensitive prompts by default.

Lower prices are a reason to run a controlled experiment, not a reason to remove your cost controls.

2. Claude Opus 5 pushed coding agents further into long-running work

Anthropic released Claude Opus 5 on July 24, positioning it for software engineering and long-running, multi-step work. The release also added beta API features for changing tools during a conversation and automatically routing some blocked requests to a fallback model.

The important change for a mobile developer is not a benchmark score. It is the type of task you can reasonably delegate.

Weak agent task:

Build my entire production app.

Better agent task:

Add this settings screen using the existing components, connect it to this endpoint, write the loading and error states, run the relevant tests, and show me the diff.

Agents work best when the repository already contains clear patterns, tests, typed interfaces, and product constraints. They struggle when the task hides five unresolved product decisions inside one sentence.

For an older React Native, Flutter, Swift, or Kotlin project, a useful first agent task is often maintenance rather than a new AI feature:

• upgrade one dependency safely;
• replace a deprecated API;
• add a missing test around checkout or authentication;
• document an unfamiliar module;
• reproduce and isolate a crash;
• migrate one screen without rewriting the whole app.

3. Apple turned Foundation Models into a broader AI layer

Apple's Foundation Models framework originally gave apps access to the on-device model behind Apple Intelligence. The latest updates make the framework substantially broader.

Apple now describes a common LanguageModel protocol that can work with its on-device model, Private Cloud Compute, models shipped with the app through Core AI, MLX models, and third-party model providers. The latest system model also adds image understanding and stronger tool use. Apple covers the new model choices, vision support, dynamic profiles, and evaluation tools in its WWDC26 Foundation Models update.

That opens practical iOS features such as:

• offline rewriting and summarization;
• extracting structured data from text;
• generating accessibility descriptions for an image;
• calling an app-defined tool to search local content;
• using a cloud model only when a task exceeds the local model's capabilities.

Availability still matters. The user may have an unsupported device, Apple Intelligence may be disabled, or the requested model may be unavailable. Treat model availability as runtime state and design a useful fallback rather than hiding the entire feature behind a permanent loading indicator.

4. Android is making local-and-cloud routing a product decision

Google's on-device Gemini Nano APIs already support tasks such as prompting, summarization, rewriting, image description, and speech recognition on supported devices. In April, Google announced an experimental hybrid inference API for Firebase AI Logic.

The initial API uses rule-based routing between Gemini Nano on the device and Gemini models in the cloud. This is an important direction even while the API is experimental: model selection can become part of the app's runtime policy.

A practical routing policy might look like this:

Situation	Route
Offline, sensitive, or high-frequency lightweight task	On-device model
Large context, complex reasoning, or current web-backed information	Cloud model
Unsupported device or local model unavailable	Cloud fallback with consent
User has reached a paid cloud quota	Local fallback or a clear limit state

Do not make hybrid routing invisible in situations where data sensitivity changes. If a task that normally runs locally needs to move to the cloud, tell the user when that distinction matters.

5. Expo is connecting AI agents to the real mobile toolchain

Prompt-to-app demos are easy. Producing a build, testing it on a device, understanding a native failure, and shipping through an app store are the hard parts.

Expo introduced Expo Agent in beta as a system for building native iOS, Android, and web apps from a description. Expo's latest platform updates also include an official MCP server that can connect an agent to the project's SDK version, configuration, development server, simulators, cloud services, and crash data. The company summarized these releases in its App.js recap.

This does not eliminate mobile engineering. It changes where the work happens. Less time can go into scaffolding and repetitive configuration. More attention can go into:

• deciding what the app should do;
• reviewing generated architecture;
• validating native behavior on real devices;
• measuring whether users return;
• protecting secrets and personal data;
• handling store requirements and production failures.

AI can generate a plausible screen quickly. It cannot decide whether that screen solves a problem people care about.

Which AI architecture should you choose?

Use this as a starting point rather than a permanent rule.

Choose on-device AI when

• the feature must work offline;
• inputs are private and should stay on the device;
• the task runs frequently enough that per-request cloud cost matters;
• the required model capability fits supported hardware;
• predictable low latency matters more than frontier reasoning.

Choose cloud AI when

• the task needs stronger or longer reasoning;
• the feature needs current or server-owned information;
• tools must interact with your backend;
• you need consistent behavior across a wide range of devices;
• model routing, quotas, and observability must be centrally controlled.

Choose a hybrid approach when

• the same feature has both lightweight and complex paths;
• privacy and capability requirements change by request;
• you need an offline baseline with a stronger online upgrade;
• you want to change providers without redesigning the mobile interface.

Three small experiments worth building

You do not need a new company or a six-month roadmap to test these changes.

1. An offline writing helper

Let a user rewrite, shorten, or proofread text locally. Measure whether people use the suggestion and whether the feature remains fast on supported devices.

2. A hybrid support assistant

Classify and summarize a support question locally when possible. Send only the necessary context to a server model when the question needs account data or stronger reasoning. Always provide a human-support path.

3. An agent-assisted maintenance sprint

Choose one older application and give a coding agent a bounded upgrade task. Measure time saved, defects introduced, review time, and whether the resulting code follows the project's existing patterns.

The experiment should answer a product or engineering question. "We used AI" is not a useful result.

A practical seven-day plan

1. Choose one painful, repeated task.
2. Decide whether it belongs on-device, in the cloud, or in the development workflow.
3. Define one success metric before writing code.
4. Build the smallest version with a clear fallback.
5. Test on real devices and weak network conditions.
6. Put a budget and kill switch around cloud inference.
7. Show it to a real user and watch what they do.

The AI stack will keep changing. A disciplined way to test it is more valuable than choosing this month's most powerful model.

What are you building next?

We are rebuilding the Dopebase community around people who still create mobile apps, AI tools, and useful software. If you are building again, create your community profile and tell other builders what you are working on.