Verify a Swift package’s minimum toolchain and CLI contract

Robin Winters — Sun, 04 Oct 2026 03:45:00 GMT

Verify a Swift package’s minimum toolchain and CLI contract

Robin Winters · October 3, 2026

I’m an iOS / Full Stack Engineer at ShowFlex, a shipped iPhone fitness product. This article examines a separate, public Swift teaching package prepared with coding-assistant support. Its fixtures are synthetic; the results below are not a test report for ShowFlex.

A package that passes on my current Mac has established something useful. It has not established that another person can build it on the oldest supported tools, on Linux, or with an unexpected command-line input. Those are different questions, and each needs a concrete check.

The fitness event data pipeline declares Swift tools version 6.0 and provides a library plus a normalize-events executable. The example turns synthetic event records into normalized events and decision receipts. Release 0.1.1 adds compatibility evidence without changing the library, executable source, tests or fixtures from 0.1.0.

Record what actually ran

The manifest’s Swift tools version specifies a minimum tools requirement. It is a declaration, rather than evidence that this package was executed with those tools.

The public workflow run records three successful environments:

Environment	Observed compiler	Checks
Linux, official Swift container	Swift 6.0.3	12 unit tests and an exact fixture-output comparison
macOS 15 runner	Apple Swift 6.1.2	12 unit tests and four CLI contract cases
Ubuntu 24.04 runner	Swift 6.4	12 unit tests and four CLI contract cases

These are the same 12 unit tests executed in three environments. They are not 36 distinct tests. Swift 6.0.3 supplies evidence for a specific compiler in the declared 6.0 line; it does not prove an execution on 6.0.0. The package’s iOS deployment declaration likewise does not establish an iPhone runtime result.

Each job prints swift --version before building. Runner labels alone are too imprecise for the compatibility record: the compiler observed on a hosted runner can change.

Test the executable boundary separately

Library tests can pass while the executable’s exit status, output stream or input decoding is wrong. The host-runner jobs invoke Scripts/check-fixture.py, which checks four cases:

The complete synthetic fixture succeeds, writes no error, and produces the expected normalized events and receipts.
An empty array succeeds with empty events and receipts.
Malformed JSON exits with status 1, emits no success report, and writes the specified input-contract error to stderr.
An object in place of the expected array produces the same rejection behavior.

The fixture assertion compares the complete decoded JSON document. Checking only the event count would miss changes to identities, timestamps or conflict receipts. The rejection checks inspect stdout as well as stderr: an error message is insufficient if the process also emits an apparently successful report.

The Swift 6.0.3 job runs a narrower check: it executes the valid fixture and uses diff against the expected output file. It does not run the other three CLI cases. Keeping that distinction visible makes the evidence easier to trust.

Reproduce the release checks

On a machine with Git, Swift and Python 3, check out the published tag:

git clone https://github.com/RobinWinters/fitness-event-data-pipeline.git
cd fitness-event-data-pipeline
git checkout 0.1.1
swift --version
swift build
swift test
python3 Scripts/check-fixture.py

The Python script uses the standard library. Its four-case check expects the debug executable produced by the preceding build. The versioned compatibility record distinguishes these host checks from the container’s narrower comparison.

State the remaining gaps

The workflow uses read-only repository permissions, a pinned checkout action and a pinned minimum-toolchain container. It needs no private application credentials. Those choices make this small public example reproducible without connecting it to a production backend.

The checks establish the recorded package behavior in the recorded environments. They do not establish physical-device execution, private product behavior, performance under real event feeds, or automatic compatibility with every later compiler. A useful next compatibility check should answer one of those unresolved questions, rather than add another badge for the same run.

For native product work, the habit carries over: distinguish an API declaration, a successful build, a tested boundary and an observed user interaction. Each is valuable; each supports a different claim.

Robin Winters works on Swift, SwiftUI, MapKit and Firebase at ShowFlex. Professional reference · robin.ac. This self-authored technical account was prepared with editorial and coding-assistant support.

A SwiftUI search adapter needs its own request ownership

Robin Winters — Sun, 04 Oct 2026 01:10:30 GMT

A SwiftUI search adapter needs its own request ownership

