Bonjour à tous,

Je viens de lancer Five (fivepro.link). Je le précise tout de suite : c'est mon projet, je ne suis pas neutre.

Le problème de départ : beaucoup de petites entreprises font du bon travail, mais leur fiche Google ne le montre pas. Les clients contents oublient de laisser un avis, et personne n'a le temps de relancer chacun à la main. Les mécontents, eux, n'oublient pas.

Ce que fait Five :

• après chaque prestation, une demande d'avis part par email au nom de votre entreprise, avec 5 étoiles à toucher directement dans le message ;

• sans réponse, une seule relance deux jours plus tard, jamais plus ;

• le client note en 30 secondes, sans compte ni application. Avec 4 ou 5 étoiles, il est invité à publier sur Google ;

• avec une note basse, il peut d'abord vous écrire en privé, et vous êtes alerté tout de suite pour le rappeler. Il reste libre de publier son avis quand il veut : Five ne bloque aucun avis ;

• vous pouvez aussi envoyer la demande par SMS ou WhatsApp en un geste, importer votre fichier Excel du mois, ou utiliser un QR code ou une plaque NFC sur place.

C'est pensé pour les artisans, les agences d'intérim, les formateurs et les commerçants. Prix : à partir de 19 € par mois (soit 64 centimes par jour), sans engagement, avec un essai gratuit de 14 jours sans carte bancaire.

Ce que j'aimerais savoir :

• Aujourd'hui, comment demandez-vous des avis à vos clients ? Ça marche ?

• Qu'est-ce qui vous ferait essayer (ou pas) un outil comme ça ?

• Qu'est-ce qui manque, d'après vous ?

Toutes les critiques sont bienvenues, même dures. Merci d'avoir lu !

I built peek (open source, my project) because I don't have a Mac but wanted to iterate on SwiftUI without rebuilding and sideloading an IPA after every change.

You run "peek dev MyApp/" on Linux and save a file; about a second later the view on your iPhone updates. It's the real SwiftUI on a real device, so animations, gestures and the iOS 26 tab bar behave like they do in your app. It handles Preview blocks, UIKit views, or the whole app, with SwiftPM packages, macros and resources, and print() output shows up in the terminal.

It cross-compiles your code into a dylib with swiftc and xtool's iOS SDK, signs it with your free Apple ID certificate, and a small host app (SideStore, AltStore or LiveContainer) loads it.

https://github.com/kimikr/peek

Only tested on my own phone so far (iOS 27, in LiveContainer). Feedback welcome, especially from anyone running it outside LiveContainer.

Hi all. I've been building SwiftUIWeb, an open-source framework that lets you describe screens with SwiftUI's own names (View, State, Observable, NavigationStack, NavigationSplitView, List, Table, Charts, MapKit, ...) and run them in the browser. The app compiles with Embedded Swift to WebAssembly, runs in a Web Worker, and renders ordinary DOM laid out by CSS (not a canvas).

The video runs Apple's Food Truck sample three times: iPhone, iPad, then the web, from the same sources. The sample is Apple's code with a short list of adaptations, documented in the example's README (mainly Combine -> Observation, plus stand-ins for StoreKit, WeatherKit and passkeys that have no browser counterpart). The point of the exercise was to find what SwiftUI the framework was missing, so those gaps were closed in the framework.

Things I'd rather you hear from me:

• It's a preview; the API may still change before 1.0.

• The first download is large compared with JS frameworks (about 400 KB Brotli for a counter, ~930 KB for the component playground). In my React comparison a small board app transfers 552 KB against React's 57 KB; interactions after load are on par. Smaller output is the top roadmap item.

• No Combine, UIKit or AppKit; no SwiftData, WidgetKit, App Intents, CloudKit, Metal.

• Needs the swift.org Swift 6.4 toolchain and its WebAssembly SDK (Xcode's compiler doesn't build wasm).

Repo (MPL-2.0): https://github.com/Vitorsilveira31/SwiftUIWeb Food Truck example: https://github.com/Vitorsilveira31/SwiftUIWeb/blob/main/Examples/FoodTruck/README.md

I'd love feedback, especially on SwiftUI APIs that behave differently from Apple's.

