How to Add AI to My App: Hosted API, On-Device, and the New Rules

If you are asking how to add AI to my app, the honest first answer is that the model is the easy part. Anyone can paste an API key into a screen and get a demo working in an afternoon. The hard parts are the three things the demo hides: where the request runs, who pays for every call, and which rules now apply to what the feature says and shows.

I add AI features to apps for a living, and the founders who struggle are rarely stuck on the code. They chose a route before they named the job, and the bill or the review team told them so later. This is the order I work in when a founder asks how to add AI to my app and means it.

How to Add AI to My App: Start With the One Job

Before any provider, write the job in one sentence: "the user photographs a coin and sees what it is", "the user describes a room and sees it redesigned", "the user asks a question and gets an answer from our content". A job has an input, an output and a failure you can tolerate. If you cannot write it that way, you do not have a feature yet, you have a mood.

The job decides almost everything after it. Does it need a large, current model, or a small one that runs on the phone? Does the input contain anything the user would not want leaving the device? Does it have to work on a train with no signal? What happens when the answer is wrong, a shrug or a refund?

Founders who skip this step ask how to add AI to my app and get a chat box, because a chat box is what the tutorials build. A chat box is rarely the job.

The Hosted API Route

A hosted API means your app sends the input to a provider and gets the result back. It is the usual answer when founders ask how to add AI features to mobile app projects, and for good reasons: the best models live there, they improve without an app update, and a first version is cheap to build.

The cost is the other half of the trade. Every call is metered, the provider can change price or retire a model, and your user's input leaves the phone. Two rules follow from that. Keep the API key off the device and call the provider from your own backend, because a key shipped inside an app can be extracted. And put the provider behind one interface, so swapping it is a one-module change. An AI companion app we shipped ran two providers behind one abstraction and added a third eight months later without touching the screens. I wrote the cost side of that pattern up in the piece on AI app development cost, so I will not repeat the table here.

The On-Device Route

The alternative is to run the model on the phone. On iPhone, Apple's Foundation Models framework gives apps access to the on-device model behind Apple Intelligence, and as far as I can tell from Apple's documentation there is no per-request fee for it. It works offline and the input never leaves the device.

The honest limits: it needs a supported device with Apple Intelligence turned on, the model is smaller than the hosted ones, and you build and test a separate path for Android. So the real comparison of on-device AI vs cloud AI is not cheap against expensive. It is a feature that is free to run but narrower and device-dependent, against a feature that is capable and universal but billed per use.

My usual split is simple. Classification, extraction, summarising short text, anything private or offline: try on-device first. Generation, long context, image creation, anything that has to work the same on every phone: hosted. Plenty of apps end up with both, and the code should make that a configuration choice. Apple has also said that server-side model features carry daily usage limits and that expanded access will be offered for a fee later, so read the current terms before you build on any server-side option.

Put a Number on the Per-User Bill

However you settle how to add AI to my app, price one active user for one month before launch. Take the number of times the feature runs per session, the sessions per month, and the cost of one call from the provider's current price page. Multiply, then multiply again by ten users and by a thousand.

In my experience the number that hurts is never the average user. It is the enthusiastic one who runs the feature two hundred times in a day, or the script that finds your endpoint. So the bill needs a ceiling: a per-user daily cap, a rate limit at the backend, and an alert that tells you when the day's spend crosses a line you set. If the feature is a paid one, tie the cap to the plan, and keep the billing logic behind the same kind of boundary described in the payment provider abstraction article.

A quote that says "AI feature, fixed price" without any of this has priced the build and left the running cost with you.

What the EU Rules Now Ask: AI Chatbot Disclosure

This part changed recently, so I checked the primary text rather than my memory. Article 50(1) of the EU AI Act says systems meant to interact directly with people must be built so that those people are told they are dealing with an AI system. The exception is when that is obvious to a reasonably well-informed, observant person in the circumstances. The article has applied since 2 August 2026.

For a founder this turns AI chatbot disclosure from a nice touch into a design requirement for any feature a European user can reach. Where the AI is a chat that sounds human, say so in the interface, near the input, in plain words. Where it is an obvious tool, such as a scanner that labels a coin, the exception may cover you, but do not stretch it: "obvious" is judged from the user's seat, not yours. I am an engineer, not your lawyer, so have counsel read how it applies to your product and markets. What I can do is make sure the disclosure has a place in the design, so adding it later is not a rebuild.

What the App Store Now Checks

Apple updated its App Review Guidelines on 16 October 2026. Guideline 1.2 now says content moderation must explicitly cover nonconsensual intimate imagery, including imagery generated with AI tools, which apps must proactively prevent and remove. Apple's post says developers who fail to put adequate safeguards in place, or do not fix violations after notice, risk breaching the Developer Code of Conduct and removal from the store.

If your feature generates or edits images, that is a design item: input filtering, a way for users to report content, and a process for removing it. A new guideline, 2.5.19, also bars hiding features during review and adding them afterwards, which matters if you gate an AI capability behind a server switch. Disclose what the app does, and plan for this early when you decide how to add AI to my app. If the app was assembled by an AI builder, the guide to getting a vibe-coded app through review covers the other flags.

The Order I Build It In

When a founder hands me the question of how to add AI to my app, this is the sequence.

1. Write the job and the tolerable failure in one sentence.
2. Choose the route: on-device, hosted, or both behind one interface.
3. Build the backend proxy, the cap and the alert before the feature screen.
4. Build the feature with the disclosure and the reporting path in the design.
5. Test with the worst user you can imagine, not the average one.
6. Ship to a small group, read the bill after a week, then widen.

Notice that the model appears in step two. Everything around it is what makes the feature safe to leave running. That is the work behind how AI-augmented delivery works in practice: the speed comes from the tooling, and the judgment about caps and rules stays with a person.

What I Would Do If You Asked Me Tomorrow

The question of how to add AI to my app is really four questions: which route, what it bills, what it must say, and what it must filter.

I would ask for the one-sentence job, the markets you ship to, and whether the feature touches images or minors. Within a day I could tell you which route fits, what a month of one active user would cost, and which rules apply. That is a short written note, not a project.

If you want that note, or want the feature built with the caps and disclosure in from the first commit, see the engagement model, or tell me about your project.