Source Code: https://github.com/mrosenbergtech/Headscapades

Solo dev. My iOS + watchOS UI is pure SwiftUI, but the whole session brain — programs, exercise models, the workout engine, command validation — lives in a shared Kotlin Multiplatform core (Android reuses it). Wiring SwiftUI up to a non-Swift core taught me a few things about keeping the SwiftUI layer from turning into glue code:

1. One observable state object, not a hundred calls. My first pass sprinkled fine-grained calls to the shared core all over my views and it got ugly fast — nullability bridging, async handlers, the works. Collapsing it to a single ObservableObject that publishes one session-state struct, with views sending back a handful of coarse commands, made the SwiftUI side clean and declarative again. Views just render state and fire intents; all the messy bridging hides behind that one object.

2. The workout clock lives on-device, and SwiftUI just reflects it. watchOS ↔ iPhone links drop constantly. I learned not to let a view's timer depend on sync — the session engine ticks locally and my @Published state updates from it, so the UI keeps counting even when the phone's gone. SwiftUI's job is only to reflect state, never to own it.

3. Small @Published surface = smooth watch UI. On watchOS, publishing a big state object on every tick caused more re-renders than I wanted. Splitting the hot values (elapsed time, current set) into their own fine-grained published properties kept the watch views buttery without over-invalidating.

Questions for the SwiftUI/watchOS folks:

• For a long-running (60–90 min) session, how are you structuring the view + runtime so watchOS doesn't suspend you mid-workout?
• Anyone found a genuinely clean pattern for bridging async/suspend work into @MainActor SwiftUI state without a pile of completion handlers?

Happy to go deeper on the SwiftUI structure or the interop. (It's live + free on both stores if seeing it running helps — I'll drop the link in a comment so this stays a SwiftUI thread.)

I kept dreading App Store screenshots, so I built a tool for it.

Taking the shot was never the slow part. The slow part was getting the app
into a state worth photographing — a month of history, a streak, the paid tier.
So I stopped driving the app and started rendering the views.

shotBoth("home") { HomeView().environmentObject(thirtyDays()) }
shot("paywall", dark: true) {PlusSheet().environmentObject(PlusStore(active: true)) }

An Apple silicon Mac runs iOS binaries natively, so each view is drawn
through UIHostingController at device size. No simulator, no navigation,
nothing installed. Your coding agent writes that script, not you.

It doesn't make store artwork — no backgrounds, no captions, just the screen
as a device draws it. And if you ship once a year in one language, doing it
by hand is faster.

The rendering tool I created this time：Bakeshot

Hello,

I’m trying to reproduce this view on Swift, but I always get to this rendering... How to separate the 3 elements?

I kept looking these up one at a time so I made a table. Portrait pixels; landscape is the same numbers swapped.

- iPhone 6.9" — 1260 × 2736 (also accepts 1290 × 2796 and 1320 × 2868). Required for iPhone apps; Apple scales it for smaller iPhones.
- iPhone 6.5" — 1284 × 2778 (also 1242 × 2688). Optional if you provided 6.9".
- iPad 13" — 2064 × 2752 (also 2048 × 2732). Required for iPad apps.
- iPad 12.9" (2nd gen) — 2048 × 2732. Optional; scaled from 13" if you skip it.
- Mac — 2880 × 1800 (16:10; 2560 × 1600, 1440 × 900, 1280 × 800 also accepted)
- Apple TV — 1920 × 1080 or 3840 × 2160
- Vision Pro — 3840 × 2160

Files: flattened PNG or JPG, RGB, no alpha channel — an alpha channel is the #1 reason an upload gets rejected on the spot.

Source: App Store Connect Help → Screenshot specifications, checked Sept 5, 2026. If Apple changes one, tell me and I'll edit.

I need the screen bounds to be sent when initialising my viewmodel. I know to get the size from geometry reader. But that is only available after the view is created. is there a way to send the screen size within the init scope?

a solution I found over the internet was to use a separate function in my viewmodel for the initialisation and call it on .onAppear.

EDIT: I am trying to make a game where an object is randomly generated within the screen and moves. So I want it stay within screen bounds

