Is it possible to ensure that only one document can be open at a time? My target is macOS 15. The idea would be that the user is alerted and no existing document can be opened (e.g. drag and drop, file->new, Finder etc).

I've tried everything I found on Google and none of these work:

• `.listRowInsets()`
• `.environment(\.defaultMinListRowHeight, 0)`
• `.controlSize(.small)`

I'm looking for a GitHub library to recreate a similar effect

I have -Xfrontend -warn-long-function-bodies=275 set in Other Swift Flags, and one of my views recently tripped it hard: the body came in at around 506ms. Compile times were getting annoying.

I did not rewrite anything. I just pulled pieces out of body into separate computed properties: the main content, the transition, and the sheet modifier. Same code, same behaviour, just moved out of body.

The warning went away.

What surprised me is that there was no single monster expression to blame. body was just long, and the type checker seems to struggle with the accumulation rather than with one specific line. What helped was extracting one piece at a time and rebuilding, instead of refactoring the whole view at once.

So now I am wondering about the threshold itself. 275 is just the first number I tried. Too low and you drown in warnings on a big project, too high and you only find out when builds are already painful.

What do you use, and did you land on it deliberately?

For my use case, I don't need to change an element's value nor rearrange elements. Yes, I can mess around with using elements' collection's indices, but I don't want to explicitly do that; a wrapper is OK. Is it possible to write one? I can insist that the source of truth be a `RandomAccessCollection` to allow `Index`-based checking if needed.

Building an iOS app (SwiftUI) and I want to add a 3D animation of an object falling onto a scene with gravity and collision — similar to Clash Royale style. Nothing overly complex, but I come from app dev, not 3D.

Apologies if this isn't the best sub for this — happy to be redirected.

I'm looking for a free solution (no budget for Spline or paid tools). Here's what I'm considering :

1) Blender + export → RealityKit — Can AI (DeepSeek, MCP) help me model the object? Does RealityKit handle imported animations well? (I'm struggling to find clear docs on RealityKit.)

2) Unity — Use Unity just for the 3D animation and embed it in a Swift app, or does it have to be fully built in Unity?

3) Unreal Engine — Overkill for a simple animation?

4) Godot — Lighter weight, does it export well to iOS?

Anyone here who's integrated free 3D animation into an iOS app? Looking for feedback and experience.

Thanks!

Je souhaite reproduire cette animation d'ouverture dans mon application. Elle est présente dans certaines applications Apple (Livres ou Sports). Quelqu'un aurait-il une idée ?

Hi everyone,

I recently built a macOS app inspired by tools like Mockuphone. It helps you quickly add realistic device frames to your screenshots, making them look more polished for app presentations, App Store screenshots, demos, and sharing.

The project is now open source, and anyone interested is welcome to check it out, try it.

GitHub: https://github.com/dogegg-cc/mock-apple-device

Download the latest release: https://github.com/dogegg-cc/mock-apple-device/releases

Requirements:

• macOS 14 or later
• Apple Silicon recommended for the current DMG build

How can I copy exactly this design, into my app? I have a tabview to switch between view in the app, and I want to have this (both a button and a search field just like that) on the right of the tabview...

I tried to ask AI for help... but didn't work 😅 So I ask people now

I've tried to find solution, but searching online is helpless if you have no idea how to phrase your problem or what you are searching for.

Every time I had an agent generate SwiftUI, the result looked right but the colors were stale — Apple refreshed the system palette at WWDC25 (systemBlue went from #007AFF to #0088FF), and every model's training data predates it.

The HIG itself is prose, so fetching the page doesn't help either.

hig-mcp is a small MCP server that serves the structured half of the HIG:

• - current system color values (verified against the live HIG)
• - the type ramp, layout metrics, SF Symbols by role
• - Liquid Glass guardrails as an actual checklist (blur budgets, layer caps, contrast measured after blur, the Reduce Transparency fallback)
• - HIG component → SwiftUI API mappings
• Every token is provenance-tagged — Apple-published facts are marked as such, community heuristics are flagged so the agent doesn't present them as gospel.

Prose is delegated to sosumi.ai rather than rebuilt.

Python, works with Claude Code / Cursor / any MCP client. Free, MIT.

It's small on purpose. Feedback genuinely welcome — especially if you spot a token value that's drifted.

https://github.com/aka-kika/hig-mcp

I built Astryft as a SwiftUI package experiment around keeping Web and native iOS design-system output in sync.

The technical problem I wanted to explore was: if React fixtures and SwiftUI components are driven from the same manifest/token contract, can we make visual and API drift easier to catch?

Astryft includes generated SwiftUI tokens, SwiftUI components, docs, and a comparison viewer that puts live React fixtures next to generated SwiftUI snapshots from the same manifest contract. The part I’m most interested in is the cross-platform pipeline: translating token/component decisions into SwiftUI, then checking whether the native output still tracks the Web source closely enough.

I’d especially appreciate feedback on:

- whether this manifest-based contract makes sense for Web/iOS design systems

- how you’d structure SwiftUI token APIs for long-term maintainability

- what parity checks would be useful beyond snapshot comparison

- where this kind of tooling usually breaks down in real teams

Repo: https://github.com/suho-han/astryx-swift

Compare viewer: https://suho-han.github.io/astryx-swift/compare/

- Astryft is an independent reinterpretation and is not affiliated with or endorsed by Meta.                                  

A couple of months ago I open-sourced swift-markdown-engine here, the native Markdown engine I built for my macOS app Nodes. The feedback, issues, and PRs that came back were a huge help, a lot of what I changed since then came from that.

WHAT’S NEW: The parser got rewritten from scratch, regex matching is gone, it’s a real AST now. That’s what made the extension system possible: Stuff you wouldn’t expect in standard Markdown, like highlighting, used to be hardcoded into the core grammar. Now it’s opt-in. Write one file, register it, and the core parser/styler/renderer never change. Extensions can’t touch the core or each other, and you can toggle them at runtime.

Also new: full GFM/CommonMark parity, tables, task lists, quotes. More layout control (scroll-away header, fixed reading column, fit-to-content height), and a real writing layer (formatting bus, find & replace with undo, clean RTF/HTML clipboard, raw source mode). Full changelog’s on GitHub if you want details.

When I started Nodes I wanted the editor to feel properly native. Most Markdown editors on the Mac are Electron or some web view wrapped in a window, and you feel it, the text handling never quite behaves like a real Mac app. I wanted live styling in an actual native text view, not HTML rendered to look like one. Nothing built on TextKit 2 that I could just drop into a Mac app existed, so I built it, ran it in Nodes for a while, and then open-sourced it. TextKit 2 is still thin on docs and rough to migrate to, so if you’ve been putting off building something like this, it might save you a few weekends. Issues and PRs welcome. Still pre-1.0, still plenty I want to improve.

written on Nodes

Repo: https://github.com/nodes-app/swift-markdown-engine

Used in production in Nodes (App Store): https://apps.apple.com/app/nodes-by-the-werk/id6745401961

Last week, I shared my clipboard app here under the name "PurePaste."

I received feedback that the name was already in use by another macOS project, so I decided to properly rename it and rethink the architecture—going beyond just a simple name change.

The new version is called ActionSense.

When you copy something on macOS, the system only recognizes it as text.

However, different types of content imply different intended actions:

• URL → Open in browser
• Email address → Compose an email
• Color → Convert format
• Date → Create calendar event

ActionSense attempts to detect the most likely intended next action for the copied content.

Changes in v2.0:

• Renamed from PurePaste to ActionSense
• New detector protocol architecture
• Added support for 5 languages: English, Chinese, Japanese, French, and German
• Streamlined functionality to 10 useful detectors

GitHub: https://github.com/xiaoyunchengzhu/ActionSense

I’d love to get your feedback:

• What clipboard actions do you find yourself performing repeatedly every day?
• What types of content do you wish macOS understood better?
• Would you like to customize certain rule types? If so, which types and intended actions?

Agent skills I built and actually use: current Apple HIG design + "understand a project before you touch it"

Two sets of skills I lean on, cleaned up and put on GitHub.

The Apple HIG ones bug me the most: most design advice a coding agent has seen is old — deprecated APIs, pre-SwiftUI patterns, HIG from a few versions back. So I rewrote the ones I use to the current guidelines — sidebars, toolbars, typography, empty states, SF Symbols — done to spec. If you've been hoarding a pile of stale snippets, you can throw them out and keep these.

The other set is project intelligence — the boring-but-critical part of understanding a project before you touch it. Should I even build this, or does it already exist (build-vs-buy)? What does this unfamiliar codebase actually do? What broke in my dependencies while I was away? I built these four for my own work and use them on real projects, so they're shaped by actual friction, not hypotheticals.

They're plain SKILL.md files — YAML frontmatter plus the real guidance. No build step, no deps. Works with Claude Code, Codex, Cursor. Free + MIT.

Feedback welcome, especially if a HIG detail is off — I'd rather know.
https://github.com/aka-kika/akakika-skills

Hey r/iOSProgramming —

I got tired of reaching out of my blanket to tap the screen every page, so I built SwiftBook: an Apple Books-style EPUB reader for iOS that lets you turn pages with the volume buttons.

Volume Button as Page Turner

What it does:

• Import EPUBs → read with tap / swipe / progress bar / **volume button** page turns
• 5 fonts (PingFang, Source Han Serif Regular/SemiBold/Bold, Georgia)
• 4 reading themes (white · warm · dark · eye-care green)
• Font size, line spacing, margins, alignment — all adjustable
• Resume reading, TOC with chapter jump

Tech stack: SwiftUI + WKWebView. Pagination uses CSS multi-column layout rather than native scroll. Volume button detection uses AVAudioSession KVO + a silent looping WAV to keep the audio session alive.

🔗 GitHub: https://github.com/KevinLeeeee323/SwiftBookApp

MIT licensed. Free to use, modify, contribute. Built with help from Claude & Codex.

Would love feedback — this is my first iOS app!

A while ago, I shared an early version of this small iOS privacy experiment. That post reached around 104K views—and someone later downloaded the video and reposted it on X, so this version finally has a watermark 😄

The interaction is simple: you rest the side of your hand on the display, similar to covering a keypad while entering a PIN, and the app reveals only the content underneath your hand.

My first attempt used the proximity sensor. Unfortunately, iOS quite reasonably interpreted that as the phone being next to someone’s face and turned off the display.

I considered using the camera to detect the hand, but requesting camera permission felt wrong for a privacy-focused app. Instead, I built the interaction around a multi-touch area and used the active touches to control what becomes visible.

Since the original prototype, cryptoscreen has become a fully native iOS app with:

- A SwiftUI interface

- An App Clip

- An iMessage extension

- An App Store release

- An open-source codebase

The next major update will make it possible to share messages with people on the web, without requiring them to install the app. The core experience, however, is still this unusual hand-to-reveal interaction.

The source is available here:

https://github.com/DomenicoDD/cryptoscreen

App Store:

https://apps.apple.com/us/app/cryptoscreen/id6779173642

I’d be interested to hear how other SwiftUI developers would approach this interaction especially the touch handling and reveal behavior.

I am writing a spreadsheet app (long term goal). My user interface I am currently implementing the same as what Apple's Numbers app does. Right now, I have a primitive app with three "cells" which are text fields. I can click in each cell and type.

In Numbers, if the first character is an equal sign, the app changes state. Lets say I type an equal sign in cell A and then click in cell B. The result is the location of cell B is added to the text in cell A. Eventually a return is entered (into cell A) and the state returns to normal where clicking a cell puts focus on that cell.

Can someone give me some pointers on how this should be (or could be) implemented?

I've been building ImmersiveMap, a map component you can drop into a SwiftUI app - think Mapbox / MapLibre, but rendered natively for Apple platforms. It hands you a plain SwiftUI view with modifiers, so it composes like any other SwiftUI component on iOS and macOS.

What it can do so far:

• Show a full interactive vector map (streets, buildings, water, labels) as either a flat map or a 3D globe
• Camera control straight from SwiftUI: pan, zoom, rotate and tilt
• Place custom markers / avatars on real coordinates and move them in real time - handy for live-location and social features (friends on a map, driver/delivery tracking, and so on)
• Grouping: several avatars can merge into a single marker that follows their moving average (that's the marker sliding around in the clip)

It's alpha - the API will still change and there are rough edges - but it already feels smooth and responsive to use, so I wanted to share it and get feedback.

Repo (MIT): https://github.com/artembobkin/ImmersiveMap

Curious what SwiftUI folks think, and what you'd want from a native map component. Happy to answer any questions.

^{If it turns out useful, a GitHub star would genuinely help - I'd love to get it onto the awesome-swiftui list one day, and that list runs on stars.}

https://i.imgur.com/J1CHOrE.jpeg

Does anyone know how Apple created these episode thumbnails? It looks like the backgroundExtensionEffect they added for the sidebar and safe area last year, but it’s on a component. I like this design, and feels like a good use of the Liquid Glass for content on images, but can’t get the same effect that looks as seamless.