Robin Winters · October 3, 2026 · Native iOS engineering and fitness technology

This standalone teaching example and article were prepared with coding-assistant support. The events are synthetic. The code is separate from ShowFlex, whose shipped iPhone product is available on the App Store.

A search controller can correctly reject stale requests while its view adapter still publishes the wrong state. The useful question is not only whether the controller owns its result: it is whether the task waiting for that result still owns the screen.

The public controller already checks a revision before publishing success, failure or cleanup. Its new native SwiftUI demo makes the surrounding adapter explicit. It searches three synthetic fitness-event titles, selects by identifier and exposes clear, cancel, error/retry and a deliberately troublesome request race.

Keep the observable owner stable

The controller has plain state properties. The adapter conforms to ObservableObject, publishes the state the interface reads and owns the controller. The view holds the adapter with @StateObject. These are established SwiftUI state-object and Combine observable-object mechanisms; this example uses them to preserve the declared iOS 16 minimum.

Starting a search immediately copies the controller's loading state, empty results and cleared selection. When the returned task settles, the adapter copies the completed state only if its own version still matches the version captured when it started waiting:

version += 1
let ownedVersion = version
let pending = controller.search(query)
publish()

Task { [weak self] in
    await pending?.value
    guard let self, self.version == ownedVersion else { return }
    self.publish()
}

This excerpt shows the ownership rule; the full source also handles an empty query before creating the waiting task. The adapter version protects its activity text and state-copying path. The controller revision protects the underlying results. The two checks sit at different boundaries.

Make the race difficult on purpose

The Race demo control starts a slow request, allows it to enter the fixture fetcher and then starts a fast request. The slow fetch uses a continuation resumed by a dispatch timer. Cancelling its Swift task does not cancel that timer. It really completes after the replacement request, instead of disappearing in a cooperative mock.

The accepted result is the fast request. The integration check waits for that result, then waits past the slow completion and verifies that the query and visible adapter results still belong to the fast request. This tests the published state that the SwiftUI list reads, rather than only the controller's internal value.

Selection and leaving the screen are separate policies

Selecting a result passes its identifier to the controller and republishes the resolved selection. Starting another query clears it. Cancel invalidates the adapter's waiting tasks, cancels the scheduled race transition and tells the controller that pending work no longer owns the surface. The view calls that method when it disappears.

Those are this demo's policies. A production search flow may retain old results during refresh or restore a selection when returning to a screen. Either choice needs a corresponding state model; it should not arise accidentally from a late completion.

Reproduce the checks

From the example directory, with Xcode on an Apple silicon Mac:

swift test
sh Demo/check-model.sh
sh Demo/build-simulator.sh

The seven controller tests and four executable adapter checks passed on macOS on October 3, 2026. The adapter checks cover the non-cooperative race, identity selection and clearing, current error and successful retry, and cancellation after a fetch has started. The ARM64 iOS simulator app compiled, installed and launched on an isolated iPhone 17 Pro running iOS 27.0. A compiler sysroot warning was emitted. At this initial build checkpoint, UI inspection, recording, accessibility, live-network behavior and physical-device execution were unverified; the later partial inspection is documented below.

Observed iPhone simulator interaction — October 3, 2026

A later inspection in Xcode Device Hub showed the initial screen on the isolated iPhone 17 Pro simulator running iOS 27.0. Tapping Strength returned one synthetic Strength meet result. Selecting it showed both the checkmark and the Selection section. These are actual, unaltered simulator-window screenshots, captured with coding-assistant support.

Initial state: synthetic event search controls and no selected result.

Observed search and selection: one Strength meet result, selected by identity.

This partial inspection adds evidence beyond build and launch. It does not complete the race, clear, cancel, error/retry, scrolling or accessibility review. Recording, live-network and physical-device behavior remain unverified. The separate macOS checks above cover controller and adapter contracts.

The code is MIT licensed within the teaching example. It grants no access or license to private ShowFlex code. Build and test evidence belongs to this example; the separate App Store listing is evidence of the shipped ShowFlex product.

Code and executable checks · Original controller explanation · Robin Winters professional record · robin.ac

ShowFlex: event discovery connects native interaction with structured data

