Issue #38

Hi there,
welcome to issue #38!

Modern collection views

A lot has changed in UITableView and UICollectionView APIs in the recent years. While before we would subclass UICollectionViewCell and implement UICollectionViewDataSource and UICollectionViewDelegate protocols, the modern ways look nothing like that.

Now we provide cell content using cell configurations, dequeue reusable cells using cell and supplementary registrations, use diffable data sources for safe data with animatable updates, and use compositional layouts for grids, lists and carousels. All of this is available iOS 14+.

Apple has comprehensive articles with explanations and sample code, going over these concepts and showing how they play together:

Implementing Modern Collection Views
Implementing Custom Cells Using Content Views

xcconfig files

Xcconfig files are considered an advanced feature, only reserved for larger projects. That's my impression, at least. But the idea is quite simple - we can override build settings of a target via plain text files.

When we have multiple targets with mostly same build settings, it's better to use xcconfig files for specifying the parameters that are different - the contents of .xcodeproj files are not easily trackable in source control, and using xcconfig files solves that.

How to manage build settings using Xcode configuration files | Danijela’s blog

You use Xcode build configuration files to define all sorts of useful build settings. You can open them with different text editors outside of Xcode and all properties are in plain text. It’s common to use them for managing constants across different environments.

Danijela's blog

Custom screenshot support

TIL about UIScreenshotServiceDelegate - allowing you to support custom PDF export via the native screenshot functionality. To see it an action, try taking a screenshot in Safari - there will be a segment control at the top, choosing between just the screenshot or a PDF of the whole page.

When the user captures a screenshot of your app’s windows, UIKit calls the methods of this protocol to retrieve PDF data for those windows, and then it provides that data to the user.

Dummy data for previews

To reduce app size and memory footprint of your app, make sure that the test data for SwiftUI previews is not included in release builds. You can wrap the code to exclude in #if DEBUG.
Another option is to use "development assets" - a relatively new build setting in Xcode. You can specify which files (code or assets) will be stripped during release builds. Read more: Development Assets in Xcode to enrich SwiftUI Previews

Coding is like gardening

A wonderful analogy, indeed the code is not built once and done, but grows and evolves over time. I'm a big proponent of building code in a way that welcomes future changes.

✌️
Alright, that's it for today.
Thank you to TelemetryDeck for sponsoring this issue!