Edit: the first version of this post bound $app.showIcon straight to the @Published property, which caused an endless redraw loop (about 97% CPU). The code below is corrected; details at the end of the fix section. Sorry if you copied the earlier version.

My menu bar app has a "Show in menu bar" toggle, and opening the app again from Finder is supposed to bring a hidden icon back. The usual pattern: MenuBarExtra(isInserted:) bound to @AppStorage, and the app delegate flips the stored value on reopen.

// App
@AppStorage("showIcon") private var showIcon = true
MenuBarExtra(isInserted: $showIcon) { ... }

// AppDelegate
func applicationShouldHandleReopen(_ sender: NSApplication, hasVisibleWindows: Bool) -> Bool {
    UserDefaults.standard.set(true, forKey: "showIcon")
    ...
}

It passed my tests, because I always started with the icon visible and hid it from Settings. It failed when the app launched with the icon already hidden: the handler ran (I logged it), the value went to true, and it was false again before defaults read polling every 100 ms could see it. Deferring the write by 0.3 s didn't help. Weirder: a defaults write from Terminal while the app was running did stick.

So I added a KVO observer on the key and logged Thread.callStackSymbols on every change. The false was written by SwiftUI itself:

-[NSUserDefaults setObject:forKey:]              // showIcon = false
UserDefaultLocation.set(_:transaction:)
Binding.wrappedValue.setter
MenuBarExtraController.observeValue(forKeyPath:of:change:context:)
NSKeyValueDidChange
_NSSetBoolValueAndNotify
MenuBarExtraController.updateConfiguration(_:environment:)
AppMenuBarExtrasController.updateMenuBarExtras(namespace:sceneList:)
AppDelegate.appGraphDidChange()                  // SwiftUI's, not mine
GraphHost.flushTransactions()

During a normal graph update, MenuBarExtraController sets a Bool on its status item, its own KVO observer fires, and it writes the item's state back through the isInserted binding. The scene still had the old value at that point, so what went back was false. That last part is my reading (I can't see SwiftUI's source), but the stack is clear about who wrote it.

The fix was to stop having two writers. The flag is now one @Published property that the scene observes, and reopen, the Settings toggle and Restore Defaults all go through it:

final class Controller: ObservableObject {
    static let shared = Controller()
    @Published var showIcon: Bool {
        didSet { UserDefaults.standard.set(showIcon, forKey: "showIcon") }
    }
    ...
}

@main
struct ScrollrApp: App {
    @NSApplicationDelegateAdaptor private var delegate: AppDelegate
    @ObservedObject private var app = Controller.shared

    var body: some Scene {
        // MenuBarExtra writes isInserted back on every update, so skip equal writes
        MenuBarExtra(isInserted: Binding(
            get: { app.showIcon },
            set: { if $0 != app.showIcon { app.showIcon = $0 } }
        )) { ... } label: { ... }
        Settings { ... }
    }
}

// AppDelegate
func applicationShouldHandleReopen(_ sender: NSApplication, hasVisibleWindows: Bool) -> Bool {
    app.showIcon = true
    ...
}

Now the scene gets true in the same update that inserts the item, and the value sticks.

The equality check in the binding matters. My first version bound $app.showIcon directly, and Scrollr sat at about 97% CPU while idle: MenuBarExtra writes isInserted back on every update, @Published announces a change even when the value is the same, the scene updates again, and so on forever. A CPU sample showed exactly that cycle. Skipping equal writes breaks it (back to 0% idle).

Two smaller things from the same code:

• OpenSettingsAction only exists in the environment, so the delegate can't make one. The menu bar label captures it in .onAppear and hands it to the delegate, which calls it on the next run loop turn after showing the icon.

• AppKit also stores the status item's visibility in your app's defaults (NSStatusItem VisibleCC Item-0 on macOS 27). Deleting it didn't change this bug, but it's worth knowing when you're poking at menu bar state.

Tested on macOS 27.2 / Xcode 27.2. The app is Scrollr, a small open-source (MIT) utility that reverses mouse wheel scrolling but leaves the trackpad alone: https://github.com/atuuuuuuu/Scrollr (fix in commits 000fd62 and fd29bb8, files ScrollrApp.swift and Controller.swift).

Has anyone else run into MenuBarExtra writing its binding back like this? Curious whether there's a cleaner pattern than moving the state into an ObservableObject.

