Payment Wallet App

01 Problem

A payment technology company needed a modular mobile wallet supporting credit card management, KYC onboarding, secure payment processing, and a MiniApp platform for third-party integrations. The wallet required enterprise-grade security with PKCE authentication and strict code quality enforcement.

02 Approach

Chose Assembly-based dependency injection over Swinject or manual construction because it allowed each feature module to declare its own dependency graph without coupling to a global container. Evaluated VIPER vs modular-Assembly architecture — selected Assembly because VIPER's rigid per-screen decomposition didn't scale well beyond 15 modules. Each of the 33 modules owns its Assembly, its view hierarchy, and its coordinator — enabling parallel development across the team without merge conflicts in shared files.

03 Solution

Architected and built a 33-module iOS wallet application using Assembly-based dependency injection. Each feature is isolated in its own module (KYC, Cards, Payment, PIN, Profile). Integrated WebView-based MiniApp platform via custom native-web bridge. Enforced 50+ SwiftLint rules and automated CI/CD with Fastlane and Danger for PR reviews.

04 Outcomes

05 Trade-offs

33 modules created significant build overhead — clean builds took noticeably longer than a monolithic app. The Assembly DI pattern required boilerplate for each new module, which slowed feature bootstrapping. However, it eliminated the "god AppDelegate" problem and enabled true parallel development — two iOS developers could work on KYC and Cards simultaneously without touching shared code. The MiniApp WebView bridge introduced a JS↔Native serialization boundary that was harder to debug than pure-native communication.

06 Constraints

• PCI-DSS compliance for card handling
• PKCE authentication flow
• 50+ SwiftLint rules enforced on CI
• MiniApp sandboxing for third-party code

07 Innovation

33-module wallet with Assembly-based DI. Each feature (KYC, Cards, Payment, PIN, Profile, MiniApp) is a self-contained module with its own Assembly container. Custom WebViewBridge enables native↔web communication for third-party MiniApps with topic-based pub-sub messaging.

08 Reflection

The 33-module architecture was the right call for a team of this size and a product of this complexity. The key insight was that modularity pays off not at build time but at development time — merge conflicts dropped to near zero. If rebuilding today, I would use Swift Package Manager local packages instead of framework targets for faster builds, and adopt SwiftUI for new modules while keeping UIKit for existing ones.