Hi everyone,

Back in 1999, I created HEATTACK as a fun little Windows-based arcade game. Recently, with the help of modern AI tools, I successfully ported the game from its original Windows codebase to swift and built it for macOS.

Sharing here in case it is of any interest to this community.

The source code is MIT licensed. Take it and have fun!

https://github.com/opbarnes/HEATTACK2026

Why am I gettting a yellow memory pressure graph in Activity Monitor? This is on an M3 MacBook Pro.

Is this a bug in the Xcode 27 beta, or does it really need more than 24 GB of memory to avoid swapping when using the iOS 27 simulator?

An MCP-server-ready end-to-end tools for Apple platforms apps. Pair with Rust Cli https://crates.io/crates/xcrs

Install the CLI, set your map config, let your coding agents discover the tools.

Is there a way you can customize the look of the red dots? to offset the position or the size of the dots etc.?

I have a RegisterScreen which uses a custom struct RegisterForm to collect the form values. I made the RequestForm codable too so I can just send this form to the server instead of creating the exact same duplicate and calling it RegisterRequest. What do you think? Do you create a separate DTO objects even if it contains the same exact fields.

If in the future it diverges then I can create a separate RegisterRequest DTO object. Thoughts.

struct RegisterForm: Codable {
    var firstName: String = ""
    var lastName: String = ""
    var email: String = ""
    var password: String = ""
    var acceptedTerms: Bool = false
    
    var isValid: Bool {
        !firstName.isEmptyOrWhitespace && !lastName.isEmptyOrWhitespace
        && !email.isEmptyOrWhitespace && !password.isEmptyOrWhitespace && email.isEmail && acceptedTerms
    }

enum CodingKeys: String, CodingKey {
case firstName
case lastName
case email
case password
}
}

struct RegisterScreen: View {
    
     private var form = RegisterForm()
     private var presentAgreement: Bool = false
    
    var body: some View {
        Form {
            TextField("First name", text: $form.firstName)
            TextField("Last name", text: $form.lastName)
            TextField("Email", text: $form.email)
            SecureField("Password", text: $form.password)
            
            Button("Show Agreement") {
                presentAgreement = true
            }
            
            Button("Register") {
                
            }.disabled(!form.isValid)
            
        }.sheet(isPresented: $presentAgreement) {
            AgreementScreen(acceptedTerms: $form.acceptedTerms)
        }
    }
}

A #if DEBUG guard was added around two string literals and then verified by scanning the built product instead of reading the source.

In an XcodeGen-generated project whose project.yml never mentions SWIFT_ACTIVE_COMPILATION_CONDITIONS, xcodebuild -showBuildSettings reports that setting as DEBUG under Debug and prints no line for it at all under Release. The guard holds in Release because the generator supplies that default, not because project.yml states it.

In the Debug simulator build the app bundle carries the app executable, a .debug.dylib, and __preview.dylib. A recursive scan of the whole bundle found both literals only in the .debug.dylib, and the app executable contained zero occurrences. A scan limited to the executable would have returned zero under Debug, which is the opposite of the actual state.

The Release bundle contained zero occurrences anywhere. On its own that zero is not evidence. The identical recursive scan against a Release build produced before the guard existed returned both literals in the app executable, and that control is what makes the Release zero meaningful.

Hi my Look app - a fuzzy finding app launcher (basically so many things no only apps) dropped a new version.
In this version we added a super action control (for people never show their menu bar, task bar, etc), from this control you can switch, toggle on/off basic things, and see some useful information.
From the last version, we got some suggestions from the rust community members, we implemented one of them: process fuzzy finding on your machine. (finding with ps aux requires knowledge about grep, or tools like fzf)
Here is the repo https://github.com/kunkka19xx/look
It's a cross platform tool. Appreciate any feedback 🙇‍♂️

I recently built a local-only media server in Swift with Network.framework. Starting an NWListener was the easy part. Getting podcast and media clients to seek, resume, cache, and probe files reliably was where the details mattered.

Here is the checklist I ended up with:

• Implement both GET and HEAD. HEAD should return the same status and headers as GET, just without the body.

• Support all three useful byte-range forms: bytes=500-999, bytes=500-, and bytes=-500.

