A quick visual reference for the standard SwiftUI button Styles:

Mac OS

iOS

Apple provides dynamic colours which match the system.

I couldn’t find a chart showing what they look like in light and dark mode, so here it is.

Dynamic Colours – light mode on the left – dark mode on the right

Codable is a kind of magic.

@Published certainly behaves like magic.

But if you try to add a @Published property to your codeable, then XCode complains

This one had me frustrated for many hours. The issue is that the encoder gets an instance of Published<Type> to encode. As far as I know there isn’t a proper way to get the actual value.
(normally, your code will call the getter on wrappedValue, but I’m not aware of a way to call that directly with Published)

In the end, the only solution I found was to Mirror the struct and extract the value from the ‘value’ Mirror.Child

This has been pretty typical of my SwiftUI experience. There is lots of magical functionality that falls out for minimal effort in a magical way.

But then you try to push the edges, act like a programmer and extend things – and you find that the basic API seems designed to frustrate you. Why would the Published struct not have a simple way to access the wrapped variable?

Anyway, for now at least – we can hack around the limitations

import Foundation
import SwiftUI

extension Published:Encodable where Value:Decodable {

    public func encode(to encoder: Encoder) throws {

        let mirror = Mirror(reflecting: self)
        if let valueChild = mirror.children.first(where: { (child) -> Bool in
            child.label == "value"
        }) {
            if let value = valueChild.value as? Encodable {
                do {
                    try value.encode(to: encoder)
                    return
                } catch let error {
                    assertionFailure("Failed encoding: \(self) - \(error)")
                }
            }
            else {
                assertionFailure("Decodable Value not decodable. Odd \(self)")
            }
        }
        else {
            assertionFailure("Mirror Mirror on the wall - why no value y'all : \(self)")
        }
    }
}

extension Published:Decodable where Value:Decodable {
    public init(from decoder: Decoder) throws {
        self = Published(initialValue:try Value(from:decoder))
    }
}

tl;dr – UIApplication.shared.idleTimerDisabled now causes an undocumented crash if you compile with the iOS 13 SDK and use it from a background thread.

VLC Streamer is one of my oldest apps. It has been going strong since 2008!

It’s a pretty complex app with a bunch of different code paths and edge cases. It’s mostly written in Objective-C.

I uploaded a new build on Jun 15, 2019 to deal with some details around new device screens. No problems there.

I uploaded again on November 20th. There were two relevant changes.

1. I updated the base SDK to 11.0 (from 9.0)
2. I compiled with the latest XCode using the 13.0 SDK

I woke up on the 22nd to get loads of crash reports. One of my code paths calls this from a background thread:

[[UIApplication sharedApplication] setIdleTimerDisabled:YES]; 

This now causes a crash.

Three things of note here for me

1. Nothing in the documentation says you can’t call idleTimerDisabled from a background thread.
2. No code has changed. I just recompiled and resubmitted. The old build worked, the new build crashes.
3. Why is this even an issue? If Apple really need this flag to be changed on the main thread – couldn’t they dispatch it to main in the implementation?

Of course – better testing would have caught this, but how many of us really have proper UI testing in all of our code paths…

Update:

Building a test app with iOS 9 as the target still gives the crash.

Presumably this means that the change has come from using XCode 11.2.1 and the iOS 13 SDK.