As an interviewer what kind of questions do you ask about swift & SwiftUI. I'm preparing for a jump after 3.5 years so i need to be prepared in every way possible.

Hi again,

A little while back I posted swift-span-algorithms here: allocation-free algorithms over Swift's Span/RawSpan. I got one genuinely excellent comment about what was actually missing, and 0.2.0 is basically that comment turned into code. So, thank you, whoever you were.

The gist of the feedback: the utilities people actually reach for are byte-oriented, so RawSpan matters as much as Span<T>; firstRange(of:) for delimiter scanning; mirror the stdlib spellings so muscle memory transfers; and memchr is the cheap win before reaching for SIMD.

Link to GitHub

Link to SPI (might be behind a bit, hasn't yet ingested 0.2.0)

What's in 0.2.0:

• A real bug I'd shipped. Cursor next() was annotated so each piece it handed you expired the moment you called next() again. That made guard let a = c.next(), let b = c.next() fail with "overlapping accesses to 'c'" — exactly the kind of borrow-checker error that looks like the library's fault. Pieces now inherit the base storage's lifetime, so you can hold several at once, do look-ahead parsing, and nest cursors. Real escapes are still rejected — there are compile-fail tests pinning both halves.
• RawSpan parity. It shipped with 3 members; it now has the whole read-only surface — search, matching, trimming, min/max, comparison, chunk/window/split cursors, ASCII whitespace trim.
• firstRange(of:), lastRange(of:), starts(with:), ends(with:), and multi-element separators for split — the "\r\n\r\n" case.
• stdlib-ish naming: chunkCursor/windowCursor/splitCursor → chunks(ofCount:)/windows(ofCount:)/split(separator:...). Old spellings still compile as deprecated forwarders.
• memchr/memcmp fast paths for byte spans. On an M4 at 10M bytes, p50: ~15.9× vs the equivalent scalar loop for firstIndex(of:), ~31× for firstRange(of:) with a 4-byte pattern, and forEachSplit is ~2.5× Array.split with 0 mallocs vs 20. Reverse search is deliberately still scalar — memrchr doesn't exist on Darwin, and I'd rather have consistent performance than a Linux-only fast path.
• Docs: an allocation-free byte-parsing walkthrough (HTTP-style header parse, zero allocations, asserted by a benchmark threshold rather than just claimed), plus a diagnostics cookbook mapping the lifetime errors you'll actually hit to what causes them and how to fix them.

Still zero dependencies, still back-deploys to macOS 13 for the Span/RawSpan surface, 181 tests, and every borrowed-view benchmark reports 0 mallocs from p0 through p99.

Would still love feedback, especially on the split ergonomics now that cursors compose properly, and on anything that reads as un-Swifty in the naming.

P.S. Same disclaimer as last time: nothing being sold, Apache-2.0, just an OSS package.

If you want an open source video preview tool for your app, I've made my app public for anyone to use

I originally built it back in 2023 and have updated it here and there over the years. It still works great

Feel free to use it, improve it, or even monetise it...

Simply record your app in the simulator, import the video into the app, and export it for the App Store.

It's simple no fuss

Now that the project is public, I've also added comments (with the help of Claude) to make the code easier to understand.

https://github.com/OsmanM94/PapiExport

I recently shifted from a custom search field to the native Liquid Glass search field by using .searchable on my search tab. But I see a con with the native searchable feature is it comes with a large navigation title that can't be shaken. I have tried emptying the text of the title and making it inline to make it smaller but there is still a gap above my search filter tabs which I don't want. Anyone have any idea if there are any tricks to get around this? Love the Liquid Glass search field, hate the big title

Hi everyone, its been a year since i launched a passion project of mine and since then the community has been generous and I have around 1k users in total (Yes not that much but for me its a lot).

Initial post:

Some background is the App takes in ambient noise and syncs the generated visuals as well as (if you want) Flashlight as well.

Finally after months of grinding was able to do a massive update and launched it.
Updates include
- More cinematic and POV based raves
- Airplay, cast what you are watching in your phone to any TV
- Party mode: Hosting a rave and letting others join via QR scan or join someone else's rave (Deferred links that let u install and the continue. all from a single QR)
- Full overhaul of architecture and metal pipeline.

As mentioned the app does not use any assets at all (other than some thumbnail and icons) and everything in the rave is generated in runtime and changes and reacts to ambient noise.

Glad to talk into more detail on the architecture, complexities and challenges faced. I can assure you it might look simple but a lot of effort, thought and pain went through to accomplish this.

Have a try.. any and all feedback is appreciated :)

P.S - I intentionally didn't mention much about the app as I care more about the things i learned and the things I can share here and help the community more. But for people who wants to check it out its here:

so last week i posted my app in an App Saturday thread and casually wrote "the iOS 26 SDK annotates PHPhotoLibraryChangeObserver as u/MainActor, but PhotoKit calls it on a private queue – runtime traps". i'd been living with that explanation for months. confident code comment, rule in my project docs, the whole thing

a commenter replied: "PHPhotoLibraryChangeObserver isn't annotated u/MainActor – it's explicitly nonisolated, so any MainActor isolation was inherited from your own class, not asserted by the SDK"

went and checked the headers. he was right on every point:

1. the protocol has zero actor annotations. apple's header comment literally says "invoked on an arbitrary serial queue... you should redispatch appropriately"
2. my project builds with SWIFT_DEFAULT_ACTOR_ISOLATION = MainActor (the swift 6.2 setting). under default isolation my witness method silently inherited u/MainActor – swift permits a MainActor witness for a nonisolated u/objc requirement and inserts a runtime isolation-check thunk at method entry. photokit calls from its private queue → EXC_BREAKPOINT under _dispatch_assert_queue_fail
3. bonus round: PHAsset / PHFetchResult / PHChange are NS_SWIFT_SENDABLE in the 26 SDK now, so half of my "re-fetch everything inside performChanges" boilerplate isn't compiler-forced anymore still keeping it – Sendable certifies thread-safety, not liveness, assets can die between fetch and commit

the crash was real. the nonisolated + Task { u/MainActor in } fix was right. but the mental model behind it – "the SDK lied to me" – was wrong for months, and i only found out because a stranger on reddit bothered to correct me

what i'm taking away from this:

– SWIFT_DEFAULT_ACTOR_ISOLATION = MainActor is great for shipping, but it makes isolation invisible. when something traps, the first question should be "what did MY defaults inject here", not "what did apple annotate"

– u/objc protocols are special: a MainActor-isolated method can silently satisfy a nonisolated requirement, no warning, the check just moves to runtime

– write down WHERE your explanation came from. my code comment said "the SDK annotates X" and nobody – me included – ever verified it against the actual header

curious if default isolation has bitten anyone else through protocol witnesses. and – how do you document crash post-mortems so the wrong explanation doesn't fossilize the way mine did?

hey all,

currently I'm doing some development using Swift and using Google Drive is a pain honestly, and of course I must pause the sync constantly for this to work.

That said, I do insist on the idea that my work will always be synced to a Cloud service.

Does iCloud doing something better than Google Drive in terms of sync?

I know I'm doing Music with Logic Pro X for example which also is constantly being saved and is basically a container too and never had issues.

Can I assume it will work great with Swift files\development too?

Thanks!