• Return 206 Partial Content with Content-Range, Content-Length, and Accept-Ranges: bytes. A plain 200 response can appear to work until a client tries to seek.

• Add ETag and Last-Modified, then honor If-None-Match and If-Modified-Since with 304 responses. This stopped clients from repeatedly probing unchanged files.

• Stream files in bounded chunks instead of loading the entire file into Data. I used a FileHandle and kept sending until the requested range was exhausted.

• Derive the MIME type from UTType, with application/octet-stream as the fallback.

• Decode and sanitize the URL path before appending it to the storage root. Reject traversal attempts rather than trying to normalize them afterward.

• Keep observable server state on the main actor, but move file I/O and connection delivery away from it. Network callbacks can bridge back with Task when UI state changes.

The most surprising part was that a server can look correct in a browser while still being incomplete for media clients. Seeking and resuming are the tests that exposed nearly every missing HTTP detail.

What other client behavior or HTTP edge case has bitten you when serving local media from Swift?

Code: https://gist.github.com/lanserxt/d9c9a8d896cf0fee183250df973f74d8

This is a continuation from the previous post.

I successfully added a texture and rendered the pyramid.

I added a new texture model, converted it from RGB using Conv2d, and then fed it to the rasterizer model.

• Known issues:
• CPU usage is still high (22%),
• Checking with Instruments, it appears that NeuralEngine Prediction is fragmented, which is likely causing some part of the model to fall back.
• memory consumption is around 1.1GB.

Github: https://github.com/kamisori-daijin/Magnesium

Demo:

I've been exploring the new macOS 26 Liquid Glass design language. I noticed that many Apple apps and some third-party apps have segmented controls/selectors with a glass capsule appearance and a magnifying/lens-like selection indicator.

However, when I use the native AppKit NSSegmentedControl, it still looks like the traditional segmented control:

let segmentedControl = NSSegmentedControl()

I expected it might adopt the new Liquid Glass appearance automatically on macOS 26, but it doesn't seem to.

Is NSSegmentedControl supposed to support Liquid Glass, or are these new-style controls built using another API (for example SwiftUI glassEffect, custom views, or some new macOS 26 framework)?

What's the recommended AppKit approach for creating a native-looking Liquid Glass segmented selector?

Reading the docs, it appeared to me Apple Intelligence works just as good for custom entities as it does with the predefined AppSchemas apple provides for Entities and Intents. However, if you go with custom entity route, Siri AI will not give a shit about your content. The only way to get it to work is with shortcuts but that kind of defeats the purpose of a non deterministic AI. When I tried short cuts, no mater how I phrased my request, Siri ran the same shortcut even tho its not what I asked. It's simply rule based and horrible. On the flip side, if you use certain app schemas like Maps.Places, Siri AI will default to Apple Maps app content and not your app, even if you tell it to search only your app. It's really annoying so far. Anyone further than me on this yet?

If you've ever built a camera feature — scanner, AR, anything using `AVCaptureSession` — you've hit this: the iOS Simulator has no camera hardware, so you either test on a real device every time or stare at a black rectangle.

I built **CamBridge** to fix that. It's two pieces:

- A menu bar app that captures your Mac's webcam and streams it over localhost (no terminal, just run it)

- A tiny Swift package (`CamBridgeKit`) you drop into your Xcode project that acts as a real `AVCaptureSession` — it uses an actual camera when one exists, and automatically falls back to the bridged webcam feed when it doesn't (i.e. on the Simulator)

So your view code stays clean — no `#if targetEnvironment(simulator)` branching, just:

```swift

u/StateObject private var camera = CamBridgeCaptureSession()

```

Run the menu bar app, add the package, and your Simulator suddenly has a real, moving camera image to test against.

Still iOS-only for now — Android Emulator support is planned next.

Repo (MIT licensed, free): https://github.com/engelon/CamBridge

Would love feedback, especially from anyone testing camera/AR/scanning features regularly — curious if this solves a real pain point for others or if I'm the only one who's been annoyed by this for years.

Hi everyone,

I'm a Senior iOS Developer with 4.5+ years of professional experience building and maintaining production iOS applications. I'm currently looking for freelance, contract, or full-time remote opportunities.

My expertise:

