DEV Community: Ashish Bhandari

Building an On-Device Training Strategy for Personalized iOS Apps

Ashish Bhandari — Sat, 13 Jun 2026 17:20:51 +0000

Machine learning on mobile devices is often associated with inference: download a model, run predictions, and return results.

But what if the model could continue learning directly on the user's device?

In this article, I'll walk through a practical training strategy for on-device personalization in iOS using a lightweight Multilayer Perceptron (MLP). The goal is to create applications that adapt to individual users while keeping their data private and avoiding cloud infrastructure.

Why Train On Device?

Consider a habit-tracking application.

Two users may exhibit completely different behaviors:

User A completes habits every morning.
User B completes habits late at night.
User A responds well to reminders.
User B ignores reminders entirely.

A single global model cannot capture every user's unique patterns.

Instead, we can train a small neural network locally using each user's own interaction history.

Benefits include:

Privacy-first personalization
No server-side training costs
Offline functionality
Faster adaptation to user behavior
Reduced regulatory concerns around user data

The Training Pipeline

A typical on-device learning pipeline looks like this:

User Events
    ↓
Feature Extraction
    ↓
Training Dataset
    ↓
MLP Training
    ↓
Updated Model
    ↓
Personalized Predictions

Every user effectively owns a customized model.

Step 1: Collect Behavioral Signals

Start by recording meaningful events.

struct UserEvent {
    let timestamp: Date
    let type: EventType
}

enum EventType {
    case appOpened
    case reminderTapped
    case habitCompleted
    case habitSkipped
}

These events can be stored using:

SwiftData
Core Data
SQLite

The goal is to build a historical timeline of user behavior.

Step 2: Build Feature Vectors

Raw events aren't useful for neural networks.

We need numerical features.

Example:

struct HabitFeatures {
    let currentStreak: Double
    let completionRate30Days: Double
    let appLaunchesToday: Double
    let remindersOpenedToday: Double
    let hourOfDay: Double
}

After normalization:

[
    0.45,
    0.80,
    0.30,
    0.10,
    0.75
]

These values become the neural network's input.

Step 3: Generate Training Samples

Every day becomes a training example.

For example:

Features on Monday
        ↓
Completed Habit on Tuesday?

Represented as:

struct TrainingSample {
    let inputs: [Float]
    let target: Float
}

Where:

1 = completed habit
0 = missed habit

Over time the device accumulates hundreds of examples automatically.

Step 4: Keep the Model Small

On-device learning is not about training giant models.

A compact MLP is often sufficient:

10 Inputs
    ↓
16 Neurons
    ↓
8 Neurons
    ↓
1 Output

This architecture typically contains only a few hundred parameters.

Advantages:

Fast training
Tiny memory footprint
Low battery usage
Instant predictions

Step 5: Schedule Training Intelligently

One of the biggest mistakes in mobile ML is training too frequently.

Training should happen only under favorable conditions.

Recommended conditions:

Device charging
Connected to Wi-Fi
Screen locked
User inactive

Use BackgroundTasks:

BGProcessingTaskRequest(
    identifier: "com.example.training"
)

Training should typically run:

Once per day
Once per week
After collecting enough new samples

Example configuration:

epochs = 20
batchSize = 32
learningRate = 0.001

This usually completes in under a second for small datasets.

Step 6: Save Model Checkpoints

After training, persist the updated weights.

struct ModelCheckpoint: Codable {
    let weights: [[Float]]
    let biases: [Float]
    let version: Int
}

Store checkpoints inside:

Application Support/

On launch:

model.loadCheckpoint()

The model immediately resumes from its previous state.

Step 7: Run Fast Local Inference

Predictions should happen in real time.

let probability =
    model.predict(features)

Example output:

0.87

Meaning:

The user has an 87% probability of completing today's habit.

Inference latency for small MLPs is typically less than one millisecond on modern iPhones.

Step 8: Convert Predictions into Product Decisions

Predictions only become valuable when they drive experiences.

Examples:

if probability < 0.4 {
    scheduleReminder()
}

Or:

if probability > 0.8 {
    suppressReminder()
}

The application becomes adaptive rather than rule-based.

Continuous Learning

The most powerful aspect of on-device learning is the feedback loop.

Predict
    ↓
Observe Outcome
    ↓
Store Example
    ↓
Retrain
    ↓
Improve Predictions

Every interaction helps improve the model.

No data ever leaves the device.

Privacy by Design

Traditional personalization systems often require:

Device
    ↓
Cloud
    ↓
Training
    ↓
Predictions

An on-device system looks like:

Device
    ↓
Training
    ↓
Predictions

User behavior never leaves the phone.

