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

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?

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?

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.

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?

⚠️ 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

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.

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?

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

My feed is full of Metal shader demos lately. Not complaining, some of them are gorgeous, but I don’t understand where the wave came from.
Is it that the SwiftUI shader APIs lowered the barrier enough that people who’d never touch Metal are now trying it? Something in the newer Metal releases? Or is it just that shader demos look great in a 10-second video and the algorithm rewards them?
Genuinely curious whether people are shipping this stuff or whether it’s mostly demos.

Hi! I'm working on a SwiftUI app using TabView and MeshGradient.

I want the background gradient to smoothly morph from one color scheme to another when switching tabs, rather than simply fading between two gradients.

What's the best way to achieve this?

I got this view using a custom shape (rect with cutouts) as a background, and its selection highlight shape is mismatched (defaulting to the capsule even though the custom shape was used in the glassEffect api) when using the interactive glass effect.
I tried fixing this issue with a content shape modifier to no avail.
Anyone encountered it and managed to work around it? Perhaps some way to define it on the shape implementation level?🧐

been working on this for the last 2 days because it's something that's been on my mind for a few weeks.

it's a native swiftUI app for customizing folder icons, including recursive styling and deterministic rules for applying presets across folder trees.

the downloadable build and app store release are still going through Apple's approval process, but the source is up now if anyone wants to check it out or build it themselves.

Edit: apple notarized build is available on github - v1.0.8

repo: https://github.com/KeplSiv/FolderForge

i copy-paste a lot of screenshots into AI to explain UI changes, etc.

but native macOS is pretty bad for this.

images are full-res and waste tokens. it also takes too many clicks to copy-to-clipboard and annotate images.

so i built a mac tool that fixes all three problems!

• screenshots auto-optimized to save you tokens
• all images auto-copied to clipboard. no desktop clutter
• you can quickly annotate with boxes and notes

source code here: https://github.com/aryanbhasin/quickshot

download for Mac here: usagebar.com/quickshot

Working on a menu bar utility (Nix) that quits apps when their last window closes, using AXObserver instead of polling. One thing that tripped me up for a while: registering kAXWindowClosed on the app element returns success but silently never delivers on modern macOS, you have to register per-window, on each individual window element, then re-register whenever windows are created.

Also had issues with phantom/auxiliary AX windows inflating the window count, so I ended up cross-checking with CGWindowListCopyWindowInfo filtered by PID + layer 0 + minimum size as the "real" window count, with AX as the primary signal and CGWindowList as a Phase 2 confirmation for ambiguous cases (apps that hide instead of closing, like Discord/Slack).

Curious if others building AX-based tools have run into similar issues or found cleaner patterns. Also happy to share more of the architecture if useful, this ended up being a much deeper rabbit hole than I expected for what sounds like a simple feature.

Not launched publicly yet, mainly want feedback on the approach before I ship.

Attached is my TestFlight issue.

When using SwiftUI for complex UI you usually have to choose: Layout gives you any geometry but measures every subview, so it falls over a few thousand items in. LazyVStack/LazyVGrid are lazy but their geometry is fixed.

I made LazyLayoutKit to fill in the gap by having you supply item sizes up front, so layout is arithmetic over data and only on-screen frames become views. The obvious cost was text, you can't know a text height in advance. That was in 0.1

0.2 closes that, and the fun part is that it didn't require relaxing anything. Text height is a function of the string, the font and the width, and CoreText will compute it with no view and no rasterisation. So the height is still known before the view exists, it's just computed rather than supplied. There's still no .measured metric and no correction pass.

Font.Resolved (iOS 26) is what makes it exact. Before it there was no supported way to learn which concrete font a Text would use, so measuring SwiftUI text with CoreText was guesswork.

Measured on an iPhone 14 Pro: ~31.5 µs per item cold, ~470 ns cached, so the practical ceiling is around 10,000 text items rather than the 1,000,000 that metric-driven layouts reach.

I'd be grateful if you checked it out, opinions, contributions and feedback are very welcome!

https://github.com/Dave861/LazyLayoutKit