A Create ML model that tells punch types apart, running on the device with Core ML.
Create MLCore ML
🌴
California
Helpros for PROS
iOS Engineer · Feb 2018 to Sep 2019
Overview
I built the pro app for Helpros, the side of the marketplace that does the work. Pros go online, take jobs on a ten-second clock, drive to the customer and get paid. I owned all of it, from the first screen to release.
Role
iOS Engineer. I owned the pro app end to end, architecture through release, and shipped it alongside the customer app.
Offers arrive by push with a ten-second window the server owns. Accept is confirmed server-side, so a job can only ever go to one pro.
One model of a shift
Booked jobs, on-demand work and the online toggle all run off a single state machine, so every screen agrees on where a pro is.
Built to stay on all day
A live ETA for the customer while a pro is en route, and a light touch on GPS for the rest of the shift.
Case study6 min read
Inside the pro app
The pro app looks simple on purpose. This is the engineering that keeps it that way: the constraints, a shift screen by screen, the architecture underneath, and the problems that took the most work.
Role
iOS EngineerPro app, end to end
Timeline
Feb 2018 to Sep 2019Pro and customer apps
Stack
Swift · UIKitMapKit · Core Location · APNs
Owned
Architecture to releaseEvery screen, every state
01Constraints
Built for a ten-second decision
Pros use the app with one eye and one hand: driving, under a car, or between jobs. Offers expire in ten seconds, the signal drops without warning, and the app has to run for a whole shift. Those constraints set every engineering decision that follows.
Ten seconds, every time
An offer has to reach a phone in a pocket, render instantly and resolve inside its window, whether the app was open, in the background or killed an hour ago.
Assume a bad connection
Anything that matters survives a dropped request. Actions are safe to retry, and the server always has the final word.
On for the whole shift
Push, location and a live map run all day, so battery is a budget the app has to stay inside, not an afterthought.
02Walkthrough
A shift, screen by screen
Four moments from a pro’s day. Every numbered detail is outlined on the screen. Hover one to find it.
Step 1 of 4 · Services
Choose the work you do
Pros opt in to the services they’re equipped for, and only those turn up as offers later.
A tick, not a switch, so the list reads as a set of skills.
Learn More sits under each service for pros new to the platform.
Confirm lands in the same spot as every primary action in the app.
Step 2 of 4 · Booked jobs
Booked jobs come first
A pro with bookings works through them before taking on-demand requests. The day comes one card at a time.
The arrival window is the one line in red, because it’s the detail a pro can’t miss.
“1 of 8” pages through the day’s bookings, in order.
Messages ride on the job itself; the badge sits on the card.
Go Online stays visible but disabled, with the reason written beside it.
Step 3 of 4 · The offer
An offer, and ten seconds
A request slides up over the map with everything needed to decide, plus a clock.
Distance and drive time come before the price.
The payout is the largest thing on the screen.
The countdown sits beside Accept, because the clock belongs to the action that expires.
Today’s earnings stay pinned, even mid-offer.
Step 4 of 4 · Wrap-up
Rate, and straight back online
When a job ends, rating the customer is a single tap, and the pro never leaves the online state to do it.
A word sits above the stars, so the rating reads as meaning, not a number.
“You’re Online” holds in the bottom sheet the whole time.
Service area snaps to 25, 40 or 50 miles, which is quicker than a slider with a thumb.
03Under the hood
One shift, one state
Every screen in the walkthrough is a view of the same thing: where the pro is in their shift. Modelling that as a single state machine meant every edge case had exactly one answer, whether an offer landed mid-schedule, a job was cancelled en route, or the app was killed halfway through.
The ten-second stateOne pro, one lap of a shift
Screens
UIKit throughout, with MapKit for the map and service radius. One bottom-sheet container is reused by every state.
State
One object owns the pro’s availability. Screens render from it and ask it to change; none of them decide on their own.
Delivery
Offers arrive by push so they reach a phone in a pocket. Accept isn’t final until the server confirms it.
04Ten seconds
The life of an offer
An offer crosses three systems in under ten seconds: the server that issues it, the push that carries it, and the phone that has to decide. The demo runs on the real timing; tap Accept or Decline to see what happens.
Brake service · 10 miles · $70.00
10seconds
An offer is on its way…
t = 0
Issued
The server matches the booking to an online pro by service and radius, and stamps the offer with an expiry time. From here on, that timestamp is the only clock.
Moments later
Delivered
A push carries the offer to the phone, whether the app is open, backgrounded or killed, and it opens straight over the map.
0 to 10 s
Deciding
Distance, drive time and payout on one screen. The ring counts down to the server’s deadline, not a timer of its own.
Within 10 s
Resolved
Accept goes to the server, which gives the job to exactly one pro, and the customer sees who’s coming and when.Decline, or let the clock run out, and the offer moves straight to the next pro. Nobody waits on a silent phone.
05The hard parts
Where the engineering went
Four problems took most of the engineering: offers expiring in transit, accepts racing each other, booked jobs colliding with on-demand work, and live location without the battery drain.
01Real-time
Offers that expire in transit
Problem
An offer lives for ten seconds, and a phone in a pocket can take a few of them to wake. A local timer would happily let a pro accept something that was already gone.
Approach
I made the server’s expiry the only clock. The ring counts down to that deadline instead of running its own ten seconds, so a late open shows the real time left, or that the offer has passed.
Result
No one can accept a dead offer, and a pro always sees exactly how long is left.
02Concurrency
Two taps, one job
Problem
On a weak signal, Accept can race the countdown, another pro, or the customer cancelling. The phone can’t know who won; only the server can.
Approach
Accept is a request, not a state change. It’s safe to retry, the server arbitrates, and the app holds a short Confirming state until it hears back: the job, or a clear “this one’s gone”.
Result
Every job resolves to exactly one pro, and nobody is left wondering whether a tap counted.
03State
Booked work before on-demand
Problem
A pro with scheduled jobs mustn’t be pinged for on-demand work mid-job, and shouldn’t have to remember to go back online afterwards.
Approach
Availability is one state machine. Outstanding bookings hold Go Online in a disabled state with the reason beside it, and finishing the last job opens it up again.
Result
Scheduled and on-demand work never collide, and there’s no toggle to forget.
04Location
A live ETA without a flat battery
Problem
Customers watch their pro approach in real time, but pros keep the app running all shift.
Approach
Location accuracy follows the state machine: precise GPS only while en route, significant-change updates the rest of the time, and nothing while offline.
Result
Customers get a live ETA exactly when they’re watching, and the rest of the shift stays light on battery.
06Outcome
Shipped, end to end
The pro app shipped on the App Store as the working half of the Helpros marketplace, alongside the customer app. I owned it from architecture through release.
The App Store listing, with the screenshots it shipped with.
ArchitectureThe availability state machine, the screens built on it, and every call to the server.
Real-timePush-delivered offers, the server-owned countdown and the accept handshake.
LocationMapKit, a live ETA while en route, and battery-aware tracking the rest of the shift.
ShippingBuilds and releases, in step with the customer app and the backend.
07Looking back
What I’d keep, and what I’d change
Keep
Availability as one state machine. Every new edge case became a question about a transition, not another flag scattered across screens.
Change
A persistent connection alongside push for foreground offers. Push was the right backbone for a phone in a pocket, but an open app could hear about an offer, or its cancellation, a beat sooner.
Carry forward
Design for the worst network first. I start every feature by asking what happens on one bar of signal with the app killed, then build the happy path on top.
Want to go deeper?
I’m happy to walk through the architecture, the trade-offs and the code behind any of this.
I built the customer app for Helpros, the side of the marketplace that books the work. A customer picks a service, chooses today or a cheaper day later, watches their pro drive over, then rates and tips in one pass.
Role
iOS Engineer. I built the customer app alongside the pro app, on one shared backend, so a job looks the same from both sides.
Every service has two prices. Now goes out to nearby pros as a live offer, and another day becomes a booking on a pro’s schedule.
Your pro, on the map
Once a pro accepts, the customer sees who’s coming, with a photo and a live drive time fed by the pro’s phone.
Rate and tip in one pass
Three quick ratings and a preset tip share one screen, and a single OK sends them all.
Walkthrough
A booking, screen by screen
Four moments from the customer’s side of a job. Every numbered detail is outlined on the screen. Hover one to find it.
Step 1 of 4 · Services
One tap to start a request
The address and card are set once and stay pinned, so choosing a service is the only decision on the screen.
Each service is a single card, and the whole card is the button.
“Labor Only” is on every card, so the price is never mistaken for parts and labor.
The address and the card on file are confirmed at a glance before anything is booked.
Step 2 of 4 · Now or later
Now, or another day for less
Picking a service opens the map, with the nearest pro’s route already drawn and two prices to choose from.
The nearest pro’s photo and drive time show before anything is booked.
Later is the lower price, and it becomes a booking on a pro’s schedule.
Now sends a live offer to nearby pros: the ten-second offer in the pro app.
Step 3 of 4 · Booked
Every booking lives under its car
Bookings sit under the car they’re for, so a household with two cars can see at a glance which one is booked.
Confirmed sits above the card, so the status is read before the details.
The date, a one-hour window and the pro’s name and photo: who’s coming, and when.
Chat belongs to the booking, the same thread the pro sees on their job card.
Step 4 of 4 · Wrap-up
Rate, tip, done
When the job is finished, rating the pro and tipping share one screen, with nothing to type.
Three ratings instead of one, so feedback points at something specific: friendliness, neatness or communication.
Tips are preset amounts, one tap each, and $0 is a choice like any other.
One OK sends the ratings and the tip together.
Both apps
One job, two apps
The customer app is one half of the marketplace. Every step here is answered by a step in the pro app, and I built both sides of each hand-off.
Customer appPro app
Customer: Taps Now for a service today.
Pro: Gets a live offer, with ten seconds to accept.
Customer: Books another day, for less.
Pro: Finds it in scheduled jobs, ahead of on-demand work.
Customer: Sees who’s coming, and a live drive time.
Pro: Shares precise location only while en route.
Customer: Messages from the booking.
Pro: Replies from the same job card.
Customer: Rates the pro and tips in one pass.
Pro: Rates the customer, and stays online.
Shipped
Shipped alongside the pro app
The customer app shipped on the App Store as Helpros, alongside Helpros for PROS. Its listing shows the three moments the app was built around: booking, rating and tracking.
The App Store listing, with the screenshots it shipped with.
BookingServices, the Now or Later choice, and bookings kept under each car.
Live mapNearby pros, the route, and a drive time that updates as the pro moves.
NotificationsA push when the pro arrives, and another when the service is complete.
ShippingBuilds and releases, in step with the pro app and the backend.
Want to go deeper?
I’m happy to walk through how the two apps fit together, and the code behind them.
I designed and built Swivel Partner, the company side of Swivel. Inspection companies say what they inspect, what they charge and when their people are free, and agents book straight into that, instead of calling around during escrow.
Role
iOS Engineer & Designer. I designed the company app and built it: onboarding, the pricing model, scheduling, and the booking flow the agent side hands off to.
A company prices each service once, by property type and size. Every quote an agent sees after that comes out of their own model.
A calendar agents can book into
People, shifts, and the inspections each person is qualified for. What stays open is what an agent gets offered.
Booked, paid, closed
A request arrives by push and holds the slot until it’s answered. Stripe invoices the buyer or the agent, and an unpaid job comes off the calendar.
Walkthrough
Setup to first booking
Six screens, from an empty account to a job on the calendar. Every numbered detail is outlined on the screen. Hover one to find it.
Step 1 of 6 · Services
Say what you inspect
Nine inspection types, and a company ticks the ones it does. That list decides everything an agent can ask them for.
Each service is one row with its own mark, so a long list still reads fast.
Anything left unticked never reaches this company as a request.
One tap out of onboarding, with the choice already saved.
Step 2 of 6 · Service area
Draw the area you cover
Inspectors travel, but not everywhere. The area is an address and a number of miles, not a shape to draw.
The address the company works out of, typed once.
The radius redraws on the map as it changes, so the number means something.
Miles step up and down, which is quicker than dragging a pin.
Step 3 of 6 · Pricing
Price it once, quote it forever
Pricing is per service, then by property type and size. After this, an agent’s quote is a lookup rather than a phone call.
The day stays empty until there is pricing, because a slot with no price can’t be booked.
The trade in one line: the company sets the prices, Swivel runs the billing.
Straight into the model: per service, per property type, per size bracket.
Step 4 of 6 · People
Put your people on the calendar
A company is rarely one person. Each employee gets their own hours and their own set of inspections.
A shift is a start and an end, set per person, per day.
Each person carries what they’re qualified for, so a request only reaches someone who can do it.
One button writes the shift onto the day.
Step 5 of 6 · The request
A request lands on the day
When an agent books, the slot is held straight away and the company hears about it on their phone.
The push carries the service and the address, so it can be judged from the lock screen.
The day is a timeline per person, and the held slot is already on it.
Beds, baths, lot and square footage come from the agent’s side, so nobody accepts blind.
Confirm keeps the slot. Decline hands it back, and the agent is offered another.
Step 6 of 6 · The booking
Accept, and billing takes over
The booking holds everything the job needs: the property, who is doing it, what it costs, and whether it has been paid.
The employee on the job, taken from the schedule that was set in step four.
Price and payment state sit together, so an unpaid job is obvious before the date.
Accepting here is the same decision as the push, for whoever opens the app later.
End to end
How a booking gets made
The company app is one half of Swivel. Agents work in the other one, and what they book is priced and scheduled from what companies set up here.
Agent
A property, by address
An agent adds the property they’re selling. Public records fill in the type, the size, the systems and the rooms, so nothing has to be typed twice.
Swivel
A price and a slot
Each company’s pricing model turns the property into a quote, and their calendar turns the day into times. The agent picks from real prices and real openings.
Request
The slot is held
Booking writes the appointment onto the company’s day and pushes it to them. Nothing double books while they decide.
Company
Accept or decline
Accepting confirms the job. Declining releases the slot and sends the agent back another option, without a call.
Stripe
The invoice goes out
Payment is an invoice to whoever is covering it, the buyer or the agent, and the company is told when it clears.
Rule
Unpaid, and it comes off the calendar
An inspection that isn’t paid before its date is cancelled, so a slot is only ever held for work that is actually happening.
Shipped
Shipped on the App Store
Swivel Partner shipped as the company half of Swivel. Its App Store previews run the same path as the walkthrough above: choose services, set pricing, then watch the bookings arrive.
The App Store previews, with the captions they shipped with.
Want to go deeper?
I’m happy to walk through the pricing model, the scheduling, or how the two sides hand off.
I designed and built Swivel, the app agents use to get a property’s inspections booked during escrow. They type an address, the property fills itself in from records, and every inspection comes back with a price and a time from a real company’s calendar.
Role
iOS Engineer & Designer. I designed and built the agent app next to the company app, so one booking reads the same from both sides.
An address is enough. Records bring back the type, the size, the systems and the photos, and the agent only corrects what’s wrong.
Real prices, real openings
Every slot carries a company, a time and a price that came from their own pricing model, so what an agent picks is already bookable.
One property, one schedule
Every inspection on a deal sits on the property, with the buyer’s number and what is still unpaid.
Walkthrough
An address to a booked week
Four screens, from typing a street name to a property with its inspections on the calendar. Every numbered detail is outlined on the screen. Hover one to find it.
Step 1 of 4 · The address
Start with a street name
An agent types the address they’re selling. The app goes and finds the property before asking anything else.
One field, one job. Nothing about the house is typed by hand.
Who the inspections are for decides who the invoice goes to later.
A transaction is the common case, so it gets the solid button.
Step 2 of 4 · The property
Pick what the deal needs
The property comes back with its own photos and numbers, and the inspections sit right underneath it.
Address and photos from records, so it’s obvious this is the right house.
Beds, baths, lot and square footage: the numbers every price is based on.
Nine inspection types, and a deal usually needs several at once.
Step 3 of 4 · Times
Pick times with prices attached
This is the screen the whole product exists for. Each inspection gets its own days and its own openings, from the companies that cover this address.
Each inspection has its own row of days, because they rarely land on the same one.
A slot is a company, a time and a rating, already free on their calendar.
The price comes out of that company’s pricing model for this property.
Step 4 of 4 · The deal
Everything sits on the property
After booking, the property is the file: who is coming, when, and who to call about it.
One card per deal, with the photo and size an agent recognises it by.
The buyer is one tap away, since they’re often the one paying.
A date range and a count, so a week reads at a glance.
Every inspection shows the company that took it, once they’ve confirmed.
Both apps
Two apps, one booking
Swivel only works because the other side is already set up. Every choice an agent makes here is answered by something a company published in Swivel Partner.
Agent appCompany app
Agent: Picks the inspections a deal needs.
Company: Only shows up for the services it offers.
Agent: Sees a price on every slot.
Company: Set that price once, by property type and size.
Agent: Picks a day and a time.
Company: Published those hours as an employee’s shift.
Agent: Books, and the slot is held.
Company: Gets a push, and accepts or declines.
Agent: Pays, or sends the invoice to the buyer.
Company: Is told when it clears, through Stripe.
Want to go deeper?
I’m happy to walk through the property lookup, the scheduling, or the company app it books into.
Pressr gives an athlete a public profile with a press room behind it. Anyone can record a question on that profile, and put money behind it. The athlete picks which ones to answer, records them as one voice-guided press conference, and the money on a question is released when it gets answered.
Role
Sr. iOS Engineer. Shipped as MEedia, now Pressr, and still on the App Store.
Anyone can ask through an athlete’s profile, and attach money to the question. Answering it is what releases the payment.
Run by voice, not by hands
“First question” puts one on screen and reads it out. The athlete answers. “Next question” moves on, so a whole pressr is recorded without touching the phone.
Finished like a broadcast
Backdrop, mic, podium, lower thirds and a chiron, then it renders with the asker’s own video in the corner, the way a reporter appears on a feed.
End to end
How a pressr gets made
A press conference an athlete can hold whenever they want, out of questions that arrived while they were asleep.
Screen neededStart Pressr, mid-recording, with the voice prompt on screen
Screen neededEarnings, after a paid question is answered
Step 1 of 6 · The portal
Someone asks
A fan, a scout or a recruiter records a video question on the athlete’s public profile. They can attach money to it, or just send it.
Step 2 of 6 · The queue
Questions pile up
Everything lands in the app, paid and unpaid together, waiting for the athlete to be in the mood to talk. They pick the ones worth answering and hit Start Pressr.
Screen neededStart Pressr, mid-recording, with the voice prompt on screen
Step 3 of 6 · On the mic
Voice runs the room
“First question” puts one on screen and reads it aloud, the athlete answers, “next question” moves on. The phone stays on its stand the whole time.
Step 4 of 6 · The look
Dress the set
Backdrop, mic, podium, lower thirds and a chiron, all chosen at the end, so every pressr comes out looking like the same show.
Step 5 of 6 · Render
The asker appears in the corner
As each answer renders, the question’s own video drops into the top right, then clears, so you see who asked and the athlete answering them.
Screen neededEarnings, after a paid question is answered
Step 6 of 6 · Payout
Answering is what pays
Money attached to a question is released once it is answered, and Stripe moves it to the athlete’s bank.
An older demo from the MEedia days: the raw recording on the left, the finished pressr on the right, backdrop and chiron included.
Beyond the press room
The rest of an athlete’s case
A pressr is the loud part. The profile behind it is what a recruiter actually reads, so the app carries the evidence too.
Stats
Season numbers kept on the profile, managed from the app rather than retyped into a message thread.
Highlights
Game film and training clips uploaded straight from the phone, so the gallery on the public page stays current.
The public page
Bio, measurables, highlights, team and schedule on one link, which is the thing a recruiter actually opens.
Pressr Combine
Numbers the phone can vouch for
Recruiting runs on self-reported numbers. The Combine measures them with the phone instead and flags the result as verified, so a coach knows where the figure came from. Push-ups are the metric that ships today; the vertical and the 40 run through the same scanner.
It watches joints
The front camera runs Vision body pose on every frame, with depth from the TrueDepth camera alongside it, so the app is tracking a skeleton rather than pixels.
It calibrates first
Before counting starts, it checks you are genuinely in a plank, using the depth gap between hips and shoulders, then learns your own top and bottom elbow angles.
It counts honestly
A rep is a state machine with hysteresis and a dwell time, not a single threshold. Anything short of your calibrated depth still counts, but is recorded as a partial.
It coaches mid-set
Framing hints when you drift out of frame, tones at the top and bottom of each rep, and a haptic on every count, so nobody has to watch the screen while they work.
The app
Five screens, in its own words
These are the App Store previews the app ships with today. They cover the whole loop: record a pressr, take questions from fans, customise how it looks, and publish it to a profile.
The current App Store previews, in order.
Shipped
Ten years on the App Store
Pressr first shipped in July 2015 as MEedia and is still being updated: version 3.1.0 landed in June 2026, adding stats management, highlight uploads and team mode. It is the one project on this page you can still download.
Store
LiveFree, iOS 15 and up
Rating
4.5 out of 516 ratings
First release
July 2015As MEedia
Latest
3.1.0June 2026
The profiles it publishes are public, so the output is easy to check: pressr.app/_genecastillo is an athlete, and pressr.app/sacroar is a club, with its roster and season.
Want to go deeper?
I’m happy to walk through the recorder, the overlays, or how a pressr gets published.
Vookie is a sportsbook where you never stake a cent. Watching a rewarded ad earns a free bet, you put it on a real line, and what it wins buys raffle tickets for real prizes. Four steps, and no money goes in at any of them.
Role
iOS Engineer & Designer. Rewarded ads into credits, the board, the bet slip, live tracking and the raffle draw.
A rewarded ad is how credits arrive, which makes the ad the business model rather than a tax on the user. Nobody is ever asked for a card.
Real lines, real board
Spread, moneyline and total across every league, laid out the way a sportsbook does it, with creators’ picks and an activity feed running beside it.
Winnings buy real prizes
Winnings turn into raffle tickets for real things: game tickets, gear, gift cards. The draw happens in the app, in front of everyone who entered.
The model
Free bets in, real prizes out
The whole product is one loop, and a user never puts money into it.
Watch
An ad pays for the bet
A rewarded ad hands back credits. That is where every stake comes from, which means the advertiser funds the action rather than the user.
Bet
Real lines, free stake
Those credits go on the actual board: spread, moneyline or total, as a single or a parlay, priced like any sportsbook.
Win
Winnings become tickets
A winning slip pays out more credits, and credits buy entries into the raffles running in the app.
Prize
The prizes are real
Game tickets, sneakers, gift cards. The draw happens in the app with everyone who entered watching, so the payoff is something you can hold.
Walkthrough
A night on Vookie
Five screens, from an ad that pays for a bet to a raffle being drawn. These are the App Store previews the app shipped with.
Step 1 of 5 · The feed
Start with someone's read
Home is people, not fixtures: podcast clips and picks from creators, with an activity feed of what everyone else is betting, watching and entering. The rewarded ads live here too, and each one is another free bet.
Step 2 of 5 · The board
Read the card
Every league on one board, with spread, moneyline and total per game, and the same layout a sportsbook uses so nobody has to learn it twice.
Step 3 of 5 · The slip
Build it in credits
Singles or a parlay, staked with the credits those ads earned, 10 to 500 a slip, free plays applied on top, and a swipe to place rather than a button you can fat-finger.
Step 4 of 5 · The night
Watch it run
Open and closed bets sit against live scores, so a slip is something you follow through the evening rather than check once in the morning.
Step 5 of 5 · The payoff
Spend what you won
This is where free money becomes a real thing: winnings buy raffle tickets, each raffle with a countdown and an entry cap, and the draw plays out in the app. That is the clip here.
Social
Every bet is a post
A slip, a picks list or a raffle result renders as a branded card, sized for a story, with the App Store badge already on it. Sharing it is one tap into Instagram, and that card was how new users found the app.
Picks, a raffle result, and the card landing in an Instagram story.
Shipped
On the App Store as Vookie Sports App
Vookie shipped on the App Store under Vookie LLC, rated 17+ in Sports, with the five previews above on its listing. It reached version 1.51.0, and this is the listing as it stood.
The listing as it stood at version 1.51.0.
Rating
4.9 out of 543 ratings
Category
SportsRated 17+
Developer
Vookie LLCSacramento
Version
1.51.049.7 MB
Want to go deeper?
I’m happy to walk through the feed, the slip, or how the raffle draw was built.
Typpo turns words into video. Speak, drop in audio or paste a script, and it transcribes the words, times them, and animates them into a finished piece: type, effects, 3D, all rendered on the phone. I lead engineering on it, reporting to the CTO.
Role
Lead Engineer, reporting to the CTO. The current one, and still shipping: 2.0.9 went out in September 2026.
Talk to the camera and captions and graphics animate as you speak, or hand it a podcast, a voice note or a pasted script and it does the same.
Rendered on the phone
Metal effects, a SceneKit 3D animator and Lottie motion, composed with AVFoundation into a file that is ready to post, with no server render in the loop.
Built for people who ship a lot
Templates you can make your own, folders, tags, statuses and a Kanban board, because the people using this post every week, not once.
Engineering
Features I lead development for
Each one is shown by the ad I cut for it. The caption is the engineering underneath, not the pitch. The clips play as you reach them.
Metal effectsA Metal shader pipeline: nine effects previewed live and rendered into the AVFoundation export, with no server in the loop.3D animatorSceneKit: type set on 3D geometry with a scripted camera, rendered into the composition on the device.3D shot animatorA single product still turned into a camera move, keyframed in SceneKit and rendered on the device.Transcript timingSpeech returns per-word timestamps; the timeline binds each word’s motion to the moment it was said.Scene swapLayout and content are separate in a template, so a scene is a swappable asset and the type, timing and motion carry over.Template dropsTemplates are data, authored in Template Studio and delivered to the app without a release.Font switcherSwap the typeface and the layout reflows around the new metrics instead of breaking.Custom export sizeCompositions are resolution independent, so one edit exports at whatever size a channel needs.Window resizeOne layout code path serves iPhone, iPad and Mac, and it responds to the window live.
iPad and Mac
The same app, desktop class
Typpo is designed for iPad and runs as the same build on Apple silicon Macs, macOS 14.6 and up. One codebase, one layout system, three screen sizes. These are the six iPad screenshots on the listing.
The iPad and Mac listing, in order.
Under the hood
What a lead actually owns here
A video editor on a phone is a render pipeline first and an app second. The interesting work is in keeping that pipeline fast, predictable and testable while a team ships into it every week.
The pipeline
Transcription and word timing from Speech, type and motion laid out on a timeline, Metal effects and SceneKit scenes rendered into an AVFoundation composition, then exported at whatever size the post needs.
The architecture
MVVM with a state, store and reducer per feature, dependencies injected, and a navigator and factory for every route, so a screen can be built and tested without the rest of the app.
The release train
Dev, QA, Beta and Prod schemes, Fastlane for builds and tests, SwiftFormat before every commit, SSL pinning on the network layer, and a credit system that gets audited.
Template Studio
A second iOS app, for authoring templates: preview groups, check every font, debug the type, and export the template data the main app consumes.
The ad system
The ads are code too
Every ad on this page, moving or still, is rendered from code: real screen recordings dropped into compositions written in TypeScript, so a new feature gets an ad the same week it ships.
Two of the stills, rendered from the same project as the videos.
Shipped
On the App Store, and still moving
Typpo went up in April 2023 and has kept going: version 2.0.9 shipped in September 2026, with custom templates, prompt-to-animation and a Kanban board for projects. It is the one on this page I am working on right now.
Store
LiveFree, iOS 17.6 and up
Rating
4.6out of 5 on the App Store
First release
April 2023BeatPitch Inc.
Latest
2.0.9September 2026
Want to go deeper?
I’m happy to walk through the pipeline, the template system, or how the team works.
A model that tells punch types apart, trained with Create ML and running on the device with Core ML. No server, no round trip: the phone decides in the moment the punch lands.
What it is
Side work, outside the day job. The point was to take a model from raw recordings to an on-device classifier end to end, and see how far Apple’s own tooling goes before you need anything else.
Stack
Create MLCore MLSwift
Trained, not hand-tuned
Punch types are close cousins in the data. A trained classifier separates them better than any set of thresholds I could write by hand.
Runs where the punch happens
The exported model ships inside the app and runs on the Neural Engine, so classification is immediate and works with no signal.
A short loop
Record, label, train, check the confusion matrix, export, try it. Create ML makes that loop minutes long, which is what makes it fun.
The loop
From recordings to a model on the phone
Record
Capture real punches
Sessions recorded as they happen, each one a labelled example of a punch type.
Label
Name what each one was
The training set is only as good as its labels, so this is the slow, honest part.
Train
Create ML does the heavy lifting
Pick the classifier, point it at the data, and read the confusion matrix to see which types it still mixes up.
Ship
Export and run with Core ML
The model goes into the app as a file. Core ML runs it on the device, and the app reacts to the result as the punch lands.
Results
Six punches, called as they land
Create ML replays a session on the left and calls each punch as it lands. On the right, what the model is actually looking at.
Create ML’s Preview tab replaying a session. The wireframe is the pose it reads; the label is its call, with a confidence.
What the model reads
Body pose, not pixels
Vision finds the joints in every camera frame. A short window of those points, not the video itself, goes to the classifier, so the room, the light and the clothes don’t matter.
Relay is a library of single-purpose tools that run on the phone: cut a subject out of a photo, blur or swap a background, caption a video, pull the text or the numbers out of a file. Run one, and it suggests the next. Save the chain, and that chain is a Relay you can run again on anything.
Status
A personal project, in progress, not on the App Store yet. Designed and built by me, evenings and weekends.
Drop in a photo, a video, an audio clip or a file, run a single-purpose tool, then chain the next. When one finishes, the app suggests what is natural to do after it.
Nothing leaves the phone
Every tool runs on the device: Apple Intelligence for the language work, Vision for the masks, on-device speech for captions. Cloud tools exist, and a private mode keeps them locked.
Chains you can keep
A saved chain is a Relay. It runs again with one tap, on new content, from the app, from the share sheet, or from a Shortcut.
Onboarding
The three screens you see first
The app explains itself in three steps. These are those steps, in its words, with its art redrawn for the page.
Remove BGCaptionsAdd OutlineColor WashReplace BG
Step 1
A library of focused tools.
Every tool does one thing, and does it well. No menus, no toolbars, no clutter to wade through.
Remove BackgroundAdd OutlineCaptions✓ Saved as Relay
Step 2
Chain them into a Relay.
When one tool finishes, we suggest what’s natural next. Save the chain and replay it forever.
Portrait Cleanup3 stepsRun
Step 3
Run it again with one tap.
Your saved Relays sit at the top of the app, ready to rerun on a new file. The same five-step edit you used to do by hand, now one tap.
Pre-built relays
Chains that ship with the app
Each one is a few tools in a row, saved. The names are the app’s own.
What’s it worth?
Snap a photo, see what to pay and what to sell for.
Lost Pet Flyer
Turn your pet’s photo into a high-contrast MISSING poster.
Find a Dupe
Photograph a pricey find, get affordable lookalikes.
Extract a Recipe
Paste a social link, get a clean recipe card to cook from.
Screenshot to Event
A flyer, a text, a booking. One tap and it’s on your calendar.
Card to Contact
Snap a business card or an email signature. It lands in Contacts.
List to Reminders
A handwritten list, a whiteboard, a text. Every item becomes a reminder.
Teach Me This
Snap a homework problem. Get a slideshow that teaches the concept.
The toolbox
Small tools, built to be chained
Every tool takes one input and does one thing, so any output can feed the next tool in line.
Apple Intelligence through the Foundation Models framework for the reading, extracting and summarising, with MLX as a second engine for local models when a task wants one.
Vision
Foreground instance masks and person segmentation from Vision drive the cut-outs, blurs and replacements, frame by frame for video.
Speech
Captions and transcripts come from the on-device speech analyzer, then get burned into the video with AVFoundation.
Everywhere you are
A share extension and App Intents mean a Relay runs from the share sheet, from Shortcuts, or on whatever is on the clipboard.
Want in early?
Relay isn’t out yet. If you’d like to try a build before it is, say so.
Currently on a team
Open to consulting
