Weekly Comment
Last Saturday, a two-way switch in our living room suddenly stopped working. This would have been a mundane electrical fault, but for me, it carried a deeper significance. It was the last of the many smart switches I installed 18 years ago that still functioned, and its “retirement” marked the complete sunset of traditional smart devices in my life.
Eighteen years ago, “smart home appliances” were nothing more than a vague concept, and smart switches lacked any unified standard. As a tech enthusiast back then, I purchased dozens of Schneider ULTI series switches and controllers for my home. I fondly remember those first few months after installation, immersed in the novelty of adjusting lighting ambiances with a remote control and eagerly showcasing these “futuristic” smart living scenarios to visiting friends. However, this enthusiasm lasted only a brief period. It wasn’t that smart devices were inadequate, but I gradually realized that life could remain vibrant even without them, and manual close-range operations wouldn’t significantly inconvenience me.
Today, “smart” has become a standard descriptor for household appliances. Refrigerators, televisions, air conditioners, washing machines, water heaters—almost every device purchased in recent years boasts “smart” and “networked” capabilities. While I can understand and accept the smart features of certain devices, I can’t help but question the necessity when even kitchen appliances like range hoods and gas stoves start claiming network connectivity. Apart from a few products, I haven’t integrated all home smart devices into app control, consistently wondering: Is this truly necessary? Is “smart” really that important? Has it become an irreplaceable life requirement?
The overarching concern of excessive “smartification” has similarly extended to the process of replacing my wife’s car. Smart driving, oversized screens, and dazzling interaction modes have become the focal points of research and development for current automotive manufacturers, rapidly eroding traditional design philosophies. Now, finding a vehicle that retains sufficient physical buttons, maintains a modest screen size, and offers a driving experience aligned with human physiological sensations is becoming increasingly challenging. I’m not without worry: in a few years, the market might no longer offer models that aren’t overwhelmingly “smart.”
I am by no means a technological conservative—I’m still someone who loves learning and embraces new things. However, I’m increasingly aware that current products are trending towards ever more apparent over-”smartification”. Though this may seem like a commercial gimmick, prolonged focus on smart features could lead manufacturers to neglect core functionalities and become overly enamored with superficial, flashy features. Whenever I perceive this trend, I involuntarily reminisce about products from the pre-smart era: pure and stable, authentic and grounded.
Whether we like it or not, humanity is perhaps inevitably heading towards a comprehensively smart era. That being the case, we should provide consumers with more choices, offering products that retain traditional operation methods and cleverly conceal smart functionalities for those unwilling to be engulfed by over-smartification. Technology’s development should respect users’ diverse needs, rather than unilaterally forcing progression.
Originals
Intentional Design or Technical Flaw? The Anomaly of onChange in SwiftUI Multi-Layer Navigation
SwiftUI provides the onChange modifier, allowing developers to listen for changes in specific values within a view and execute corresponding actions when those values change. Intuitively, as long as a view is part of the currently visible branch of the view tree (active), the corresponding closure should be triggered when the observed value changes. However, in certain navigation scenarios, the onChange modifier seems to become “selectively deaf,” inexplicably remaining silent even when the observed value changes. Is this a carefully designed feature by Apple, or a long-hidden code defect? This article aims to unveil this phenomenon and provide necessary caution to developers.
After the article was published, I received feedback from developers, who pointed out that they had encountered instances of
onChangenot working in different scenarios. This further suggests that this could be a long-standing bug that has not been adequately addressed.
Recent Selections
Using AppKit in Your Mac Catalyst App
While Apple has significantly enhanced macOS native capabilities in recent versions of SwiftUI, many developers still choose to quickly migrate their apps to macOS via Catalyst. Catalyst indeed simplifies the adaptation process, but it also has a clear limitation: it cannot directly use some AppKit components that Catalyst cannot bridge. In this article, Seb Vidal demonstrates how to leverage private _UINSView and the AppKit bridging mechanism to introduce native AppKit components into a UIKit app, effectively bridging the gap in Catalyst and extending app functionality.
Calling Hidden Swift Functions
@_spi is a powerful yet lesser-known attribute in Swift. Simply put, it allows methods to be “selectively hidden,” making them unavailable via public APIs but still callable through specific methods if their signatures are known. Apple extensively uses this feature in several official frameworks (such as SwiftUI) to restrict certain functionalities to internal or specific modules. In this article, Noah Martin dives deep into how to call hidden functions in Swift frameworks and provides a detailed explanation of how to bypass Apple’s framework restrictions and use the undocumented System Programming Interface (SPI). This not only reveals how SPI works but also offers developers new ways to extend framework functionality.
EmergeTools used this technique in building SnapshotPreviews to successfully call an undocumented SwiftUI function that renders previews as images.
Working with Natural Language Framework
Apple’s Natural Language framework provides powerful tools for processing natural language in real-time. In this article, Artem Novichkov demonstrates several practical applications of the NL framework, including:
- Semantic Text Search: Using
NLEmbeddingto achieve semantic matching, enhancing the intelligence of search features. - Sentiment Analysis: Leveraging
NLTaggerto evaluate the sentiment of text, distinguishing between positive, negative, or neutral emotions. - Dynamic Background Gradients: Creating real-time visual effects with iOS’s MeshGradient technology based on sentiment scores.
macOS Tips for Programmers: Threading
When developing on macOS, thread management and priority settings are not only crucial for performance optimization but also directly affect system energy consumption and user experience. In this article, Luna Razzaghipour provides an in-depth analysis of macOS’s unique thread management mechanisms, highlighting the central role of Quality of Service (QoS) in task prioritization and resource scheduling. Luna explains how developers can take full advantage of macOS’s hardware capabilities by properly understanding QoS categories and widely using the Dispatch framework, ensuring both app performance and energy efficiency.
Dev Conversations #4: Matt Massicotte
Natan Rolnik and Matt Massicotte
As an expert in Swift concurrency models, Matt Massicotte has written several articles on the subject and contributed to the Swift 6 Migration Guide. In this interview, hosted by Natan Rolnik, Matt shares his extensive development experience and deep insights into Swift concurrent programming.
Debugging SwiftUI Layouts: Tips, Tricks, and Techniques
While SwiftUI makes building UIs fun and easy, debugging layout issues often proves to be a challenge for developers. In this article, Wesley Matlock shares a series of practical debugging techniques to help developers quickly identify and fix common layout issues in SwiftUI. Matlock points out that debugging SwiftUI layouts is not only a problem-solving process but also a great opportunity to gain a deeper understanding of the SwiftUI layout system. By skillfully utilizing visual debugging tools, Xcode’s debugging features, and layout analysis techniques, developers can optimize layouts more efficiently and create higher-quality user interfaces.
Event
Advent of Code 2024
The Advent of Code 2024 will take place from December 1st to December 25th, with a new challenge released every day, progressively increasing in difficulty. This is a fantastic opportunity to sharpen your algorithmic skills and refine your programming expertise while enjoying the satisfaction of solving engaging puzzles during the year-end season.
The Swift community warmly invites all developers to participate in this annual event. Whether you are an experienced Swift expert or a beginner just starting your coding journey, Advent of Code offers a wide range of fun and challenging problems to spark your creativity and deepen your understanding of Swift’s versatile applications. It’s also a great opportunity to connect with fellow developers in the community, share ideas, learn new techniques, and exchange solutions.
To join, visit the Swift community’s forum post for detailed participation instructions, discussions, and helpful tips. Don’t miss this chance to make your holiday season both productive and rewarding!
If you’ve never worked on a Swift project outside of Xcode, this is a great opportunity to try. With the help of the Advent of Code Starter Template, you can experience the joy of coding Swift in alternative editors and unlock new possibilities.