I have been building Rimline, a menu bar app for macOS where the edges and corners of the trackpad are programmable. The whole UI, including the settings and the on-screen HUD, is SwiftUI, with a thin layer underneath for reading raw touch positions.

Things that were harder than I expected:

- Telling a deliberate edge slide from a palm or a resting thumb. I ended up with a typing guard that ignores the pad while keys are being pressed.

- Hold a corner, slide toward a place on the screen, show an outline, and move the window on lift. The outline overlay was the fiddly part.

- Rules that switch layouts on their own (headphones connected, external display, frontmost app, time of day) and put everything back when the rule ends.

Universal build, macOS 13 and later. Happy to go into any of these if people are curious, and I would like feedback on the HUD design.

It is called Rimline, page at rimline.zawalid.com

I built this onboarding interaction in SwiftUI. The globe rotates under a ring of lettering, reacts to a press or drag, and zooms through the screen when you tap the button.

Here's how the SwiftUI version works:

1. A TimelineView with the animation schedule asks a motion driver for the current frame. The driver supplies rotation, zoom, the text-ring angle and touch effects, so the renderer and the surrounding SwiftUI controls use the same frame state.

2. The globe is a Metal shader applied with SwiftUI's .colorEffect to a Rectangle. ShaderLibrary passes in the view size, globe centre, radius and motion parameters. The land and lettering are sampled from two signed distance field textures: a 2048 x 1024 land map and a 4096 x 256 text strip.

3. DragGesture(minimumDistance: 0) handles touch-down, movement and release. A press slows the rotation and zooms the globe in. Dragging turns it; release velocity feeds the fling. A tap starts a ripple, while a held press reveals the night lighting and connection arcs.

4. The zoom uses a damped spring in the motion driver. The SwiftUI button has its own pressed scale and spring, then triggers the globe's zoom transition.

5. accessibilityReduceMotion pauses the animated TimelineView. The globe stays still, the button's moving gradient stops, and a press switches to the night state immediately.

The land data comes from Natural Earth. This is an implementation study based on an onboarding reference; I don't have the original designer's credit.

XCUI practitioners rejoice

Hey everyone,

We just open-sourced MotionSwift, something we put together to get native rendering performance without relying on Remotion and headless Chrome.

We've been using it in our day-to-day video production pipeline, and so far we're seeing roughly 10–20x faster renders while using only about 10% of the memory compared to the Remotion + Chrome setup. We also brought a visual editor and timeline preview directly into Swift, so you can inspect and adjust agent-generated compositions natively on both iOS and macOS.

The eventual goal is 100% compatibility with Remotion, but we're still working our way there. There's still plenty of room to improve the APIs, rendering speed, and overall platform support.

Here's the repo if you want to check it out:

https://github.com/rxtech-lab/MotionSwift

Along with the rendering engine, we also put together a timeline view, property editor, and SwiftUI preview so you can inspect and adjust compositions natively on macOS, iOS, and iPadOS.

I'm building Publit, an open-source public transport app for iPhone and Apple Watch, written in SwiftUI. Almost every row shows a countdown like "in 4 min", so most of the UI depends on the current time.

The first version used `TimelineView(.periodic(from:by:))` on the departure and trip screens. Freeze logs from an early build showed the main thread stuck inside SwiftUI's update loop, in `requestUpdate(after:)`, while it drew the trip screen.

I replaced the timelines with a plain observable clock that ticks on whole-minute boundaries. One timer serves every row in a list, and thanks to Observation only the views that read `now` redraw on a tick:

```swift

u/MainActor u/Observable

final class Ticker {

static let minute = Ticker(every: 60)

private(set) var now = Date()

u/ObservationIgnored let interval: TimeInterval

u/ObservationIgnored private var loop: Task<Void, Never>?

init(every interval: TimeInterval) {

self.interval = interval

loop = Task { [weak self] in

while !Task.isCancelled {

guard let delay = self?.delayToNextTick() else { return }

try? await Task.sleep(for: .seconds(delay))

guard let self, !Task.isCancelled else { return }

self.now = Date()

}

}

}

private func delayToNextTick() -> TimeInterval {

Ticker.delay(toNextMultipleOf: interval, from: Date())

}

nonisolated static func delay(toNextMultipleOf interval: TimeInterval, from date: Date) -> TimeInterval {

let t = date.timeIntervalSinceReferenceDate

let next = (floor(t / interval) + 1) * interval

return max(0.05, next - t + 0.05)

}

}

```

