Modernize an old Swift example
A practical approach to examples written for early Swift versions.
Read the intent first
Before changing syntax, identify what the example proves. A small optional-binding demonstration needs less migration work than an old UI controller with framework changes. Keep a tiny expected result you can compare after each change.
Separate syntax from API changes
Early Swift used names such as println and older forms of optional binding and collection APIs. A rename can solve a compiler error, but framework behavior may have changed too. Read compiler diagnostics and consult the current API documentation.
Treat concurrency as a design change
Adding async, await, or an actor annotation is not just a mechanical syntax update. Consider isolation, values crossing concurrency boundaries, and cancellation. Fix warnings by understanding data ownership rather than suppressing checks.
Build a minimal reproduction
Remove unrelated code, choose a supported compiler, and preserve the failing input. Online playgrounds are useful for pure language behavior; move to a platform project when the question depends on an Apple framework.