Release support for small iOS teams
I build and maintain my own apps on the App Store. For teams that already have engineers and ship regularly, I review the flows that matter on a fixed build, fix what we scope together, and carry the checklist into your next release.
01 — WORK
My own products, not client projects. Each links to its App Store listing so you can check the details and version history yourself.
An English dictation and review app. Learners turn a photo, pasted text or typed words into practice lists, then work through dictation, listening and spelling. Mistakes come back for review.
View on the App Store
A calm tap-to-clear block puzzle with Game Center leaderboards and consumable in-app purchases, in English and Simplified Chinese.
Relevant: keeping an app from 2015 current. Version 1.5.1 (Aug 2026) stopped a rating prompt appearing after leaderboard activity and tightened when share rewards are granted.
View on the App Store
Walks through router firmware recovery using the path that matches the device, instead of treating every router as the same TFTP case.
Relevant: how I treat evidence. A finished upload counts as one step, not proof of recovery, and the app exports a local evidence file without IP addresses, device identifiers or credentials.
View on the Mac App Store
A native iOS app for batch editing photo keywords, captions and ratings in the Photos library, with a review step before changes are applied.
02 — SERVICES
Each is agreed in writing before work starts: which build, which device and iOS version, which flows and which networks. Results apply to those conditions.
The flows that matter, checked on one fixed build before it moves forward.
YOU GETA pass / fail / blocked / not-tested matrix, prioritised issues with steps to reproduce, and what was left out.
How your app reads and behaves for users in mainland China, on a real iPhone.
TEST SETUPiPhone 16 · iOS 27.0.1 · China Telecom Wi-Fi and mobile data. Roaming, travel eSIM and ICP filing are not included.
A separately quoted repair once a problem has been diagnosed.
CROSS-PLATFORM STACKSReact Native, Capacitor, Flutter: I test and report. I quote fixes only if the diagnosis shows they are within my reach.
03 — HOW WE START
I am looking for teams I can work with across many releases. A small paid first step lets us both see whether it works before committing to more.
One build, a fixed list of flows, agreed device and networks, a written report.
Scope, inputs and access agreed firstIssues the review confirms are quoted one by one, each with its own acceptance check.
Only after diagnosisRe-run the checklist, check what changed, update last time’s issue log.
Quoted per release while the workload settlesOnce a few releases show a predictable workload, agree a fixed number of hours per cycle.
Based on recorded hours, easy to end04 — CONTINUITY
Continuity only saves your team time if it is written down. Every review leaves these behind.
# Release record build <version (build)> device <model> · iOS <version> network <Wi-Fi / mobile data>, route noted accounts <test accounts used> # Checklist C-01 sign in PASS C-02 purchase subscription FAIL → I-07 C-03 restore purchase BLOCKED sandbox C-04 map search (zh-Hans) NOT TESTED # Issue log I-07 major open first seen: this build I-03 minor fixed verified on this build
05 — WORKING TOGETHER
Briefs, updates, annotated screenshots and screen recordings. My spoken English is basic, so frequent or long video calls are not a good fit.
I use AI tools to help read code and draft documents. For private code I use only the tools you approve, and I check every deliverable myself.
Only the builds, accounts and repository access the agreed task needs. Remove it when the work ends.
A short written brief is enough. I’ll reply with a suggested first scope, or tell you plainly if the work isn’t a good fit for me.
I take on work through Upwork and keep discussion there before a contract starts.