On February 21, the Swift community officially launched its official account on Bluesky, while also posting its first message on its Mastodon account, which had been created back in 2022. On the surface, this may seem like just another typical social media update, but in reality, this decision has been under discussion and consideration within the Swift community for some time, and a series of recent events have accelerated this process.
Since the privatization of Twitter, many users have been looking for alternative platforms, with Mastodon and Bluesky emerging as the main choices. However, due to its massive user base and deeply ingrained habits, X (formerly Twitter) still maintains significant influence. If a large portion of the social circle cannot be persuaded to move to a new platform, users might miss out on important communication opportunities. This has meant that the migration to other platforms has not had a significant impact on X, but rather forced many users to spread their attention across multiple platforms to keep content synchronized and maintain interactions.
Recently, a series of actions by Elon Musk has once again prompted the community to deeply reconsider their choice of social media platforms. In last week’s blog post, Matt Massicotte strongly responded to Apple’s decision to resume advertising on the X platform: he decided to suspend providing feedback and improvement suggestions to Apple. Moreover, since the Swift community still relies on X as the sole platform for information dissemination, he also announced he would pause his participation in Swift forums and Evolution discussions. This stance was widely supported by many developers, and to some extent, it sped up the Swift community’s decision to launch accounts on Mastodon and Bluesky.
Considering Apple’s special position within the Swift community, the decision to expand social media channels at this point is a courageous one. As a mature open-source community, the Swift team has taken a pragmatic approach: neither abandoning the existing platform entirely nor sticking exclusively to one channel. By extending its reach to more platforms, the community has shown inclusivity and respect for users on different platforms.
As a newsletter editor, after each issue is published, I make sure to tag the author’s accounts on multiple platforms as a sign of respect. However, I also recognize that each developer has their preferred social platform. Therefore, I suggest content creators clearly indicate their primary platform of activity on their personal blog, so that I can better respect your choice and include your most frequently used platform account in the newsletter.
Platform migration can be an expression of attitude, symbolizing dissatisfaction with the status quo and anticipation of change, or it may simply be a fresh attempt to explore a more suitable way of communication. But we must understand that everyone has their own considerations and freedom of choice. For those who choose to stay on their original platform, we should not make judgments or accusations lightly. After all, what truly matters is not which platform we choose, but how we maintain meaningful communication on our chosen platforms and continue to contribute value to the community.
Original
From Host to Serverless: A Blog Architecture Migration Journey
In the past month and a half, I’ve made a series of adjustments to my blog, covering areas such as the publishing mechanism, code architecture, and layout design. These changes have not only enhanced the performance and user experience of the blog but also made content maintenance and updates more efficient. This article provides a brief overview of the key changes.
Recent Recommendations
How Swift’s Server Support Powers Things Cloud
Things is a well-known task management app in the Apple ecosystem, relying on Things Cloud for seamless cross-device synchronization. Previously, the service was built on Python 2 + Google App Engine—while stable, it suffered from slow response times, high resource consumption, and a lack of static typing. Over a three-year refactor, the team fully migrated to Swift + Vapor, successfully running in production for a year. This transition resulted in three times lower computing costs, better performance, and improved development efficiency. Additionally, the move allowed them to replace their C-based push notification service, simplifying the architecture. In this article, Vojtech Rylko and Werner Jainek share their migration experience, offering valuable insights into server-side Swift development.
Why You Should Keep Your Git Commits Small and Meaningful
Version control is an essential part of modern software development, and well-structured commits can greatly enhance code management and team collaboration. Ideally, each commit should serve as a logical checkpoint—even if a feature is incomplete, the code should remain compilable with a clear change objective. In this article, Donny Wals emphasizes how small and meaningful commits help developers track changes, reduce debugging costs, and make Git history a valuable resource rather than a cluttered log. He also discusses the importance of using git rebase to clean up commit history and avoid unnecessary merge commits for better readability.
As AI-powered coding tools become more prevalent, managing commit frequency and granularity presents new challenges. Finding a balance between maintaining a clear history and ensuring a smooth development workflow is something developers should consider carefully.
async let vs Task group
In Swift’s structured concurrency model, both async let and Task Group can be used for parallel task management, but they have significant differences in lifecycle and behavior. Vitaly Batrakov provides a detailed analysis of their implementations and highlights edge cases that developers may overlook. He argues that when choosing a concurrency approach, developers should not only consider the number of tasks but also take into account error-handling strategies and lifecycle management to select the most suitable implementation.
What to Test (and What Not to Test) in SwiftUI
SwiftUI’s declarative nature encourages developers to separate business logic and state management into ViewModels, but this does not mean that view behavior should go untested. In this article, Jon Reid explores the boundaries of SwiftUI view testing, focusing on key principles such as testing behavior instead of appearance, verifying UI communication, and testing UI components with logical conditions.
Although SwiftUI does not provide official unit testing tools for views, developers can use ViewInspector to directly inspect SwiftUI view internals or leverage Snapshot Testing for visual regression testing. These tools help maintain stable and maintainable SwiftUI code without adding unnecessary architectural complexity.
Creating Custom SF Symbols
SF Symbols in SwiftUI provide built-in support for variants, color modes, and animations, ensuring visual consistency across apps. If you need unique symbols while maintaining system compatibility, custom SF Symbols can be a great solution. In this article, Antonella Giugliano explains how to create custom SF Symbols by combining existing symbols, designing new ones using vector tools, and importing them into Xcode for seamless SwiftUI integration.
Modern Concurrency and Legacy Code
Swift Concurrency with async and await offers a cleaner and more maintainable approach to asynchronous programming, but many teams are still tied to callback-based legacy code, making migration difficult. In this article, Omar Elsayed presents a low-risk, efficient migration strategy that introduces modern concurrency patterns without disrupting existing functionality. By gradually adopting Swift Concurrency and leveraging Swift Macros to automate the transition, developers can upgrade their codebase while maintaining stability. This approach provides a practical solution for teams looking to transition to Swift Concurrency without compromising development speed.