Blockchain wallet app
We rebuilt a live blockchain wallet app for another platform, single-handed. In a wallet, one wrong address or signature can leave users unable to find their own assets, so the first priority was handling the same wallet with the same addresses as the existing app. Working only from the existing app's source code to analyze its features and screen flows, we implemented everything from the screen architecture to wallet creation and recovery, transfers and signing, and transaction history. Rather than just copying existing behavior, we reorganized the screen structure and interactions to suit how the new platform is used.
Ported from source alone, with screens rebuilt the new platform's way
Porting the blockchain wallet app began with analyzing features and screen flows against the existing app's source. Working alone, we both carried existing behavior over and reorganized the screen structure and interactions to suit the new platform. We designed an architecture that separates the responsibilities of screens, screen state, and navigation, which kept the wallet, transfer, and transaction history screens from growing tangled.

Recovery that restores a wallet from the existing app to the same addresses
The blockchain wallet uses a hierarchical deterministic (HD) structure that derives many addresses from one wallet following a standard path rule. When moving these derivation rules to the new platform, we verified the paths, key management, and address generation one by one to make sure that creating, recovering, and deriving a wallet produced the same results as the existing app. If one wallet gave different addresses in the two apps, users could not find their own assets.

Transfers with private keys and signing kept away from the screens
A crypto transfer runs in order: enter the recipient address and amount, sign the transaction, send it to the blockchain network, and check its status. The parts that handle private keys and signing were separated from screen logic, so changing a screen never touches the key and signing flow. We also handled the screens for the moments users are most sensitive to, such as a slow or failed network response, or a transaction moving from pending to complete.

Balance, address, and transaction list re-laid out for each screen size
Wallet screens pack in information that has to be read at once: balance, address, transfer inputs, and the transaction list. We laid out the main screens anew to fit each device's screen size and safe area, the edges at the top and bottom of the screen that can be covered. Tapping an entry in the transaction list opens that transaction's details.

Highlights
Ported single-handed to another platform from the existing app's source alone
HD wallet creation and recovery that yields the same addresses as the existing app
A transfer design that keeps private keys and signing apart from screen logic
Insights
GA4 client_storage: 'none'은 정말 쿠키를 막을까?
두 달 전 이 블로그에 「GA4 쿠키 없이 쓰기」라는 글을 썼습니다. clientstorage: 'none' 으로 쿠키 저장을 끄고, 자체 분석이 쓰던 익명 ID 를 clientid 로 넘기면 쿠키 0개로 GA4 를 쓸 수 있다는 내…
GA4 Measurement Protocol: gtag.js 없이 서버에서 이벤트 보내기
랜딩 페이지의 전송량을 파일 단위로 쪼개 보다가, 가장 큰 파일이 우리 코드가 아니라는 것을 알았습니다. Google Analytics 의 gtag.js 였고, 방문 한 번에 176KB 를 받고 있었습니다. 페이지 전체가 1,094K…
중소 제조업 AI 도입 순서: DX를 먼저 끝내야 할까?
공장을 가진 중소·중견 제조기업 16만여 곳 가운데 스마트공장을 도입한 곳은 19.5%입니다. 회사가 작을수록 이 비율은 더 떨어집니다. 중소벤처기업부가 2025년 4월에 낸 제1차 스마트제조혁신 실태조사 결과입니다. 그림: 기업 규…
Next.js loading.tsx와 404: 버튼이 화면보다 먼저 살아나게 하기
관리 화면 왼쪽 위에 사이드바를 접고 펴는 ☰ 버튼이 있습니다. 폭 하나 바꾸는 버튼인데, 대시보드에서 누르면 2초 넘게 아무 반응이 없었습니다. 레이아웃만 바꾸는 일이 왜 이렇게 오래 걸리는지부터 들여다봤습니다. Next.js 16…



