Welcome to another issue!
I have some news for you!
I have rebranded the newsletter from "This Week in Swift" to "Those Who Swift". Not sure if everyone will like it, but I wanted some changes.
I own the domain now which will be used in the near future and I finally have X (ex-Twitter) account. Let's connect! 👋
There will be new design elements, such as a logo, banners, etc. But for now, that's all I have.
I would appreciate if you could share any ideas or thoughts you have about what we should add/remove or implement in the near future.
Now, let's dive in!
Subscribe to another newsletter I run!
3150 subscribers already! 🚀
Weekly newsletter featuring the best tools for iOS developers. Subscribe if you like @iOS developers
Sponsored Link
Swift Craft Conference in the UK
Are you motivated by the craft of writing Swift? Want to improve your productivity and the quality of your results? Want to hang out with other awesome developers with the same mindset?
Swift Craft is a brand new conference for passionate developers working on Apple platforms. Set in a UK seaside town with stunning views across the English Channel, with an incredible line up of some of the community's top speakers, delivering dozens of sessions on the latest Swift features and writing even better code - this is the inaugral event you won't want to miss!
Swift Around the Web
Comparing @Observable to ObservableObjects
In iOS 17, we’ve gained a new way to provide observable data to our SwiftUI views which is the @Observable macro.
We were using either an ObservableObject with @StateObject, @ObservedObject, or @EnvironmentObject whenever we had a reference type to observe in one of our SwiftUI views.
But with the new updates, the @Observable macro can only be applied to classes and we can observe their values with the @State or @Bindable property wrappers.
How it works:
The @Observable macro inserts a bunch of code when we compile our app and we can see the generated code with the Expand macro option by right-clicking on the macro in Xcode.
3 Ways to set up an @Observable observer to the SwiftUI views with 3 different property wrappers for 3 different purposes: @State: to cache the instance it’s applied to across view redraws. @Bindable: to create bindings to @Observable models @Environment: to add our @Observable objects to the environment where we don’t need to pass a specific key
Note:
@Observable allows users of an Observable to only be notified when a property that was accessed within something called withObservationTracking was changed.
Tips and Considerations for Using Lazy Containers in SwiftUI
This article explored some practical tips and important considerations aimed at enhancing developers’ ability to leverage SwiftUI’s lazy containers for improved app responsiveness and resource management.
Tips:
- Customize a data type that conforms to the RandomAccessCollection protocol for the incompatible data source to optimize performance and memory usage.
- Dynamically loading new data sets based on user scrolling or demand significantly enhances user experience, especially when dealing with large amounts of data.
- When we use the id Modifier on List's Lazy Loading Mechanism, it instantiates all the child views immediately even though they are not about to appear in the visible area.
- For structures with multi-layered subviews and rich states, the recommended practice is to elevate all relevant states to the top-level view, ensuring the correct maintenance of the state.
- In lazy containers, certain types of data do not immediately release the memory space they occupy unless they completely exit the lazy container view. By changing the state type, the eagerness for resource recycling can be improved.
Coding
SwiftUI Tasks Blocking the MainActor
This blog warns developers about accidentally blocking the user interface in SwiftUI with long-running tasks. Even though you use async and await, the code might still run them on the main thread if the function is isolated to the MainActor. This freezes the UI because the app can't do anything else while the task finishes.
The solution is to remove the @MainActor decoration from the long-running task function, making it run on a background thread and keeping the UI responsive. While strict concurrency checking helps with data races, it doesn't catch this specific issue.
The blog highlights the need for Xcode tools that visualize which code parts run on the main thread, allowing developers to identify and fix these UI-blocking mistakes more easily.
Apple News
New App Store, iOS, and CloudKit data analytics now available
Apple is expanding the analytics available for your apps to help you get even more insight into your business and apps’ performance.
Over 50 new reports are now available through the App Store Connect API to help you analyze your apps’ App Store and iOS performance. These reports include hundreds of new metrics that can enable you to evaluate your performance and find opportunities for improvement.
Reports are organized into categories like App Store Engagement, App Store Commerce, App Usage, Frameworks Usage, Performance, Apple Push Notifications, File Provide, etc.
Additionally, new reports are also available through the CloudKit console with data about Apple Push Notifications and File Providers.
Other Cool Stuff
Real-time with WebSockets and Swift Concurrency
This post is about sending and receiving real-time messages over a generic WebSocket connection using AsyncStream and Swift Concurrency.
Here, WebSockets is a pretty cool technology and with iOS 13 Apple even added official support for it on iOS! The easiest way to get started is to use the methods on our favorite networking API, URLSession.
They have used the URLSessionWebSocketTask instance to send and receive messages. A generic WebSocketConnection over incoming and outgoing messages is all you need.
And also uses Vapor which is used for creating web applications and also supports WebSockets to make it easy to spin up a simple WebSocket server application.
By combining these things it creates real-time app magic using WebSocket, SwiftUI, and Swift Concurrency.
Using Apple’s OpenAPI Generator to Make and Mock Network Calls in SwiftUI
With the OpenAPI generator with only a few minor modifications to our code, we can create a mock client which could help make testing easier.
- This blog explains the use of Apple's OpenAPI Generator to simplify network calls in SwiftUI.
- It generates type-safe code from OpenAPI specs, to reduce boilerplate and improve code quality.
- You can build network models and parsers with minimal code, making it easier to work with data.
- Mocking capabilities are also included for unit testing without external APIs.
- Overall, it streamlines network interactions for cleaner and more robust SwiftUI development.
Videos
SwiftData & CloudKit: See How To Add Syncing In Your Apps
Video covers:
CloudKit Basics: Briefly explain what CloudKit is (Apple's cloud storage for apps) and why you might want to use it (sync data across devices).
Setting Up: Guides you through enabling CloudKit in your Xcode project and configuring SwiftData to work with it.
Modeling Data: Explains how to structure your app's data for CloudKit (with some limitations) and how to test your setup in the simulator.
Advanced Topics: Covers viewing your CloudKit data in the dashboard, simulating different iCloud accounts for testing, fixing data issues, querying your data in CloudKit, handling potential data duplicates, and deploying your app with CloudKit enabled.
Migrations: Explains how to handle changes to your data model when using CloudKit and some potential challenges with migrations.