A dump of the SwiftUI.framework binary for the iOS simulator (as of Xcode 12.0 beta 2) using the swift-reflection-dump tool.
Note: I used a Swift 5.3 compiler build from a few weeks ago that I had laying around. Because of ABI stability, I don't think the swift-reflection-dump version has to match the compiler version that was used to build the binary, but I'm not 100% sure.
| # A Best in Class Checklist | |
| A boiled down checklist adapted from this [post](https://www.swiftjectivec.com/a-best-in-class-app/), created by @jordanmorgan10. | |
| > To use this, create a Github Issue in your own repo, and simply copy and paste this text. | |
| ## iOS Core Technology | |
| _Things any iOS app can benefit from_ | |
| - [ ] iCloud Sync | |
| - [ ] Focus Filter Support |
| disallowed_racist_terms_of_art: | |
| name: "Disallowed racist terms of art" | |
| regex: 'blacklist|whitelist|^((?<!git)[^\n])*master(?! (manifest|playlist))|slave' | |
| message: "Please, refrain from using terms which have racist connotations. Consider alternatives such as allow, disallow, primary, secondary..." | |
| severity: error |
| // | |
| // DarwinNotificationCenter.swift | |
| // | |
| // Copyright © 2017 WeTransfer. All rights reserved. | |
| // | |
| import Foundation | |
| /// A Darwin notification payload. It does not contain any userInfo, a Darwin notification is purely event handling. | |
| public struct DarwinNotification { |
| import UIKit | |
| @UIApplicationMain | |
| class AppDelegate: UIResponder, UIApplicationDelegate { | |
| var window: UIWindow? | |
| func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool { | |
| let window = UIWindow(frame: UIScreen.main.bounds) |
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
| import XCTest | |
| /// An expectation that is fulfilled when a Key Value Observing (KVO) condition | |
| /// is met. It's variant of `XCTKVOExpectation` with support for native Swift | |
| /// key paths. | |
| final class KVOExpectation: XCTestExpectation { | |
| private var kvoToken: NSKeyValueObservation? | |
| /// Creates an expectation that is fulfilled when a KVO change causes the | |
| /// specified key path of the observed object to have an expected value. |
| #import <objc/runtime.h> | |
| @interface DebuggingOverlay: NSObject | |
| @end | |
| @implementation DebuggingOverlay | |
| + (void)toggleOverlay { | |
| id debugInfoClass = NSClassFromString(@"UIDebuggingInformationOverlay"); |
In Swift there's a message in "Test Target" that states that the bridging header will be removed in newer versions of swift. I'm using mixed objc and swift clasess, but the UnitTest class is a swift file. Using @testable key was there in code
@testable import YourProject
You fix it by adding in your Test area the bridging header with objc headers that your test will use: