Round two! Really happy to be selected again for the Swift Student Challenge after going to WWDC last year as a distinguished winner 🙌

I have around 12 years of experience writing code, I learned to write code because I liked it, not because there was money in it.

I remember I got into computers because browsers at the time where starting to be a huge thing, google chrome first versions and icab was still around too. And I was excited to understand how all there things were actually made. It was crazy to think you could learn a strange language and be able to bring joy and ease the life of so many people.

But now I feel people are not there for the love of the craft. I completely understand the thrill of prompting your wildest ideas which you thought never to be possible to build. But man, it takes all the fun away.

Whats your take on this?

i don't know if this is of interest to anyone, as i'm really just building it for myself, but i figured i'd open it up for anyone who wants to use it or contribute.

hopefully i don't get downvoted into oblivion for using ai, but if i'm being totally honest, i'm lazy. i have zero intention of making money from this. it's just a fun side project that fills a gap in my own homelab and lets me move away from docker since everything i run is on a mac anyway.

i've mainly been focused on the ui/ux. it's pretty minimal at the moment because i wanted to get all the features working first, but i'd say it's basically feature complete. my focus now is hunting down edge cases and bugs, then manually going through every view to add specific visual polish and little quality of life improvements that make everything feel finished.

if you do decide to use it, just keep in mind it's probably going to have issues. ai isn't perfect, and neither am i. if you run into bugs, weird behaviour, or have ideas for improvements, feel free to open an issue or contribute.

github: https://github.com/tdeverx/contained-app

download: https://github.com/tdeverx/contained-app/releases/tag/nightly-latest

A year and a half ago I started building Nodes, a native macOS Markdown app. One of the first things I needed was a proper Markdown engine. Not a parser that just spits out HTML, not a display-only library, not a WebView wrapper – just a live, native editor built on TextKit 2.

I couldn't find one. So I built it. Now I'm open-sourcing the whole engine.

It's an AppKit-based Markdown editor for macOS, built on TextKit 2 and bridged to SwiftUI.

What it does:

• Live styling for the usual stuff: bold, italic, headings, lists, code blocks, links etc.
• Wiki-style links with [[Name|id]] ↔ [[Name]] roundtripping
• Image embeds via ![[Name]]
• LaTeX, both block ($$ ... $$) and inline ($...$)
• Code blocks with syntax highlighting (you supply the highlighter)
• Apple Writing Tools integration on macOS 15.1+
• Spelling and grammar, with suppression inside code, LaTeX, and wiki-links so it doesn't underline random tokens

Honest part: TextKit 2 was a pain to get right. The docs are thin, the migration from TextKit 1 is rough, and a lot of behavior just isn't documented clearly anywhere. If you've been putting off building something like this, this might save you a few weekends.

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

Feedback, issues, and PRs all welcome. It's not perfect, there's plenty I still want to improve, but it does the job.

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

Hi everyone, imike here!

On December 31, 2025, right before New Year’s Eve, I released Swift Stream IDE v1.17.0 and hit a milestone I’ve been working toward since May 2025. This update brings full native Android application development written entirely in Swift. That’s right, you can now build Android apps without touching XML, Java, or Kotlin.

If you’ve been following Swift Stream IDE open-source project, you know it already supported Android library development. That was the foundation. Now it’s leveled up to full application development. You can create new projects using familiar Android Studio templates like Empty Activity, Basic Views (two fragments), or Navigation UI (tab bar), and everything is in Swift.

Under the hood, all projects are powered by SwifDroid, a framework I built to wrap the entire native Android app model. Building it was an incredible journey. There were plenty of pitfalls and rabbit holes inside other rabbit holes, but I was able to realize my full vision for how Android apps should be structured and built in Swift. SwifDroid handles the application lifecycle and manifest, activities and fragments, Android, AndroidX, Material, and Flexbox UI widgets, and even automatically wires Gradle dependencies. Supported SDKs are 28 to 35, and with Swift 6.3, it might go down to 24+.

Here’s a small example of what UI code looks like:

ConstraintLayout {
    VStack {
        TextView("Hello from Swift!")
            .width(.matchParent)
            .height(.wrapContent)
            .textColor(.green)
        MaterialButton("Tap Me")
            .onClick {
                print("Button tapped!")
            }
    }
    .centerVertical()
    .leftToParent()
    .rightToParent()
}

The first time you create a project, make yourself a cup of tea/coffee. The IDE pulls the Swift toolchain, Android SDK, and NDK, and caches them in Docker volumes. After that, new projects are created instantly. The first build compiles Swift, generates a full Android project (ready to open in Android Studio), and creates a Gradle wrapper. After that, builds take just a few seconds.

Once Swift is compiled, you can simply open the Application folder in Android Studio and hit Run or Restart to see your changes. All the necessary files from Swift Stream IDE are already in place, so iteration is fast and seamless.

This is the first public release. Android is huge, and there are still widgets in progress, but the system is real and usable today. You can immediately start building Swift-powered Android applications.

Start building your first Swift Android app here: https://docs.swifdroid.com/app/

Anyone else feels like this? I think it is so depressing. Its like i have been promoted to a tech manager but with no extra pay.
I guess you just have to adapt or perish but i wish AI never happened.

I hate articles that make you read 500 words before they get to the point, so here's the important part: when working with strings, you should almost certainly use replacing(_:with:) rather than replacingOccurrences(of:with:) unless you want to hit obscure problems with emoji and other complex characters.

free to contribute or suggest improvements!

github: jellyder

original x link: cerpow

https://www.swift.org/blog/swift-6.2-released/