Robin Winters

ShowFlex: event discovery connects native interaction with structured data

Robin Winters — iOS/Full Stack Engineer, 2024–present

I’m an iOS / Full Stack Engineer at ShowFlex, a shipped iPhone fitness product available on the App Store. Since 2024, my work has spanned Swift and SwiftUI engineering, mobile architecture, MapKit event discovery, Firebase-backed data, interaction quality and release execution. Here is how native interaction and structured event data meet in that work.

A map is one part of a discovery flow

Event discovery connects a user's query, active filters, a set of locations and the event currently being inspected. Search results and map markers should refer to the same event identities. A detail sheet should describe the selected event even when the surrounding result order changes.

My work includes MapKit, search and filtering, dynamic geocoding, draggable detail sheets and persistent navigation. The product problem crosses those components: the interface needs clear state transitions as data and selection change. Accessibility, motion and efficient loading are part of the approved engineering scope.

The companion Swift search example demonstrates one general state-management problem: rejecting asynchronous results that belong to an older query. It is a separate educational package, not extracted ShowFlex code and not evidence of the exact implementation shipped in the app.

Event information needs a usable structure

The approved data work includes ingestion pipelines that normalize global event calendars, athlete metadata, registration information and media into structured JSON and Firebase-backed product data. Source information and native presentation meet at that boundary.

A calendar entry, location and registration link are useful only when they can be connected to the event a person is viewing. This explains why the work spans both data handling and the consumer interface. No throughput, latency, accuracy or adoption figures are claimed here.

Public release evidence

The ShowFlex iPhone App Store listing, checked October 2, 2026, identifies ShowFlex Inc. as developer and seller. Version 17.0 describes an interactive IFBB events map and calendar import tools for IFBB Pro and NPC events. That is public evidence for an iPhone product and the listed map/calendar release.

It does not establish an Android release, individual authorship of every feature, a measured business outcome or release of the AI prototypes below. Store metadata can change; the check date matters.

Applied AI remains a distinct work stream

My approved scope also includes prototypes for AI-assisted physique and posing feedback and predictive competition features. These are experimental workflows. They are not described as released product capabilities or validated fitness assessments.

The distinction matters when assessing the portfolio: released iPhone event discovery has public product evidence; AI prototype work has a narrower professional claim and needs additional releasable demonstrations before it can become a detailed implementation case study.

Existing work account · ShowFlex · Portfolio · Professional profile

Updated October 2, 2026. Self-authored professional account prepared with editorial assistance.

Building an iOS Moderation Layer with Apple Foundation Models framework and Firebase

Robin Winters — 2026-04-02

Building an iOS Moderation Layer with Apple Foundation Models framework and Firebase

By Robin Winters

First published April 2, 2026 on LinkedIn. Republished October 2, 2026 with original wording, images and captions. Technical observations and opinions retain their original context.

"YOU KNOW MARTIN THAT IT'S JUST GOING TO BE TAKEN DOWN AND YOU'LL BE BLOCKED FROM POSTING FOR THE NEXT 30 DAYS"

When building out a moderation layer in the Apple ecosystem we have a LOT of tools and guidance to help the process along so we as developers can make something both delightful and safe for the wide range of users we hope to reach.

I build iOS native products in Swift and SwiftUI, so I care a lot about how a system behaves in hand. I also care about whether it holds up once users start poking at it in weird ways. Moderation is where those things meetup. A bad classifier or a vague rejection banner is a product bug, but users experience both as the same thing.

Below is how I've been going about building a new-ish moderation layer for iOS that can be applied basically anywhere it's needed with a few caveats.

After messing about with a number of increasingly elaborate designs, I landed on a hybrid architecture where each side does a different job quite well:

Apple’s Foundation Models framework gives fast, private, on-device text classification and rewrite suggestions.
Firebase callable functions for server authoritative decision paths with Auth, App Check, audit logs, and review hooks.
Cloud Storage triggers for handling media separately, because images and video are their own special form of pain.