This dramatically improves privacy while reducing infrastructure complexity.

Final Thoughts

Not every application needs a transformer, a recommendation engine, or a cloud-based ML platform.

Many personalization problems can be solved with a small neural network trained directly on the user's device.

For habit tracking, content recommendations, notification timing, fitness coaching, and user engagement prediction, a lightweight MLP combined with background training can deliver highly personalized experiences while remaining fast, private, and inexpensive to operate.

The future of mobile AI isn't only about larger models. Sometimes it's about making smaller models personal.

From PyTorch to Core ML: My Journey Running Recommendation Models Directly on iPhone

Ashish Bhandari — Fri, 12 Jun 2026 13:30:45 +0000

Most recommendation systems run entirely on the backend. User interactions are sent to servers, models generate recommendations, and results are returned to the client.

Recently, I explored a different approach: running recommendation inference directly on an iPhone using a Two-Tower model and Core ML.

The goal wasn't to replace backend recommendation systems, but to understand the feasibility, trade-offs, and developer experience of on-device personalization.

Here's what I learned.

Why On-Device Inference?

Traditional recommendation flow looks like this:

User Action
    ↓
 Backend
    ↓
 ML Model
    ↓
 Recommendations
    ↓
 Mobile App

This approach works well, but comes with a few challenges:

Network latency
Backend inference costs
Privacy concerns
Offline limitations

With on-device inference:

User Features
    ↓
 Core ML Model
    ↓
 Recommendation Embedding
    ↓
 Local Ranking

the recommendation logic executes directly on the device.

Benefits include:

Near-instant inference
Reduced backend dependency
Better privacy
Offline recommendation capabilities

Understanding the Two-Tower Architecture

Before implementation, I spent time understanding why Two-Tower architectures are widely used in recommendation systems.

The model consists of:

User Tower

Generates a user embedding from features such as:

User ID
Purchase history
Preferences
Behavioral signals

User Features
      ↓
  User Tower
      ↓
 User Embedding

Item Tower

Generates embeddings for products.

Product Features
       ↓
   Item Tower
       ↓
 Product Embedding

Matching

Recommendations are generated by comparing embeddings.

Similarity(
    User Embedding,
    Product Embedding
)

Products with higher similarity scores are ranked higher.

This architecture is particularly attractive because item embeddings can be precomputed and stored, leaving only user embedding generation to happen on-device.

Converting the Model to Core ML

One of the first challenges was model conversion.

I initially assumed that converting a PyTorch model into Core ML would be straightforward.

Reality was slightly different.

A common issue was discovering that the downloaded .pt file contained only model weights (state_dict) rather than the actual architecture.

For example:

type(torch.load("model.pt"))

returned:

collections.OrderedDict

which meant the model architecture had to be reconstructed before conversion.

After rebuilding the model and exporting it through Core ML Tools, I obtained:

TwoTower.mlpackage

which could be integrated directly into an iOS project.

Integrating with Xcode

Importing the model into Xcode automatically generated Swift bindings.

One lesson I learned was not to assume generated class names.

I initially tried:

let model = UserTower()

which failed because Xcode generated classes based on the model package name rather than internal tower names.

The generated class was actually:

let model = TwoTower()

A small detail, but one that cost more debugging time than I'd like to admit.

Running Inference

Once integrated, inference became surprisingly simple.

let prediction = try model.prediction(
    userId: userId
)

The Core ML runtime handled execution using available hardware accelerators.

The developer experience was significantly smoother than expected.

Performance Observations

The most impressive part was latency.

Since inference happened locally:

No network request
No API dependency
No server round-trip

The user experience felt immediate.

For recommendation systems, even a few hundred milliseconds can impact engagement.

On-device inference effectively removes an entire network hop from the critical path.

Challenges I Encountered

Model Conversion

This was by far the biggest challenge.

Questions that frequently came up:

Is the model TorchScript?
Is it only a state dictionary?
What are the expected input shapes?
Which outputs are generated?

The conversion pipeline often requires more ML engineering knowledge than mobile engineering knowledge.

Input Feature Engineering

A recommendation model is only as useful as the features provided.

Preparing inputs consistently between training and inference environments is critical.

Even small mismatches can significantly affect recommendation quality.

Debugging Core ML Models

Debugging application code is easy.

Debugging machine learning outputs is harder.

When recommendations look wrong, the issue could be:

Data preprocessing
Feature encoding
Model conversion
Training quality

Finding the root cause requires a systematic approach.

What Surprised Me Most

Before this project, I assumed recommendation systems were too heavy for mobile devices.

The reality is that modern phones are extremely capable.

For many personalization use cases, running lightweight recommendation models directly on-device is entirely practical.

