Rebuilding Nala in Swift Because UX Is the Product

I moved Nala to Swift because the app has to feel right in the hand. Not “fine.” Not “good enough for now.” Right.

Nala is supposed to become a daily assistant, so the tiny moments matter: opening the app, typing a task, swiping between screens, using the keyboard, getting back to what you were doing. If those moments feel heavy, the product loses before the AI even gets a chance to help.

For this kind of product, UX is not decoration.

It is the trust layer. If the app feels slow, awkward, or slightly off, people will not build a habit around it.

Why rebuild before launch?

Because launching faster with the wrong feeling is not really faster. It just moves the pain to later.

The first version helped me move quickly, but the iPhone experience still felt like it needed more control. Nala should feel like it belongs on iOS, not like a website wearing an app costume.

That is why I made the annoying decision: rebuild the iOS app in Swift before launch.

It feels more native

Swift is built for Apple platforms, so the app can follow iOS patterns more naturally.

The small things get better

Keyboard behavior, gestures, transitions, and screen rhythm are easier to tune properly.

There is more control

When the product depends on feeling calm and fast, control over the details matters.

What Swift actually helps with

Swift is Apple’s native language for building iPhone apps. That means it sits closer to the system: navigation, animations, gestures, notifications, input, performance, and all the little behaviors people expect without thinking about them.

Most users will never care what language an app is written in. They should not have to. They just feel whether the app is smooth, quick, and comfortable — or whether something is slightly annoying every time they open it.

For a normal app, that might be acceptable. For a personal assistant, it is a problem. The assistant needs to disappear into the day, not become another thing you have to manage.

The trade-off

Rebuilding is not glamorous. It slows things down for a while. It creates work that nobody can see from the outside. It also makes you question your life choices at least twice a day.

But it gives the product a better foundation. And for Nala, the foundation matters. I would rather take the hit now than ship something that feels average and then spend months fighting that feeling.

Step 1

Move the iOS experience into Swift.

Step 2

Make the core flows feel clean: capture, tasks, navigation, settings, and daily use.

Step 3

Use real-device testing to find what feels slow, confusing, or annoying.

Step 4

Keep tightening until the product feels calm enough to trust with your day.

What changed so far

The new iOS build is already in real-device testing. That does not mean the product is finished. It means the work has moved into the part where the phone starts telling the truth.

Some things look good in a design file and feel wrong after the tenth use. That is the whole point of this stage: use it, feel the friction, remove the friction, repeat.

A screen either earns its place in your day, or it starts asking for rent in your brain.

What this means for Nala

Nala is still in development. The direction is simple: build an assistant that helps people move through work with less friction.

That only works if the product feels good before it tries to be clever. Swift is not the whole answer, but it gives the iOS app the kind of foundation I want to build on.

The short version

I moved Nala to Swift because UX is the product. If an assistant is going to live in your daily workflow, it has to feel native, fast, and calm from the first tap.