Screen Time & Family Controls

Because Apple built the screen-time frameworks to stop you doing the obvious thing. The usage data a parental app wants is exactly the data Apple will not let you read directly, so it runs your reporting code in a sealed extension that has no way to phone home. Most teams design as if they can read usage in the main app, hit the wall late, and have to re-architect. Knowing the wall is there before you start is most of the value, and you only learn it by building deep into the stack and hitting it.

Third parties can get it, but you have to apply and make the case. Apple restricts it because the same powers enable stalkerware, so the review is looking for a genuine parental-control or wellbeing use. A vague pitch gets rejected. I know what Apple's reviewers need to see in that request and can frame your app so it reads as the legitimate product it is, which is harder than it sounds when the API can technically do surveillance.

Partly, and you should plan for it. Apple owns the baseline now: time limits, schedules, the family media plan framing. If your app only re-skins those, you are exposed. The apps that survive add something Apple has no reason to build: a specific interpretation of the data, a coaching layer, a niche too small for the platform. One workable angle is a reading of the raw usage Apple has no reason to ship, like turning screen-time data into a mood or wellbeing signal for a parent. Working out where your edge sits is worth doing before you build rather than after.

Partly, but it is a different track. FamilyControls is built around a family and a child account rather than a fleet of managed devices, and the entitlement story is different from MDM. If you are doing classroom or workforce management, some of this applies and some belongs in the device-management world instead. I will tell you early which side of that line your product sits on, because building the wrong one is expensive and slow to undo.

Advisory calls can happen within days. For project work, I typically need 1-2 weeks notice to clear the calendar, though I keep some buffer for urgent firefighting. Check the availability badges above for current openings.

Yes, from pre-seed to Series C and beyond. For very early teams, the advisory tier often makes more sense than project work: you get architecture guidance without committing to a large engagement before you've validated the product.

Everything: code, architecture decisions, code review, documentation, async Slack availability during working hours. No surprise add-ons. I bill for time spent working on your project, not for "thinking about it in the shower."

I'm currently in Vancouver (PST), with full overlap for North American teams. For UK and Europe, I'm online by their afternoon. For Gulf or APAC, we'd agree on overlap hours and handle the rest async. I've worked with teams from San Francisco to Dubai.