What I can help with

Six offers. Each one says what it covers, what you get in writing, who it is for and how it usually runs. Each one also names public work you can read before you write to me. The lengths are typical, not promises: I scope every piece after the first conversation.

Two groups have a page of their own: Apple platforms covers modernisation, SwiftUI diagnosis and the iOS 27 SDK review, and Coding agents and search quality covers the agent-ready codebase and the search-quality audit.

• 1. Agent-ready Swift codebase

  Scope. I look at how your team works with AI coding assistants today, and at what your repository tells an assistant before it writes a line. Then I set up four things with the team. Written rules: what is forbidden, and what must be verified before a change counts as done. Skills: step-by-step instructions for the tasks your team repeats. An MCP setup, so the assistant reads current documentation and does not guess an API. Verification: hooks and CI gates for everything a machine can decide, each one with a case it must reject, because a gate that has never failed proves nothing. What a machine cannot decide becomes a review practice for the people.

  What you get in writing. An audit of current practice, the rules and skills as files in your repository that the team owns, the gate scripts, and a short guide for reviewers.

  Who it is for. Engineering leads of Swift teams that use AI coding assistants, or are about to, and want the code to stay correct while more of it is written that way.

  Typical shape. A few days of audit, a half-day workshop with the team, then the written rules and the gates. Rules age, so the upkeep can continue under the monthly advisory.

  Read first. The post The rules my AI coding agent is not allowed to break, the public rules-swift and skills repositories, and Cupertino, my open-source MCP server for Apple’s developer documentation.

• 2. Search-quality audit for documentation or code retrieval

  Scope. You run a search over documentation or code, for people or for AI coding assistants, and nobody can say whether the last change made it better. I build a reference set: queries with known right answers, taken from how the search is really used. I measure where the right result ranks, compare two versions on the same queries with paired statistical tests, and set up a regression gate so a later change cannot make the ranking worse without anyone noticing. The audit is about the ranking of search results. It does not grade the text an assistant writes afterwards.

  What you get in writing. The reference set, the method, the numbers for the current state, the paired comparison where there are two versions, and a gate your build can run.

  Who it is for. Teams that maintain a documentation search, a code search, or an MCP server with a search tool.

  Typical shape. One to two weeks for the first audit, depending on whether a reference set already exists. After that, a repeat measurement when the search changes.

  Read first. How Cupertino’s search quality was measured in version 1.2.0. On 50 reference queries the right page came first 26 times in version 1.1.0 and 46 times in version 1.2.0. I measured the same set again on November 14, 2026: 48 times in version 1.5.0. The post gives the method and what the search still got wrong in version 1.2.0.

• 3. Verified modernisation

  Scope. Objective-C and UIKit code moved to Swift and SwiftUI. An app split into Swift packages with dependencies that point one way. The move to Swift 6 and strict concurrency. XCTest suites moved to Swift Testing. Each step is checked against a reference: before a part changes, tests record what it does today, and the new code has to match them.

  What you get in writing. A review with ranked findings, a plan in steps that each leave the app in a state you can ship, and for every finished step the evidence that behaviour did not change.

  Who it is for. Teams with a long-lived app that works and has become hard to change. That includes teams where an AI coding assistant does part of the conversion and someone has to show that the result behaves the same.

  Typical shape. An audit of one to two weeks, then bounded delivery: one module or one layer at a time, in your repository, through your review process.

  Read first. My NSSpain XIII talk, API-Driven Development Refactored, the post ExtremePackaging, and The SwiftUI Oracle, which shows the method of holding code to a reference in 125 differential tests.

• 4. SwiftUI rendering and performance diagnosis

  Scope. A view runs again when it should not, a screen is slow to draw, state is lost when it should survive, or an animation behaves differently on a Mac than on an iPhone. I reproduce the behaviour in a small case, measure what SwiftUI and Core Animation do, and explain the cause in terms your team can use again.

  What you get in writing. The explanation with the measurements, a fix or a recommended change, and the steps to repeat the measurement later.

  Who it is for. Teams with a SwiftUI screen that is slow, or that behaves in a way nobody on the team can explain.

  Typical shape. Half a day to three days for one problem, with a session for the team if you want one.

  Read first. SwiftUI Is One Graph, which I presented at swiftCon Berlin 2026 and Do iOS 2026, How SwiftUI Animates, and Where It Is Not Like UIKit, and The SwiftUI Oracle.

• 5. Monthly advisory

  Scope. An agreed amount of time each month. I review designs and pull requests, take part in architecture decisions, answer questions from the team, and keep the rules and gates current if I set them up.

  What you get in writing. A note for each review and each decision: what was looked at, what was decided and why, and what to check later.

  Who it is for. Teams that have their own senior engineers and want a second reader for the decisions that are hard to reverse.

  Typical shape. Monthly and rolling. It usually follows a first review or audit, so that I already know the codebase. The formats are on How I work.

• 6. iOS 27 SDK readiness review

  The rule. In its notice of September 9, 2026, Apple writes: “Starting April 2027, apps and games uploaded to App Store Connect need to meet the following minimum requirements”. The first one on the list is: “iOS and iPadOS apps must be built with the iOS 27 & iPadOS 27 SDK or later”.

  Scope. I build your app with the iOS 27 SDK and review four things that change with it.

  The scene life cycle. Apple’s iOS and iPadOS 27 release notes say: “Apps built with the latest SDK must adopt the scene-based life cycle or they fail to launch.” The migration is described in Apple’s TN3187.

  Liquid Glass without the opt-out. Apple’s documentation of the UIDesignRequiresCompatibility key says: “The system ignores this key when you build for iOS 27 or later”.

  Resizable layouts. Apple’s guide for iPhone Duo says: “Apps built with the iOS 27 SDK and later resize dynamically on iPhone Duo.” I look for hardcoded screen sizes, fixed orientations and layout that depends on the device.

  Touch on Mac, if you also ship a Mac app. Apple asks developers to get ready for Touch on Mac. Apple states no requirement and no date for it, so this part is a look ahead.

  What you get in writing. Findings ranked by what blocks the upload or the launch first, each with the place in the code, and a plan in the order to do the work.

  Who it is for. Product owners and engineering leads of apps with older UIKit code, or with layouts built for fixed screen sizes.

  Typical shape. A review of about one week. The migration itself, if you want me to do it, is a separate bounded piece of work under verified modernisation.

I also take work on OpenAPI-first networking and on MCP servers in Swift, and I give workshops and talks. That work is described on the two pages above, and the public results are on Work and on aleahim.com/speaking.