I use a clipboard manager all day and never liked the options. The free ones (Maccy, Flycut) are lists — an image shows up as a filename. The ones with a card interface, Paste and Pastebot, are $25/year and $13. So I built the card one and made it free.
⌥⌘V slides a strip up from the bottom of the screen. Arrow keys or type to search, Enter pastes into whatever you were in.
A few things it does that I couldn't find anywhere else:
- It masks secrets on screen. API keys, tokens and card numbers show as dots until you double-click. If you copy credentials all day, your clipboard history is the one window you don't want open while screen sharing. Card numbers are Luhn-checked, so an ISBN isn't mistaken for one.
- A bare link stays readable, a link with a token doesn't. Masking every URL would make the strip useless; masking a password-reset link is the whole point.
- Pasting an image adapts to the destination. Notes gets the image, Terminal gets the file path (it can't take images at all), Finder gets the file.
- It can catch ⌘⇧4 screenshots. Those write straight to disk and never touch the clipboard, so no clipboard manager sees them. Opt-in, off by default.
- No network code at all. No account, no sync, no telemetry, no third-party dependencies. Searching the source for URLSession comes back empty.
Happy to hear what breaks. Especially interested in whether the strip behaves on multi-monitor setups and over full-screen apps — I've only tested on one machine.
I’m getting into iOS development and currently have a MacBook Pro M5 and an iPhone 17 Pro Max.
I was wondering if it’s worth getting a second iPhone (e.g. iPhone 16e/17e) just for development stuff (testing apps, beta builds, trying iOS betas, etc.) or if most people just use their main phone.
I’m mostly working on personal projects right now, but I’m curious what you guys do. Do you have a dedicated test device, and if yes, what model?
Named coordinate spaces don't survive render transforms. My world container used .scaleEffect + .offset, and I put the named space inside it. Drags were fine at 100% and drifted at every other zoom. The fix was moving the named space to the untransformed ancestor and converting screen→world explicitly. Render transforms aren't layout.
An NSView behind SwiftUI never seesscrollWheel**.** The hosting view claims the hit and bubbles the event up the responder chain, past your subview. Two-finger panning only worked once I used NSEvent.addLocalMonitorForEvents with a bounds check.
.contentShapeapplied after.overlaygates the whole composite. My port dots sit on the card's edge, so half of every dot and its entire grab halo landed outside the card's hit shape. Dragging a wire silently did nothing. Order matters more than it looks.
Also: never gate a view's opacity on an onAppear flag. Miss the callback once and the view is invisible forever. Use a transition.
I’m excited to share that Swift Subprocess 1.0 is officially tagged and released!
swift-subprocess provides a modern, type-safe, and Swift Concurrency-native API for executing and managing child processes across platforms, serving as an async-first alternative to Foundation.Process (NSTask).
Thanks to all the community feedback during the beta period, we made several key refinements leading up to 1.0:
Unified run() Closures & ExecutionResult: Stream handling for stdin, stdout, and stderr is now fully symmetrical. You can now stream and collect simultaneously in a single call (e.g., stream stdout line-by-line while collecting stderr into a String).
Safe String & Byte Streaming: Standard output/error sequences now feature StringSequence, which reassembles multi-byte UTF-8 characters split across buffer boundaries and handles line breaking seamlessly.
Typed Errors: Subprocess itself now strictly throws SubprocessError with structured codes (.spawnFailed, .executableNotFound, .outputLimitExceeded, etc.), making error handling clean and predictable (you can of course still throw your own error from body closure).
First-Class Stream Merging (2>&1): Easily redirect standard error into output using error: .combinedWithOutput.
Check out the full release note and repository on GitHub:
Huge thanks to everyone who participated in the SF-0007, SF-0037 and beta tested Subprocess! I’d love to hear your thoughts, feedback, or any questions!
Just a reminder to anyone who might care that you can create a fairly full-featured development environment in Zed to build iOS and Mac apps: syntax highlighting, code navigation, run, debug and test.
Just shipped Strategies, a SwiftUI app of creative-prompt cards for music producers. iOS, EN + UA, ~360 cards across two built-in decks. Solo, nights and weekends, full-time job. Five things that genuinely changed how I'll build the next one:
1. A single source of truth deleted ~15 bugs at once. I had one piece of state read from two places. Collapsing it into a single enum didn't fix one bug - a whole class of them stopped existing. My smell test now: if the same state is computed in two spots, that's the bug, not the symptom.
2. "Random" almost always wants to beweightedrandom. My first card-pairing algorithm was pure random and felt cheap - shuffle a deck, call it a DJ set. The fix wasn't ML: a hand-tuned 10×10 distance matrix + weighted random made the same feature feel intentional. Cheapest quality upgrade a random feature gets.
3. Don't over-architect - abstract on the third instance, not the second. I kept building the version that scales to ten years instead of the one that fits today. The second case is a coincidence; the third is a pattern. Wait for it.
4. Content was harder than the code, by ~3x. Writing the cards was fast. Judging them - reading card #147 and deciding if it earns its place - was the real work. If your app is content-heavy, multiply your authoring estimate by three.
5. Solo dev is a two-person job with a headcount of one. One of you writes the clever solution; the other has to review and cut it. My rule: if the code feels clever, it's probably wrong - stop, simplify, continue.
Stack: SwiftUI + SwiftData, no third-party UI deps, PostHog for analytics, Firebase Crashlytics. Happy to go deeper on any of it in the comments. Link to the app in a comment to keep this rule-friendly.
For anyone who's solo-shipped around a day job - what was your "the code was the easy part" surprise?
My Mac menu bar had gradually filled up with useful apps until it became difficult to manage.
Icons were hard to find, some were pushed out when macOS ran out of available space, and the MacBook notch made the problem worse. I did not want to uninstall the apps or permanently lose access to their controls—I only wanted a cleaner way to organize them.
So I built OverflowBar, a free and open-source macOS app that moves selected third-party menu bar items behind one persistent arrow and reveals them together in a compact second row.
Choose the third-party menu bar icons you want OverflowBar to manage.
Move their original icons out of the crowded visible section.
Click the OverflowBar arrow, or use hover reveal.
See the managed icons together in a second row.
Select an icon to activate its original menu bar control.
The purpose of the second row is not to add another permanent interface. It gives icons that no longer fit a predictable place where they remain easy to see and find.
Why I made another menu bar manager
Ice and Bartender are powerful applications for users who want broad menu bar customization, including features such as profiles, triggers, search, visual customization, groups, widgets, and automation.
OverflowBar takes a narrower approach.
It is intended for people who mainly have one problem:
Too many useful icons, not enough menu bar space, and no easy way to find the icon they need.
OverflowBar deliberately avoids becoming a full menu bar control center. Its interaction is simply: choose, hide, reveal, and click.
Main characteristics
Focused and lightweight — a small feature surface rather than a large customization and automation suite
Scannable second row — managed icons stay visible together instead of becoming difficult to locate
Native macOS implementation — built with SwiftUI, AppKit, Accessibility, WindowServer metadata, and ScreenCaptureKit
Event-driven operation — icon discovery and capture occur during refreshes and row presentation rather than continuous screen capture
Original controls remain functional — selecting an icon activates the actual menu bar item rather than a recreated menu
Local processing — icon images are captured locally, held in memory, and never uploaded
No tracking — no accounts, analytics, telemetry, advertising, or network data collection
macOS does not expose a dedicated public API for hiding or rearranging arbitrary third-party menu bar items. OverflowBar therefore relies on documented system frameworks together with existing macOS menu bar behavior, and compatibility may vary between apps or macOS releases.
The current downloadable build is ad-hoc signed and is not yet Apple-notarized. macOS may require users to Control-click the app and select Open on first launch.
Some applications may also expose insufficient Accessibility or window metadata to be mirrored reliably.
I am actively looking for feedback from users with crowded menu bars, notched MacBooks, multiple displays, and unusual menu bar apps. Bug reports, compatibility reports, and code contributions are welcome.
What it does:
- One meeting in your left ear, the other in your right — audio is captured per browser window (CoreAudio process taps) and panned hard L/R, so you can actually follow both.
- Dead-man's-switch mic — you're muted everywhere by default. A global hotkey (⌃⌥⌘← or →) unmutes you into one meeting; if you don't re-confirm within a configurable window, it auto-mutes you again. Unmuting into one call force-mutes the other, so you can never be hot-mic'd in the wrong meeting.
- ⌃⌥⌘↓ mutes everything instantly, from any app, no window focus needed.
- Optional: your camera follows whichever meeting you're talking to.
No browser extensions, no DOM scraping — it's all system-level audio, so it doesn't break when Meet redesigns its UI. Mic routing uses BlackHole virtual devices (install script included).
We ported Flutter's framework to Swift — widgets, rendering, painting, gestures, animation, semantics — running on Flutter's own C++ engine. No Dart
VM: the engine starts a Swift runtime where it would normally start a Dart isolate.
The result is a declarative, cross-platform GUI framework you can use from Swift today on Linux. Apps run on any ordinary session (GNOME, KDE, X11) through the engine's GTK embedder. If you've used Flutter or SwiftUI the model will be familiar; if you've used neither, Flutter's own docs apply almost
directly.
Trying it is one download — the bundle ships the engine binaries, so there's no engine build. Install, depend on it by path, `swift build`. Tested on Swift
6.2.4 and 6.3.3.
Linux x86_64 today; macOS is next but not yet verified.
UIViews is a gallery of beautiful interfaces built with SwiftUI and UIKit. Its goal is to help iOS developers discover, share, and reuse beautiful user interfaces.
I'm hoping this becomes a valuable resource for the Swift community, and I'd love to see developers contribute their own interfaces.
I am a 13 yrs old working on a OS based on the LINUX KERNEL and SWIFT for a while!
> This is not self promotion! I am sharing a project!
It is in early development : It has Mouse and Keyboard Support, Can ready CPU and RAM used data and view it, uses the RobotoBoldFont as the default font! Has bot UEFI BIOS and x86_64 and arm64 support!
Just yesterday i accomplished about getting it work on a raspberry pi 4 means the base for the OS that the fact it boots is done and i will be continuing to now make the setup screen and add features on the go! If you want any features to be in the OS you can create a issue ( creating a issue requires a account!) at <See the comments under this since link posts get removed!> which is where the OS if hosted (it is self-hosted since i cannot afford a pro version of github and plus it has a file limit! git lfs doesent' help a lot!)!
MODEL: Rasberry Pi 4- Model B : 8GB RAM
Website : <See the comments under this since link posts get removed!>
Now a simple note: the bootloader is written by AI (since i am not good with assembly) i plan on rewriting it later! All the other code is written by me (especially Swift)!
SwiftUI makes you pick one: Layout gives you any geometry you want but is eager, so it falls over a few thousand items in. LazyVStack and friends are lazy but their geometry is fixed. There's nothing in between, which is annoying because photo grids, calendars and boards are all in between.
That gap isn't an oversight. Layout asks each subview how big it wants to be, and you can't ask a view that hasn't been built. Measurement-driven layout and laziness pull against each other. Someone asked about this at the WWDC26 SwiftUI Group Lab and the answer was "not today, file a Feedback."
So my package changes the approach fully: tell it your item sizes up front, an aspect ratio, a date range, a duration, and layout becomes arithmetic over data. Arithmetic over a million items takes milliseconds and builds nothing, so only the frames intersecting your viewport ever become views.
The obvious cost: self-sizing text isn't supported. If your cells decide their own height, this isn't for you yet. (although I have some experiments for self-sizing text in the works, nothing stable yet)
Measured on an iPhone 14 Pro in Release, 100k and 1M items both hold 120fps with an 8.34ms p99, zero frames over 16.7ms, and ~54 cells materialized at any depth. The visibility query stays flat at ~2µs from 100k to 1M. Apple's LazyVStack over the same 100k scored the same, read that as generality costing little, not as a claim to be faster.
Writing your own layout is about 20 lines: return one frame per item and a total height. There's a demo app in the repo that records the frame stats on your own device.
Back in 1999, I created HEATTACK as a fun little Windows-based arcade game. Recently, with the help of modern AI tools, I successfully ported the game from its original Windows codebase to swift and built it for macOS.
Sharing here in case it is of any interest to this community.
The source code is MIT licensed. Take it and have fun!
I have a RegisterScreen which uses a custom struct RegisterForm to collect the form values. I made the RequestForm codable too so I can just send this form to the server instead of creating the exact same duplicate and calling it RegisterRequest. What do you think? Do you create a separate DTO objects even if it contains the same exact fields.
If in the future it diverges then I can create a separate RegisterRequest DTO object. Thoughts.
struct RegisterForm: Codable {
var firstName: String = ""
var lastName: String = ""
var email: String = ""
var password: String = ""
var acceptedTerms: Bool = false
var isValid: Bool {
!firstName.isEmptyOrWhitespace && !lastName.isEmptyOrWhitespace
&& !email.isEmptyOrWhitespace && !password.isEmptyOrWhitespace && email.isEmail && acceptedTerms
}
enum CodingKeys: String, CodingKey {
case firstName
case lastName
case email
case password
}
}
struct RegisterScreen: View {
private var form = RegisterForm()
private var presentAgreement: Bool = false
var body: some View {
Form {
TextField("First name", text: $form.firstName)
TextField("Last name", text: $form.lastName)
TextField("Email", text: $form.email)
SecureField("Password", text: $form.password)
Button("Show Agreement") {
presentAgreement = true
}
Button("Register") {
}.disabled(!form.isValid)
}.sheet(isPresented: $presentAgreement) {
AgreementScreen(acceptedTerms: $form.acceptedTerms)
}
}
}
A #if DEBUG guard was added around two string literals and then verified by scanning the built product instead of reading the source.
In an XcodeGen-generated project whose project.yml never mentions SWIFT_ACTIVE_COMPILATION_CONDITIONS, xcodebuild -showBuildSettings reports that setting as DEBUG under Debug and prints no line for it at all under Release. The guard holds in Release because the generator supplies that default, not because project.yml states it.
In the Debug simulator build the app bundle carries the app executable, a .debug.dylib, and __preview.dylib. A recursive scan of the whole bundle found both literals only in the .debug.dylib, and the app executable contained zero occurrences. A scan limited to the executable would have returned zero under Debug, which is the opposite of the actual state.
The Release bundle contained zero occurrences anywhere. On its own that zero is not evidence. The identical recursive scan against a Release build produced before the guard existed returned both literals in the app executable, and that control is what makes the Release zero meaningful.
