Chilindo — Live Auction Platform

01 Problem

An online auction platform needed a native iOS app with real-time bidding capabilities. The system required Socket.IO for live bid updates, a swipe-based interface for browsing auction items, integrated Stripe payments, and cart management for won auctions.

02 Approach

Chose VIPER architecture because the auction flow had clear boundaries: bidding logic, payment processing, item browsing, and cart management each needed independent business logic that could be tested without UI. Evaluated MVVM+Coordinator but VIPER's explicit Interactor layer was better suited for the complex bidding state machine. Selected Socket.IO over raw WebSockets for real-time bidding because it provided automatic reconnection and room-based channels — critical for an auction where a dropped connection means a missed bid.

03 Solution

Built a VIPER architecture iOS app with real-time Socket.IO bidding engine, Stripe payment integration, and cart management for won items. Implemented a swipe-based auction browsing interface for intuitive item discovery. Used RxSwift for reactive data binding and Fastlane for CI/CD automation.

04 Outcomes

05 Trade-offs

VIPER added significant boilerplate — each screen required 5 files (View, Interactor, Presenter, Entity, Router). For a 5-person team this was manageable, but it slowed onboarding for new developers. RxSwift for reactive binding was powerful for the bidding state updates but made the learning curve steeper. Socket.IO's JavaScript dependency added ~2MB to the binary. The swipe-based browsing UI was visually compelling but harder to make accessible than a traditional list.

06 Constraints

• Real-time bid updates with sub-second latency
• Swipe-based UI for auction item browsing
• Secure Stripe payment processing for won items
• Cart management for multiple won auctions

07 Innovation

Real-time auction bidding via Socket.IO with swipe-based item discovery. VIPER architecture enabled clean separation of bidding logic, payment processing, and UI concerns across modular components.

08 Reflection

The VIPER architecture was the right level of structure for this project's complexity. The bidding Interactor, tested independently from the UI, caught several edge cases (simultaneous bids, expired auctions, payment timeouts) that would have been harder to catch in an MVVM setup. This project solidified my preference for architecture patterns that separate business logic from presentation in apps with complex state management.