Mobile app
development services
in Newton

An app that earns revenue through ads, rather than through a purchase or a subscription, adds a piece of infrastructure that has nothing to do with the product itself. It is a mediation layer. It auctions ad space among several ad networks and shows whichever one pays the most for that particular person at that particular moment.

Each ad network ships its own software library. Each library adds startup time, memory use, and its own set of background network calls. Adding five networks to raise fill rate can measurably slow the app down, especially on older phones. The slowdown often shows up in reviews first. Nobody checks the newest ad partner until then.

Mediation platforms exist precisely to avoid stacking several separate libraries by hand. A single mediation library talks to multiple networks through one interface. It runs the auction. It loads only the winning ad, which keeps the number of libraries an app has to carry down to a more manageable handful.

Placement matters as much as the technical stack. An interstitial ad shown between two screens a person expects to move through quickly interrupts a task in progress. The same ad format, shown at a natural pause such as after a task finishes, reads as a break rather than an interruption. It draws far fewer complaints from people using the app.

Ad-supported apps also need a plan for people who would rather pay to remove ads entirely. Build that option in from the start. Adding it after launch means a second wave of architecture work later, since the purchase flow, the entitlement check, and the ad-loading logic all need to agree on whether a given person should see ads at all.

Subscriptions and ad revenue can coexist. Mixing them inside the same screen without a clear rule creates a confusing product: a subscriber still seeing ads, or a free user missing a feature that was supposed to stay free. Decide up front which tier gets which experience. That keeps the logic simple later.

Privacy rules add another layer to the decision. Ad networks that personalize based on device or usage data need consent handled correctly before any tracking call fires. A mediation stack has to respect that consent choice across every network it talks to, including networks a team tested less carefully than the primary one.

The simplest version of this decision is a budget one. Revenue per ad impression is small. An app needs meaningful, repeated use to make an ad-based model worthwhile at all. For a niche tool opened once a month, a one-time purchase or a subscription will likely raise more revenue with far less engineering overhead than an ad stack ever could.

A recommendation, a text prediction, an image tag, a fraud check. Many features that used to run only on a server can now run directly on a phone. No network call needed. A small trained model, bundled with the app itself, does the work instead. Deciding which approach fits a given feature is now a real architectural question. It is not a foregone conclusion.

Running a model on the device removes the network round trip entirely. That matters for anything that has to respond while a person is actively typing, scrolling, or pointing a camera at something. A cloud call measured in a few hundred milliseconds feels instant when it is the only thing happening. Stacked behind several other things a screen is already waiting on, it feels sluggish instead.

On-device processing also keeps the raw input off the network. A photo never has to leave the phone to get tagged. A typed draft never has to reach a server to get a suggestion. For features touching anything sensitive, that alone helps a great deal. It can simplify much of the privacy and security work a cloud-based version would otherwise require.

The trade-off is model size and update speed. A model bundled into the app adds to the download. It has to ship inside a normal app update cycle. That is slow. Updating a server-side model is faster, since it improves for every person the moment it is deployed. A phone-bound model also has to run within the memory and processing budget of whatever device happens to open the app, including older hardware still in wide use.

A cloud-based feature, in exchange, can use a much larger model than any phone could reasonably hold. It improves for every person at once. Nobody has to install anything. It also depends entirely on a live connection. Any feature built this way needs a real answer for what happens the moment that connection drops.

Many teams land on a hybrid shape rather than picking one extreme. A small, fast model on the device handles the common case instantly. A heavier server-side model takes over for anything the small model is unsure about. The device model acts as a first pass. Nothing more.

Battery and heat belong in this decision too. Running inference repeatedly, such as analyzing every frame from a live camera feed, can warm a phone fast. It can drain the battery too, if the model runs more often, or at a higher resolution, than the feature actually needs. Limit how often the model runs. That usually costs little in accuracy and far less in battery.

None of this needs to be decided once and left alone. A feature can launch cloud-only first. That tests whether anyone wants it at all. Processing can move onto the device later, once real usage shows it is popular enough, and sensitive enough to delay, to justify the extra engineering it takes to ship and maintain a model inside the app itself.