Dmytro Polianskyi
iOS Developer
I’m Dmytro Polianskyi, an E2E Lead / iOS Developer at Salmon, focused on building consumer apps that are flexible, fast to ship, and actually useful to people.
I originally started as a product designer, but taught myself how to code because I wanted to get closer to how products are really built. That path shaped the way I think about engineering: not just as writing clean code, but as designing systems that help teams learn, adapt, and ship better product experiences.
I lived and studied in China, where I studied applied computer science and big data analysis before leaving the country and continuing my career in iOS. My first iOS app was Chinese With Laowai, a language-learning app where I worked on everything from custom UI to NLP, pronunciation practice, and performance-heavy text rendering.
Today, my work sits at the intersection of iOS engineering, product thinking, and cross-functional delivery. I’m especially interested in how SwiftUI architecture, backend contracts, analytics, and team structure can help mobile teams move faster without turning their codebase into chaos.
Product-Oriented Programming: When Shipping Speed Is an Architectural Requirement
Consumer app architecture is not only about clean code or correctness. For iOS engineers, it is also about how quickly we can change what users experience without waiting for an App Store release.
This talk introduces Product-Oriented Programming: treating product velocity as an architectural requirement. Through a real onboarding flow built in SwiftUI, we will explore how server-driven forms can render fields, handle validation, manage dependencies, and lock behavior from a backend contract instead of hardcoded screens.
Attendees will learn how to decide when server-driven UI is worth the complexity, how feature flags and remote config can become safe product controls, how to design analytics into iOS architecture from the start, and how a shared contract helps iOS, Android, backend, and QA move together. We will also cover the trade-offs for iOS codebases: weaker local reasoning, harder debugging, and the discipline needed to avoid turning flexibility into debt.