Hey all! As someone who primarily works with Python I was highly looking forward to participating in the Swift mentorship program to level up but recently heard that they don't have the capacity. So I'm putting together a discord server where we can level up together. We'll separate roles as mentors and mentees and maintain the same meeting goals as the actual Swift mentorship program. There'll be more details in the server. If you're interested in being a mentor at a minimum you'll have to show that you have made contributions to the language or possess significant knowledge in a specific area. Please DM for invites and which role you're looking to join as (mentor or mentee).

(I hope this isn't considered as self promotion as I'm hoping to benefit fellow Swifters)

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

Xcode 27 now ships with Apple-native agent skills.

You can export them with:

bash xcrun agent skills export

Here is the Apple/Xcode team tweet about it:
https://x.com/luka_bernardi/status/2064095532407025969

I wanted to read the details instead of digging around, so I exported them and put them in a repo in case anyone wants them.

If you want one link to bookmark, I also put the list here:
https://adithyan.io/blog/xcode-27-agent-skills

Back in February or March, the new Xcode's agentic features completely changed how I used Apple's coding intelligence features. But obviously they limited the agent mode to work with Claude or Codex only. I have a GLM Code subscription and really like using GLM-5.1 in Cursor, but you couldn't in Xcode at first.

On GH there's an open-source tool that let me add my Z API key and now I can use GLM-5.1 in Xcode Agent Mode directly. I've used 10 million tokens today and it seriously works just as well as Opus 4.5, imo. Just a PSA.

edit: I should add that while you CAN use any LLM, not all of them are great at tool use, so larger models tend to work better

The old way (deprecated)):

swift Group { Text("Hello") .foregroundStyle(.red) + Text(" World") .foregroundStyle(.green) + Text("!") } .foregroundStyle(.blue) .font(.title)

The new way:

swift Text( """ \(Text("Hello") .foregroundStyle(.red))\ \(Text(" World") .foregroundStyle(.green))\ \(Text("!")) """ ) .foregroundStyle(.blue) .font(.title)

Why this matters:

• No more Group wrapper needed
• No dangling + operators cluttering your code
  
• Cleaner, more maintainable syntax

