About

How I got here

I did not come to software through a computer science degree. My BSc is in Light Sources and Lighting, and for a while I expected to spend my career around optics and electronics. What actually held my attention was the software side of the instruments I was working with — the part where you could change behaviour by changing a few lines of text. I started with Objective-C because that was what the tutorials I could find used, learned UIKit by rebuilding screens from apps I liked, and kept going until it stopped being a hobby. Swift arriving in the middle of that was lucky timing: I got to learn the old runtime-heavy world and the new type-safe one close enough together that I still think in both.

The engineering I care about

The kind of engineering I care about is mostly the unglamorous kind. I like modular code — feature boundaries that hold, dependencies that point one direction, modules you can build and test in isolation without launching the whole app. I like testability, which in practice means designing so that the interesting logic isn’t trapped inside a view controller. And I like release engineering more than most iOS engineers seem to: multi-environment build configurations, CI pipelines that produce signed builds without a human clicking anything, SwiftLint running where it can actually block a regression, crash reporting wired up properly so a spike in a release tells you something specific. A feature that works on your machine is maybe forty percent of the job. The rest is making sure it works on ten thousand devices you’ll never touch, and that when it doesn’t, you find out fast and can ship a fix the same day.

Where I have worked

Professionally I’ve worked across a few domains: banking and fintech mobile apps, retail e-commerce flows, event registration platforms, and BLE-based connected wearables — including SDK work meant to be integrated by external customers, which changes how you think about API design very quickly. When your consumer is another engineering team, every awkward method signature becomes someone else’s support ticket.

I’m not only a client engineer. A good part of my recent work has been full-stack: TypeScript and Node with Express or Next.js, Prisma over PostgreSQL, Redis and BullMQ for queues and background jobs, deployed with Docker onto Azure or Cloudflare with GitHub Actions doing the boring parts. I don’t claim to be a backend specialist, but I’ve found that being able to build and change the server makes me a much better mobile engineer. You stop proposing API designs that are convenient for the client and impossible for the service, and you can debug across the boundary instead of filing a ticket and waiting.

Toolbox

• iOS — Swift, Objective-C, UIKit, SwiftUI, RxSwift, Combine, MVVM, Objective-C runtime, WebKit, BLE, Swift Concurrency
• Architecture & testing — Swift Package Manager, modularisation, XCTest, Swift Testing, SwiftLint, Crashlytics
• Backend & web — TypeScript, Node.js, Express, Next.js, Prisma, PostgreSQL, Redis, BullMQ
• Delivery — Docker, Azure, Cloudflare, GitHub Actions, multi-environment release automation

What I am looking for

What I’m looking for now is a role at a foreign company or an international remote team — somewhere the working language is English and the engineering culture takes code review, testing, and release process seriously. I’m a native Mandarin speaker; my English reading and writing are at a professional level and my speaking is conversational and improving with use. I’d like to work on a mobile product with enough complexity that architecture actually matters, alongside people who will tell me when I’m wrong.

Get in touch

Email is fastest: levileiwork@outlook.com. I am also on GitHub and LinkedIn.