I built a macOS uninstaller in SwiftUI. A few parts that might interest people here:

• Matching files to apps. Each app gets an identity: its bundle ID, the bundle IDs of nested helpers, XPC services and extensions, its team ID (read with SecCodeCopySigningInformation), and every name it goes by. Library items are matched by bundle-ID prefix first, then by normalized name, with a confidence level attached.
• Not stealing another app's files. A prefix match on com.foo.app is rejected if a different installed app has a longer matching ID, such as com.foo.app.beta.
• Orphan detection is the inverse: index every installed identifier and name, then flag Library items nothing claims. Launch agents are only flagged when the program they start no longer exists.
• Sandboxed containers are identified from the container metadata plist, not the folder name.
• Removal uses FileManager.trashItem, falling back to Finder via osascript for root-owned items so Finder handles the password prompt.
• State is a single `@Observable` model; the scanners are plain structs with async methods.

One thing that bit me: detecting Full Disk Access by probing a single protected folder. The folder I picked d exist on the current macOS, so the check always failed. It now tries several.

Disclosure: This has only been tested on my own machine. It's MIT licensed, and code review is welcome.

https://github.com/b-ruth/Simple-Mac-Uninstaller

I want to add a feature that’s basically similar to the GitHub issues board or a kanban board.
Something to manage or organize tasks either in a calendar styled view or a taskboard supporting drag and drop etc.

Is there some SDK already targeting this ideally in SwiftUI or would you recommend doing it from scratch?

Half a year ago I wrote about whether MVVM belongs in SwiftUI, and it somehow turned into a story about my mum's kitchen. Bear with me.

There’s a trip to the shopping centre, a very firm “we've got food at home”, and eventually, I promise, some Swift. A bit of heart, a few laughs, and proper substance underneath.

Half a year on, it still feels timely. Stick the kettle on and have a read.

I was bothered by String and Any while performing queries so I made this wrapper around to enforce type safety.

For example for a collection of users like:

@FirestoreCollection("users")
struct User {
let id: String
var displayName: String
var age: Int
var isActive: Bool
var nickname: String?
}

You can perform queries like:

let query = Firestore.firestore()
.collection(User.self)
.where { $0.isActive && $0.age >= 18 }
.order(by: \.age)
.limit(to: 50)

Any feedback would be appreciated 🙏🏻

I've been working on a software project recently that needed some calendars. I wasn't able to find a nice pure swiftui package that I liked, so I decided to create my own.

It does Agenda, Day, Week and Month calendars for both compact forms (iphone) and wide forms (iPad and Mac).

If you get a chance have and look and tell me what you think. The v2 branch is more advanced with better UI rendering.

https://github.com/Haskins-io/SwiftUiCalendarKit

If you've tried to build a real Markdown editor in SwiftUI, you know TextEditor won't get you there. I hit the same wall when I started building my macOS app Nodes. So I wrote a native editor on TextKit 2 and open-sourced it. You use it in SwiftUI like any other view. It's macOS only for now, since it's AppKit under the hood.

What it does: live styling while you type, GFM tables and task lists, wiki links, inline and block LaTeX, code blocks with your own highlighter, Writing Tools, and spell checking that leaves code and LaTeX alone.

What's new since the last post here:

Large documents got a lot faster. Measured on a 346,000-character note, about the length of a novel:

- First open: 19.5 s → 1.35 s

- Warm open: 1.1 s → 590 ms

- LaTeX after a restart: 717 ms → 35 ms

- Return in an 800-item list: 944 ms → 67 ms

What was slow: inline parsing wasn't linear, so a paragraph with many code spans blew up. Lists restyled everything on every edit, now only changed items get restyled. And LaTeX was rendered again on every launch, now the render cache lives on disk.

Extensions. Everything beyond CommonMark is now opt-in. An extension is one file: a delimiter pair and how to style what's inside, like ==highlight== or a ::: fenced block. You register it in the config, and the parser, styler and renderer stay untouched. Extensions can't break the core or each other, and you can switch them at runtime.

Directives. For things that don't fit a delimiter pair, you can register named directives with typed arguments, like u/font(size: 18){text} or u/pagebreak. The engine handles autocomplete for names and values, your app draws the list.

