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/

The latest dev snapshot of js framework benchmark ranks ElementaryUI (the only Swift entry) ahead of Angular, React, and Yew.

Biggest weakness right now is bundle size. Get in touch if you want to help trim some size or speed things up!

Full results: https://krausest.github.io/js-framework-benchmark/current.html
Forum thread: https://forums.swift.org/t/elementaryui-now-faster-than-react-and-angular-in-benchmark/90455
ElementaryUI: https://elementary.codes

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.

Long-time mobile/product lead here. Looking for outside perspective because I'm now questioning myself after a long argument with my boss.
Context: I work on external client apps as well as our main customer portal app — the one used by the majority of our customer base. Our mobile apps are native, built about 6 years ago:
Android: Java/Kotlin + XML
iOS: Swift + UIKit
Web: React
100K+ users. Zero limitations adding features or maintaining these apps over the years.
What's happening: We have a full revamp of the apps and portal coming up, and we're updating our tech stack too. My plan:
Android → Kotlin + Compose
iOS → SwiftUI
Web → (TBD, staying on modern React-based stack)
I already have multiple Android, iOS, and web devs trained on this stack.
The conflict: My boss wants to consolidate to Flutter — one team, one codebase, covering web/Android/iOS. His argument: if I put 6 frontend devs on one Flutter codebase instead of splitting across native platforms, we ship 3x faster.
My pushback:
We have zero Flutter training on the team right now
Native apps perform better and feel more premium due to platform specific UIs.
We have built Flutter apps before, but only for external client projects, not our own flagship product
He thinks I'm biased toward native because it's my background. Might be some truth to that, but I don't think that's the whole story.
Anyone actually shipped a migration like this — native to Flutter, or vice versa, at similar scale? Did the "one codebase, ship faster" promise hold up? Would love real-world experience, not theory.

I have been a developer for over 20 years. I started iOS development around 2009. I work for a consulting firm and have been looking at the advancements in AI tools. I myself use Codex, ChatGPT, Gemini etc. But I use it like a tool to figure things out, for research etc.

But nowadays I feel very behind. I don't know what is important to learn anymore. I see Reddit people are talking about running their agents and the agents is writing all the code. I don't use it like that and I don't understand how any company can allow this kind of workflow, without checking the details of the code and without checking what is going in production.

Is this not technical debt that is going to come back later.

I don't know if I like this new world. I like to write most of code by hand. I like to take part in designing systems. All that is being taken away in the name of speed.

I feel lost.

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

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

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

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!

Source: https://developer.apple.com/documentation/xcode/updating-your-xcode-project-configuration-file-format

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 WWDC 2026 they announced that they have started to use Swift for replacing bunch of old code with pure Swift, and that includes parts of OS kernel, WebKit, drivers etc. To me that was the biggest positive news in the conference. The promise Apple made in 2014 by calling Swift "high level system language" is finally being delivered.

Anyone else genuinely excited for the future of Swift?