A few days ago, I routinely ran brew upgrade after typing brew update. To my surprise, the terminal displayed something I’d never seen before—numerous packages downloading in parallel, neatly arranged and progressing simultaneously. After a moment of astonishment, I learned from the news: Homebrew had released version 5.0.
This update brings substantial enhancements. Beyond enabling parallel downloads by default, it officially promotes ARM64/AArch64 devices—including Raspberry Pi, ARM mini PCs, and WSL2 on Windows ARM—to Tier 1 support, while adding various new commands and capabilities. Most notably, the official support for local MCP (Model Context Protocol) services stands out. Through brew mcp-server, developers can enable AI agents to operate Homebrew automatically, seamlessly integrating brew into the emerging AI workflow. This is truly a forward-thinking update.
However, not all of the news is equally encouraging. With macOS Tahoe 26 very likely to be the last version supporting Intel x86_64, Homebrew has adjusted its own support strategy accordingly: starting in September 2026, Intel Macs will be downgraded to Tier 3, and by September 2027 (or later), support for Intel may end entirely.
Undeniably, over the past decade, Intel architecture brought Apple a vast pool of “potential users”—its ability to run Windows natively attracted many users outside the Mac ecosystem to choose Apple devices for compatibility reasons, providing crucial support for Apple’s market share. Now, with Apple Silicon’s maturity, Intel Macs are destined to join the MOS 6502 and PowerPC as important chapters in Apple’s hardware history, gradually drawing to a close in the near future.
Looking back, every major CPU transition has sparked a wave of design innovation at Apple, giving rise to iconic products that defined their eras—from the Lisa pioneering graphical interfaces in the 68k era, to the translucent aesthetics and colorful clamshell iBooks of the PowerPC era, and later the white and black MacBooks and the game-changing MacBook Air of the Intel era.
In the age of the M-series chips, Apple has achieved remarkable leaps in performance, efficiency, and system integration, yet in terms of hardware appearance and industrial design language, we have not yet seen a breakthrough with a truly lasting, era-defining impact.
I hope the next design worthy of the history books arrives soon. Don’t keep us waiting too long.
Recent Recommendations
Grow on iOS 26: Liquid Glass Adaptation in UIKit + SwiftUI Hybrid Architecture
Grow is a health management app that has received App Store editorial features in 173 countries and regions, with over 180,000 five-star reviews. When adapting to iOS 26’s Liquid Glass design language, the team encountered numerous challenges: How to achieve native morph effects in a UIKit + SwiftUI hybrid architecture? How to precisely control Scroll Edge Effects? How to handle dynamic sizing of custom navigation bar elements? Shuhari, one of Grow’s developers, shares the team’s practical experience from this adaptation process. The article covers transformation solutions for Sheet, Navigation, Popover scenarios, diving deep into implementation details like UIBarButtonItem size calculations and CABackdropLayer side-effect handling, while also demonstrating how to create “glass text” effects using Core Text. All core concepts come with complete demo projects.
Pitfalls of Parameterized Tests
Parameterized Tests are a distinctive new feature in Swift Testing, enabling developers to expand test coverage while minimizing code duplication, easily verifying multiple input sets for the same logic. However, Alex Ozun discovered during large-scale migration that while convenient, this feature harbors easily overlooked pitfalls that can quietly reduce test effectiveness. The article demonstrates common traps through multiple examples and provides practical recommendations such as avoiding test parameter reuse on both sides of #expect expressions and clearly distinguishing between example-based and property-based tests.
Task Identity
In SwiftUI, task / onAppear execute once when a view “appears,” but unlike views, they don’t automatically track dependencies—if a task closure depends on some state, the task itself won’t automatically re-trigger when that state changes. Chris Eidhof demonstrates this easily overlooked issue using remote image loading as an example, recommending explicitly specifying task “identity,” such as using .task(id: url), allowing relevant dependencies (like URLs or composite identifiers formed from multiple values) to participate in task re-execution conditions, enabling SwiftUI to cancel old tasks and start new ones when dependencies update. The author reminds that whenever using task / onAppear in views, ensure relevant dependencies are reflected in the task’s identity.
One Swift mistake everyone should stop making today
Swift has been around for ten years, but many Swift APIs used in daily development are still just simple wrappers around Objective-C APIs, which can lead to easily overlooked serious issues. Paul Hudson demonstrates this with replacingOccurrences(of:with:): when handling characters composed of multiple Unicode scalars (like flag emojis), this method can incorrectly “split” characters and match non-existent sequences, producing completely wrong results. Paul’s advice is simple: prioritize using Swift’s native replacing(_:with:), which correctly handles Unicode by character semantics, avoiding these bizarre and hard-to-debug string errors.
With Foundation’s reconstruction in the Swift community complete, on platforms like macOS, for APIs with similar functionality, prioritize the Swift native versions provided in the new Foundation. This not only avoids the above issues but also prepares for cross-platform compatibility.
Learning About Swift Concurrency (from Matt Massicotte’s Blog) with a Zettelkasten
Swift’s concurrency evolution hasn’t been smooth sailing. After introducing the Approachable Concurrency concept, different compilation option combinations can even produce completely different compilation results, with understanding costs rising accordingly. Christian Tietze initially planned a brief demonstration: showing how to use the Zettelkasten method to digest Matt Massicotte’s blog posts about Swift concurrency, but kept encountering deeper complexities during practice—for example, actors cannot directly satisfy Sendable protocols with nonisolated requirements unless members are explicitly marked as nonisolated or nonisolated(unsafe). By the time he came to his senses, the video had reached 80 minutes.
The video excellently presents the true nature of “deep technical learning”: not linear knowledge accumulation, but full of confusion, hypotheses, and open questions to be verified later with code and documentation. It also demonstrates that the Zettelkasten method is particularly suited for complex, continuously evolving topics like Swift concurrency, building searchable, linkable note networks that support understanding’s gradual convergence over time.
Claude Code Skills: Features and Usage Experience
Ein Verne introduces Claude’s newly launched Skills mechanism—a modular system for extending Claude’s capabilities. Compared to MCP, Slash Commands, and traditional plugins, Skills emphasize composability, portability, and context-window-friendly usage. Each Skill exists as an independent folder containing name, description, operation instructions (SKILL.md), executable scripts, reference documents, and resource files. Claude automatically scans and matches appropriate skills when executing tasks, loading details on-demand through “Progressive Disclosure,” significantly reducing context consumption. The author believes Skills essentially evolve “prompt engineering” into “workflow engineering,” moving Claude from a general intelligent assistant toward maintainable intelligent infrastructure.
Multiplatform with Rust on iOS
Just as many Swift developers hope to bring their code outside the Apple ecosystem, iOS itself maintains considerable openness to other programming languages. Tjeerd in ‘t Veen shares a detailed Rust + iOS integration guide in this article, demonstrating how to elegantly integrate Rust code into iOS projects through Mozilla’s UniFFI. UniFFI can automatically map Rust enums to Swift enums and convert function names from snake_case to camelCase, making Rust modules look like native APIs on the Swift side.
The article provides a complete, actionable workflow: from creating Rust libraries, building static libraries for multiple iOS architectures, packaging XCFrameworks, to finally wrapping them as Swift Packages, with detailed explanations and common pitfall warnings for each step. This solution not only allows iOS projects to consume Rust logic like regular Swift packages but also lays a solid foundation for reusing the same Rust code on Android and other platforms.
Tools
VisualDiffer 2: Rebirth from Objective-C to Swift
Davide Ficano has completely open-sourced his long-running macOS file comparison tool VisualDiffer and thoroughly rewritten it from Objective-C to Swift. This isn’t a simple language migration or AI-assisted conversion, but a from-scratch manual refactor.
Core features remain unchanged:
- 🟩 Intuitive Comparison - Side-by-side directory differences with color-coded new, modified, or missing files
- 🧩 Deep Analysis - File-level line-by-line comparison (based on UNIX diff)
- 🧹 Smart Filtering - Automatically exclude version control files (.git, .svn) and system files (.DS_Store)
- ⚡ Performance Optimization - Multiple comparison strategies from fast date/size comparison to precise byte-by-byte comparison
On Reddit, the author admits still greatly appreciating Objective-C, but Swift’s potential made him willing to bear the huge migration cost. Rewriting the UI layer (especially NSTableView and delegate patterns) was particularly challenging, initially filled with concurrency attribute annotations, but as understanding deepened, Swift’s advantages gradually became apparent.
FSWatcher: High-Performance Swift Native File System Monitoring Library
okooo5km developed FSWatcher while creating the image compression tool Zipic, needing real-time awareness of image file changes for timely processing. This is a file system monitoring library based on macOS/iOS’s underlying kqueue mechanism, using event-driven rather than polling approaches with minimal resource consumption.
Core features:
- 🎯 Smart Filtering: Supports multi-dimensional filtering by file type, size, modification time, with chainable combinations
- 🔍 Predictive Ignoring: Automatically identifies and skips self-generated output files (like *_compressed.jpg), avoiding circular triggers
- 📁 Recursive Monitoring: Can monitor entire directory trees with depth limits and exclusion rules
- ⚡ Modern API: Full support for Combine, async/await, and traditional closure callback patterns
The library is ideal as a listener for image processing pipelines, hot reload components for development tools, or building lightweight automatic backup systems and other scenarios requiring real-time file change awareness.
SFSymbolKit: Zero-Maintenance Type-Safe SF Symbols Library
While there are already several libraries for improving the SF Symbols experience, LiYanan’s SFSymbolKit still stands out: all symbols and availability information are automatically generated directly from system frameworks with one command, truly requiring no manual maintenance.
Core advantages:
- ✅ Reliable Data Source: Directly reads
/System/Library/PrivateFrameworks/SFSymbols.framework/, 100% synchronized with the system - ✅ Fully Automated: Just run
./update_symbols.shto update, no manual symbol additions needed - ✅ Version Aware: Automatically generates
@availableattributes for compile-time symbol compatibility checking - ✅ User Self-Service: Anyone can update locally without depending on author releases