macshome

This page is now depreacted!

Check out the repo instead. The Wisdom of Quinn Now with 100% more archived PDFs.

The Wisdom of Quinn

Informative DevForum posts from everyone's favorite DTS member.

(Arranged newest to oldest)

schwa

struct ErrorHandler {
    var callback: (Error) -> Void

    func handle(_ block: () throws -> Void) {
        do {
            try block()
        }
        catch {
            callback(error)
        }

lukaskubanek

This is an excerpt from our internal documentation describing an issue with drawing in NSViews on macOS Big Sur.

1️⃣ Introduction

In macOS Big Sur (probably starting with β9), Apple changed the default contents format for backing layers of NSViews. Instead of an explicit CALayerContentsFormat.RGBA8Uint value, an „Automatic“ value is now used. Even though it also resolves into „RGBA8“ in our testing, it has some serious implications as it breaks assumptions our code relies on.

I first stumbled upon this issue in this tweet by Frank. It links to a thread on Apple Forums by Mark that contains valuable information as well as ideas for workarounds. The changed behavior was also confirmed by Marcin in this tweet.

2️⃣ Impact on Diagrams

0x36

#if 0
IOAccelContext2::finish_fence_event() race condition OOB read/write

This is a method exposed to user space, it takes a kernel read-only shared memory
(type 2 via clientMemoryForType())  address and treats it as an IOAccelEvents Array.

The user supplied index is checked against the IOAccelEvents array bounds,since there are no
locks held in this method,it is possible to change the array bounds by calling
IOAccelContext2::clientMemoryForType() again in a separate thread, this will expand the size by
multiplying the older size by 2, but we still have a reference to the old shared memory address

iccir

/*
    During Dark Mode migration for macOS, I found it helpful to have a global hotkey
    which toggled between Light/Dark Mode.
  
    This hack attempts to do something similar for iOS.
  
    1) Add your main window in -applicationDidFinishLaunching:
    2) Triple tap the window (I tend to do this near the title bar) to flip between light and dark.
*/

tclementdev

libdispatch efficiency tips

The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).

My take-aways are:

• You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.

• Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse

chockenberry

#!/bin/sh

defaults read com.apple.finder CreateDesktop > /dev/null 2>&1
enabled=$?

if [ "$1" = "off" ]; then
	if [ $enabled -eq 1 ]; then
		defaults write com.apple.finder CreateDesktop false
		osascript -e 'tell application "Finder" to quit'
		open -a Finder

omz

# coding: utf-8
from objc_util import *
import console
import urllib
import dialogs

WKWebView = ObjCClass('WKWebView')
UIViewController = ObjCClass('UIViewController')
UIBarButtonItem = ObjCClass('UIBarButtonItem')
NSURLRequest = ObjCClass('NSURLRequest')

gist:8a163db3f7f3d81d5296

Your goals are to reduce the number of things that you have to keep in your head at any given moment, and to rely as little as possible on your own ability to consistently do things right.
If you make a thing immutable ('let' in swift), you never have to think about what happens if it changes, or what other parts of the code you'll effect if you change it.
If you split complex functions into several smaller functions that only interact by passing arguments or getting return values, then you limit the amount of code you need to consider when hunting for a bug, and you can test each small piece separately.
If you understand what things must be true in your code (aka invariants, for example "a person's age must be greater than 0"), and either provide no function that can cause them to be untrue, or check and crash immediately when they're untrue, then you don't have to debug issues caused by incorrect assumptions.
If you remove possibilities (for example, Swift removes the possibility of things being nil unless 

mattt

struct もじれつ: Printable {
    let description: String

    init(string: String) {
        var mutableString = NSMutableString(string: string) as CFMutableString
        if CFStringTransform(mutableString, nil, kCFStringTransformLatinHiragana, 0) == 1 {
            self.description = mutableString as NSString
        } else {
            self.description = string
        }