welcome to issue #38!
Modern collection views
A lot has changed in
UICollectionView APIs in the recent years. While before we would subclass
UICollectionViewCell and implement
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
Your app's users are mostly satisfied, but let's make them fall in LOVE with your app! Let's make them loyal ambassadors for your idea, tell their friends all about it!
We believe that by continuously improving your app's performance, design and experience through respectful, privacy-first, real-time analytics, it can really shine.
Start for free at telemetrydeck.com
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.
Custom screenshot support
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
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!