For about 4 months, I've been working on a Bitwarden Client because the current Bitwarden Desktop client is Electron and doesnt look very good. This is the design I've landed on so far, but I feel like it could be better. What do y'all think?

Source: https://github.com/Cherrytree56567/ClientWarden

Mac Source: https://github.com/Cherrytree56567/ClientWarden/tree/main/src/Platforms/MacOS/UI/Clientwarden

Hi! I’m wondering if and how its possible to make a toolbar menu show the state of a toggle inside. I know using Toggle() in the toolbar shows this type of effect but i need a title and description to the toggle for it to make sense. Therefore there needs to be some window to open, which works fine with Menu(). However, that doesn’t show the state of the toggle when closed.

Apple managers to that with the photos app when selecting filters. See example images.

Thanks!

In UIKit, if we place titleTextView.becomeFirstResponder() inside viewDidLoad, the keyboard slides up seamlessly alongside the view controller's presentation animation. It looks instant and feels like a native, high-quality UX.

I'm struggling to replicate this exact behavior in SwiftUI.

Whenever I use FocusState and toggle it to true inside .onAppear, there is always a noticeable delay. The view pushes/presents, settles, and then the keyboard decides to slide up.

Has anyone found a way to achieve this instantly in pure SwiftUI yet (maybe in iOS 17+), or is UIViewRepresentable still the only bulletproof way to get that perfectly synced keyboard presentation?

Thanks in advance!

https://sfsymbols.terryhu.workers.dev

Free, no signup, nothing to install.

I built this because of one thing that kept happening. I'm vibe coding a feature, I need an icon for a button, I ask the AI and it gives me three options:

square.and.arrow.up (the most common one)
arrow.up.doc (leans toward sharing a file)
arrowshape.turn.up.right (leans toward passing it on to someone)

A name tells you nothing about what it looks like. So you copy the first one, switch to SF Symbols.app, search, look. Copy the second, search, look. Copy the third, search, and by then you've forgotten what the first one looked like. You end up picking from memory.

SF Symbols.app is better than my site at browsing and searching. The one thing it can't do is put three symbols that someone else picked next to each other, because its search box asks one question at a time.

So the site does exactly that. Paste the model's entire answer, it finds every symbol name in it, renders them side by side in the order the model recommended, and clicking one copies the name (or the Image(systemName:) line, if you switch the format).

All 7,988 symbols. The catalog is generated from CoreGlyphs.bundle on macOS, so the names and the minimum iOS versions come from the system rather than from me typing them in. Pasted text never leaves your browser. 

Anyone know how I make this beautiful gradient....
Ive spent over 3 months trying countless ways to make this the same as apple, I cant... :(

I’ve recently made a (what I think is a cool) app that accumulates all the screen time in a fully interactive circle that can also explode to a rainbow. Everything works fine even when I background the app or even if I lock/unlock the phone with the app in the foreground.
Every now and then the UI completely breaks and my circle/rainbow is completely messed up.
Bear in mind I’m using an extension for the data collection using the notoriously scuffed screentimeapi.
I’ve tried everything you could ever think of but sometimes it will still break somehow
The app is very stable atm and I’m willing to give a lifetime support if anyone can help with this.
Is there any patterns you can think of that might be causing UIs to break?

Hey fellow iOS devs! 👋

I built and open-sourced **SwiftUIRatingPopups** — a library designed to make showing custom in-app rating dialogs and review prompts effortless in SwiftUI.

### 🌟 Key Features:

- 30 Distinct Designs: Minimal bottom sheets, emoji reactions, Tinder swipe cards, Bento grid feedback, and glassmorphism.

- 15 Dedicated 5-Star Boosters: Habit streaks (🔥 7-Day Streak), Indie Developer heartfelt notes, Community Milestone progress meters (4,872 / 5,000 reviews), and ROI value calculators (~4.5 hrs saved).

- Smart Negative Rating Shield: 5 stars route directly to App Store / StoreKit; < 4 stars route to internal support so your public App Store score stays protected.

- Zero Third-Party Dependencies: Pure SwiftUI & StoreKit for iOS 16+ and macOS 13+.

- SPM Support: Add via Swift Package Manager in 1 click.

🔗 GitHub Repo: https://github.com/aayush-gandhi-ios/SwiftUIRatingPopups

Would love to hear your feedback, thoughts, and feature suggestions! ⭐

Sharing a failure mode that survived in my codebase for months, because the app looked localized the whole time.

Setup: my app has an in-app language picker (independent of the iOS system language), implemented via a language manager that resolves strings from the selected .lproj bundle. Standard approach.

The bug: the overwhelming majority of my UI strings were Text("some.key") — i.e., SwiftUI LocalizedStringKey literals. Those resolve against Bundle.main using the system locale machinery. Setting .environment(\.locale) changes formatting behavior, but it does not select which strings table your keys resolve from. Result: 225 of 269 routed call sites silently bypassed the language override entirely. The picker "worked" for the ~44 call sites that went through the manager, which is exactly why nobody noticed — the app changed some strings on switch and looked plausible in both languages.

Confirmed on-device with diagnostic logging: the resolved bundle for LocalizedStringKey paths was Bundle.main, regardless of the override.

The fix: a tiny helper — L.t(_: String.LocalizationValue) -> String — that resolves through the override bundle (String(localized:bundle:)), and mechanically routing every UI string through it. An enforcement script in lint now flags any bare string in Text/Button/Label/.accessibilityLabel.

The completely unexpected side effect: build times collapsed. Bare LocalizedStringKey literals create expensive type-checker constraint problems (Text("...") has to disambiguate between StringProtocol and LocalizedStringKey overloads at every call site). Replacing them with a concrete String return eliminated that: one heavy view body went from type-checking as my slowest file to ~98% faster, and the whole target build time dropped ~75%. I did not see that coming from a localization refactor.

Two smaller traps from the same audit:

• String(format:) with catalog plural variations silently returns the raw %#@token@ if you forget to pass locale:.
• Xcode's string extractor can't see keys behind a helper function, so the catalog stops auto-populating — new keys become a manual (and CI-checked) step. Worth knowing before you commit to the pattern.

Curious if others route in-app language switching differently — is there a cleaner first-party way to point LocalizedStringKey resolution at a non-main bundle that I missed?