Senior iOS architect on mobile security, the SDK approach, and engineering decisions with long-term impact
In 2025, mobile applications finally became the primary interface between users and businesses — from payment services and B2B platforms to corporate ecosystems and service products. At the same time, the vulnerability of the mobile layer sharply increased: industry research shows that the number of attacks and fraud cases in mobile apps continues to grow at double-digit rates, and the compromise of a client application increasingly becomes an entry point for data leaks, financial losses, and systemic incidents.
Against this backdrop, the architecture of mobile solutions has ceased to be purely an internal engineering matter. Today, architectural decisions — modularity, dependency management, client trust models, cryptography, and account-to-device binding — largely determine the resilience of a product, its ability to scale safely, and its capacity to maintain user trust. Mistakes at this level are too costly for businesses and cannot be offset by fast releases or feature growth.
The industry has never needed competent engineers more: those who treat mobile products as platforms, embedding security, scalability, and stability at the architectural level. Oleg Pankiv, senior iOS developer and architect, specializes in the SDK approach, high-reliability mobile systems, and user data protection. His work includes payment and B2B systems, device binding, cryptography and biometric solutions, secure local data storage, and architectural changes that have enabled multiple engineering teams across the organization to accelerate development, reduce code coupling, and scale products safely. He also contributed to a white-label food ordering platform for Tacit Corporation, where his architectural decisions supported a shared mobile core deployed across multiple independent branded applications and business clients, ensuring consistent security and performance at scale apps, ensuring consistent security and performance while reducing time-to-market. Oleg spoke to us about how the rise of mobile threats is changing application architecture requirements, why security today must be part of system design rather than a post-hoc add-on, and which engineering principles allow companies to scale mobile products without losing reliability or user trust.
“Architecture is not about code, it’s about responsibility”
You started as an iOS developer, worked on your first commercial applications, and later moved into the architecture of complex mobile systems and SDKs. When did you realize that this level — system design, not just feature implementation — was what interested you?
At some point, I noticed that the problems teams face are rarely related to a specific feature. More often, they are the consequences of decisions made earlier: tight dependencies, unclear contracts, and inability to scale safely. I became increasingly interested not in “how to write code” but in “why the system is designed this way” and what it would look like in a year or two. To address these recurring issues, I formalized my approach: architecture is not about code, it’s about responsibility. And when I started taking responsibility for architecture, it became obvious that this is where I bring the most value to the product and the team.
You mentioned that your transition from task execution to architectural thinking was gradual. What helped you make that leap?
Systemic thinking and discipline. I always tried to look at the product as a whole: data, user scenarios, security, maintainability, and cost of changes. Plus constant self-learning and analysis of mistakes. I saw the same architectural problems recurring across different projects and began to develop my own principles, which later became the foundation of my SDK solutions and internal standards. This included formalizing security baselines using OWASP MASVS, enforcing stable SDK contracts, and designing modular components that minimized coupling between layers.
“An SDK is a contract between you and dozens of teams you may never see”
You developed modular SDK architectures that were integrated into dozens or hundreds of third-party applications. How does SDK architecture fundamentally differ from ordinary application architecture?
An SDK is not just a library; it’s a contract. You do not control the environment, the skill level of developers, or the application lifecycle. Any error or poor decision scales along with the number of integrations. To prevent cascading issues, stability of the API, backward compatibility, module isolation, and predictable behavior take priority. I have always treated an SDK as a separate product, not auxiliary code. Distribution through Swift Package Manager and XCFramework ensures consistent delivery and versioning for internal and external teams.
How did your architectural decisions in SDKs impact the teams working with them?
In several projects, implementing modular architecture reduced the development time of new features by approximately 25–35%. Teams built projects faster, encountered fewer dependency conflicts, and could develop different parts of the system in parallel. In the Tacit Corporation project, we applied an SDK-first approach to create a shared core that could support multiple branded apps, which made scaling to new markets and partners more predictable and efficient. In practice, this meant designing SDKs not as supporting libraries, but as independent products with clearly defined contracts, security baselines, and long-term evolution in mind — an approach that later became a reference point for other teams and projects. Several of these approaches were later adopted by other teams and spread across additional projects without my direct involvement or supervision, becoming internal engineering standards. This approach also reduced the coordination overhead and made independent module releases predictable and safe.
“Security is not a feature, it’s the foundation of architecture”
You have worked extensively with payment systems, secure data storage, and Device Binding. What key security challenges in mobile applications have you encountered most often?
The main challenge is the illusion of security. Often, protection is limited to data encryption or biometrics, but the threat model as a whole is not considered. In reality, it is a combination: device, user, runtime environment, and server logic. In payment systems, a mistake can lead not just to a bug but to financial loss and loss of user trust. In practice, this meant using Keychain and Data Protection for secret storage, cryptographic keys anchored in Secure Enclave, App Attest/DeviceCheck for client integrity, and OWASP MASVS as a security checklist. So security is not a feature; it is the foundation of architecture.
You were the initiator of implementing Device Binding. What is the practical value of this approach?
Device Binding allows an account to be tied not only to a password but also to a specific device. This drastically reduces the risk of account theft and fraud. Technically, we combined several mechanisms: cryptographic keys protected by Secure Enclave, attestation to ensure the server trusted only our client instance, and OWASP MASVS as a baseline for security requirements. As a result, thousands of users gained an additional layer of security without complicating the user experience, and the system was designed from the outset with scalability in mind.
“A mature product must be observable”
In your projects, you paid significant attention to performance and stability. Why is this so critical for you?
Performance is part of the user experience. If the interface stutters and the app behaves inconsistently, no features will save the product. I have always believed that a mature mobile product must be observable: we need to understand what is happening in production, where the bottlenecks are, and how the system behaves under load. Beyond security, we also optimized performance. For example, we improved large feeds by differentiating updates (recreate vs reconfigure), reducing flicker, random animations, and regression issues.
What practices did you implement to improve application quality and predictability?
These included FPS monitoring, UI snapshot tests, and unit testing of key components. In one project, test automation reduced regression testing time by approximately 20% and significantly decreased the number of release bugs. We also achieved up to 80% test coverage in critical modules, speeding up the detection of issues even during development. Additionally, we standardized reusable UI/logic components, dependency injection patterns, and mock setups to accelerate feature development.
“When solutions become standard, it is a form of recognition”
You have mentioned that your architectural decisions became standards within teams. How did that happen?
It was usually not a formal process. Teams saw that a certain approach made life easier: it sped up builds, reduced coupling, and made code more understandable. Over time, these decisions evolved into internal engineering standards and began to be adopted by default across teams. Essentially, when solutions become standard, it is a form of recognition. I was also often involved in analyzing complex technical scenarios and evaluating risks — I was regularly consulted as a subject-matter expert for high-risk architectural and security decisions.
You also mentored other engineers. What is important for you in this role?
I believe a strong engineer must share knowledge. Through mentoring, I helped colleagues develop architectural thinking, understand the long-term consequences of decisions, and not just solve current tasks. This raised the overall level of the team and allowed products to develop sustainably, rather than through constant “firefighting.”
“Expertise extends beyond the company”
Your expertise is sought after beyond specific projects — you are a member of professional associations AITEX and Hackathon Raptors. Why is this membership important to you?
These organizations bring together specialists who have already made a significant contribution to the industry. Membership is not a formality but recognition of a professional level. For me, it is an opportunity to exchange experiences, participate in expert discussions, and stay connected within the professional community.
In 2025, you won the Alliance Top Award in the “IT Systems Architect” nomination. How did this international recognition influence your professional perspective, and why does it matter to you?
It was a good sign that my approach to architecture actually works not only within individual teams but also in a broader context. For me, it matters not as a “title,” but as confirmation that long-term, responsible architecture is not an abstract ideology, but a real value for products and business. When experts from different regions evaluate your work and recognize it, it gives you additional confidence: you understand that the decisions you make today can truly withstand the test of time and scale.
You also judge and evaluate projects, including the Time of Innovations Award. What do people expect from you in this role, and why do you find this experience valuable?
In general, I am expected to provide an objective assessment of technological solutions from the perspective of architecture, security, and production readiness. Judging requires the ability to quickly and objectively evaluate both the technical solutions themselves and their scalability and prospects. I assessed AR/VR, AI-assisted platforms, B2B procurement, HR, and educational systems, checking architecture, security, trust models, scalability, observability, and production quality — translating technological concepts into practical implementation. My conclusions were used to make strategic decisions on product development. And, of course, it is very valuable for me as a specialist to confirm that my experience is in demand not only within specific teams but also at a broader industry level.
“Architecture is a contribution to long-term growth, not a quick result”
Looking back, what impact do you think your work has had on products and business as a whole?
In several projects, architectural improvements led to reduced development effort, increased stability, and fault tolerance, especially when handling large amounts of data. Clients could release updates faster, retain users, and scale products without sharply increasing technical debt. These improvements included modular UI updates, offline caching with proper layer separation, and reusable components that sped up delivery and reduced regressions.
How do you define your professional mission today?
I see my task as creating reliable, secure, and scalable mobile systems that stand the test of time. Combining long-term architecture principles with attention to emerging trends, I also focus on Zero Trust, passkey-based passwordless authentication, secure-by-design systems, and hardware trust anchors to ensure products remain scalable and secure. It is important to me that the decisions I make remain relevant for years — regardless of whether I am directly involved in the development of a particular product.
