Last Saturday, Apple officially and permanently closed an Apple Store in Dalian, China, marking the first time the company has closed a directly-operated store in the country. The store opened in 2015, exactly ten years ago. Following the announcement, numerous online reports emerged, with some interpreting this as a signal about Apple’s business conditions in China. Since this store happens to be located in my city, I have some firsthand knowledge of the situation and would like to share a different perspective.
When the store opened in 2015, it was situated in Dalian’s most prominent commercial district. In its early days, it indeed attracted large numbers of Apple enthusiasts, and given its prime location, many tourists visiting Dalian also made it a must-visit destination, contributing positively to Apple’s brand promotion and customer service. However, with urban expansion and the restructuring of functional zones, this once-premier shopping district has been replaced by multiple emerging commercial centers over the past few years. Both foot traffic and the infrastructure of the shopping complex have declined significantly, with current visitor numbers less than one-tenth of peak levels. Within the same district, numerous international brands have also adjusted their presence or withdrawn entirely.
In fact, even when I need to visit an Apple Store now, I choose the second location Apple opened in Dalian in 2016 (situated in a more modern shopping complex). Over the past few years, my family, friends, and I have visited the old shopping district only a handful of times. Therefore, I’m actually surprised Apple waited until now to close this store. The timing coincides with the shopping complex undergoing operational restructuring due to ownership changes, making Apple’s decision to close the store a reasonable business move from an operational perspective.
There are rumors that Apple may maintain a two-store presence in Dalian, considering opening a new location in a high-end shopping complex currently under construction at a new landmark site (expected to open in 2028). I genuinely hope this plan materializes, as the new location would be close to where I live—I pass by it almost daily during my walks.
Apple currently operates over 40 official retail stores in China. While online shopping is sufficiently convenient, retail stores remain irreplaceable in terms of brand promotion, cultural dissemination, and after-sales service, particularly in providing unique emotional value for Apple enthusiasts. For a global company like Apple, adjusting store locations based on market changes—opening new stores and closing old ones—is simply routine business practice. While this Dalian closure is indeed a “first in China,” it’s more coincidence than turning point, a natural outcome of urban evolution and change.
It’s time for my annual summer break ⛱️. Blog posts will be on hiatus for the next 4-5 weeks, while Fatbobman’s Swift Weekly will continue as usual during this period.
Original
Swift 6: Sendable, @unchecked Sendable, @Sendable, sending and nonsending
Swift’s concurrency model introduces numerous keywords, some of which are similar in naming and purpose, often causing confusion among developers. This article examines several keywords related to cross-isolation domain passing in Swift concurrency: Sendable, @unchecked Sendable, @Sendable, sending, and nonsending, helping you understand their respective roles and use cases.
Recent Recommendations
@isolated(any)
Among the many keywords Swift has introduced for concurrent programming, most are rarely important for API consumers to understand in depth, but can be crucial in specific scenarios. In this article, Matt Massicotte explains one such keyword in detail — @isolated(any).
It mainly addresses the type-erasure problem encountered when working with async functions: we can’t statically determine a function’s isolation state. @isolated(any) adds a special isolation attribute to indicate whether the function is isolated to an any Actor instance or is nonisolated. For developers designing APIs that need to accept isolated functions and schedule them intelligently, this offers finer control, particularly in task scheduling and execution ordering.
Swift Observations AsyncSequence for State Changes
The Observation framework brought native, property-level observation to Swift, but from the start it lacked one crucial feature — continuous observation of properties. While this could be partially implemented by recursively calling withObservationTracking, the shift to strict concurrency in Swift has made writing continuous observation code without concurrency warnings increasingly difficult. In this article, Keith Harrison introduces a new Swift 6.2 feature: using the Observations function to observe properties of observable objects continuously and safely via an asynchronous sequence. This new API not only solves concurrency-safety issues but also fits neatly into modern Swift async programming patterns.
Unfortunately,
Observationsis strictly limited to iOS 26/macOS 26, which is disappointing for such a practical feature that deserves backward compatibility.
Introducing valkey-swift, the Swift Client for Valkey
Valkey is a high-performance key-value store, forked from Redis 7.2.4 to retain the BSD license and avoid SSPL and commercial license restrictions. Recently, Valkey released its official Swift client, valkey-swift: built with Swift Concurrency, supporting the full Valkey command set, and featuring built-in connection pooling, pipelining, clustering, and Pub/Sub. In this article, Adam Fowler provides complete usage examples and best practices to help Swift developers seamlessly integrate Valkey into their applications.
Build, Run and Debug iOS and Mac Apps in Zed instead of Xcode
With its efficient and collaboration-friendly design, Zed has attracted many developers, but its native Swift support remains limited, making it hard to cover the full development workflow for Apple platforms. In this article, Adrian Ross explains how to combine xcode-build-server and his own tool, xcede, to build, run, and debug iOS and macOS apps in Zed, making it a viable daily alternative to Xcode.
Exploring the Foundation Models Framework
At WWDC 2026, Apple introduced Foundation Models, further strengthening its position in on-device AI. In this article, Luca Palmese details how to obtain the system language model (including specialized adapters), create sessions for complete or streaming responses, use @Generable and @Guide for type-safe structured output, and implement the Tool protocol to let models call into app functionality — providing a complete example for building local chat, summarization, and classification experiences.
While Foundation Models showcase the potential of on-device AI, their relatively small parameter sizes leave some developers questioning their capabilities and possible use cases. There’s an ongoing related discussion on Reddit you can join.
Crafting SwiftUI Components for a Scalable Design System
As projects grow in complexity, developers often extend beyond SwiftUI’s native components with custom implementations. However, feature-heavy components can quickly fall into the trap of “overloaded initializers + tightly coupled layouts.” Starting from this pain point, muhammad osama demonstrates, through iterative examples, how to build components that are maintainable, extensible, and accessible — resulting in custom SwiftUI components that retain native usability while evolving gracefully within a design system.
macOS Sequoia End of Cycle Report
With macOS 26 (Tahoe) just a month away, Howard Oakley looks back at macOS Sequoia (15.x)’s year-long lifecycle, summarizing update cadence, security fixes, system size changes, and framework growth trends. In the comments, Howard reveals an intriguing fact: from Sonoma to Sequoia, macOS gained 50 public frameworks but added 708 private frameworks, highlighting Apple’s significant expansion of internal features and apps, with far less growth in third-party developer support.
Tokens are Getting More Expensive
A core assumption behind the massive funding for AI large-model companies is that training and inference costs will drop significantly over time, enabling ideal profit margins. But Ethan Ding points out a harsh reality: users always gravitate toward the highest-performing models (while low-cost older models see minimal adoption), and increases in context capacity have caused per-task token consumption to grow exponentially — making fixed-price “unlimited use” plans economically unsustainable. Using the Claude Code case, the article examines the industry’s “prisoner’s dilemma” and offers three possible escape routes.