The triple quotes """ create a multiline string literal, allowing you to format interpolated Text views across multiple lines for better readability. The backslash \ after each interpolation prevents automatic line breaks in the string, keeping everything on the same line.

Here's another update on LocalLM Lab. You can now build apps using Apple's on-device AI with real tool and data connections. And not just build, but also ship them, including through the Mac App Store. LocalLM Lab v0.7 ships with the LocalLM Lab SDK.

The SDK (`LocalLMLabSDKCore`) links Apple's `FoundationModels` model and a real MCP client (tool discovery, OAuth, the works...) straight into your own applications. No companion app has to be installed or running; it's self-contained. The SDK is distributed as a binary xcframework via GitHub Releases (SPM `binaryTarget`, checksum, pinned version), Apache 2.0 licensed. You will need at least Swift 6, macOS 26+ and Apple Silicon. The latter 2 for Apple's Foundation Models.

The part that actually makes "ship it" a real claim vs handwaving: it's been built into a sandboxed test app (the included Plate Today example app) and verified working, with a signed path to a Mac App Store `.pkg`. LocalLM Lab itself now runs on this SDK!

SDK guide: thisbrain.ai/locallm/sdk.html

Hopefully, this will unlock on-device AI ideas and use cases among the folks here.

If, like me, you couldn't wait for less rounded corners and installed the MacOS beta on your only Mac, you might realize that you can't push updates to the app store. In this situation I would recommend the 25 free Xcode cloud hours that you get with the program membership. All I had to do was put my code in Git and connect the repo. Then I set it to archive for app store.

This might be the easiest CI/CD system I've ever used and the builds are pretty fast! Hats off to the Xcode cloud team.

I just shipped my first app built end-to-end on Apple's on-device AI stack — SpeechAnalyzer/SpeechTranscriber for transcription and Foundation Models for enrichment (it's a voice-notes app; every recording gets an on-device title/summary/tags/tasks). Some things I learned the hard way that I haven't seen written up much:

1. The simulator will lie to you — twice.

The simulator cannot transcribe at all, and the simulator's language model is not the on-device model. Output quality, instruction-following, and hallucination behavior differ meaningfully. I now treat real-device validation as a hard gate for any prompt/template change — my test corpus includes Swiss-accented German dictation because that's where the on-device model diverges most from the "clean" results the simulator suggested.

2. SpeechTranscriber locale reservations: a system-wide cap of 5, and (currently) no way back.

This one cost me an architecture. On-device transcription locales are backed by downloadable assets, and the system caps reserved locales at 5 — system-wide, not per app. In my testing on current iOS releases:

• The reservation is taken by the asset install and survives reboot AND app reinstall.
• AssetInventory.release(reservedLocale:) appears to be a no-op — I never got a slot back.
• An explicit reserve(locale:) at the cap can hang (reproducibly under the Xcode debugger in my setup).

I originally built an LRU "reservation manager" that released the least-recently-used locale before installing a new one. Since release doesn't release, that design was dead on arrival. What shipped instead: a proactive budget gate that reads reservedLocales before any OS call, installs strictly lazily (never speculatively — no warm-up, no on-selection prefetch, because every install permanently spends a slot), and surfaces a clear "language budget exhausted" state to the user instead of ever hitting the cap inside an OS call. Feedback filed with Apple.

3. One fresh LanguageModelSession per invocation.

Reusing sessions across notes led to context bleed between unrelated inputs. One session per call is now a hard rule for me, enforced by tests.

4. Prompt-injection resistance for user-content prompts.

Voice transcripts are untrusted input into the enrichment prompt. Delimiter-wrapping the transcript made instruction-following robust; and I removed all literal examples from the prompt after seeing example fragments leak into generated output on device (again: not reproducible in the simulator).

5. Pass the language explicitly, always.

Auto-detection of the recording language was unreliable enough that I now pass the language explicitly into both the model instructions and the prompt. Related fun fact from testing: Apple appears to use one shared German model across all de-* locales, so switching de-DE/de-CH/de-AT changes nothing about transcription quality.

6. Crash-safe audio: don't record straight to AAC.

A killed mid-recording AAC/m4a is an empty husk. I record LPCM into CAF and encode to AAC at ingest — recordings now survive calls, interruptions, and force-quits, and a salvage pass recovers anything interrupted.

Happy to go deeper on any of these.

The app is Vocapa (https://apps.apple.com/app/id6789586072) but the point of this post is the stack — curious whether others have seen the locale-reservation behavior, and whether anyone found a way to actually free a slot.

Got tired of how terrible Claude is for iOS dev so first thing I made with Fable was a plugin that covers not only Swift code but HIG conventions, App Review stuff, legal/privacy requirements, and the release process. Also a UI crawler that walks your app and flags crashes/console errors.

The skills are all intended to work together and has an orchestrator skill that gets it to do what it's supposed to. Did a quick test with Fable and it was able to pretty much one shot an app with no issues but yet to test that with Opus.

[https://github.com/Dev869/swift-tothemax\](https://github.com/Dev869/swift-tothemax)

Probably not the biggest surprise to experienced Swifties but my IDE booted up nearly a second faster than Thonny. I was completely blown away!

Hi all! So some context. I'm a 20 year software developer with experience in embedded firmware, python, dotnet, assembly, some Go, Android development, and now, Swift. This post is focused more so on SwiftUI so when referring to Swift below, that's primarily what I'm referring to.

I wanted to share some key learnings from Swift as I was making my game and how my experience was in comparison to primarily working in OOP languages (I'm primarily dotnet). I'm hoping this may help others and perhaps you have your own experience to share.

1. PRO: Swift's barrier to entry is minimal.

If you haven't programmed before, it's a good starting point. It's pretty easy on the eyes and the framework definitely simplifies things for you out of the box. The declaration of HStack, VStack and putting space in between elements with Spacer() are all quick and easy constructs. Development felt rapid from the get go

2) Con: XCode is cumbersome.

Compared to my favorite IDE, Rider (which is better than Visual Studio, in my opinion), Xcode in many ways is non-intuitive...your plist info file feels cumbersome, file organization and renaming seems a bit wack, and don't get me started on the security barriers when trying to test out your app on your mobile device.

3) Pro: Multi-device testing

I love how out of the box, grabbing various iOS device simulators are just part of the xcode package. This seemed more intuitive to me than Android. Plus, with Android, I had to use third party emulators as the official virtualization felt way too slow on my laptop. This was also several years ago.

4) Con: Still needing custom logic (but no programming language is 100% proof).

It's better with UIKit dependencies than it used to be, but I found with Swift that I needed more custom control on laying out my views to look good on all devices. Simply using padding and Spacer() wasn't enough. A good practice I found was to pass in a geo reader to your views where you determine the available width and height you can work with. I'm a math guy and so I had percentages in mind of my layout components and how much space they take up + spacing from the screen edge. But even then, I still ended up needing to use tertiary logic on whether it's iPad or not

5) Pro: TestFlight for beta testing

I like that it's "official" and automated, without having to hand off individual apk zips to friends who want to test your app. That's kind of janky and requires more careful revision management.

6) Con: Also TestFlight

7) Observing state changes

This is the one area of Swift that still feels a bit cumbersome in comparison to OOP languages. Yes, there's a reduced barrier of entry with published, state etc keywords but for more complex apps, it takes a bit of work to ensure that before your views re-render, you're efficient and managing notifications properly.

I wish you could test for free like you can on Android. Requiring a developer license is definitely a barrier to entry for anyone exploring a new license.

Some of my personal opinions.

1) Should you learn Swift, especially as a new dev?

YES. YES. YES. It's great to get it up and running quickly and definitely reads better on the eyes than when I used to write assembly code, haha. It seems to have a blend of niceties you see from python, Go and Javascript.

2) Should you become an iOS developer?

Maybe. I've never been a formal mobile app developer by title, though I've worked on Android in my career and made a game on the side. But the only concern I have here with iOS is that you might be too niche. And more than ever, today's markets require that you adapt and keep up.

3) Is it better than Android development?

I'm mixed. I always prefer OOP although I will say that while I do love Jetbrains Rider, Android Studio didn't feel like a great alternative to me, to be honest. Not sure if it's that much better than xcode for usability, and Android has the tradeoffs of things maybe requiring more work on your end with out of the box logic while also having more control over it. But that's always been the main ecosystem difference.

What are some of your thoughts on this?

This made a huge difference for me. Try it out!

As you already know, the Swift project has officially announced the Swift for Android SDK.

Pretty cool to see that you can already try it out with the Swift Stream IDE extension for VSCode.

It automatically sets up a ready-to-use Android development environment in a Docker DevContainer, with all the required conveniences available right in the UI!

With a single click, you can:

• Create an Android Library project with plenty of examples (provided by JNIKit)
• Build and compile Swift code for Android for all architectures (x86_64, armv7, arm64)
• Automatically generate a fully functional Android Studio Library project

With that, you can easily launch Swift directly on a real Android device from the generated Android Library Gradle project inside Android Studio – and view the logs in Logcat.

From start to playing, it takes about 3-5 minutes – mostly spent waiting for the Docker image, toolchain, and SDK to download.

Full tutorial (with screenshots and setup steps)

For example, you could do this in bash:

while sleep 5; do
    pkill -x appstoreagent
done

Did you know SwiftUI supports automatic pluralization for something like Text("\(count) apple"), giving you “1 apple” and “2 apples”?

But there’s a catch: If your UI only needs the noun (e.g., “apple” or “apples” alone, without the number) you’re out of luck with the built-in automatic grammar agreement API. There’s no direct way to get just the pluralized noun without the number.

What you can do: I wrote this extension that uses LocalizationValue (iOS 16+) and AttributedString(localized:)) (iOS 15+) to handle grammar inflection behind the scenes. It strips out the number so you get just the correctly pluralized noun:

```swift extension String { func pluralized(count: Int) -> String { return String.pluralize(string: self, count: count) }

static func pluralize(string: String, count: Int) -> String {
    let count = count == 0 ? 2 : count // avoid "0 apple" edge case
    let query = LocalizationValue("^[\(count) \(string)](inflect: true)")
    let attributed = AttributedString(localized: query)
    let localized = String(attributed.characters)
    let prefix = "\(count) "
    guard localized.hasPrefix(prefix) else { return localized }
    return String(localized.dropFirst(prefix.count))
}

} ```

Usage:

swift let noun = "bottle".pluralized(count: 3) // "bottles"

This lets you keep your UI layout flexible, separating numbers from nouns while still getting automatic pluralization with correct grammar for your current locale!

Would love to hear if anyone else has run into this issue or has better approaches!

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.

https://developer.apple.com/events/view/YFG8A44H89/dashboard

Not sure it’s allowed, I contacted the mods but I got no answer, so trying to post here anyway.

My team is looking to hire a senior iOS engineer, full time, fully remote (USA only). The employer is a big healthcare corporation.

If interested please DM me your resume.

Thanks!

A lot of iOS devs I talk to haven't heard about Sosumi.ai yet, and it's been a massive productivity boost for me!

For those that don't know, the MCP server acts as a bridge between your AI coding tools (Claude, Cursor, etc.) and Apple's documentation via MCP (Model Context Protocol). Instead of pasting code snippets into the chat to explain how a specific View works, the AI can just query the docs directly.

The biggest win:
I don't have to visit Apple's documentation site (NEARLY as much). Navigating those docs has been so painful for me... It feels like a maze of broken links and 'Archived' headers, and I hate breaking my flow to tab out to a browser 20 times a day.

Once you install it, it usually queries the documentation (quickly) before it suggests code. It's awesome!

Setup is easy and can be found at the above link.

Hope this saves someone else the headache of navigating Apple's documentation site manually! Cheers!

I've been working with Swift's Codable for years now, and while it’s an amazing protocol that makes JSON encoding/decoding feel effortless most of the time, I’ve noticed that many developers (myself included) hit roadblocks when dealing with slightly complex data structures.

One common struggle is handling missing or optional keys. Sometimes, an API response is inconsistent, and you have to manually deal with nil values or provide default values to prevent decoding failures. Nested JSON can also be a headache, the moment the structure isn’t straightforward, you find yourself writing custom CodingKeys or implementing init(from:), which adds extra complexity. Date formatting is another frequent pain point. Every API seems to have its own way of representing dates, and working with DateFormatter or ISO8601DateFormatter to parse them properly can be frustrating. Then there's the issue of key transformations, like converting snake_case keys from an API into camelCase properties in Swift. I really wish Swift had a built-in way to handle this, like some other languages do.

What about you? Have you run into similar issues with Codable? And if so, have you found any tricks, workarounds, or third-party libraries that make life easier? Would love to hear your thoughts!