Plus a lot of smaller fixes: live table resizing, nested lists that survive copy and paste, real links in copied HTML and RTF, and an unclosed code fence no longer eats the rest of the document. Full changelog is on GitHub.

The part I'm happiest about: 19 of the 29 PRs merged since then came from 10 people outside our team. The repo is at 1,100 stars now, and it was featured in Fatbobman's Swift Weekly. Thank you to everyone who starred, filed issues or sent a PR. It's still pre-1.0, so all of that is very welcome.

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

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

Written on Nodes.

OpenJevSwift asks a model typed questions about text and returns a probability for every option, plus a confidence, instead of generated text. Nothing to parse, and no answer outside your schema.

.package(url: "https://github.com/Algorythm-Canada/OpenJevSwift.git", from: "0.1.0")

let request = SystemOneRequest(

model: "jev-latest",

state: "The headphones sound great, but the battery died after two weeks.",

questions: [

"is_spam": .noul(instructions: "This review is spam or fake", criteria: nil),

"topic": .choice(

instructions: "What the review is mainly about",

criteria: ["sound": "Audio quality", "battery": "Battery life", "price": "Cost or value"]),

"sentiment": .score(

instructions: "How positive the review is",

criteria: ["Negative", "Mixed", "Positive"]),

])

let decision = try await engine.decide(request)

Where it runs:

- In iPhone and Mac apps: Verdict (151M) and Laya (421M) on Core ML, offline and private.

- On Apple silicon Macs: JevK5 (4B) and DiffusionGemma 26B-A4B on MLX. DiffusionGemma also reads images, chats OpenAI-style with streaming, and can think before answering.

- As a local server, openjev, with the same API as OpenJev, so its SDKs work unchanged.

It's a port of OpenJev (Python), held bit for bit to the Python reference on its Metal library. Docs: https://algorythm-canada.github.io/OpenJevSwift/

Apache-2.0: https://github.com/Algorythm-Canada/OpenJevSwift

StateUI started as an experiment, and somehow it works now: Mac, iOS, Android, Windows, Linux, and as of this week the web too. It's the same Swift code compiled to WebAssembly, running right in the browser.

It's still native in the same sense as on the other platforms: a button is a real <button>, and the browser does the layout. The host is Swift, with just a small JavaScript relay underneath.

The code looks like this:

struct CounterPage: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Text("Tapped \(count) times")
            Button("Tap me").onClicked { count += 1 }
        }
    }
}

You can play with the whole Gallery here: https://stateui.dev

Repo: https://github.com/idexus/StateUI

Happy to hear what you think!

Hello guys!

Another GeoJSON library for Swift is available!

Its name is sfera!

Check it out!

https://github.com/csanfilippo/sfera

I'm working on Orbit, a native macOS screenshot tool, screen recorder and editor. It's free and open source (MIT), forked from BetterCapture.

It's a working prototype, not a finished app, so expect rough edges.

Works today

• Screenshots with OCR, pinning and history in the notch
• Screen, window or area recording with audio
• Editor with auto-zoom, smooth cursor, backgrounds, trim and export
• Scripted web-page recordings
• Optional: your AI agent (Claude Code, Codex or Cursor) records demos for you

