Swift Posts

Having one semantic data model but two different types for implementation to separate domains and architecture layers brings up the question: where to put the conversion code?

During WWDC24, Apple finally introduced a “swifty” test framework to replace XCTest.

Breaking down individual features of domain-oriented managers into dedicated implementations improves developer experience.

Some SwiftUI views I have require padding one platform and none on the other. To avoid preprocessor switches everywhere I created a custom view modifier for it.

Having a file provider extension with multiple domains and processes and even more enumerators logging in parallel can become a mess. Leveraging the subsystem and category fields to the rescue.

Out of necessity I created a minimalistic SwiftUI app which performs MD5 hashing to get a rough feeling how efficient it is on Apple devices.

I need to maintain a virtual file system in a CoreData database. Setting up test scenarios is tiresome, so I made use of result builders and its nice.

There is a better way than to repeat the same or similar NSPredicate all the time and it is very nice to read.

I rarely need to use defer blocks and mostly it is for ending signpost intervals. I checked the possible situation of having multiple and in which order they are executed.

I was very excited about macros because they allow the reduction of boilerplate code like handling signposts. This macro reduces signposting in a method to a single word expression.