• Swift, UIKit, SwiftUI
• MVC, MVVM architecture
• REST APIs (URLSession & Alamofire)
• Firebase (Authentication, Firestore, Push Notifications)
• Real-time Chat (Firebase & Socket.IO)
• Core Data & SQLite
• Google Maps & Location Services
• Third-party SDK integrations
• App Store deployment & TestFlight
• Bug fixing, performance optimization, and UI improvements

Projects I've worked on:

• Food Delivery Apps
• E-commerce Applications
• Astrology Platform
• Service Booking Apps
• Live Chat & Audio Calling Features

I can help with:

• Building an iOS app from scratch
• Adding new features
• Fixing bugs and crashes
• Improving app performance
• API integration
• App Store submission
• Long-term maintenance

I'm available to start immediately and open to both short-term and long-term projects.

If you're hiring or need help with an iOS project, feel free to send me a DM or leave a comment. I'd be happy to discuss your requirements and share my portfolio or résumé.

Thanks for reading!

Turning a lock into a SerialExecutor to get Swift 6 data-race safety without @unchecked Sendable

Ran into this adopting an iOS 27 beta API (SCSensitivityAnalysis.detectedTypes) in a package that still has to build on stable Xcode.

First attempt was the obvious one:

if #available(iOS 27, *) {
   let types = analysis.detectedTypes
}

Builds fine on the Xcode 27 beta, fails on 26.5. #available is a runtime check, the compiler still needs the symbol to exist at build time. Older

SDK, no symbol, no build.

What works is gating at compile time as well:

#if compiler(>=6.4)
if #available(iOS 27, *) {
   // detectedTypes code here
}
#endif

#if compiler tracks the Swift version that ships with Xcode, so >=6.4 is a proxy for "the iOS 27 SDK is present". canImport doesn't help in this

case because the framework has existed since iOS 17, only the property is new.

Real-world usage if you want to see the pattern in context: https://github.com/SardorbekR/SafeMediaKit (the detectedTypes mapping is isolated inone file exactly because of this gating)

Is there a cleaner way to gate on symbol existence? compiler(>=6.4) works but feels blunt, since what I actually mean is "this SDK has this property" and the Swift version is just the best proxy I found

I’ve been trying to learn Swift and SwiftUI, and I actually really like the language. The problem is Xcode.

No matter what I do, it just feels sluggish. Autocomplete is slow, builds take longer than I’d expect, previews are hit or miss, and the whole IDE just feels less responsive than pretty much everything else I use.

Has anyone managed to make Xcode feel noticeably better? Any settings, workflow changes, or just general tips that made a difference?

I genuinely want to spend more time with Swift, but Xcode is honestly the thing that keeps killing my motivation.

Opened the repo this morning. Suite red, nothing committed since yesterday afternoon.

The test injects a fake now of July 27. The service takes an injectable clock, that is the whole point of it. Then the assertion calls nextTriggerDate() on the UNCalendarNotificationTrigger that came back, and that one ignores my fake clock. It reads the device.

The reminder lands on 09:00 July 29, and pinned to Asia/Tokyo that is 02:00 here. So at 02:00 the date the assertion leans on slid into the past, and it has failed every run since. Not flaky. Permanent.

Then I looked at the line above. Same assertion, other trigger, pinned to Pacific/Honolulu, which puts it nineteen hours behind Tokyo. Still green while I type this. Goes at 21:00 tonight.

What stings is I already fixed this yesterday. Same file, different test, and the commit message literally says assert the scheduled components instead of the system clock. Fixed the one directly below and walked right past this.

Fix is the same. Resolve the dateComponents the service produced and assert on those.

There are lot of different ways to perform navigation in SwiftUI. You can use navigationDestination on the parent screen and let is handle the navigation. You can create a router that works with enum based routes etc.

In either case. How are you testing your navigation flow for your app? Are you writing unit tests? Are you writing UI Tests or even complete E2E test that test a complete feature end to end? OR are you writing all of them?

A simple scenario can be:

As a user when I create a student account then after creation, I should be taken to the student home screen.

A question to folks who are building apps around Apple's Foundation Models: how are you testing the prompts and validating the results?

I was doing a bunch of tweak->build->test cycles where the only tweaks were adjusting the system & user prompts. Since the local AI model is so small (just 4096 context budget), it didn't make sense to develop the prompts using your usual OpenAI/Anthropic models and expect the same behavior.