For a small part of a screen that needs its own pace, a wrapper runs the same loop in `.task`, so it stops when the view leaves the screen:

```swift

Clocked(every: 30) { now in

LeaveHero(itinerary: itinerary, now: now, framed: false)

}

```

Two details mattered. The delay goes to the next whole multiple of the interval plus 50 ms, so the minute has really changed when views redraw. And the loop only holds `self` weakly, so a clock that nobody uses can go away.

Full file: https://github.com/elija-7580/Publit/blob/main/Sources/Views/Components/Ticker.swift

Repo (AGPL-3.0): https://github.com/elija-7580/Publit

Has anyone else hit this with TimelineView? I'd like to know whether I was using it wrong or whether a shared clock is the usual fix for long lists of countdowns.

Full disclosure: I build Publit with help from AI coding tools. I review, test and maintain it myself.Replacing TimelineView with one shared u/Observable clock in my transit app (open source)

Hey everyone 👋

My friend and I have been working on StableBar for a while now. It's a menu bar for macOS, a bit like SketchyBar or simple-bar, except you set it up in a Settings window instead of writing shell scripts. It's free and open source (MIT): https://github.com/Seb-GRAF/StableBar

Since this is r/SwiftUI, I thought I'd share a few things we ran into while building it, in case it helps someone:

The bar is a SwiftUI view inside an NSPanel. Each display gets its own borderless, non-activating panel with an NSHostingView. The border lives in a second panel that ignores clicks, so it never gets in the way of the widgets.

Popups morph into each other. Every popup is its own panel too. When you move from one widget's popup to the next, a temporary panel carries the background across while the two contents cross-fade.

Watch out for view identity with .glassEffect**.** On macOS 26 the bar can use Liquid Glass. If your background flips between an if and an else when a color changes on hover, SwiftUI rebuilds everything inside it. For us that tore down the popup's anchor and closed the popup. Keeping one view structure and switching the glass to .identity fixed it.

The app takes its own screenshots. All the images in the README are drawn offscreen by the app from small "scene" files with sample data, so nothing real runs. CI uses the same thing to post before/after images on every pull request, which makes reviewing UI changes so much easier.

It works with AeroSpace, yabai, OmniWM and Rift, and you can drag widgets around right on the bar. macOS 14+ on Apple silicon.

Happy to answer questions or dig into any of this, and feedback is very welcome!

I built Convrt, an open-source macOS menu bar app: hold Shift while dragging files and a radial wheel opens at the cursor to convert them. The windowing is AppKit (a borderless, non-activating NSPanel), but the wheel itself is SwiftUI in an NSHostingView, and two drawing problems took me a while, so sharing in case it helps someone.

1. Gaps between wedges that stay the same width. If you just shrink each wedge's angle, the gap is wide at the outer edge and pinches to nothing at the inner edge. Instead, each edge is pulled in by an angle that depends on its radius, asin(halfGap / radius), so the gap is a constant number of points everywhere:

struct WheelWedge: Shape {
    let index: Int, count: Int
    let innerRadius: CGFloat, outerRadius: CGFloat
    var gap: CGFloat = 5
    var corner: CGFloat = 3   // stroke with 2 * corner for rounded corners

    func path(in rect: CGRect) -> Path {
        let c = CGPoint(x: rect.midX, y: rect.midY)
        let slice = 2 * Double.pi / Double(max(count, 1))
        let mid = -Double.pi / 2 + Double(index) * slice   // slice 0 at the top
        let a0 = mid - slice / 2, a1 = mid + slice / 2
        let rOut = outerRadius - corner, rIn = innerRadius + corner
        let half = Double(gap / 2 + corner)
        let dOut = asin(min(half / Double(rOut), 1))
        let dIn = asin(min(half / Double(rIn), 1))
        var p = Path()
        p.addArc(center: c, radius: rOut, startAngle: .radians(a0 + dOut), endAngle: .radians(a1 - dOut), clockwise: false)
        p.addArc(center: c, radius: rIn, startAngle: .radians(a1 - dIn), endAngle: .radians(a0 + dIn), clockwise: true)
        p.closeSubpath()
        return p
    }
}

