Skip to content

Instantly share code, notes, and snippets.

@steipete
steipete / ios-xcode-device-support.sh
Last active May 11, 2025 13:30
Using iOS 15 devices with Xcode 12.5 (instead of Xcode 13)
# The trick is to link the DeviceSupport folder from the beta to the stable version.
# sudo needed if you run the Mac App Store version. Always download the dmg instead... you'll thank me later :)
# Support iOS 15 devices (Xcode 13.0) with Xcode 12.5:
sudo ln -s /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/15.0 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport
# Then restart Xcode and reconnect your devices. You will need to do that for every beta of future iOS versions
# (A similar approach works for older versions too, just change the version number after DeviceSupport)
//
// Signal+Extensions.swift
// Khan Academy
//
// Created by Nacho Soto on 10/1/15.
// Copyright © 2015 Khan Academy. All rights reserved.
//
import ReactiveCocoa
@alanzeino
alanzeino / lldb-debugging.md
Last active September 8, 2025 00:06
LLDB debugging with examples

LLDB Debugging Cheat Sheet

Commands

LLDB Commands

LLDB comes with a great set of commands for powerful debugging.

help

Your starting point for anything. Type help to get a list of all commands, plus any user installed ones. Type 'help for more information on a command. Type help to get help for a specific option in a command too.

@jspahrsummers
jspahrsummers / transcript.md
Last active September 12, 2015 15:14
Excerpt from https://reactivex.slack.com about API design, especially as it relates to RAC

carlossless [09:50] So anyone used RxSwift? I’m wondering what are your thoughts and opinions vs RAC3.

jspahrsummers [10:00] @carlossless: https://github.com/ReactiveCocoa/ReactiveCocoa/blob/07813339d3c44aa02fb1b71777baa4ede0f0f77a/README.md#how-does-reactivecocoa-relate-to-rx

carlossless [10:13] Yeah, I was looking for a more practical point of view but even so. RxSwift has UI bindings, it follows the haskell naming for most transformation and composition functions ​map​, ​filter​ etc. rather than ​select​, ​where​.

carlossless [10:14]

@rnapier
rnapier / erasure.swift
Created August 4, 2015 20:10
A Little Respect for AnySequence (http://robnapier.net/erasure)
import Swift
/*:
A simple type-erased sequence
*/
let seq = AnySequence([1,2,3])
/*:
## Who Needs Types Like That?
@drewmccormack
drewmccormack / jiggle-wifi.sh
Last active March 13, 2021 20:27
Keeps your OS X WiFi connected to the interwebs.
#!/usr/bin/env bash
# If your OS X WiFi connection stops working, but can be fixed by
# toggling WiFi off and then on, this script can help prevent mouse arm.
# Pings Apple's server repeatedly, toggling WiFi off/on when a connection times out.
while true ; do
curl --head --silent --connect-timeout 10 http://www.apple.com/my-wifi-keeps-dropping-out > /dev/null
if [ $? -ne 0 ] ; then
networksetup -setairportpower en1 off
networksetup -setairportpower en1 on
@nicklockwood
nicklockwood / gist:21495c2015fd2dda56cf
Last active August 13, 2020 13:57
Thoughts on Swift 2 Errors

Thoughts on Swift 2 Errors

When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.

So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.

Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?

I'm going to cover three things in this post:

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
@JaviLorbada
JaviLorbada / FRP iOS Learning resources.md
Last active August 14, 2025 01:40
The best FRP iOS resources.

Videos