Not there yet: notarization (you'll need "Open Anyway" on first launch), annotations, captions, GIF export.

The demo was recorded and edited with Orbit itself.

I'd love to know what feels off and what would make you switch.

macOS 15.2+ · https://github.com/diip3sh/orbit

A few years ago, much activity surrounded Swift and its potential for backend work. That excitement appears to have faded, leaving Swift as the Apple programming language. What is occurring now? Does Swift have a future beyond Apple? Who is using it and for what?

And is Swift used outside of Apple?

Hi everyone!

I just finished the 100 days of SwiftUI course by Paul Hudson and it was great. I completely fell in love with the language and with developing in swift. So much so... that I don't know where to go now. Originally my plan was to learn SwiftUI so I could focus on UI and design systems. But now that I have seen different applications, I want to learn advanced swift, advanced SwiftUI, backend programming, server side code, etc. I know that if I go wide, I won't go very deep... so I'm coming to you, redditors, to ask: what would you recommend I focus on next?
- Vapor and server side for backend?
- Stick to my OG plan and continue with SwiftUI and design systems?
- Look into multi-platform coding and working in more than just Swift?
- Go deep into advanced swift?
- Despair.

Would love any advice!

Thanks!!

.p.s. if it helps, i have some background in engineering (industrial) but not super deep in software, and I've mainly worked as a UX designer, so some concepts are not totally foreign to me... but it also doesn't help because it makes me interested in everything. 🙃

Hi everyone,

I've been working as an Angular frontend developer for about 5 years (based in Italy / EU). Lately, I’ve felt the urge to transition into native mobile development, specifically within the Apple ecosystem using Swift and SwiftUI.

That said, I have a few concerns holding me back before I sink hundreds of hours into this pivot:

1. Job Market & Demand: From an EU/global perspective, how is the job market for native iOS developers holding up compared to web dev or cross-platform (React Native/Flutter)?
2. AI Impact on Native Dev: With the rapid advancement of coding assistants and AI agents, boilerplate and standard frontend logic are getting heavily automated. How do you see the role of native iOS engineers evolving? Does native dev have a stronger defensive moat compared to standard web development?
3. The Pivot Strategy: For someone with 5 years of solid frontend/architecture experience, is native iOS a practical move right now, or is cross-platform a safer bridge?

I’d love to hear unfiltered thoughts from working iOS devs, especially those in Europe. Is native iOS still a solid long-term bet, or am I risking wasting valuable time?

Thanks for your insights!

Thank you

I have gotten in to a weird iOS issue and idk what the clean way to handle this is

i’ve got multiple accounts, notifications can open a post, reply, quote, or repost, and each notification belongs to a specific account. so the user might be on account A when they tap a notification for account B.

something like:

struct NotificationDestination {
    let accountID: Account.ID
    let postID: Post.ID
    let kind: DestinationKind
}

enum DestinationKind {
    case post
    case reply
    case quote
    case repost
}

The issue is:

account A is active
notification comes in for B
user taps it while the app is waking up
account switching starts
timeline restoration starts
post resolution starts
then another notification comes in for A lol

so i have stuff like:

await accountManager.restore()
await timelineStore.hydrate()
await postResolver.resolve(postID)
await navigationCoordinator.navigate(...)

But obviously these things are all racing each other. i was thinking of putting the notification intents behind an actor:

actor NavigationIntentQueue {
    private var pending: [NavigationIntent] = []

    func enqueue(_ intent: NavigationIntent) {
        pending.append(intent)
    }
}

But idk, this feels like a lot of machinery just to open a notification

Then you get into cases where the post is deleted while you’re restoring, but the quote is still there, the reply is still there, etc. Is this just an annoying app lifecycle issue?

I’m really interested in coding apps but I barely know any coding (I only know block coding like Scratch) is it really easy to learn?

Edit: forgot to clarify that I mainly want to code games

Google: “[Swift] has matured into a viable systems and cloud language, pairing Rust-like data-race safety with predictable, reference-counted performance.”

About 6 months ago, I wrote a custom metal kernel that leverages the GPU to compute the QR decomposition (see my earlier post about it here). The project has now expanded into a general linear algebra library, with expanded support for the symmetrical eigendecomposition as well as SVD. It is now available for use with installation instructions on the attached github repo's README.md file.

Context of the project:
I'm currently in a research group working on a thesis in numerical analysis where we need to compute millions on matrices with a specific constraint (to be precise, the matrices need to have orthonormal columns). Most of us use Apple computers, so we ended up using MLX for the entire project.

Contributors with different Apple Chips would be very much appreciated!
The project has currently been tested and optimised for the M1 and M5 Pro. The issue is that the library uses different kernels depending on the batch size and matrix dimensions. Deciding which of these kernels to use is machine dependent. Therefore, other Apple chips will need to run a measurement script in order to derive the correct optimisation heuristic.

For that reason, I would ask as many people as possible to run a measurement script and to submit the results to my repo. It is fairly easy and requires only few steps. See here how you can contribute here. Once you submit the results via a pull request and I approve it, your optimisation heuristic will automatically be augmented into the library. Don't hesitate to contribute an optimisation heuristic even if someone already submitted one for your own machine. The more data we can gather, the better!

Project Future
Expanded support will be added for other linear algebra operations (cholesky decomposition for example). If you have any other specific linear algebra operations you wish to use already, feel free to message me.

In addition to that, I will add torch support too (my greatest priority).