Caveat: The main constraint with Apple’s model is that it only runs on Apple Intelligence capable devices in supported regions and Apple explicitly tells developers to check availability before building around it. Their own guidance also says to make sure the experience still works when generative features aren’t available. I definitely don't want moderation to disappear because a user has an unsupported device, region, or language setup, but this should solve itself with time and broader adoption of more modern devices.

Sauce: WWDC25 Foundation Models, SystemLanguageModel availability, Generative AI HIG

Here’s a fun little diagram for flowchart fans:

Fun is a relative term.

On the client side I’m using Apple’s model for text-only moderation signals before the content ever leaves the device. That gives me two preem properties right away. First, it's fast. Second, I can warn a user about obvious problems without dumping every draft to the backend.

Apple’s Foundation Models framework is a good fit for this b/c Apple positions it for tasks like extraction, summarization, and classification. Exactly the kind of narrow job I want on device.

Sauce: What’s New in Apple Intelligence

The Swift side looks roughly like this:

import FoundationModels

@Generable
struct ModerationSignal {
    @Guide(description: "One of: safe, harassment, self_harm, doxxing, spam, sexual_content, review")
    var label: String

    @Guide(description: "Confidence score from 0 to 100")
    var confidence: Int

    @Guide(description: "True if the text appears to include personal contact information")
    var containsPII: Bool

    @Guide(description: "Short user-facing suggestion if the content should be revised")
    var userMessage: String
}

@MainActor
func classifyDraft(_ text: String) async throws -> ModerationSignal? {
    let model = SystemLanguageModel.default
    guard case .available = model.availability else {
        return nil
    }

    let session = LanguageModelSession()
    let response = try await session.respond(
        to: "Classify this user-generated text for moderation: \(text)",
        generating: ModerationSignal.self
    )

    return response.content
}

A couple of things I dig about this. The response is structured so I’m not parsing model soup. The feature is private by default, and when the model is unavailable the app still works. It just skips the preflight hint and sends the content to the server.

Apple’s model is great when it's there but I am not building a moderation system that only works for the best case device matrix. Once the user submits content, Firebase takes over. I’m using a callable function so the app sends the content, the local moderation signal if one exists, and the user’s auth context through a standard path. Firebase’s docs call out a useful detail here: callable functions automatically include Auth and App Check tokens when available, and App Check enforcement can be turned on serverside.

Sauce: Callable functions, App Check for Cloud Functions

The server side looks more like infrastructure now. Cool beans.

import { onCall, HttpsError } from "firebase-functions/v2/https";
import { getFirestore } from "firebase-admin/firestore";

const db = getFirestore();