Hey everyone,
I need your help figuring out what is happening in my app.
I have been vibe-coding (yes yes, I know, I'm just a designer trying to build stuff), and normally I'm good at reverse engineering and figuring out the issues, but for this one, I just don't get it.

It looks like my tab items have a glow in an active state, but when pressed down, it shows as if there's a copy of the icon + label on top/behind the existing one.

Cursor says this is the accessibility one, but I tried commenting it out, and it still did not remove it.
I've never seen this behaviour in any other apps, so it's not a default thing, I think.

I tried removing the "pinkCoral" branding, and then I am left with 2 white icons and labels on top of each other, and with the glow.

Anyone that could help point in a direction I need to look to remove the second one?

Tab view setup

TabView(selection: $navigation.selectedTab) {
    Tab("Home", systemImage: "fireplace.fill", value: .home) {
        HomeView()
    }
    Tab("Journal", systemImage: "book.closed.fill", value: .journal) {
        JournalView()
    }    Tab("Community", systemImage: "person.2.fill", value: .community) {

        CommunityView()
    }
    Tab("Settings", systemImage: "gear", value: .settings) {
        SettingsView()
    }
}
.background(TabBarConfigurator())

Global UITabBar appearance (set at launch)

let coralPink = UIColor(/* #FFA4B5 */)

let tabBar = UITabBarAppearance()
tabBar.configureWithTransparentBackground()
tabBar.backgroundEffect = nil
tabBar.shadowColor = .clear

let itemAppearance = UITabBarItemAppearance()
itemAppearance.normal.iconColor = UIColor.white.withAlphaComponent(0.5)
itemAppearance.normal.titleTextAttributes = [
    .foregroundColor: UIColor.white.withAlphaComponent(0.5)
]
itemAppearance.selected.iconColor = coralPink
itemAppearance.selected.titleTextAttributes = [
    .foregroundColor: coralPink
]

tabBar.stackedLayoutAppearance = itemAppearance
tabBar.inlineLayoutAppearance = itemAppearance
tabBar.compactInlineLayoutAppearance = itemAppearance

UITabBar.appearance().standardAppearance = tabBar
UITabBar.appearance().scrollEdgeAppearance = tabBar
UITabBar.appearance().tintColor = coralPink
UITabBar.appearance().unselectedItemTintColor = UIColor.white.withAlphaComponent(0.5)

Attempted fix (didn't remove the double icon+label)

/// Walks the UITabBar and tries to kill Large Content Viewer.
private static func configureTabBarSubview(_ view: UIView) {
    if let control = view as? UIControl {
        control.showsLargeContentViewer = false
    }
    if let button = view as? UIButton {
        button.showsLargeContentViewer = false
    }

    for interaction in view.interactions {
        if interaction is UILargeContentViewerInteraction {
            view.removeInteraction(interaction)
        }
    }

    for subview in view.subviews {
        configureTabBarSubview(subview)
    }
}

I’m talking about the ones that offset the view in or out. .slide is at the front of my mind for this

The reason it is lame is because of the distance it travels before being yanked from the view tree.

You would think that Apple, as the gods of this system with access to any device data they need, would ensure view traveled far enough to be out of sight before vanishing.

However it seems that Apple chose not to look at the parent view’s width when deciding how far the transitioning view should travel. Instead they used the view’s own width. It travels its own width and then vanishes. But how does that make any sense? What does its own width have to do with anything. If I want a view to transition out then obviously I want it to travel far enough to be one point beyond its parent view’s edge.

I just do not know why Apple designed it the way they did. Travelling its own width feels like a completely arbitrary bodge.

What happened to good enough is not enough, Apple?

I’ve just released the first public beta of Roam Control, an open-source SwiftUI app for location-based development and QA testing on a physical iPhone.

It supports fixed locations selected through MapKit search, coordinates or a map pin, plus simulated Apple Maps walking routes with pause, resume, reverse and redirect controls. It also includes favourites, history, interrupted-session recovery and native on-device pairing.

The interface is written in SwiftUI and MapKit. Device pairing and location sessions use a narrow Rust-to-Swift bridge around the open-source idevice library.

Source code:
https://github.com/seanhowarthdev/Roam-Control

Beta 1 release:
https://github.com/seanhowarthdev/Roam-Control/releases/tag/v0.9.0-beta.1

It currently requires iOS 27, Developer Mode, LocalDevVPN and either SideStore or Xcode for installation.

I’d especially appreciate feedback on the onboarding, pairing flow, map controls and walking-route experience. Please don’t include pairing records, credentials or private locations in reports.

Quick update on CoreDataBrowser: it's officially live on the Mac App Store!

A few months ago I shared a side project I’ve been working on to solve a common iOS dev headache: inspecting local data in the Simulator without digging through nested AppData folders or writing custom scripts.

It lets you inspect: • Core Data databases • SwiftData storage • UserDefaults values

It’s completely free, native for macOS, and 100% open-source

If you want to give it a try or share feedback, you can download it here:https://apps.apple.com/app/coredatabrowser/id6807113765

GitHub repo:https://github.com/kyletaylor94/CoreDataBrowser

I just released v0.2.0 of enriched-markdown-ios - SwiftUI Markdown renderer powered by TextKit 2.

New in this release:
🔸 GFM Tables
🔹 Task lists
🔸 Superscript & subscript support

💎 Available via Swift Package Manager!

.package(
  url: "https://github.com/software-mansion-labs/enriched-markdown-ios.git", 
  from: "0.2.0"
)

GitHub & Docs:https://github.com/software-mansion/enriched-markdown/blob/main/packages/enriched-markdown-ios/README.md

What features or syntax support would you like to see next? I'd love to hear your thoughts! If you find the library useful, a ⭐️ on GitHub is always appreciated.

I just finished work on a Swift Package called SwiftEDR. It helps you to leverage increased raster bit depth, improve color tonality in Canvas, or add HDR effects to any non-HDR SwiftUI view.

It's got a useful example app to help explore the effect, and is incredibly lightweight and easy to apply to your own apps. I hope you find it useful!

https://github.com/Jiropole/SwiftEDR

One thing I keep running into with SwiftUI work is that screenshots lose the part that matters. They show the pixels, but not which view I mean, the current navigation state, or what should stay untouched.

I’m building an open-source tool called Monad Design around a more direct loop. You run an existing iOS project in Simulator, navigate to the real screen, select a view or annotate the area, and describe the change there. The coding agent still edits the SwiftUI source in the existing repo, then rebuilds the same target for review.

The most useful case for me is subjective UI work. I can keep the original next to a few source-backed variants, compare them in the same screen state, and choose one before treating anything as final.

The app is the canvas. There isn’t a separate mockup that has to be translated back into SwiftUI.

Source: https://github.com/Monadix-AI/monad-design

Short demo: https://watchclueso.com/embed/pio8jqfcg4ivj0r1

It currently runs locally on macOS and works with Xcode and Expo iOS projects. I’m building Monad Design, so this is a project post rather than an unaffiliated recommendation.

Hey everyone,

I recently open-sourced RedeemDeck, a native SwiftUI app for managing App Store Connect offer codes and promo codes.

It imports CSV exports from App Store Connect, organizes codes by app and offer, and lets you request an exact quantity before copying, sharing, or saving them as QR posters. I designed the main workflow around getting codes quickly instead of browsing through a long inventory list.

The app is built with SwiftUI, SwiftData, Swift concurrency, Core Image, and Vision. It runs on iPhone, iPad, and Mac, has no third-party package dependencies, and stores everything locally.

RedeemDeck is based on Matteo Comisso’s CodeVault. I preserved the original MIT attribution and substantially rebuilt the workflow and implementation.

GitHub:
https://github.com/jinwandalaohu66/RedeemDeck

Original project:
https://github.com/mcomisso/CodeVault

I’d love feedback on the SwiftUI navigation and state flow, especially the separation between the quick “Get” flow and full code management.

I really like the way Arc Browser handles Spaces: a horizontal rail where you can switch between workspaces with a click or a trackpad gesture.

I wanted the same interaction in a native macOS app, so I built it in SwiftUI and extracted it into a standalone package.

SpacesRail is an open-source recreation of that UI, built for macOS 14+ with SwiftUI/AppKit.

A surprisingly annoying part was getting two-finger horizontal gestures to work correctly when the pointer is over nested ScrollViews, without breaking their normal scrolling behavior.

It’s small, dependency-free and MIT licensed.

GitHub: https://github.com/nexion-one/SpacesRail

Hey everyone! 👋
I’ve been building Mooziac, a music player designed specifically for macOS.

GitHub: https://github.com/shirkeharsh/mooziac

I wanted something that felt more like a Mac app rather than a web app wrapped in a desktop window, so I built it natively in Swift and focused on keeping the interface simple and lightweight.
What makes it different
Native Swift + AppKit — Universal build for Apple Silicon and Intel
Privacy-focused — no analytics, tracking or remote logging
Local-first — playlists and listening history stay on your Mac
YouTube Music + local music in one player
FLAC, MP3, WAV, AAC and M4A support
Synchronized .lrc lyrics
Interactive waveform for seeking through tracks
Trackpad edge gesture for volume control with haptic feedback
Discord Rich Presence
Menu bar interface for quick access

The project is open source under the MIT license, so the source is available for anyone who wants to look through it, report an issue, suggest something, or contribute.

I'm building the completed state of a Live Activity and I want the text tucked up next to the sensor housing, like the second screenshot. What I actually get is the first one: the row starts below the cutout, which makes the whole island taller than the design needs.

I've spent a long evening on this and measured a lot of it, so here's what I found in case it saves someone else the time — and in case someone can tell me the bit I'm missing.

Measurements (iPhone 17 Pro, iOS 27 SDK, expanded presentation):

• The island is 371pt wide. The sensor housing is ~125pt wide and ~37pt tall, leaving ~123pt of usable width each side.

• Content in DynamicIslandExpandedRegion(.leading) starts ~36pt down — i.e. the region's own top edge is already below the housing. That number tracks the housing height almost exactly.

• .leading content reaches ~113pt of the ~123pt available before truncating, so truncation happens ~9pt short of the cutout. It's a slot budget, not a collision with the camera.

• The HIG documents the expanded height range as 84–160pt; I measured 67pt on device, below the documented floor, so the system is clearly computing this itself.

What I tried, all of which failed to move the row up:

1. DynamicIslandExpandedRegion(.leading, priority: 1) + .dynamicIsland(verticalPlacement: .belowIfTooWide) — the combination in most of the blog posts about this. Changes which content wraps below, not where the region starts.

2. .belowIfTooWide on just the Text views instead of the region.

3. .frame(maxWidth:) and .layoutPriority() on the text. The docs actually say these don't apply in a Live Activity, and they don't.

4. A definite .frame(width:). This does matter, but for a different reason — see the gotcha below.

5. Cutting content down to a single short label so nothing could possibly need the space. Still starts below the cutout.

6. Shrinking the leading image from 56pt to 44pt to free width. Frees width, changes nothing vertically.

7. Negative .offset(y:). Moves the content within its slot but it clips at the slot bounds — the rectangle doesn't grow upward.

8. Trimming the text's line box so it could sit higher: .lineHeight(.multiple(factor:)) and a hand-rolled cap-height-to-baseline trim. lineHeight eats from the bottom — the glyph top moved 39.7pt → 40.3pt, i.e. the wrong way. Deleted both.

9. Declaring different regions conditionally to swap layouts. DynamicIslandExpandedContentBuilder rejects control flow outright: "Closure containing control flow statement cannot be used with result builder."

The conclusion I've landed on is that WidgetKit computes each region's rectangle from the island's geometry before measuring your content, and the .leading rectangle's top edge is placed below the sensor housing by construction. Nothing applied to the content can move it, because the content never gets a say.

Which leaves the actual question: is there any supported way to get content into that band beside the cutout? The system does it — the Phone app's incoming-call UI has a green timer sitting high up next to the housing — but I assume that's system UI rather than an ActivityKit presentation, and therefore not reachable.

Unrelated gotcha worth knowing, since it also made my island taller: a self-updating Text(timerInterval:) reserves layout width for the widest value its range can produce, not the value on screen. I handed it a 30-day range and it reserved room for 719:59:59. Because the system keeps the island symmetrical, that reservation grew it on both sides — 16pt of extra height for a number that read 30:00. Only a definite .frame(width:) bounds it.

Current layout, which does work — image in .leading, text in .center, button in .trailing:

DynamicIslandExpandedRegion(.leading) {
    BreakLeadingMark(display: display, size: 56, iconSize: 20)
        .frame(width: 56, height: 48)
}
DynamicIslandExpandedRegion(.center) {
    BreakCompleteSummary(display: display)
        .frame(maxWidth: .infinity, alignment: .leading)
}
DynamicIslandExpandedRegion(.trailing) {
    LogButton()
        .frame(maxWidth: .infinity, alignment: .trailing)
}

.center is sized first from the leading/trailing minimums, so a long string there truncates rather than widening the island — which is fine for English and will be a problem the moment this is localised.

Help.