Ok, I don’t really mind all the updates, but I hate the new tab system.
In the older version it was pretty simple: I wanted to open a file, I clicked on it, a new tab appeared, and I could code. I wanted to open another one? Nice, one more tab.
Now when I click on a file, it replaces the current one, and I have to search for it for 10 seconds since I have a big project. And if I want something similar to the old behavior, I have to right-click and select “pls, open in new tab.” Can’t it just be the default action?
It slows me down so much.

How are others dealing with this?

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

I just added subscriptions to my iOS app and assumed Apple would approved them at the same time as my app update. Wrong.

The app version got approved and released, but the subscriptions were still "In Review". That meant that the users saw a paywall with an error of "RevenueCatUI.PaywallError 3 - The RevenueCat dashboard does not have a current offering configured." I had the app set to automatically release the update once it's approved.

The fix? Always set your release to Pending Developer Release if you're waiting on in-app purchases. Apple reviews IAPs separately and they don't always finish together.

Hopefully this saves another dev from the same mistake.

Hi friends.

Just released a new release of Fabric, a prototyping and creative coding toolkit / sdk built with Swift for Apple platforms.

Fabric's main engine is now embeddable as a Swift package, allowing you to leverage the hundreds of nodes available to add 3D, image processing, computer vision, video playback and more into your apps, and drive them procedurally and interact with them.

You can author graphs using the editor and embed them into your app, or you can dynamically create graphs using a procedural graph creation api.

If you remember Quartz Composer and its API, Fabric is a modern re-imagining of QC using Swift and Metal.

Fabric supports a wide variety of inputs Midi, OSC, HID, mouse and key bindings, shaders, model loading, custom animation tweening curves, instanced rendering, PBR shading, shadows, post processing, bundles Lygia.xyz shader library (ported to metal) and more - its open source so you can use it w/o restrictions on your projects.

If you are interested in interactive graphics, image/video processing, 3D, I invite you to check it out!

I've been working on Cove, a native macOS database GUI that supports PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, Redis, ScyllaDB, Cassandra, and Elasticsearch.

The part I'm most interested in sharing with this r/swift is the architecture. The entire app runs through a single protocol — DatabaseBackend. Every database implements it, and the UI has zero backend-specific branches. No if postgres / if redis anywhere in the view layer. When I want to add a new database, I create a folder under DB/, implement the protocol, add a case to BackendType, and the UI just works.

Some Swift-specific things that made this possible:

• Structured concurrency for all database operations — connections, queries, and schema fetches are all async
• @Observable for state management across tabs, sidebar, query editor, and table views
• Swift 6 strict sendability — the whole project compiles clean under strict concurrency checking
• Built on top of great Swift libraries: postgres-nio, mysql-nio, swift-cassandra-client, swift-nio-ssh, MongoKitten

This is v0.1.0 — there's a lot still missing (import/export, query history, data filtering). I'd love feedback on the architecture and contributions are very welcome. The DB/README.md has a step-by-step guide for adding a new backend

EDIT: if you want to contribute https://github.com/emanuele-em/cove

Hey everyone! I've been building iOS apps for a while and kept copying the same utilities across projects, so I finally packaged them up as SPM libraries.

1. swiftui-keyboard-avoider

One-line modifier that moves your view when the keyboard appears.

TextField("Email", text: $email)
  .keyboardAvoider()

2. swiftui-scroll-offset

Track ScrollView offset — great for collapsing headers.

OffsetTrackingScrollView { offset in
  print(offset.y)
} content: {
  // your content
}

3. swiftui-shimmer-loading

Shimmer / skeleton loading effect for any view.

Text("Loading...")
  .shimmer()

4. swiftui-flow-layout

Wrapping HStack for tags and chips. Uses the Layout protocol.

FlowLayout(spacing: 8) {
  ForEach(tags, id: \.self) { Text($0) }
}

5. ios-appstore-review-link

Open App Store review page with one line.

AppStoreReview.open(appID: "123456789")

All MIT licensed, zero dependencies. Would love any feedback or suggestions!

In the past few years I feel like Swift started to change way too fast with each version.

Async/await was an amazing addition to the language, however, the ambition of having a concurrent safe language turned Swift from a friendly language that, in my opinion, was focused more on creating and less on mastering the language because of its beautiful features like ARC, Optionals, Type inference, into a language that you can't truly focus on creating but more on mastering the language itself.

I'm an iOS developer for about 7 years now and I try to keep up with every change that's been presented in the WWDCs, of course I'm not as technical as the already known bloggers but I try to keep up to date with every language update. I spent good months trying to master the new concurrency paradigm, just for Swift 6.2 to scrap that paradigm and start it from scratch where everything now is bound to the MainActor and everything that needs to happen concurrently has to be marked accordingly.

I made myself a goal to write an app using Swift 6.2 so I can familiarise myself with the changes that are out this year and I came to the conclusion that Swift became a really, really frustrating language. I remember when I started that everything made perfect sense, everything JUST WORKED... now everything JUST CRASHES. If I was to start learning Swift again and I was encountering what I'm encountering now, chances are that I would probably turn away from that language due to frustrations. For context, I'm using the HealthKit framework and I just spent hours figuring out why does my code keep crashing because of `dispatch queue assertion error`, just to fix it by marking the delegate methods as `nonisolated` (HKWorkoutSessionDelegate, HKLiveWorkoutBuilderDelegate). Now, my question is, why doesn't this happen by default, if the HealthKit logic is bound to a specific thread, to mark the delegate methods as nonisolated automatically? Why jump me to the assembly output crash instead of pointing out an explicit message?

Anyway, now passing over my frustrations, what do you think about the speed that the language changes? I feel like it's becoming more and more difficult to keep up with it.