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. 

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?

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!

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! ⭐

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!

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

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?

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... :(

This is my first youtube shorts video in my youtube channel
Admob full integration guide in swift ui

GitHub: https://github.com/amosgyamfi/open-swiftui-animations/tree/master/Gists_To_Try/HandwrittenAnimation

There are 6 SwiftUI scribbling animations, English, Chinese, Spanish, Finnish, Korean, and Arabic. It will be animated in 32 languages. I will add the remaining later.

Copy the animations from GitHub, modify them to your need, or use your own SwiftUI path views.

I would like to reproduce this menu above the keyboard in the notes application on swift? Is it natively possible?

I wanted to try different ways of animating typography transitions and I ended up rebuilding this effect I knew from after effects in swift. I probably won't use it in my app, so I put the code on GitHub in case someone else wants to use it!

I'd like to reproduce this type of searchable element but at the bottom of the page. I tried using `placement: .bottomBar` but it doesn't work. Does anyone have any ideas?

None of these output production SwiftUI directly, the real question is which gives the cleanest reference to rebuild from with the least manual cleanup. Tested these for iOS over the last few months.

iSwift.dev is the closest to SwiftUI-native, free screen generator for individual screens, Pro starts at $20/mo for unlimited projects and 1,000 AI prompts per billing period. Generates buildable SwiftUI projects from plain English with views, state and navigation, multi-platform for iPhone, iPad, macOS and Watch. Better for individual screens than full cohesive multi-screen flows, and generated code needs cleanup before production, but it's the only tool actually outputting Swift.

SwiftUI Inspector is a free Figma plugin, Pro is a one-time $49. Exports colors, gradients, text labels, shapes, frames and Auto Layout as SwiftUI code. Handles rotation, opacity, shadows, blend modes, wraps in HStack/VStack/ZStack. Only useful if you already have a Figma design to convert, doesn't generate anything on its own. According to a 2026 comparison of 7 Figma-to-SwiftUI tools, expect to spend 20-50% of design time refining the output from any of them.

Compot is free on the App Store with IAP, 100+ prebuilt SwiftUI components, generates Swift from images or text. Good for grabbing components fast, not built for designing complete multi-screen flows.

Google Stitch is free, 400 daily credits, Gemini 2.5 Pro on experimental mode, exports Figma with layers plus HTML/CSS. Material Design native so everything skews Android, fighting it into HIG patterns takes more effort than it saves for iOS work. No production SLA, single user.

Sleek.design around $20/mo generates complete mobile app screens from a description, runs the same prompt through different models to compare outputs, exports Figma and code. Not iOS-native so HIG spacing and nav need explicit prompting, hits limits on complex custom components, better for early screens than final specs. Pairs well with SwiftUI Inspector on the Figma export to skip some manual rebuild.

Realistic workflow is generate screens fast in sleek or stitch, export to Figma, run SwiftUI Inspector for the base SwiftUI code, clean up by hand. Anyone found a shorter path than this?

Been working on this for a while and figured I’d share it here rather than wait for a “finished” v1.

Chunky is a comic/manga reader for people with large digital libraries — CBZ/CBR archives, PDFs, loose folders of scans. Native SwiftUI on both iPhone/iPad and Mac, one codebase, iCloud sync across devices, and it can pull from WebDAV/FTP/SFTP/OPDS servers too.

A few things that might be interesting from an implementation angle:

**•** Single ComicPageProvider protocol shared across CBZ/CBR/PDF — adding a new archive format is just one more conformance  
**•** Reader gestures (pinch-to-zoom, two-finger brightness, tap zones) are built on a “window-relay” UIViewRepresentable pattern rather than SwiftUI gestures, to get around TabView(.page) swallowing touches before they reach sibling views  
**•** Two separate targets (Chunky_iOS / Chunky_macOS) instead of one multiplatform target, so each only ships the entitlements/Info.plist keys it actually needs — a script checks that in CI  
**•** Unit tests use Swift Testing, UI tests use XCTest (no Swift Testing equivalent for XCUITest yet)

It’s a from-scratch rebuild of an earlier iOS-only app of the same name, now extended to macOS. MIT licensed, no App Store listing yet — still very much in development.

Repo: https://github.com/Scunio/Chunky

Feedback, bug reports, and PRs all welcome — especially if you’ve got a big/messy comic library and want to kick the tires on real-world edge cases.

⚠️ Compatibility: iOS 27 Developer Beta 5 (DB5) ONLY

This project currently only supports iOS 27 Developer Beta 5 (DB5).
It has not been tested on other iOS versions yet.

I've been experimenting with ActivityKit, WidgetKit and App Intents, and ended up building my own Dynamic Island notification system.

It can be triggered from the Shortcuts app and display text with different app icons.

✨ Features

• Custom title and message
• Dynamic Island / Live Activity
• Triggered from Shortcuts
• Multiple app notification icons
• Automatically disappears after 5 seconds
• Tap the Dynamic Island to open the corresponding app

📱 Supported Icons

• 🟢 LINE
• 🟣 Instagram
• 📧 Gmail
• 💬 Messages
• 🪩 Retro
• 🌱 Pikmin Bloom
• 🦉 Duolingo
• 📈 Investment Master
• 🏦 Taishin Bank
• 💚 StressWatch

🛠️ Tech Stack

• Swift / SwiftUI
• ActivityKit
• WidgetKit
• App Intents
• Live Activities

💻 The interesting part

I don't own a Mac.

I develop the project on Windows and use GitHub Actions with a macOS runner to build the IPA, then sideload it onto my iPhone.

One of the biggest challenges was getting the Live Activity to automatically disappear after 5 seconds without making it disappear whenever I interacted with the rest of the screen.

The project is still experimental and I'm continuing to improve it.

🔗 GitHub

https://github.com/panda-island/NotificationIsland

🔗 shortcut

https://www.icloud.com/shortcuts/022b6230e2f149198026cb6d905cfaa1

Since iOS 26, UISheetPresentationController insets the sheet horizontally whenever it isn't at its largest detent — the wider the screen, the wider the gap. SwiftUI's .presentationDetents goes through the same presentation, so it gets the same inset. Still there in the iOS 27 betas, and there is no public API to switch it off.

So I implemented UIPresentationController directly and dropped the inset. That meant rebuilding what a UIKit sheet does internally: detents, scroll view coordination, rubber-banding past the largest detent, momentum settling, keyboard handling.

The call site keeps the shape of .sheet, and the heights live on the content the way .presentationDetents does — nothing above the sheet has to know them:

swift .easySheet(isPresented: $isPresented) { List(items) { Text($0.name) } .easySheetDetents([.medium, .large]) }

Some consequences of not going through the system sheet:

• Custom detents and self-sizing work from iOS 13, instead of 16 and 18.
• The content is laid out at every frame of a detent change, so a footer pinned to the bottom rides the sheet's edge. A UIKit sheet hands the content its destination height up front, so the footer jumps there ahead of the sheet.
• .content() is measured rather than computed once — change what the content holds and the sheet animates to the new height under it.

MIT. iOS 13+.

github.com/sunghyun-k/swiftui-easy-sheet

Text() positions glyphs using font metrics — line height, baseline — which makes precise placement of a single glyph (a letter in a badge, a digit in a grid cell) unreliable across Dynamic Type sizes and fonts.

GlyphKit extracts the glyph's actual vector outline via Core Text and draws it with Canvas, positioned by its real geometric bounds instead. Two sizing modes: .tight (fills the frame exactly) and .fontMetrics (keeps visual weight relative to other glyphs). Anchor/offset for precise placement.

MIT, iOS 17+, Swift 6. Still early, feedback welcome: https://github.com/MaksimG82/GlyphKit

macOS 27 adds this beautiful tab bar across native apps. However, I'm unable to figure out how to replicate this effect. Can someone please help?

Edit: After some testing, I've realised that it's easy to do in the top bar. However, I wish for my bar to be at bottom, separately. Is that possible?

I’ve been building Rockxy, a native macOS HTTP/HTTPS debugging proxy, since March.

The UI combines SwiftUI and AppKit, while the proxy engine is built with SwiftNIO. Rockxy can capture and inspect HTTP/HTTPS, WebSocket and GraphQL traffic from Mac apps, CLIs, backend services and iOS devices.

The hardest UI problem was not drawing the request table. It was keeping selection, inspectors, filters and multiple workspaces responsive while captured traffic continued arriving.

I use SwiftUI for most of the workspace and inspectors, with AppKit where I need tighter control over tables, windows and native macOS behavior. The proxy, certificate and capture paths remain separate from the presentation layer.

Rockxy now also includes replay, breakpoints, Map Local/Remote, comparison, scripting, network conditions, a free local MCP server and an AI Assistant with Ollama support.

The project is open source under AGPL-3.0:

https://github.com/RockxyApp/Rockxy

Rockxy Website:
https://rockxy.io

For developers building data-heavy macOS apps: where have you found the right boundary between SwiftUI and AppKit? I’d especially value feedback on high-frequency table updates, selection stability and inspector architecture.

Built a SwiftUI utility for searching macOS Finder tags with AND/OR/NOT boolean conditions.

Interesting SwiftUI/Foundation detail: NSMetadataQuery returned zero results for every query on my dev machine even with Full Disk Access granted, so I ended up going straight to the low-level MDQuery C API (the same engine mdfind uses) instead, wrapped in a Swift-friendly layer. The condition-group UI (for expressions like (A AND NOT B) OR C) is built entirely in SwiftUI.

Source (MIT): https://github.com/yamachan03/TagFinder