Staying current with Apple

Scenario. It is the second week of June. WWDC keynote drops at 10am PT. Apple announces something with @Observable, a new SwiftUI navigation API, a deprecation, and a privacy framework you have never heard of. Twitter explodes. Your team Slack lights up. Your boss asks: “Should we adopt this?”

A senior engineer has a framework for that question. A junior engineer panics. This chapter gives you the framework.

The Apple developer information diet

There is too much. You cannot read it all. The trick is curation, not consumption.

Tier 1 — must follow

Read every post. These are signal-to-noise gold.

Source	Why
Swift Evolution	Every Swift language change is proposed here first. Read the Motivation sections — they teach you why the language is the way it is.
Apple Developer News	Official Apple announcements — deprecations, App Store policy changes, deadlines. Subscribe to the RSS feed.
WWDC (June each year)	The single most important week of the year. Watch keynote + Platforms State of the Union live. Watch 5–10 deep-dive sessions in the following weeks.
Hacking with Swift by Paul Hudson	Best plain-English explanations of new features. His “What’s new in Swift X” articles are the canonical reference.
wwdcnotes.com	Community-written notes on every WWDC session. Saves you 100+ hours each year.

Tier 2 — skim weekly

Source	Why
iOS Dev Weekly by Dave Verwer	Curated weekly newsletter. The single best signal-to-time-spent ratio in iOS.
Swift Weekly Brief	Swift language and toolchain news. Lighter than iOS Dev Weekly.
Swift by Sundell by John Sundell	Articles + podcast. Strong on architecture and patterns.
SwiftLee by Antoine van der Lee	Practical, pattern-focused articles. Excellent on concurrency and SwiftUI.
Donny Wals’ blog	Deep dives on concurrency, SwiftData, Core Data, and SwiftUI internals.
Point-Free	Paid video series. The deepest content on functional Swift, TCA, and testing. Worth the subscription if you target high-end shops.

Tier 3 — bookmark, search when needed

Source	When
developer.apple.com/documentation	API reference. Search via Xcode’s documentation viewer (`Help → Developer Documentation`) — it is faster.
Apple Developer Forums	Apple engineers answer here. Search before posting.
Stack Overflow `[swift]` `[ios]` tags	Less active than it used to be, but still the answer to many tactical questions.
Mastodon iOS community	Where most ex-Twitter iOS folks landed.
Hacking with Swift forums	Beginner-friendly. Great alternative to Stack Overflow for the early phases of this book.

Senior engineers at Airbnb, Spotify, Uber, and Apple itself follow the Tier 1 sources in this order: Swift Evolution > Apple Developer News > WWDC > Hacking with Swift > wwdcnotes. Whatever else fits in their week, fits.

The signal: when you join a senior iOS team, you will be expected to know — within a week of release — what Apple announced. Not to have adopted it. To know it.

Common misconceptions

“I have to watch every WWDC session.” No. Watch the keynote, Platforms State of the Union, and the 5–10 sessions relevant to your work. The rest you read summaries of.
“I should adopt every new API the day it ships.” No. See “The adoption framework” below.
“Apple’s documentation is too sparse to be useful.” It improved dramatically with Xcode 13+ and now has rich tutorials and articles. The reflexive complaint about Apple docs is a decade out of date.

The adoption framework

When Apple announces a new API or pattern, ask these five questions in order. Stop adopting at the first No.

Does it raise the minimum deployment target above what my users have?
- If yes: defer until your minimum target matches. Most apps support iOS N-1 or N-2 (one or two major versions back).
Is the API stable, or marked beta / “to be revisited”?
- Apple sometimes ships APIs in beta in June, then significantly changes them by September. @Observable was a year-one win; NavigationStack took two cycles to stabilize.
Does it replace something I already use successfully?
- If the old API still works and the new one is just slightly nicer, defer. Migration is rarely free.
Does my team have capacity to learn it?
- A new pattern means PR reviews slow down for a month. Schedule that cost.
Will I be the one supporting it in 2 years?
- Bleeding-edge APIs you adopt today are your maintenance burden tomorrow. Be deliberate.

[!TIP] Best practice. Default behavior for a senior engineer: read every announcement on day 1; experiment in a side project within a month; adopt in production only after the API has shipped at least one further point release. This catches the cases where Apple revises the API in iOS X.1.

The Seasoned Engineer’s Take

The single hardest thing about being an iOS engineer is not Swift, not SwiftUI, not Core Data. It is Apple itself. Apple ships an enormous amount each year, deprecates aggressively, and rarely apologizes. Engineers who thrive build the meta-skill of picking what to ignore. The Tier 1 list above is short on purpose; ten years from now it will still be short, even though the specific names will rotate. The skill you are building is curation under information overload, and it is what separates a 5-year iOS engineer from a 15-year one. Build it deliberately starting today.

Interview Corner

Junior — “How do you stay up to date with iOS?”

What the interviewer is really testing. Do you have a learning habit, or did you just finish a bootcamp and call it done?

Junior answer.

“I follow Hacking with Swift and watch WWDC sessions every June. I read iOS Dev Weekly when it lands in my inbox.”

Red flag answer.

“I learn what I need when I need it.” This signals reactive, not proactive. It is true of every junior — saying it out loud is the problem.

Mid — “How do you decide whether to adopt a new Apple API in production?”

What the interviewer is really testing. Do you weigh tradeoffs, or do you chase shiny objects?

Mid answer.

“I check three things: does it require raising the minimum deployment target above where my users are? Is it the first version of the API, or has it been revised? And does it replace something that already works for me? I’ll experiment in a side project, but I don’t push to production until the API has at least one revision cycle behind it, because Apple often refines new APIs in X.1.”

Senior — “Apple announces a new framework at WWDC that overlaps with infrastructure your team already maintains. How do you handle the conversation with your team?”

What the interviewer is really testing. Can you separate technical merit from political and migration cost? Can you lead a team through a strategic decision?

Senior answer.

“First, I separate the technical evaluation from the adoption decision. The first conversation is just: what does this give us, what does it cost, in terms only of capability. I want everyone on the same factual page before we discuss whether to adopt.

Then I lay out three scenarios: do nothing, adopt incrementally for new code only, or migrate. For each I want to know the user-facing benefit, the migration cost, the testing cost, and what happens if Apple changes their mind in two years.

My default bias for first-year Apple frameworks is don’t migrate, adopt for new modules. The reason is that migration is the most expensive option and rarely visible to users, while new-module adoption gives the team hands-on experience without the all-or-nothing risk. I have seen teams burn a quarter migrating to a framework that Apple significantly revised the following year — NavigationStack is the recent example. Wait at least one full release cycle before betting the migration on it.

The thing that distinguishes this from inertia is that I do allocate time for the experimentation — usually a single engineer prototyping in a feature flag — so we are ready to migrate fast when the cost-benefit flips.“