How do you think about a platform organisation and multi-year technical bets: charter, paved road, build versus buy versus Apple, sequencing and measuring success?

At organisation level the question is how a hundred engineers ship quality faster over years. A platform team is justified when several product teams solve the same problem, and its customers are those engineers: it should have a written charter (what it owns and does not), a paved road (the default, supported way to do networking, persistence, analytics, navigation, design system, build and release that is easier than going alone) rather than mandates, product management of its own roadmap (user research with consuming teams, adoption and satisfaction as metrics), clear versioning and support (Q360, Q362), and a policy for exceptions. Without these a platform becomes either an ignored library or a bottleneck that product teams route around. Keep the layering honest (Q362), and measure outcomes the business feels: lead time from merge to users, deployment frequency, change failure rate and time to restore (the delivery-performance measures many organisations track), build and test times, crash-free sessions, app size and launch budgets, and accessibility and quality gates (Q432, Q453, Q477).

Multi-year bets in the Apple ecosystem include adopting Swift 6 concurrency across a large codebase (Q204), moving from UIKit to SwiftUI feature by feature, modularising the monolith, consolidating several apps or platforms onto a shared core (Q416, multi-brand), replacing a home-grown stack with a system framework as it matures, and building the observability and quality systems that make the others safe. Treat each as a portfolio decision. Write the hypothesis and kill criteria (“if build times have not fallen by a third after two modules, we stop”), sequence by risk and dependency (see the estimation question), deliver incremental value every quarter so the bet is not an all-or-nothing wager, fund maintenance as well as new work, and keep a deliberately small number of strategic bets. Prefer system APIs for commodity capabilities because Apple maintains them for the long term, buy for undifferentiated complexity with an exit plan, and build only for real differentiation. Plan for the platform’s own calendar: each year brings new OS releases, deprecations and privacy rules, so budget a standing slice of capacity for them. The L13 signal is judgement about what not to do, the ability to align several teams on one direction without command authority, and a track record of bets that were measured and, when wrong, stopped early.