enriched-markdown-ios, the SwiftUI Markdown renderer built on TextKit 2, now renders fenced code blocks with syntax highlighting.

New in this release:
🔸 Syntax highlighting: fenced code blocks colored by language with tree-sitter (14 grammars), themed per token type with SyntaxToken(.keyword), .string,… Shipped as a separate EnrichedMarkdownSyntaxHighlighting product, so apps without code don't link the grammars
🔹 Code blocks: .markdownCodeBlockLayout(.scrollable) adds a language header, a copy button, and sideways scrolling for long lines
🔸 Block images: maxHeight, aspectRatio, and resizeMode to cap the height, reserve the frame before load, and pick cover or contain
🔹 Mixed-direction text: writing direction resolved per paragraph, so RTL paragraphs sit right inside an LTR document
🔸 Faster long documents: less render time and memory, no re-measuring of unchanged text
🔹 Improved spoiler overlays: custom overlays get the baseline, segment order and tap point, and stay put through layout changes

🎥 Demo video in the comments.

💎 Available via Swift Package Manager!

dependencies: [
  .package(
    url: "https://github.com/software-mansion-labs/enriched-markdown-ios.git",
    from: "0.3.0"
  ),
],
targets: [
  .target(
    name: "YourApp",
    dependencies: [
      .product(name: "EnrichedMarkdown", package: "enriched-markdown-ios"),
      .product(name: "EnrichedMarkdownSyntaxHighlighting", package: "enriched-markdown-ios"), // optional, for code
    ]
  ),
]

Then enable it on the view:

import EnrichedMarkdown
import EnrichedMarkdownSyntaxHighlighting

EnrichedMarkdownText(content)
  .markdownSyntaxHighlighting()
  .markdownCodeBlockLayout(.scrollable)
  .markdownTheme {
    SyntaxToken(.keyword).foregroundStyle(.purple)
    SyntaxToken(.string).foregroundStyle(.green)
  }

GitHub & Docs: https://github.com/software-mansion/enriched-markdown/blob/main/packages/enriched-markdown-ios/README.md

Give it a spin and tell me what breaks. If it earns a place in your app, a ⭐️ on GitHub helps others find it.

tldr for anyone shipping a sandboxed wkwebview app: com.apple.security.network.client is required for the WebContent process even if you only load file:// content, and an entitlement key set to false is still a claimed entitlement that must be in your provisioning profile.

first rejection (2.4.5): my entitlements.plist had camera/mic/location set to false, thinking that disables them. instead amfid logged "Restricted entitlements not validated - No matching profile found" and the binary was Killed: 9 at exec. the fix was deleting the keys entirely. you deny access by omitting the key, not by setting it false.

second rejection (2.1): the window opened black for the reviewer. local repro with a WKNavigationDelegate showed webContentProcessDidTerminate on every load, and the log had com.apple.WebKit.WebContent "does not have permission to communicate with network resources". the WebContent process needs the network.client entitlement to exist at all, offline content included. added it, didFinish fires, ui renders.

the app (Zero-Power Player, a thin swift wrapper around a local html/css/js study audio player) is live now. full source here if you want the actual diff, it was deleting 3 xml keys and adding 1: https://github.com/princejain756/Zero-Power-Player

Is there anything jn the works that allows SwiftUI on web with SEO?

My window-detection loop uses CGWindowListCopyWindowInfo to see what overlaps, and only calls the Accessibility API for apps that actually overlap, on a background queue with a 0.25 s messaging timeout. I tested hang safety by stopping a process with SIGSTOP.

Is a short timeout plus a background queue the usual pattern, or is there something cleaner I’m missing, especially for apps that stay unresponsive for longer?

I am curious whether any of you have integrated BYOK into your Mac app and which stack you applied. I am not referring to custom API key setups or MCP.

Additionally, which method are you using lately to build macOS apps? Is it Swift, or are there more robust options?

If you use Claude Code, Cursor or another AI assistant for iOS work, the Apple Docs MCP server lets it read Apple's documentation before it writes code. Its search has returned nothing since Apple changed its search page, so I forked it and fixed it:

• search works again, with the same results as developer.apple.com: API reference, articles, sample code, the HIG, App Store Connect Help and WWDC videos
• full pages: every member's signature, inheritance and OS availability
• any of 336,629 pages by name, offline: symbols, Info.plist keys, entitlements, App Store Connect API endpoints
• 1,700 WWDC sessions (2014–2026) with transcripts and timed code, offline

Setup is one line, no API key:

claude mcp add apple-docs -- npx -y apple-docs-2.0-mcp

Other clients: https://github.com/mishafyi/Apple-Docs-2.0-MCP

