githubEdit

[ABC Wallet] Architecture + Modularization


πŸ“Œ Overview


🧩 Project Introduction

'ABCWallet' is a project that converted an existing React Native-based app to native, significantly improving stability and performance. Through collaboration between iOS and Android developers, we built a codebase based on clean architecture to ensure scalability and ease of testing.

By utilizing Swift Package Manager for modularization, we improved maintenance efficiency, and by stably operating core features such as multi-blockchain support, Swap, staking, and NFT transfer, we established a foundation to handle diverse user environments.


πŸ”§ Tech Stack and Architecture

  • Architecture: Clean Architecture + MVVM

  • Module Management: Swift Package Manager

  • Technologies: SwiftUI, UIKit, Swift Concurrency, Combine, StoreKit, etc.

  • Local Data:

    • CoreData – Cached data

    • UserDefaults – App settings

    • Keychain – MPC-based Shared Key


πŸš€ Key Features and Implementation Cases

1. Clean Architecture / SPM Modularization

  • Domain β†’ UseCases, Repository protocol, Entities

  • Data β†’ Repository Impl, Data Source (Network / Local Storage), Mapper ..

  • ABCUI β†’ A collection of View Components commonly used in the app

  • Common β†’ A collection of utility functions

[SPM Modularization]

2. SNSLoginUseCase Implementation Sample

This code is an example of implementing the UseCase layer of clean architecture.

It defines the business logic for SNS login processingin the execute method, and all external dependencies are injected through abstract interfaces (Repository, Service, UseCase).

  • Separation of Responsibilities: Delegate various responsibilitiesβ€”login request, user info update, token storage, device data resetβ€”to each collaborating object

  • Dependency Injection: Receive Repository and Service via constructor injection to ensure testability and flexibility

  • Asynchronous Processing: Improve readability of async flow via async/await

This structure applies equally to other use case implementations and is designed with a focus on a role-separated modular structure and flexible scalability.

3. Swap API development within the ABC Wallet app

  • Python, Redis, AWS (ECS)

  • Utilized APIs from 1inch and Swapscanner

  • Select and call different providers depending on the network (Ethereum, Polygon, Binance, Klaytn, etc.)

3-1. Implemented API list

  1. Fetch supported blockchain list

  2. Fetch available token list

  3. Fetch quote price for the swap

  4. Fetch ERC20 allowance amount

  5. Fetch ERC20 allowance Tx Data

  6. Fetch Tx Data to use for the swap

In-app Swap service

4. Designed and implemented the in-house service Waas (Wallet as a Service) SDK

  • Designed and implemented the iOS version in Swift, and based on this, colleagues implemented modules for Android/Web.


🎯 Achievements

  • Clean Architecture was used to re-establish the structure of the iOS app, minimizing code changes when adding features and maximizing maintenance efficiency.

  • Swift Package Manager (SPM) was used to modularize and design the core domains (Domain, Data) to be reusable, enabling porting to the Klip project with minimal changes.

  • Asynchronous logic (Access Token management, WalletConnect, asset transfer) stability was ensured, and concurrency control and abstraction layers were improvedto reduce client failure rates.

  • Within the project, Swap server and WaaS SDK designwere led to secure abstraction of wallet-related APIs and functional consistency across services.


🧠 Retrospective

1. Concurrency control of the Access Token management logic was the most challenging part

  • When requesting an Access Token, validity must be checked first, and if it has expired, it must be reissued via the Refresh token. In this process, when concurrent requests overlap, to prevent duplicate refreshes, it had to be handled sequentially on a single thread.

  • Initially, using GCD's Serial Queue, we ensured that the token refresh logic was safely executed on a single thread.

  • Afterwards, we learned that using Alamofire's RequestInterceptor feature can implement this flow much more concisely and reliably,and we plan to improve it using that approach in a future refactor.

2. Ensured structural stability and scalability through applying Clean Architecture

  • By applying Clean Architecture to the entire project, we clearly separated the domain, data, and presentation layersand created a structure that is easy to test and maintain.

  • Although it was regrettable that we did not consider modularization at the start of the project, we later improved the structure and successfully ported the Data/Domain modules to the Klip app, and felt great satisfaction in terms of reusability and scalability.

Last updated