TL;DR? We’ve open sourced DateBuilder, our powerful date calculation library. Check out the README to see all the incredible stuff it can do.

Apple’s Calendar API is amazing, it is. It’s quite obscure in some parts, true, and it requires quite a little bit of learning and adjusting, but it’s very effective, very expansive, and, most of all, very correct. If you do everything right, it works great and it handles all the weird edge cases for you.

Nice Photon is available for hire! Talk to us if you have any iOS app development needs. We have 10+ years of…

TL;DR? Check out our new Swift package, it helps you debug local notifications with ease and elegance.

At Nice Photon we’ve had a few projects recently where we had to implement a sophisticated and sometimes quite complex local notifications system. It’s always tricky to get right, because there are always tons and tons of moving parts. It’s very nuanced, as one would expect.

Nice Photon is available for hire! Talk to us if you have any iOS app development needs. We have 10+ years of experience making iOS apps for top Silicon Valley companies. Reach out at hi@nicephoton.com

Making sure…

UIButton is one of the most loved and hated controls in UIKit. It’s central to pretty much any app out there, but it being one of the oldest UIKit classes, it sometimes feel quite awkward to use. In this article, we’ll explain how to make it not only look beautiful, but also how to make it responsive, so that we can delight our users (spoiler: it’s actually not hard at all!). This is how we use UIButton in all of our projects at Nice Photon, so let’s dive in!

TL;DR? See this gist.

Nice Photon is available for hire! Talk…

So imagine you have an app with a fairly simple model struct like this:

struct User {
    var identifier: String
    var handle: String
    var name: String
    var dateOfBirth: Date
    var city: String
}

And to help you debug problems in your code, you have a remote-logging system that will send error messages to your backend (say, Sentry or something similar). The function looks like this:

func logError(_ description: String, userInfo: Any...) {
    // ...
}

And then, whenever something fishy is happening, you use the logError function so that you can investigate it later:

logError("trying to edit the user that…

It’s been almost three years since I wrote ”Do you often forget [weak self]? Here’s a solution”, which luckily resonated with many people. I’ll do a short recap, but if you want a deeper understanding of the topic you can go ahead and read that article first.

In short, the problem I was trying to solve was this: since traditional “protocol-based” delegation was seen by many (including me) as too cumbersome, alternative “closure-based” delegation was gaining traction. The concept is easy and, in pseudo-UIKit-code, looks something like this:

final class TextField { var didUpdate: (String) -> () = { _…

Stuck between UIKit and SwiftUI, many of us have a hard time finding the energy to push forward

“I switched one of my side projects from SwiftUI to UIKit because that shit is not ready for prime time”

Since SwiftUI was announced last summer, I talked to many, many of my colleagues about their thoughts and feelings of this new piece of technology. Many, including myself, were excited. Who wasn’t dreaming of a first-class pure Swift UI framework? …

Read a 2020 follow-up to this story here: No more [weak self], or the weird new future of delegation

Okay, so today’s post is about delegation and how we can make it better with Swift. Without further ado, let’s introduce a standard example of Cocoa-style delegation in Swift:

1. First, we create a delegate protocol restricted to classes

protocol ImageDownloaderDelegate: class {    func imageDownloader(_ imageDownloader: ImageDownloader, didDownload image: UIImage)}

2. Next, we implement our ImageDownloader

class ImageDownloader {
    
    weak var delegate: ImageDownloaderDelegate?
    
    func downloadImage(for url: URL) {
        download(url: url) { image in
            self.delegate?.imageDownloader(self, didDownload: image)
        }
    }
    
}

Note how…

Alright, no additional introductions this time — I’ll just cut straight to the point:

Only, only request a data in a synchronous manner if it’s coming directly from memory.

What do I mean by that? Well, if you have, for example, this code in your app:

let user = persistence.getUser(for: id)
label.text = user.name

You need to be absolutely sure that this data is already stored in the memory. It’s not being retrieved from the disk. It’s not being deserialized. It’s not being resolved in an algorithm of a skyrocketing complexity. It’s just there. …