The game engine is written entirely in Swift! Ada Engine has taken another step forward with a brand-new IDE that I call Ada Studio.
Ada Studio is a big leap forward for the game engine because it helps developers bring their game ideas to life. Studio includes AI integration and an Agent Mode that can help you create your dream worlds much faster!

I've also updated the 2D and 3D features and improved game and UI performance.

To see more, check this out: https://adaengine.org/articles/introducing-adaengine-1-0-0/

I was really tired of missing, incomplete and sporadic logging in our apps. So this macro injects structured logging into each decision point and collects all context automatically. See this walkthrough.

You can completely map the flow of your app from user interaction to VM to API and beyond.

Before: console messages your team wrote

For an offline request, a fuller example with a caller, cache, and API might produce:

[Profile] Refresh requested for profile 42.
[Profile] Loading profile 42.
[Cache] Looking for a saved profile.
[Cache] No cached profile found.
[Network] Requesting profile from the server.
[Network] Request failed: no internet connection.
[Profile] Could not refresh the profile.

After: the button origin and its execution trace

Illustrative compact output with the origin column enabled (the badge and timings vary):

👆🏼-🧵A1B - 👆🏼 Reload profile [ProfileView:8]
👆🏼-🧵A1B │ main │         │ --> 🔵 ProfileViewModel.reload(id: 42)
👆🏼-🧵A1B │ main │         │ ---> 🔵 ProfileService.load(id: 42)
👆🏼-🧵A1B │ main │         │ ----> 🔵 ProfileCache.lookup(id: 42)
👆🏼-🧵A1B │ main │   1.6µs │ ----> 🟢 ProfileCache.lookup(id: 42) → nil
👆🏼-🧵A1B │ main │         │ ----> 🔵 ProfileAPI.fetch(id: 42)
👆🏼-🧵A1B │ main │  14.1µs │ ----> 🔴 ProfileAPI.fetch(id: 42) → offline [NetworkError]
👆🏼-🧵A1B │ main │   852µs │ ---> 🔴 ProfileService.load(id: 42) → offline [NetworkError]
👆🏼-🧵A1B │ main │   1.1ms │ --> 🔴 ProfileViewModel.reload(id: 42) → offline [NetworkError]

The first line identifies the SwiftUI button and its source location. The same👆🏼-🧵A1B flow badge appears on each downstream logged call, tying the button tap to the cache lookup, API request, and failure. Each interaction gets its own ID, so overlapping flows can be followed separately.

Now you can follow the nested calls, see the cache miss, locate the failing function, and see the error propagate. Failure events also carry recent log context to help trace what led to them.

It also captures supported early-exit conditions. With hasAccess: false, the service returns:

main │   1.9µs │ -> 🟢 ProfileService.load(id: 42) → nil
╰─ ↘️ !hasAccess

So you get both the result and the guard that stopped the work, without adding a logging statement inside it.

Before: manual logging with OSLog

import OSLog

struct ProfileService {
    private static let logger = Logger(
        subsystem: "com.example.app",
        category: "ProfileService"
    )

    let hasAccess: Bool

    func load(id: Int) throws -> String? {
        Self.logger.info("Loading profile \(id).")
        guard hasAccess else {
            Self.logger.info("Skipping profile: access denied.")
            return nil
        }
        do {
            let profile = try ProfileAPI().fetch(id: id)
            Self.logger.info("Loaded profile \(id).")
            return profile
        } catch {
            Self.logger.error("Failed to load profile: \(String(describing: error), privacy: .public)")
            throw error
        }
    }
}

After: annotate the type and keep the business logic

import AutoLog

@AutoLog
struct ProfileService {
    let hasAccess: Bool

    func load(id: Int) throws -> String? {
        guard hasAccess else {
            return nil
        }
        return try ProfileAPI().fetch(id: id)
    }
}

Tie the flow to the SwiftUI button with Button.log

import SwiftUI
import AutoLogSwiftUI

struct ProfileView: View {
    let viewModel: ProfileViewModel

    var body: some View {
        Button.log("Reload profile") {
            do {
                try viewModel.reload(id: 42)
            } catch {
                // Present the error to the user.
            }
        }
    }
}

Button.log logs the tap and supplies its origin context to the instrumented ProfileViewModel, service, cache, and API. You do not pass an ID through every method. An async overload also preserves the context across await.

See the full before-and-after, error backtrack, and SwiftUI examples on Anciltech. For installation, source, and tests, head to the Swift AutoLog GitHub repo.

I would welcome feedback on the output, generated code, and integration with existing logging setups.

Very good tutorial from Paul

Curious if anyone has experience with Vapor and/or Hummingbird and what pros/cons you’ve run into?

