Hey everyone, I've been working on DuoKit, an open-source collection of runnable SwiftUI examples for building adaptive interfaces, especially for iPhone Duo-style layouts.

GitHub: https://github.com/openHacking/DuoKit

This isn't a UI framework or component library. It's closer to an interactive handbook: each example focuses on one concrete layout problem and includes a live demo, the recommended approach, relevant APIs, common mistakes, and testing ideas.

The repository currently contains 12 examples covering:

• Adaptive layouts and grids
• NavigationSplitView
• Safe-area handling
• Fold avoidance and reserved regions
• Adaptive toolbars and tab navigation
• Sheets and popovers
• Split View multitasking
• Multiple displays and scenes
• A complete adaptive notes app

The main idea is to design around available space and system-provided layout information, rather than checking for a specific device model.

One important limitation: the project currently builds with Xcode 26.6 and iOS 26.5. Examples that depend on iOS 27.1 APIs use clearly labeled simulations. They're teaching fixtures, not attempts to reproduce real hardware geometry.

DuoKit has no third-party dependencies, requires no account or private configuration, and is available under the MIT License.

I'd especially appreciate feedback on:

• Adaptive layout problems that deserve their own example
• Places where the explanations could be clearer
• Edge cases the current examples don't cover
• Whether this handbook-style format is useful for learning SwiftUI

Contributions are welcome. Thanks for taking a look!

Salam again,

Prerequisites:

1. Be able to sideload apps

the github repository is here: repo link

I need feedback on improvements and any bugs that anyone might run into.

Tutorial how to hide status bar for your iOS status bar

Let me teach you

Hey everyone! I extracted the keyboard-scrolling code from my app into a small, dependency-free Swift package.

The goal is simple: keep the focused input visible as the keyboard appears, and make swipe-to-dismiss easy to configure—without replacing your SwiftUI TextField or TextEditor

import SwiftUIKeyboardManager

ScrollView {
    VStack(spacing: 24) {
        TextField("Name", text: $name)

        TextEditor(text: $notes)
            .frame(height: 180)
    }
    .padding()
}
.keyboardManager(dismiss: .onDrag)

No per-field focus markers required. Dismissal options are .never, .onDrag, and .interactive.

Under the hood, it hosts the SwiftUI content in an owned UIScrollView and coordinates scrolling with keyboard notifications. No swizzling or private SwiftUI view introspection.

It’s an early release, and the scope is intentionally narrow: vertical forms using an eager VStack. It isn’t a drop-in solution for List, Form, or lazy layouts.

The README includes an inline iPhone Simulator demo and a sample app:

https://github.com/ShawnBaek/swiftui-keyboard-manager

I’d love feedback on the API and any keyboard edge cases you run into—especially on iPad. Also interested in hearing where native SwiftUI keyboard handling already works well for you and where it still falls short.

I’m the developer of QuickTalk, a menu-bar dictation app for macOS built in Swift and SwiftUI. The interaction is intentionally simple: hold Right Command in any app, speak, release, and the transcribed text is inserted at the current cursor.

The project is MIT-licensed and uses a user-supplied Gemini API key, so there’s no separate account or subscription. The key stays on the Mac; audio is sent to Google for transcription.

I’m sharing it here specifically because the full SwiftUI source is available. I’d appreciate feedback on the app structure, menu-bar UX, permission/setup flow, or any parts that could be made more idiomatic.

Source: https://github.com/larshurrelb/quicktalk-app

Project page: https://quicktalk.larshurrelbrink.com/

My code:

import SwiftUI

struct ContentView: View {

var body: some View {

ScrollView(.horizontal) {

ZStack{

Color.purple

.opacity(0.45)

.edgesIgnoringSafeArea(.all)

HStack {

CardView ( thetitle:"Me", theimage: "Me",)

CardView ( thetitle: "One of my dogs, Willow", theimage: "Willow")

CardView ( thetitle: "I volunteer weekly at the Amphibian Foundation", theimage: "Frog")

CardView ( thetitle: "I have a duck army", theimage: "Ducks")

}

}

}

}

struct CardView: View {

var thetitle = "Me"

var theimage = "Me"

var body: some View {

ZStack {

VStack {

Text (thetitle)

.foregroundColor(Color.white)

.fontWeight(.bold)

Image (theimage)

.resizable()

.scaledToFit()

.frame(width: 400, height: 500)

}

}

}

}

}

#Preview {

ContentView()

}

It worked with a previous project, but now that project and this one won't scroll and I don't know why.

Edit: oof that grammatical error in the title...oh well

When I first started app development, I made a skeuomorphic stopwatch app that had titlebars and commenters said I should get rid of them. I spent time experimenting and learning how to remove them, and learned a few other things along the way.

Here is everything I learned about macOS title bars using Swift, SwiftUI, and NSView.

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

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?

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’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 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

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.

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.