export const submitContent = onCall(
  { region: "us-central1", enforceAppCheck: true },
  async (request) => {
    if (!request.auth) {
      throw new HttpsError("unauthenticated", "Sign-in required");
    }

    const { body, localSignal } = request.data as {
      body: string;
      localSignal?: {
        label?: string;
        confidence?: number;
        containsPII?: boolean;
      };
    };

    const piiHit = /\b\d{3}[-.\s]?\d{3}[-.\s]?\d{4}\b/.test(body);
    const urlCount = (body.match(/https?:\/\//g) ?? []).length;
    const likelySpam = urlCount > 2;

    let action: "publish" | "review" | "block" = "publish";
    let reason: string | null = null;

    if (piiHit || localSignal?.containsPII) {
      action = "block";
      reason = "possible_pii";
    } else if (likelySpam || localSignal?.label === "review") {
      action = "review";
      reason = "needs_review";
    }

    const ref = await db.collection("content").add({
      uid: request.auth.uid,
      body,
      localSignal: localSignal ?? null,
      action,
      reason,
      createdAt: Date.now(),
    });

    return { id: ref.id, action, reason };
  }
);

This is where we get consistency. I can layer the review workflows around the model output instead of the model owning everything. I can also log the actual reason for a decision for later when somebody appeals or there's some over-moderation. Also, text and images fail in different ways. A Cloud Storage triggered function can pull the asset, hash it, run the heavier checks, and then write back a moderation state without blocking the client on every large upload. Firebase pushes Storage triggered processing as a standard use case.

Sauce: Cloud Functions use cases

A few outside examples:

Reddit is a good example. It shows what "mature" moderation starts to look like over time. They have AutoModerator, Safety Filters, and a moderation queue. They also have a documented flow for abuse of the report system.

The Meta example is the breast cancer awareness case from the Oversight Board. Automated nudity enforcement caught legitimate health content. If the moderation stack sees skin and loses its mind, the product starts punishing the people it is supposed to help.

So the build has to stay narrow where it makes sense. On device Foundation Models for fast text preflight, Firebase Functions for final action, hard rules for obvious stuff, review queues for the ugly middle. Fallbacks for unsupported devices, and state driven UI so the user knows what happened.

Hopefully that made sense! Obviously this is just experimenting for now, but I think it's a good way to start thinking about how to layer moderation into whatever your building with Apple's Foundation Model framework.

Be excellent to each other,

🤘Robin

All writing · Original LinkedIn edition

Swift search request ownership

Robin Winters — 2026-10-02

Swift search: cancellation needs an ownership check

Robin Winters · October 2, 2026 · Educational example prepared with coding-assistant support

Search often looks simple until two requests finish in the wrong order. A user enters “San”, changes the query to “San Francisco”, and sees the shorter query's results arrive last. The newer request may have finished correctly; the older task still owns enough code to replace the result list.

Debouncing reduces the number of requests. Cancellation tells an obsolete task to stop. Neither operation alone states which request is allowed to change the current interface. That ownership rule is the useful part of the standalone example.

Cancellation is cooperative

Swift task cancellation signals a task rather than forcibly terminating arbitrary work. The task and functions it calls must observe that signal. A cancellation-aware sleep can throw before the fetch starts, while an injected fetcher might finish despite being cancelled. Apple's Task.cancel documentation describes this cooperative behavior.

The example checks cancellation after the debounce and after the fetch. It also assigns each search a revision. Starting another search or explicitly cancelling advances that revision. Before publishing results, an error, or cleanup, the task verifies that its revision still matches the controller's current revision.

let found = try await fetch(requestedQuery)
try Task.checkCancellation()
guard let self, self.revision == requestRevision else { return }
self.results = found
self.isSearching = false
self.pending = nil

The controller is isolated to MainActor, so these state changes happen together in that isolation domain. Fetching remains asynchronous. The revision check is especially useful across an await, where another search can have started before the old operation resumes.

Errors and cleanup need the same rule

Protecting only successful results leaves two quieter bugs. An obsolete request can fail and replace a valid result with an irrelevant error. Or its cleanup can set isSearching to false while the newer search is still running. Clearing the stored pending task from stale cleanup can also lose the handle needed to cancel the current request.

For that reason, every completion path checks request ownership. Current errors are displayed; obsolete errors are ignored. Only the current request can clear its loading state or pending handle. Explicit cancellation updates the controller immediately rather than waiting for a service to acknowledge the signal.

Selection belongs to an identity

Result order changes. Two events can have the same title. Keeping a selected array index or comparing titles can therefore select a different event after results change. This example stores selectedEventID and resolves it against the current list.

The policy is deliberately simple: starting a new query clears previous results and selection. Clearing the query produces an empty idle state and invalidates pending work. A product could keep previous results while refreshing, but it would need to explain that distinction in its state model and tests.

Test the troublesome ordering directly

The seven tests use a controlled asynchronous fetcher. A test waits until a request starts, starts a second request, and chooses exactly when each one succeeds or fails. The fetcher intentionally ignores cancellation until the test resolves its continuation. This tests the failure mode that a polite mock service would conceal.

The checks cover late successful results, obsolete failures, stale cleanup, an empty query, selection by identifier, a current error, and cancellation during debounce. They passed with Swift 6.4 on macOS on October 2, 2026. No live server, iPhone runtime, SwiftUI adapter or performance benchmark was part of that validation.

The pattern applies anywhere an interface can supersede asynchronous work: search suggestions, filters, geocoding or remote detail loading. Each product still needs its own rules for retaining results, displaying errors, leaving a screen and restoring selection. The package makes one such set of rules explicit and testable.

Code and tests · Robin's professional background · robin.ac

Fitness event feeds: explicit dates, stable identity and visible conflicts

Robin Winters — 2026-10-02

Fitness event feeds: explicit dates, stable identity and visible conflicts

Robin Winters · October 2, 2026 · robin.ac

A map can look polished while the events behind it are ambiguous. Two feeds may repeat a record, supply different start times for the same event, or omit the timezone. Guessing produces a neat interface at the cost of hiding uncertainty. A better starting point is a small contract that makes each decision inspectable.

This article accompanies a standalone Swift teaching package, prepared with coding-assistant support. Its fixtures are synthetic. It is separate from private ShowFlex code and does not claim a customer deployment, an implemented product integration or measured performance improvements.

Start with the fields you can actually defend

The example accepts a provider ID, a feed ID, a title, a start timestamp, an optional end timestamp and an HTTPS source URL. The combination of feed ID and provider ID becomes the stable identity. Titles are display text; a matching title does not justify merging records. Different feeds can describe related real-world events, but cross-feed entity resolution requires evidence that this package deliberately does not invent.

The package normalizes the feed slug to lowercase and trims provider IDs while preserving their case. Neither ID may contain the colon used to join them. That keeps feed-a:event-17 unambiguous within the stated contract. A real service would also need to establish whether each provider guarantees stable IDs across updates and deletions.

Timezone ambiguity is a data state

2027-03-14T10:00:00-07:00 has an explicit offset and can be represented as 2027-03-14T17:00:00Z. A timestamp without an offset does not establish that instant. The example rejects it instead of using the machine's local timezone. It also rejects invalid calendar dates rather than allowing them to roll into a different day.

An unknown end time remains absent. Adding a guessed two-hour duration would manufacture information. If an end is supplied, it must be later than the start. Date-only events, recurring schedules, named timezones and fractional seconds need their own policies; unsupported timestamp forms are rejected here.

UTC output makes the normalization reproducible. A calendar or mobile interface would still need a deliberate display-timezone policy. That interface work is outside this package's execution evidence.

A duplicate and a conflict deserve different treatment

Two valid rows with the same identity and the same normalized payload are retransmissions. Keep one event and issue a duplicate receipt for the other row. Equivalent explicit-offset timestamps and collapsed title whitespace can produce an identical normalized payload.

Two different valid payloads with the same identity are a conflict. The example removes that event from accepted output and marks every related valid row as conflicted, including a duplicate already seen earlier. No row wins simply because it arrived first. Permuting the input order therefore cannot choose a different accepted version of that conflicting identity.

This is a teaching policy, not the only useful production policy. A provider revision number, authenticated correction or trusted snapshot might establish a winner. Without that evidence, a quarantine is easier to explain than a silent overwrite.

Return a receipt for every row

The output includes sorted accepted events and one receipt per input row: accepted, duplicate, conflict or rejected. Each receipt records the input index and a reason. A rejected row can therefore be traced to the input rather than disappearing into an apparently successful empty array.

The supplied five-row fixture produces one accepted event, one duplicate receipt, two conflict receipts and one invalid-date rejection. Invalid JSON exits with status 1 and produces no successful JSON report. That distinction matters when a command-line tool is used in a larger workflow: malformed input and a valid feed containing no accepted events are different outcomes.

Keep provenance narrower than proof

The source URL is retained as a retrieval pointer. The package rejects non-HTTPS URLs, embedded credentials and fragments. It does not fetch those URLs, authenticate a provider or establish that a claimed event exists. Every fixture URL uses the reserved example.org domain.

Storing provenance is a useful first step toward investigating a record. It should not be described as verification of that record. A production ingestion system needs provider authorization, versioned snapshots, update and deletion rules, observability and retry behavior alongside its field validation.

Evidence a reviewer can inspect

On October 2, 2026, the package passed 12 Swift Testing checks on macOS with Swift 6.4. The checks cover timezone equivalence, retransmissions, conflict propagation and ordering, source-scoped identity, malformed dates, missing offsets, end-time rules, URL restrictions, unknown ends and sorted output. The command-line fixture and malformed-JSON failure path were also exercised. The repository includes fixtures and verification details.

These results describe this educational package. They do not establish iPhone-device execution, Linux execution, an App Store release or an improvement to an existing product. The value of the example is that its contracts and failure decisions are small enough to inspect and reproduce.

Professional work and evidence · Full writing index · Source package

In iOS 27 and Xcode 27 Liquid Glass will be applied to your app automatically.

Robin Winters — 2026-06-30

In iOS 27 and Xcode 27 Liquid Glass will be applied to your app automatically.

By Robin Winters

First published June 30, 2026 on LinkedIn. Republished October 2, 2026 with original wording, images and captions. Technical observations and opinions retain their original context.

Apple's Liquid Glass Design Language

The grace period for opting out is over and Liquid Glass will be applied to your app automatically, like it or not.

In all honesty I didn't really understand Liquid Glass when it was announced at dub dub last year. However, after several developer events including "one on one's" and lab appointments at Apple campus, I've come around to it.

Below is a somewhat impromptu look at how I've implemented Liquid Glass into my projects. Important to note that I'm usually running the developer beta of whatever I'm building for/in, including Xcode, and things are subject to change before public updates go out. CYA.

Like a lot of other devs, I've been tinkering with all the new fine tuning features in iOS/Xcode 27, and there's a LOT to go over. Most importantly, imo, is the Device Hub.

It's...glorious.

Not to gush, but the Device Hub has been on many a wish list and Apple delivered. Testing is one of my favorite things to do during the development process, and being able to visually poke at UI/UX across devices and OS iterations, and tweaking the accessibility features is just "Chef's Kiss" for me.

Anyway!

I've tried to use Liquid Glass as minimally as possible. As a design principle, I want the UI to get out of the user's way so the content and UX are the primary focus. For ShowFlex, the strongest use is in the global navigation layer. The floating header orb and bottom tab bar use GlassEffectContainer, circular .glassEffect, glassEffectID, and matched geometry so the app’s primary controls behave like native system surfaces. The controls sit above constantly changing content. Event/News feeds, rosters, athlete cards, event details, and social views. Liquid Glass lets the chrome hangout in reach without becoming heavy, and it gives taps, expansion, collapse, and selection changes a physical feel.

Watch this video in the original LinkedIn article

I call it "Bloopy"

I try to not overuse it. Dense content surfaces, especially the athlete lineup cards in the above video from the app, often keep a stable filled background and add a lighter custom glass edge treatment instead of full translucency, but the clear material modifier looks pretty cool with bright colors and patterns passing underneath it. Adjust as needed, especially using/testing with Device Hub, to keep things readable and fast in scan heavy areas while still giving the product the same polished visual vocabulary. For more focused surfaces like auth gates, I used native glass more directly b/c those elements benefit from a stronger sense of elevation and touchability. "Touchability" is a word now, just like "Bloopy" which is what I call the animation effect for the tab bar at the bottom of the screen.

It's basically a question of hierarchy. Glass marks interactive surfaces as touchable, while content cards stay legible. Interactive glass is mostly reserved for things the user acts on like passive surfaces using regular glass or edge highlights.

There’s also a shared adapter layer sfGlass applies native .glassEffect and keeps an .ultraThinMaterial fallback for older probes. That wrapper is used for practical control surfaces like search bars and sheets. A custom liquidGlassEdge and lightweightLiquidGlassEdge modifiers keep the existing solid card background, then add rim/highlight treatment for depth without making dense list content fully translucent.

Watch this video in the original LinkedIn article

Auth screen

On the main auth screen Liquid Glass is used as the control layer over a video backdrop. It renders a looping video background, darkens it with a black overlay, then places the branding and auth controls directly on top, letting the screen feel cinematic while the glass controls pick up the background motion/material instead of hiding it. I think about it like applying an optical illusion to a control surface so we're not blocking the action going on in the back, but also keeping the layers separate.

That's it for now!

Apple says pretty specifically to not overuse the material modifier and to use native as much as possible. Group menus and effects so rendering doesn't bog the device down, and keep in mind the accessibility features as they can fundamentally change the UI/UX. Use Device Hub and Instruments to pick out and shave off hangs and root out resource hogs. Biggest takeaway: Less is more. Get out of the user's way and let the device do the work with native implementations over custom jobs.

Build accordingly and have fun!

🤘Robin

All writing · Original LinkedIn edition