All bites
The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.
4247 bites
Page 141
Core Bluetooth: The Central vs. Peripheral Model
Core Bluetooth lets your app talk to BLE devices by acting as a "Central" (scanner) or "Peripheral" (advertiser). Use it to read from sensors or make your app discoverable.
AVCaptureSession
AVCaptureSession is the central coordinator in AVFoundation that connects camera and microphone inputs to outputs like a preview layer, photo capture, movie recording, or real time frame processing.
Apple's Natural Language Framework
Apple's Natural Language Framework turns raw strings into structured meaning on-device without network calls. Tokenize queries or extract entities from user text locally. It is not infallible; heavy synchronous tagging on the main thread freezes your UI.
XCTest: Apple's Built-in Testing Framework
XCTest is your built-in toolbox for writing unit, performance, and UI tests in Xcode. Use it to verify individual functions or simulate user interactions. A common footgun is writing tests that depend on each other; they must be independent to be reliable.
XCTAssert: The Pass/Fail Gatekeeper of Your Tests
XCTAssert functions are the gatekeepers of your tests, asserting if code behaves as expected. Use them to validate conditions like equality (XCTAssertEqual) or truth (XCTAssertTrue).
Test-Driven Development: Write the Test First
TDD flips the script: write a failing test before the feature code, forcing a testable design. It's ideal for new Swift components with clear requirements, ensuring every line of code serves a purpose.
Mocking: Faking Dependencies in Unit Tests
A mock is a stunt double for a real object in your unit tests, letting you control its behavior. Use it to fake dependencies like network clients for fast, predictable tests. The footgun: over-mocking can create tests that pass but miss real integration bugs.
XCUITest: Automating Your App's User Interface
XCUITest is like a robot user for your app, tapping buttons and verifying what's on screen. It automates testing of critical flows like login or checkout to prevent regressions.
XCUIElementQuery: The Blueprint for Finding UI Elements
An XCUIElementQuery is a recipe for finding UI, not the element itself. It describes a search that runs only when you interact with the result. Use it in XCUITest to locate views for automated tests. The footgun: thinking a query finds an element on creation.
Testing Async Code with XCTestExpectation
XCTestExpectation is a stopwatch for your tests, pausing them to wait for asynchronous work like a network call to finish. Use it for testing code with completion handlers. The footgun is forgetting to fulfill() the expectation, causing a timeout failure.
Xcode Code Coverage: Measuring Test Effectiveness
Code coverage isn't a grade, but a map of untested code. Use it in Xcode to find gaps in your logic before shipping. The footgun: high coverage doesn't mean your tests are good, just that the lines were executed, potentially missing key assertions.
measure: Baseline and Compare Code Performance
measure in XCTest establishes a performance baseline for a block of code and fails tests if it regresses. It tracks critical algorithm speed, running the code ten times for a stable average. The footgun is ignoring the baseline: you must set it first.
XCUITest Page Object Model: Tame Your UI Tests
The Page Object Model treats each app screen as an object, separating test logic from UI interaction. In XCUITest, this creates stable tests for complex apps. The biggest footgun is forgetting synchronization—always wait for views to load before interacting.
Snapshot Testing: Catch Unintended UI Changes
Snapshot testing compares your UI to a saved 'golden' image, failing if pixels differ. It's a visual diff for your views, catching unintended regressions in layout or style. The main footgun is forgetting to re-record snapshots after intentional UI changes.
CocoaPods: Managing Dependencies in Apple Projects
CocoaPods manages third-party libraries in your Swift/Objective-C projects. You list dependencies in a Podfile, run pod install, and it handles the rest. The biggest footgun: always open the .xcworkspace, not the .xcodeproj file after installing.
Xcode Workspaces: Managing Multiple Related Projects
An Xcode Workspace is a container for multiple related projects, letting them share code and resources. Use it when building an app with its own frameworks or when managing dependencies like CocoaPods.
Framework Target
A Framework target in Xcode builds a reusable bundle of compiled code and public interfaces, separate from an app target, so an app, a widget, or an extension can share the same code without duplicating it.
Carthage: A Decentralized iOS Dependency Manager
Carthage is a dependency manager that prioritizes developer control. It compiles dependencies into binary frameworks but leaves final integration to you, avoiding automatic changes to your Xcode project.
Swift Package Resources: Bundling Assets with Code
A Swift Package resource bundle is like a fanny pack for your code, letting you package assets like images and data files directly with your library. This makes your package self-contained.
Static vs. Dynamic Linking: Code Size vs. Flexibility
Static linking bakes library code into your app, creating a large but self-contained executable. Dynamic linking loads libraries at runtime, saving space. This choice impacts app size, launch time, and updates.