private func fixturesHappeningToday() -> [LocalFixture] {
    let predicate = #Predicate<LocalFixture> { item in
        Calendar.current.isDateInToday(item.date)
    }

    let descriptor = FetchDescriptor<LocalFixture>(predicate: predicate)
    let results = try? modelContext.fetch(descriptor)
    return results ?? []
}

// Compiler error:
// The isDateInToday(_:) function is not supported in this predicate

That didn’t work out, and it kind of makes sense since the Predicate needs to be converted to SQL eventually. So instead I pivoted and tried to just format the values and compare them.

let predicate = #Predicate<LocalFixture> { item in
    item.date.formatted(date: .numeric, time: .omitted) == Date.now.formatted(date: .numeric, time: .omitted)
}

// Compiler error:
// The formatted(date:time:) function is not supported in this predicate

Yep, pretty much the same compiler error. I probably should have guessed that the formatted function would have the same limitation, but it was worth a shot.

At one point I considered storing pieces of the date values, but I didn’t like the idea of having duplicate data. The next idea was to create a computed, transient property. This actually compiled! Hooray.

 var dayMonthYear: String {
     date.formatted(.dateTime.day().month().year())
 }
 
 let predicate = #Predicate<LocalFixture> { item in
     fixture.dayMonthYear == match
 }

And then promptly crashed when the app was run.

// Fatal error: Couldn't find \LocalFixture.dayMonthYear on LocalFixture with fields dayMonthYear

At this point, I thought perhaps I was just overthinking all of this and should just compare the dates directly.

let targetDate = Date.now
let predicate = #Predicate<LocalFixture> { item in
    item.date == targetDate     // Can't use Date.now directly in #Predicate
}

No crash this time, but I didn’t get any results back. After a few minutes of head scratching it dawned on me that this was of course comparing the full date value, including the time. After a stretch, and a quick walk away from my desk, I finally hit on an idea that worked. Utilize the Calendar to create start and end dates, and then do simple compares against those directly.

let start = Calendar.current.startOfDay(for: targetDate)
let end = Calendar.current.date(byAdding: .day, value: 1, to: start)!

let predicate = #Predicate<LocalFixture> { item in
    item.date > start && item.date < end
}

We can’t really perform any operations on item.date, but we CAN do some pre-calculations to make it easier to compare against. Using theses Calendar methods we can safely create a range from midnight to midnight, fully encapsulating our target date.

isDateInToday(_ date: Date) -> Bool

Simple and to the point.

let occursToday = Calendar.current.isDateInToday(someDate)

isDate(_ date1: Date, inSameDayAs date2: Date) -> Bool

Say you have two dates returned from a server as UNIX timestamps, and want to check if they represent the same date. You could parse them into date componenets (which is another great feature of Calendar), and compare the year, month, and day. Or use the simple one-liner:

let date = Date(timeIntervalSince1970: 1764636075)
let anotherDate = Date(timeIntervalSince1970: 1764596475)
let isTheSameDay = Calendar.current.isDate(date, inSameDayAs: anotherDate)

It’s just as easy to resolve the match to a given hour, month, or any other component.

let isInTheSameHour = Calendar.current.isDate(date, equalTo: anotherDate, toGranularity: .hour)

let date = Date.now
let sixtySecondsLater = date.addingTimeInterval(60)
let twentyMinutesLater = date.addingTimeInterval(60 * 20)

// Negative values also work just fine
let sixtySecondsAgo = date.addingTimeInterval(-60)

For a more readable, and less error-prone approach, use the Calendar method of date(byAdding:…). You can easily and explicitly specify the date component you want to move forward (or backwards) by, as well as how much. There is an additional overload of the method which accepts a full DateComponents object, which allows you to easily change multiple components in one go.

let date = Date.now
let oneHourLater = Calendar.current.date(byAdding: .hour, value: 1, to: date)
let twentyHoursLater = Calendar.current.date(byAdding: .hour, value: 20, to: date)

let components = DateComponents(hour: 3, minute: 20)
let threeHoursTwentyMinutesLater = Calendar.current.date(byAdding: components, to: date)

The .date(byAdding:…) method has one last trick up its sleve. Say you are building a clock component where you can individually step the hours, minutes, or seconds up and down. If you would like the behavior to be such that incrementing the seconds from 55 to 5 to not make a change to the value of the minutes, you can set the wrappingComponents paramter to true.

let date = Date.now
let timeIsAnIllusion = Calendar.current.date(byAdding: .second, value: 60, to: date, wrappingComponents: true)

print(date == timeIsAnIllusion)     // `true`

let someLocation = CLLocation(latitude: 40, longitude: -40)

Easy! Too easy? The slight catch here is that there is no validation being done. You can create a completely invalid location and Swift won’t complain at all. No compiler errors, no runtime errors. If you log the bad location, you can see the bad values are still maintained:

let badLocation = CLLocation(latitude: 9000, longitude: -9000)
Logger().debug("The location is: \(badLocation)")
---
// The location is: <+9000.00000000,-9000.00000000> +/- 0.00m (speed -1.00 mps / course -1.00) @ 2/9/24, 13:46:53 Central Standard Time

Luckily this is something we don’t have to remember. We can use the CLLocationCoordinate2DIsValid method. It takes a coordinate and returns a boolean indicating if the coordinate is valid.

let questionableCoordinate = CLLocationCoordinate2D(latitude: -100, longitude: 95)
let isValidCoordinate = CLLocationCoordinate2DIsValid(questionableCoordinate)
print(isValidCoordinate)    // spoiler - it's not

// Note the method is for a `CLLocationCoordinate2D`, not a `CLLocation`
let questionableLocation = CLLocation(latitude: -100, longitude: 95)
let isValidLocation = CLLocationCoordinate2DIsValid(questionableLocation.coordinate)

Now you can go on your way with confidence.

Quick aside: When adding an annotation with an invalid coordinate to a SwiftUI Map view I’ve seen couple of different behaviors. Most of the time the annotation just doesn’t show up at all, which is probably the desirable behavior. Occassionally though, the framework seems to transform the invalid coordinate to one at (0,0) - the popular vacation destination of Null Island.

Xcode_15_beta.xip and iOS_17_beta_Simmulator_Runtime.dmg

If you launch Xcode you’ll see that the iOS 17 simulator is still missing, and you won’t be able to build and run with it quite yet. The good news is that it is easy to manually import the simulator runtime, and you don’t need to download it again via Xcode’s organizer.

Just follow these steps:

1. In Xcode, go to Settings, Locations, and make sure the Command Line Tools is set to Xcode-beta 15.0
2. On the command line run xcrun simctl runtime add ~/Downloads/iOS_17_beta_Simulator_Runtime.dmg
3. After a brief time you should get a response that the simulator is ready.

For more details, check out the Apple documentation here.

Say you have something like this:

@main
struct WeatherApp: App {
    @StateObject var weatherData = WeatherDataStore()
    
    var body: some Scene {
        WindowGroup {
            SimpleWeatherView()
                .environmentObject(weatherData)
        }
        .backgroundTask(.appRefresh("WeatherCheck")) {
            await updateWeatherData()
        }
    }
}

Xcode will not be happy, letting you know that Command CompileSwift failed with a nonzero exit code. Not exactly the most helpful, though digging in to the build output yields this gem:

$@_opaqueReturnTypeOf("$s7SwiftUI5ScenePAAE14backgroundTask_6actionQrAA010BackgroundE0Vyqd__qd_0_G_qd_0_qd__YaYbcts8SendableRd__sAIRd_0_r0_lF", 0) __<WindowGroup<ModifiedContent<SimpleWeatherView, _EnvironmentKeyWritingModifier<Optional<WeatherDataStore>>>>, (), ()> // user: %38
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the project and the crash backtrace.

Turns out that for now you will need to encapsulate the view and its modifiers into a single view like this:

@main
struct WeatherApp: App {
    var body: some Scene {
        WindowGroup {
	    TemporaryWrapperView()
        }
        .backgroundTask(.appRefresh("WeatherCheck")) {
            await updateWeatherData()
        }
    }
}

struct TemporaryWrapperView: View {
    @StateObject var weatherData = WeatherDataStore()
    
    var body: some View {
        SimpleWeatherView()
            .environmentObject(weatherData)
    }
}

For more details check out this thread on the Apple Developer forums. As stated there, if all is well this workaround should hopefully not be needed once Xcode 14.1 ships.

One quick aside - when my Feedback was responded to it was removed from Submitted and moved to Inbox. I didn’t realize this had happened as the issue got mixed in with all the other beta release note messages in the Inbox. I actually thought it had been deleted. Once I responded on the issue, it moved back to the Sumbmitted section. I guess this kind of makes sense, but something to keep in mind.

As I’ve been making my way through the videos though, I have realized that it is there, just in a much more subtle way.

The pre-recorded session videos allow for a much tighter experience. Not only can more content be shared in the same amount of time, but how it is shared can be altered. I have only seen a couple of instances so far where a code snippet was used to drop in a huge piece of code (I’m looking at you Core ML). Instead, most of the presenters actually typed, in “real time”, the code they were demonstrating. I think this is a huge improvement to the sessions of previous years where the new features were given as a bulleted list. I loved learning about the new features and tools in Xcode simply by watching someone use them in a normal context. Having these distributed out among so many of the videos also feels like they were able to share more of the changes that were made.

While it’s clear that my favorite video was missing from WWDC this year, it is just as clear that it doesn’t need to be there. The general consensus seems to be that the sessions were well received this year, and I have to agree. I really hope that this is something we can continue to expect from WWDC in the years to come.