The rounded corners come from insetting the radii by corner and stroking the shape with a line width of 2 * corner in the same color.

2. One soft shadow for the whole ring. A .shadow on each wedge made the shadows overlap and look muddy. Putting all wedges in a ZStack, then .compositingGroup() before .shadow(...), renders them as one layer with a single shadow. Labels are positioned in a separate ForEach on top with .allowsHitTesting(false), so they never get the shadow.

Hit testing doesn't use SwiftUI at all: which wedge is under the cursor is a pure function (atan2 plus distance from the centre), which made it easy to unit-test and to drive the highlight from scroll, Tab and arrow keys.

Source (MIT): https://github.com/atuuuuuuu/Convrt (the wheel is in Convrt/UI/RadialWheelView.swift). Caveats if you want to try the app: the current release is Apple silicon only and not notarized yet, so first launch is right-click → Open.

Happy to take code review, especially on the shape math.

Shipped an app with fifteen distinct document types and learned that two .sheets on one view don't stack

Not a promo post — the specific SwiftUI lessons, from a first app that's now live.

Two .sheet modifiers on the same view compete, they don't queue. My Guided tab froze dead on a specific path and I spent a day on the entitlement logic before realising a second sheet modifier was the whole problem. Fix was one enum GuidedSheet: Identifiable with a case per destination and a single .sheet(item:) switching on it. That pattern has since replaced every multi-sheet view I had.

Raising a sheet from another sheet's onDismiss wedges presentation entirely. Related, worse, harder to spot.

onGeometryChange fires during a sheet's presentation transform. I was caching card frames with .frame(in: .global). When the paywall animated up, the presenting view got scaled, every cached frame updated to garbage, and you could see the cards twitch. Fixed by guarding the write while a sheet is showing — the geometry during a presentation is never the geometry you want.

onChange can't observe a computed read from a store. Obvious in hindsight. Cost me an hour.

App's in my profile if anyone's curious, but I'm here for the code. Anyone found a cleaner multi-sheet pattern than the Identifiable enum?

Hey SwiftUI folks!

I've just shipped Duck 1.0.0, my Swift layer around DuckDB, and one of the parts I really wanted to get right was how it feels inside a SwiftUI app.

I didn't want the database API to end with "run a query, reload everything manually, update the view".

I wanted to write a normal typed query and let the view follow it.

So with Duck you can have a normal Swift model:

import Duck

struct Todo: Table {
    @Column("id") var id: UUID
    @Column("name") var name: String
    @Column("created_at") var createdAt: Date
    @Column("done_at") var doneAt: Date?
    @Column("deleted_at") var deletedAt: Date?
}

and then observe the query directly from SwiftUI:

@State private var todos: [Todo] = []

.task {
    do {
        for try await result in try Todo
            .select
            .where(Todo.$deletedAt == nil)
            .orderBy(.asc(Todo.$createdAt))
            .observe(on: .app)
        {
            todos = try result.all(decoding: Todo.self)
        }
    } catch is CancellationError {
        // view disappeared
    } catch {
        print("Duck error:", error)
    }
}

That's the part I personally like a lot.

The query is still SQL-shaped and typed, but from the SwiftUI side it just becomes an async stream of database state.

Duck also re-exports SwiftStream/SQL DSL, so queries can grow quite a bit without turning into raw SQL strings:

let query = SQL {
    Select {
        \Todo.$id
        \Todo.$name
        \Todo.$createdAt
        \Todo.$doneAt
        \Todo.$deletedAt
    }

    From(Todo.table)
    Where(\Todo.$deletedAt == nil)
    OrderBy(.asc(\Todo.$createdAt))
}

Underneath all of this is the real DuckDB 2.0.0 engine.

The first stable release also includes Codable integration, async/await, migrations, transactions, prepared statements, connection pooling, bulk ingestion through Appender, native LIST/STRUCT values, and UIKit observation too.

I included a complete SwiftUI example app in the repo, including the actual database setup and migrations, so you can clone it and play with the whole flow instead of trying to reconstruct it from snippets.

