.png){kind=logo}
As mobile engineering expands beyond writing and shipping code, esteemed Software Engineer draws on experience building an app used by millions to explain why reliability, judgment, and product thinking are raising the bar for mobile engineers.
Writing good code in mobile software engineering is no longer enough. A recent Forbes Technology Council article reports that median crash-free sessions have reached 99.95%, while 82% of users consider stability extremely important and 63% will uninstall an app after three crashes or fewer. As automation takes over more routine work, engineers have to bring more to the table. In this interview, Software Engineer Tomasz Kubiak, with 10+ years of experience, discusses the skills that increasingly separate strong mobile engineers from the rest and shares approaches that helped him grow and succeed in the field.
Tomasz is currently a Senior iOS Software Developer at Welltech, where he works on WalkFit, a wellbeing app with more than 10 million downloads. His product work includes A/B-tested changes that delivered a double-digit lift in early goal activation and a measurable gain in first-week retention. A nutrition module he developed was also associated with higher customer lifetime value among purchasers. Before joining Welltech, Tomasz developed iOS apps at Talixo and introduced CI improvements that halved build times. His broader engineering career includes three patent records, with patents granted in the United States and Europe, peer-reviewed research, and IEEE Senior Member status.
I think the biggest shift is toward broader ownership. Mobile engineering has become much more connected to how a product performs in the real world. Technical decisions affect stability, delivery, user experience, and how a product evolves over time. Strong engineers need to understand the context around the code and think several steps ahead. The ability to see those connections and make sound decisions as complexity grows has become a much bigger part of the job.
I studied Mechatronics at Lodz University of Technology in Poland, which gave me an early understanding of how different parts of a system affect one another. After university, I joined Corning and later moved from Poland to its engineering organization in the U.S. Working on product development there taught me to pay close attention to failure modes and to understand the cause of an issue before making changes. When I moved into software, I brought that mindset with me. It has been especially useful in mobile engineering, where an application has to perform reliably across releases and real-world conditions. That background also shaped how I approach testing and stability today: I tend to think about the whole application's behavior and the consequences an engineering decision may have beyond the feature being developed.
I would start with the development workflow itself. A major improvement came from introducing a more advanced CI/CD caching strategy, which reduced CI times. That meant less time waiting for builds and faster feedback during development. We also worked on modularization and release automation, which made the applications easier to maintain and reduced the risk of manual releases. For me, the broader lesson was that delivery speed depends heavily on the systems around the code. Improving that infrastructure gives engineers more time to focus on the product and makes releases more predictable.
The product's main goal is to help people make walking a regular part of their daily routine. It combines activity tracking with walking plans and other features that support long-term consistency. At this scale, even a small engineering decision can affect a large, diverse group of users. A feature may work perfectly in isolation and still affect the broader experience in unexpected ways. That has made me pay much more attention to what happens after release and to treating real-world behavior as part of the engineering process.
In my view, what separates strong engineers is the willingness to look beyond the immediate bug. A production issue can point to a deeper weakness in how a feature or part of the system was designed, so the goal is to understand what made that failure possible and whether the same conditions exist elsewhere.
This way of thinking also shaped my research on mobile architecture. In a recent paper, “A Local-First Architecture for Privacy-Preserving Personalization in iOS Health and Fitness Applications,” published in American Impact Review, I proposed an approach to iOS personalization that keeps sensitive health data on the device whenever possible. The work identifies potential failure points before implementation and places safeguards as close to the source as possible. The context is privacy, but the engineering principle is broader. A strong solution should address the underlying weakness and make the system more resilient, instead of simply making the visible problem disappear.
Understanding product and business metrics helps an engineer see the impact of technical work beyond the release itself. With the nutrition module, the conversion rate and customer lifetime value gave us a much clearer picture of its value after launch. That perspective also changes engineering priorities. We can direct time and complexity toward features that genuinely improve the product, and technical decisions become easier to tie to measurable outcomes. For me, that connection between engineering and product impact is central to senior-level work.
Experimentation helps connect engineering decisions with what people actually do with a product. Before releasing a change, I want to be clear about what behavior we expect it to influence and how we will know whether it worked. A/B testing gives us evidence from real usage, but I also look beyond the primary metric because improving one part of the experience can affect another. I brought that habit of considering both the intended result and the wider impact to my role as an invited judge at the recent AITEX Summit Summer 2026. The same principle applies when evaluating technology more broadly. A technically impressive solution is only part of the picture; it also needs to address a real need and create value in practice.
I would invest in judgment. Coding tools will keep changing, but engineers still need to understand the consequences of their decisions. That comes from seeing how systems behave in production, how users respond to a product, and how technical choices affect the business over time. I would also stay curious beyond the immediate mobile stack. Some of the most useful ideas in my own career came from moving between different areas of engineering and bringing those perspectives into software. I believe the ability to connect those pieces and make good decisions when the answer isn't obvious will keep engineers valuable as the profession continues to change.