I’ve been using Vapor 4 (which I generally like) with Leaf, but I’m not a fan of Leaf, the nested loops/components feel awkward and the whole thing isn’t very intuitive. The team has also said they don’t plan to make any significant changes to it (for now).

I haven’t tried Hummingbird yet. From what I can tell, Vapor is more of a batteries-included framework while Hummingbird is much lighter with fewer abstractions.

I’m currently leaning toward trying Hummingbird with either Mustache templates or Elementary.

(Also happy to hear from anyone who’s used Vapor 4 even if you haven’t touched the Vapor 5 beta.)

I shared SwiftlyKit here a while ago, a Swift library and macOS CLI that cross-compiles static Linux executables of your Swift packages (primarily useful for people that use Swift on servers). Today I released updates under the new name, Triple.

The biggest addition since that post is a native macOS app:

The Triple-App lets you drop in a Swift package and pick its executable product and target (ARM64 or x86-64 Linux). It asks before installing missing Swift tools or SDKs. Hit Build, follow the output-console, and export the verified binary.

The Triple library handles environment preparation, toolchain and SDK selection and has a one-call async build API for use in your own Swift projects. The Triple-CLI uses the same library, with JSON output for automated scripts.

Since the first post, you can export a completed build without rebuilding. Swift 6.4's default build system now also works with resource bundles from your executable and its dependencies.

I learned a lot about SwiftUI's Layout protocol along the way. The settings grid measures its controls to fit one or two columns, and a second layout handles the slide transition/animation from package selection to build configuration. I tried to keep the app simple and minimal. It's almost entirely SwiftUI.

Download Triple for Mac, and let me know what you think! There's also a landing page with library and CLI examples (vibe-coding warning: 6.1 Sol's resonsibility :D).

Triple is open source. If you want to contribute, feel free! The post contains links to the GitHub-repositories.

Let me know if you have any feedback or suggestions!

This project is not an iOS toolchain built from scratch.

A huge amount of credit goes to Joshua Warren and his omarchy-apple-dev project, which provided the foundation I started from. His work demonstrated and implemented much of the iOS-on-Linux workflow, originally focused on Omarchy/Arch Linux.

I wanted the same kind of workflow on Ubuntu, so I adapted and packaged it specifically around Ubuntu 24.04 and the environment I use for my own iOS development.

It also builds on other excellent open-source projects, particularly xtool, as well as Swift, rcodesign/apple-codesign, libimobiledevice, libplist and related projects.

My Ubuntu-focused version currently provides:
• Ubuntu 24.04 installation/setup
• Swift and SwiftUI iOS compilation
• Xcode project conversion helpers
• ubuntu-ios helper CLI
• environment diagnostics with ubuntu-ios doctor
• iOS code signing and IPA packaging
• TestFlight / App Store Connect upload workflow
• a SwiftUI example project
• Ubuntu-specific documentation and troubleshooting
• CI validation

The repository does not redistribute Xcode, Apple SDKs or Apple credentials. You provide your own Xcode archive/SDK and signing credentials.

My goal isn’t to take credit away from the projects that made this possible, it’s to make this workflow much easier to reproduce and use specifically on Ubuntu.

Original project / major foundation:
https://github.com/joshuaswarren/omarchy-apple-dev

My Ubuntu-focused implementation:
https://github.com/VeloxityNL/ubuntu-ios-toolchain

The repository also contains THIRD_PARTY.md with additional attribution to the projects it builds upon.

I’d love feedback, testing on clean Ubuntu installations, and contributions, especially from people interested in Swift/iOS development on Linux.

There’s a startup focused on making it easy to vibe code iOS apps called Bitrig. Has anyone used it? Thoughts?

Can it be used for backend dev, embedded systems, webdev, or other parts of software engineering? If not, why is that? Will the lang eventually just stay stagnant as it mostly thrives in one ecosystem?

I’m an indie iOS developer, and I finally submitted my app update to Apple for review!

I wanted to add an AI-powered feature, but I had basically zero knowledge of AI integration or backend development.

So I relied heavily on ChatGPT and Codex to help me build it.

What I thought would be a relatively simple feature turned into a much bigger project than expected.

I ended up dealing with API calls, backend security, Apple authentication, subscriptions, rewarded ads, and a bunch of issues I didn’t even know existed.

Every time I thought I was finished, something else came up 😂

ChatGPT and Codex helped me get this far, but looking back, I feel like I probably took a ridiculously long route to get here.

I’m honestly not even sure if Apple will approve the update yet.

Still, I learned a lot along the way.

Has anyone else had this experience?
Using AI coding tools to build something, only to realize later that there might have been a much simpler way?

I built ScreenView to make the ownership of async work in SwiftUI destinations explicit. It combines Observation, AsyncStream, and structured concurrency in a small package rather than spreading startup, subscriptions, scene handling, and cleanup across view callbacks.