Wondering what SwiftUI developers think about the Duck.

https://github.com/swiftstream/Duck

Apple put a black cutout right at the top center of your screen and left it dead.
I built Zenith to turn your notch into the fastest part of macOS—media, per-app volume, display brightness, AI agents, and quick tools, all one hover away. Zero clutter.
See it in action & grab it here: https://zenith-mac.github.io

I built a little iPhone browser because I wanted to open Instagram without getting pulled into Reels every time. Turning off Reels was the easy bit. The suggested posts toggle gave me a much weirder bug: the post I was reading would jump out from under my thumb.

I was hiding rows after the page had already laid them out. The fix was to filter entries I could recognize before the feed renders them. If a row is already on screen, the fallback keeps its height. That helped with the jumps, but it also exposed another bug: sometimes I'd be left with one post and no more would load. The site still had another page, it just hadn't asked for it. Getting that to load again without yanking the scroll position took more work than I expected.

The app is called Supermod. SwiftUI for the controls, WebKit for the sites. There's a timer on Home if you actually want ten minutes of Reels or Stories, and a little draggable button that shows the countdown. The filters only work in this browser.

I put the code up under GPLv3. It's a Mac + Xcode build for now, no App Store download. There are screenshots and setup steps here:

https://github.com/WarriorSushi/supermod-ios-Block-Reels-etc

If you've had to keep a WKWebView feed steady while changing what's in it, I'm curious what you ended up doing. The tests are mostly fixtures and I'd love to hear what breaks on other phones.

Trying to create a account profile view with a header and profile picture, like twitter for example. I also want it to have a bounce effect when you pull down. However my hurdle is trying to figure out how to remove the blur.

Since this is my first vibe coded app. I'm curious if anyone has feedback.I'm primarily a C# dev (and have been for 20 years). I bought a scooter earlier in the year and wanted a way to track my rides. I'm sure there things I could learn, so I'm curious as to how good AI did. I used a mix of AntiGravity, GitHub Copilot, the Xcode skills and just tried to learn as much as I could from this. I read about 50% of the code. Thank you for your time.

Source: https://github.com/clquwu/Cosmos-Music-Player
App Store (free, no ads, no in-app purchases): https://apps.apple.com/app/id6751984723

I’m a solo dev and Cosmos was my first iOS project. After more than a year, 1.3 is a full redesign of the whole interface. It’s a music player for your own files, built in SwiftUI, and it’s open source. I’m not a designer, so I’d really like feedback from people who care about SwiftUI UI/UX.

What I redesigned

• Three tabs: Home, Library and Search. Home has Start Listening, Recently Played, mixes, Recently Added and Rediscover

• Library lists Liked Songs, Folders, playlists, albums and artists, as a list or a grid, sorted by recent, A–Z or release year

• A full-screen player coloured by the cover, with lyrics and Up Next inside. You can choose Blurred Cover, Artwork + Theme or Theme

• Animated backgrounds in your theme colour (Silk, Aurora, Lines, Classic, Glow, or off)

• iPad and foldable layouts with a sidebar, bigger covers and two-column album/playlist pages

• A Select button to pick several songs at once, and playlist editing/export in the “…” menu

• Settings regrouped into Appearance, Playback, Library and Siri & History

Where I’d like honest feedback

1. Navigation: is three tabs the right structure, or is something in the wrong place? Is the “Add Music” row at the top of Library easy to find?

2. Full-screen player: are three styles too many? Is it clear where lyrics and Up Next are?

3. Readability: colours from the cover can be tricky. I added fixes for lyrics and Up Next on very light covers, but I’d like to know about any combinations that are still hard to read.

4. Animated backgrounds: does this feel nice, or is it too much? They stop after 30 seconds without a touch to save battery.

5. iPad/foldable layouts: do they feel native or just stretched?

6. Multi-select and the “…” menu: is it obvious how to select songs and edit playlists?

7. Anything that feels non-standard compared to what iOS users expect (Apple Music, Files, etc.).

If you’re a SwiftUI dev, I’d also welcome code review. The repo is open and issues are welcome.

It’s free with no ads, and there’s an optional donation link in Settings. Nothing is locked behind it.

All feedback is weclome since im more customed to do ui and ux on android !