The challenge isn't necessarily inference performance.

The challenge is building the surrounding ecosystem:

Feature pipelines
Embedding storage
Ranking strategies
Model updates
Experimentation frameworks

Key Takeaways

Two-Tower architectures are well-suited for on-device recommendation systems.
Core ML integration is easier than expected once the model is correctly converted.
Model conversion is often the hardest part of the workflow.
On-device inference dramatically reduces latency.
Privacy and offline capabilities become significant advantages.
The surrounding recommendation infrastructure is usually more complex than the inference itself.

Final Thoughts

This project started as an exploration into mobile machine learning and quickly became a deeper lesson in recommendation systems.

As mobile hardware continues to improve, I expect more personalization workloads to move closer to the user.

Running recommendation inference directly on-device won't replace backend recommendation systems entirely, but it opens interesting possibilities for low-latency, privacy-preserving, and offline-first user experiences.

For mobile engineers interested in machine learning, Two-Tower models and Core ML are an excellent place to start.

Weak References in Swift: Understanding Retention Behavior with XCTest

Ashish Bhandari — Sun, 12 Jan 2025 11:13:08 +0000

In Swift, managing object references and memory correctly is essential for building efficient and leak-free applications. One of the most useful tools for preventing retain cycles and ensuring proper memory management is the weak reference. But how exactly does a weak reference behave, and how can we test it to ensure it works as expected?

In this post, we'll dive into weak references in Swift and provide a practical demonstration using XCTest to test their behavior. Specifically, we’ll look at how to verify that a weak reference retains an object initially but does not retain the object after it is deallocated.

What is a Weak Reference?

A weak reference in Swift is a reference to an object that does not retain the object it points to. This is useful for preventing retain cycles, where two objects strongly reference each other, preventing either from being deallocated. With weak references, the object it points to can still be deallocated, and when that happens, the weak reference automatically becomes nil. This behavior is different from strong references, which keep the object alive as long as there is a reference to it.

Key points about weak references:

They do not retain the object.
If the object they point to is deallocated, the reference becomes nil automatically.
They are typically used when an object should not own or strongly retain another, such as in delegate relationships or when dealing with circular dependencies in complex data structures.

Code Implementation

Here’s the implementation of the WeakReference class:

final public class WeakReference<T: AnyObject> {
    public weak var object: T?

    public init(object: T) {
        self.object = object
    }
}

Why This is Important

Understanding the behavior of weak references is crucial when designing systems that rely on memory management, especially when:

You are working with delegate patterns where the child object should not strongly retain its parent.
You are implementing circular references in data models (such as doubly linked lists or graphs).
You need to ensure that resources are freed properly when an object is no longer needed, preventing memory leaks.

The Test Case: Verifying Weak Reference Behavior

In the following example, we will write unit tests using XCTest to verify that a weak reference behaves as expected in two key scenarios:

Initially, a weak reference should retain the object while it exists.
After the object is deallocated, the weak reference should automatically become nil.

Here’s the implementation of the WeakReferenceTests class that contains the tests:

import XCTest

final class WeakReferenceTests: XCTestCase {
    func testWeakReferenceRetainsObject() {
        let obj: TestObject = TestObject()  // Creating an object
        let sut = WeakReference(object: obj)  // Creating a weak reference

        XCTAssertNotNil(sut.object, "Weak reference should retain the object while it exists.")
    }

    func testWeakReferenceDoesNotRetainObjectAfterDeallocation() {
        var object: TestObject? = TestObject()  // Creating an object
        let sut = WeakReference(object: object!)  // Creating a weak reference

        XCTAssertNotNil(sut.object, "Weak reference should retain the object initially.")

        // Deallocate the test object
        object = nil

        XCTAssertNil(sut.object, "Weak reference should not retain the object once the object is deallocated.")
    }

    private class TestObject {}
}

By writing tests like the ones above, you can confirm that your weak references work as expected and that your application’s memory management is functioning correctly.

Running the Tests

When running these tests, you would observe the following:

In testWeakReferenceRetainsObject(), the weak reference should hold onto the object, so the assertion will pass.
In testWeakReferenceDoesNotRetainObjectAfterDeallocation(), after the object is deallocated, the weak reference should automatically become nil. If it does, the test will pass.

Summary

Weak references are a powerful tool for managing memory in Swift. They help prevent retain cycles and ensure that objects are deallocated when they are no longer needed.

By writing unit tests like the ones shown above, you can ensure that your Swift code handles memory management correctly and efficiently, preventing memory leaks and retain cycles in your applications.

https://github.com/iashishbhandari/WeakReference

Happy coding and testing!