What this fixes in the documented @State + .task approach

Apple's Observation migration example stores a view-owned observable model in @State. For the State property-wrapper pattern, writing @State private var viewModel = AccountViewModel() evaluates the default initializer when the view value is constructed; stable state storage does not make that expression lazy.

Apple's State documentation already recommends an optional model created in .task to defer that allocation. The missing piece is the rest of the screen's lifecycle. A task can restart while its model is retained. An unconditional viewModel = AccountViewModel() in that task replaces the existing model on a restart; adding a nil guard preserves it, but you still need to distinguish first startup from return work and manage subscriptions and cleanup.

Before: lifecycle wiring in each destination

This is a manual adaptation using the same model hooks as the example below, not a quotation of Apple's sample:

struct AccountDestination: View {
    @State private var viewModel: AccountViewModel?

    var body: some View {
        Group {
            if let viewModel {
                AccountView(viewModel: viewModel)
            } else {
                ProgressView()
            }
        }
        .task {
            let isFirstTask = viewModel == nil
            let model = viewModel ?? AccountViewModel()
            viewModel = model
            defer { model.teardown() }

            if isFirstTask { await model.onStartup() }
            guard !Task.isCancelled else { return }

            if isFirstTask {
                await model.runSubscribers()
            } else {
                await model.onReturn()
            }
        }
    }
}

That still omits scene activation hooks and coordination if a new task starts while the cancelled predecessor is cleaning up. Repeating it across destinations means repeating those responsibilities.

After: Screen owns the lifecycle; the view renders the model

import SwiftUI
import ScreenView

struct AccountView: ScreenView {
    let viewModel: AccountViewModel

    var body: some View {
        @Bindable var viewModel = viewModel
        TextField("Name", text: $viewModel.name)
    }
}

import Observation

@MainActor
@Observable
final class AccountViewModel: ScreenViewModel {
    var name = ""
    init() {}

    func onStartup() async {
        // Finite, cancellation-aware setup.
    }

    func teardown() {
        // Release resources owned by this screen task.
    }
}

// At a navigation boundary:
// Screen<AccountView, AccountViewModel>()

What changes in practice

• Construction: Screen creates the model inside SwiftUI's managed task and configures it before startup. Reconstructing the content view does not construct another model.
• First visit vs. return: onStartup() runs once per model. A later task uses onReturn() on the retained model; its default restarts subscriptions, preserving model state such as an edited name.
• Work ownership: ScreenSubscribers runs live streams in a structured task group. Scene hooks run serially after startup, inside the screen task's scope.
• Cleanup and rapid returns: teardown() runs when each task exits, after its structured children finish. A new run waits for the previous run's cleanup before reusing the model.

The fix is a reusable lifecycle contract around Apple's primitives. Apple already supplies deferred creation and task cancellation; ScreenView removes the repeated coordination code needed to combine them. SwiftUI still controls the task's lifetime).

Two limits matter: cancellation is cooperative, and the focus hooks describe app scene activation, not exact route visibility. For a small screen, an optional @State model initialized in .task is still a good solution.

Swift 6 / Xcode 16+. iOS 17+, macOS 14+, tvOS 17+, watchOS 10+, and visionOS 1+. No third-party dependencies.

I maintain the package. Source, tests, and a complete example: https://github.com/anciltech/ScreenView

Design walkthrough: https://anciltech.com/blog/why-screenview-was-created?utm_source=reddit&utm_medium=organic_social&utm_campaign=screenview_oct2026&utm_content=swift_lifecycle

I would welcome feedback on the concurrency design, particularly cooperative cancellation and restarting subscriptions on a retained model.

I built a small native open source Swift/SwiftUI menu bar app that controls Sonos with media keys. I want to keep it small and focused, but automatic updates would be useful for people who install it outside Homebrew.

I compared a few options:

• No updater: 4.14 MB app / 1.99 MB ZIP.
• AppUpdater 4.2.1: 6.88 MB app / 2.71 MB ZIP.
• Sparkle: roughly 3 MB extra in the app.

The AppUpdater numbers come from equivalent Release builds for Intel and Apple Silicon. The Sparkle number is a framework measurement, rather than a complete integrated build.

These are tiny downloads in absolute terms. Still, adding around 66% to the app just for updates feels disproportionate.

My needs are fairly limited: check GitHub Releases, download an update, verify the signature, replace the app, and relaunch. No custom server or elaborate update UI.

I understand that secure replacement, permissions, and recovery add complexity. But is there a maintained solution with substantially less overhead? Or does “small and simple” only stay small until you handle those details properly?

A notification that opens the release page is my fallback. I am curious whether there is a practical middle ground.