AI has changed what users expect from mobile products and created new engineering problems. A feature may take thirty seconds to return a result or fail without warning. Mobile teams now need different approaches to interface feedback and application state.
Ihor Riazantsev is an iOS engineer with more than six years of experience. At Ex-human Inc., he has worked on Botify AI and Photify AI, building mobile features around conversational AI and photo generation. He discusses how iOS development is changing and how coding assistants affect product engineering.
How has iOS development changed during your career, especially since AI-powered features became common in consumer apps?
Ihor Riazantsev:
When I started, iOS development meant UIKit with callback-based code and a lot of boilerplate. SwiftUI reduced the amount of code needed for interface work. Async/await also made asynchronous logic easier to follow.
The larger change is in the products themselves. A mobile app used to behave predictably because most of its logic lived on the device. In Botify AI and Photify AI, the main feature depends on a remote model, so the same request may take thirty seconds or return a different result each time. Much of my work now involves making that uncertainty manageable for the user.
What makes building a mobile interface for an AI product different from building a traditional app?
Ihor Riazantsev:
A traditional interface produces a predictable result, so the team can define its states in advance. An AI product may return something useful once and something unusable next time. Regeneration and failed requests therefore need to be part of the main experience. On mobile, the app may also close while the request is still running, so the interface has to preserve the operation without promising a specific result.
Which UX problems appear when users have to wait for an AI model to return a result?
Ihor Riazantsev:
A long wait gives users time to question whether the result will be worth it. When someone watches a loader for thirty seconds, the pause starts to feel like a reason to leave. The problem is not only the duration of the request, but the empty screen around it.
We stopped forcing users to wait on that screen. The generation continues in the background, and the user can return to the rest of the app. Once the result is ready, it appears in their profile or through a push notification.
What have you learned about managing long-running operations and shared state in large iOS applications?
Ihor Riazantsev:
The server should own the state of every generation. Each operation has an ID and a status, while the client reflects the latest information. This prevents the app from losing track of a request when the user leaves the screen. We also keep active operations in one shared client-side store. When the app opens, it asks the server which requests are still running and restores them. This allows the operation to survive navigation or an app restart.
The shared store can become too large if too much logic is added to it. That creates a risk of turning it into a single object that controls too many parts of the app. Even so, it has been more reliable than letting each screen manage its own requests.
Which engineering problems only become visible after an AI product reaches a large number of users?
Ihor Riazantsev:
Some problems appear only under heavier use. While stress-testing a large media gallery, I noticed that the phone was heating up and scrolling was slowing down. Items that had left the screen were still being held in memory, so unused objects kept accumulating. The code looked correct during review, but testing on a real device exposed the problem.
How are tools such as Claude Code changing the work of product engineers?
Ihor Riazantsev:
They make the first version of the code much faster to produce. When Photify AI was removed from the App Store, we had about two weeks to move its main generation feature to the web side of Botify AI. I had worked mostly in native iOS, but Claude Code helped me complete the web implementation within that period.
The code still needed close review. I had to keep the new work separate from the existing product and check that it followed the patterns already used in the codebase. The tool saved time on implementation, but it did not remove the need to understand what was being shipped.
As AI tools become better at writing code, which parts of an experienced engineer’s role become more important?
Ihor Riazantsev:
Engineers need to define the problem precisely. A coding tool works well when the task has clear limits and a clear result. Vague instructions usually produce code that looks plausible but does not fit the product. Experience also helps engineers recognise where a system is likely to fail. Many issues appear only under load or when different parts of the product affect each other. A tool can generate code, but it cannot decide which risks are acceptable.
The engineer still has to decide whether the result is ready for users. That requires understanding the system, not just checking whether the code compiles. Coding assistants change how the work begins, but responsibility for the finished product stays with the engineer.
