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.

Hello, everyone. Recently, I have been studying the problem of hook method hijacking for storekit App in-app in-app purchase. In storekit1.0, global functions such as hook payment can be hijacked directly. However, in the system after ios15.6, many apps switch the in-purchase payment module to 2.0, which leads to the previous function hijacking wireless, and the inability to obtain information at the first time of submitting the order. The payment system of 2.0 uses the closed anonymous function written by swift. The methods in each app are inconsistent, and it is necessary to manually search and hook features. Professors in the community, are there any relevant development examples of manually modifying the byte code hook and finding the exact location of the function? We can discuss it together.

Guys i have a question, i am building an AI Intent engine in native swift/kotlin with certain segments of the app or some mini-apps to be in React native, so that minor ota updates handle it rather than submitting the entire app for update. Does IOS allow OTA JS code? I am aware they allow for Wechat Mini apps but they are in Webview not RN

Hello all,

This past year has been rough. I’ve applied to 178 jobs and landed nine interview processes. Each process consisted of multiple rounds, typically between three and six interviews.

The encouraging part is that I consistently make it to the later stages, and often the final round. I feel confident in technical interviews. I enjoy solving programming problems, discussing architecture, and explaining the reasoning behind my decisions.

Where I struggle is behavioral interviews. I’m suck at these, and they’ve become the biggest obstacle keeping me from receiving offers.

I’m looking for advice on how to improve at behavioral interviews, particularly for mobile engineering roles.

I have about 1.5 years of professional mobile engineering experience. At my current company, our mobile team has gone from 12 engineers down to just three through layoffs and attrition. I’m the newest engineer on the team, and everyone else works in another state. Because of that, I often feel isolated, and I don’t feel like I’m getting the mentorship or professional growth I need. On top of that, the overall product quality isn’t where I’d like it to be, so I worry that I’m not developing as quickly as I could.

Has anyone been in a similar position or have advice for improving behavioral interviews? I’d really appreciate any guidance.

Edit: By “behavioral interview,” I’m referring to the non-technical interview rounds where you’re asked to talk about past work experiences, conflict resolution, failures, teamwork, leadership, etc.

Do you think I'm moving in the right direction?

struct StrictPlayground {

// @MainActor // uncomment it, it will get the same result.
  static func main() async throws {
    print("1,", Thread.isMainThread)
    try await run()
    print("3,", Thread.isMainThread)
  }
}

@concurrent
func run() async throws {
  print("2,", Thread.isMainThread)
}

It returned:

1, true
2, false
3, false

I am using:

Swift version 6.3.3 (swift-6.3.3-RELEASE)
Target: x86_64-unknown-linux-gnu

enabled NonisolatedNonsendingByDefault

This issue happens on all the non-Darwin OS. I am so disappointed by the language. This issue has existed for a long time. It is such a fundamental language feature. It affects all the code written by swift for non-Darwin OS. Meanwhile, The language has kept adding new feature. But it doesn't fix critical issue.

Slaptop listens to your Mac’s motion sensor and turns display taps into direct Mission Control actions. Slap the left side of your screen, you switch to the left. Slap the right side of your screen, you switch to the right. Slap the top and you launch Mission Control. Yes, really.

21 years ago, I built a utility called "Slaptop", which lets you use Apple's Mission Control and Spaces by literally slapping the side of your MacBook screen.

It lasted for 3 1/2 weeks before I realized how terrible of an idea it was. Back then, it used the MacBook's HDD Sudden Motion Sensor, designed to park the hard disk if you ever dropped your computer. End result, when users slapped their laptops it caused irrecoverable data corruption and data loss.

So, I deleted the app. A couple months later, it was cloned. And then it was cloned again.

I reached out to Amit Singh of AMSTracker and Erling Ellingsen of SmackBook so they'd understand the data corruption issue and convinced them too that it was too risky to stay online.

That brings us to today. In the modern Mac, there are no more HDDs that can be damaged through subtle percussive maintenance, and there is now a far more accurate sensor built into every Apple Silicon Mac.

Enjoy a free, open source (MIT) utility that brings a little more fun to your day.

Hey everyone,

Like most of you here, my daily workflow involves fighting my Mac's SSD. Every time I look at my disk space, Xcode has silently hoarded tens of gigabytes of hidden DerivedData, stale module caches, and device support symbols from iOS versions I haven't targeted in years.

Wiping these folders manually is a repetitive chore, and I've previously broken my active Swift Package Manager indexes by running overly aggressive rm -rf shell scripts—forcing me to waste bandwidth re-downloading dependencies on my next build.

I wanted a tool that was incredibly fast, visually intuitive, and above all, safe to run mid-workflow. So over the last few weeks, I built DevShed.

It's a lightweight, native macOS menu bar app (and a companion CLI tool for terminal power-users) written entirely in Swift and SwiftUI.

What makes it a bit different:

SPM Index Protection: It explicitly maps and excludes core Swift Package Manager registries so your offline compile times don't take a hit after a cleanup.

Execution Safe Mode: It checks for active compilation pipelines and open workspace files before letting you purge critical directories.

Ghost Cache Tracking: It targets heavy compiler caches left behind by projects you’ve deleted or moved long ago.

Multi-Platform Support: Beyond standard Apple developer folders, it includes optional quick-cleaners for Node Modules, Homebrew binaries, CocoaPods, and Flutter Pub caches.

100% Private: There are no ads, no premium lockouts, and absolutely zero telemetry or tracking. Everything runs completely local and sandboxed on your machine.

It's entirely free, and you're running low on space or just want to audit what Xcode is hoarding, give it a spin!

Landing Page: devshed.codearc.studio

GitHub Repository: github.com/codearc-studio/DevShed

I’d love to hear your feedback, feature requests, or thoughts on what package managers/caches I should add tracking for next!

This is just a quick demo post, I'll likely post some code to github over the weekendfor anyone interested. I have Embedded Swift running on a Teensy 4.0 now, and running some demo code on a SSD1351 over SPI. Not only that, the display is using DMA for SPI writes! (And writing in full 18bit color mode, tricky on these little guys).

I had this display running on linux with SwiftyGPIO in the past (and c++ on teensys too) and built these demos for it then. Same code runs the demos! (well, I upgraded both a little bit... but the same code runs on a Teensy that runs on a RaspberryPi). The Matrix Rain demo I initially translated from the python library luma.oled (link to its matrix example), this version i beefed the lines up a bit to look psuedo-glyphy. The Game of Life demo however is my own cursed set theory implementation of Game of Life in Swift. For any GoL fans, my Swift generation update function is literally this (plus some extras defining the operators and such 😄):

func Sʹ(_ S: 𝕊) -> 𝕊 {     
  N[S] | { c in ‖(N(c) ∩ S)‖ == 3 ∨ (‖(N(c) ∩ S)‖ == 2 ∧ c ∈ S) } 
}

Even better, back when I wrote the raspi/SwiftyGPIO variant, I came up with a sweet idea for dev iteration... SwiftUI Previews!! I'm basically building a HAL + Graphics abstraction layer that works across everything and lets you run the same drawing code on a mac looking at SwiftUI previews, or on a Raspi, or an embedded target. "It's protocols, all the way down"

Open Source code coming soon I promise! I just REALLY wanted to demo this!

A key functionality of my app requires that the motion sensors remain active while the app is backgrounded. However, (unsurprisingly) the app got rejected for utilizing a silent audio loop to achieve this. Are there any alternatives? Thanks.

Many SwiftData applications need to keep their local data synchronized with a backend server, but detecting inserts, updates, and deletes efficiently can be challenging. Starting with iOS 27, HistoryObserver provides a clean way to observe changes in the SwiftData store without scattering synchronization logic throughout your application.

In this article, you’ll build a one way synchronization pipeline using HistoryObserver. You’ll learn how to observe model changes, process persistent history, track the last processed transaction using history tokens, batch changes into network payloads, implement soft deletes, and synchronize your local SwiftData store with a custom backend. By the end of the article, you’ll have a practical foundation for building offline first applications that keep local and remote data in sync.

https://azamsharp.com/2026/07/16/syncing-swiftdata-with-a-custom-backend-using-historyobserver.html

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

Every iOS E2E testing approach seems to have the same core problem. XCUITest breaks on UI structure changes. Appium based tools inherit the view hierarchy dependency and degrade with each OS update. Tools marketed as AI assisted change the input method but not the execution model. At some point it feels like the options are maintain fragile scripts forever or accept that manual QA is permanent overhead.

The SE-0494 was the first evolution proposal I coauthored. This is now landed in the 6.4 toolchain and is available from the new Xcode 27 Beta.

The Evolution Proposal added a new set of “performance hook” APIs to the Swift Standard Library. The isTriviallyIdentical(to:) methods are alternatives to testing collections for value equality. The proposal itself presents some abstract and theoretical arguments for why the isTriviallyIdentical(to:) operation could save performance compared to a traditional == check for value equality. But one of the questions I get asked is how these changes could affect real-world performance. Where's the data? And that's fair. The evolution proposal does not directly present measurements or benchmarks.

The Trivially-Identical-Sample repo is a fork of the sample-food-truck repo from Apple. It's a SwiftUI project that displays many data model elements in a Table view component. With a little refactoring we can set up an experiment. Our view component needs to sort a list of data models: this is an O(n log n) operation. We could potentially display this view component many times even when our data models have not changed: we can trade memory for speed and memoize our sorted values. If the input to our sorted values has not changed… then the sorted values themselves have not changed.

But now we get to look at the memoization itself. How exactly do we determine “what changed”? Do we compare our inputs for value equality? That's an O(n) operation that might be performing more work than necessary. If all we care about is “something might have changed” we can try migrating to isTriviallyIdentical(to:) and return in constant time.

The repo fork shows how to set this experiment up with Xcode Instruments Signposts. We measure our test group and our control group for the aggregate time spent blocking our MainActor and we see about 13 percent faster performance from isTriviallyIdentical(to:).

But… there's more to the story. The repo also spends some time discussing under what situations a different experiment could show us that isTriviallyIdentical(to:) leads to slower performance. At the end of the day the isTriviallyIdentical(to:) methods are not always “fast buttons”. Sometimes they are… but sometimes they are not. Eventually it would be your responsibility to make that choice for yourself and your products.

Please let me know if you have any more questions about all this. Thanks!

I’m trying to sanity-check something before I file it as an Apple bug.

This minimal SwiftData example appears to lose precision when persisting a Decimal:

import Foundation
import SwiftData

@Model class Item {
    var value: Decimal

    init(_ value: Decimal) {
        self.value = value
    }
}

let original = Decimal(string: "123456789012345.6")!
let container = try ModelContainer(
    for: Item.self,
    configurations: .init(isStoredInMemoryOnly: true)
)

let context = ModelContext(container)
context.insert(Item(original))
try context.save()

let fetched = try ModelContext(container)
    .fetch(FetchDescriptor<Item>())
    .first!

print(original)
print(fetched.value)

I get:

123456789012345.6

123456789012346

This is one model, one Decimal property, no app code, no CloudKit. I’m using Decimal(string:) to avoid literal/Double conversion noise, and I’m fetching from a new ModelContext.

I also checked Decimal <-> NSDecimalNumber bridging separately, and that preserved the value. The loss seems to appear after persistence/fetch. A true Core Data in-memory store preserved the value in my control test, while SwiftData’s “in-memory” configuration seems to still go through a SQL-backed store.

Has anyone else hit this with SwiftData/Core Data Decimal attributes? Is there a documented limitation I’m missing, or is the practical answer to persist exact decimals as canonical strings / integer minor units instead of Decimal?

Hi! I, a 13 yrs old have been working on making my own OS based on the Linux Kernel and Swift. I have posted about this earlier in r/Swift. For the past 4-5 weeks i have been working on this project and I have finaly can say:

- It works
- Has a display Output!
- Has a functioning Runtime!
- Has a UI ( Basic ) : OpenSwiftUI
- Has complete BIOS and UEFI Support (QEMU).

UI [ Official User Interface for ARK-OS ]

Thinking about this is a bit hard! I am deciding between particles (smal particles) and pixels (like minecraft UI). SInce the boot animations is a rotating atom i think particles take the lead!

Ideas are completely Welocme!

Hosting

This repo is self hosted due to github file size limits and a strict repo limit of 2GB tops and Git LFS with 2 GB as well. Due to many pre-compiled artifacts like clang, llvm, and a full linux kernel + modules it shoots past this total 4GB limit! Putting it on Attached binarires might get too confusing so this is hosted on a free Oracle Git Server!

Repo link : https://ark-os.duckdns.org/Aarav90-cpu/ARK-OS
Website : https://aarav90-cpu.github.io/ARK-OS-Website/

Also btw, gemini did help me in this case ( No claude ) in writing the bootloader is assembly and in small tasks, mostly all the code is wrriten by me and AI generated code is re-written!

Unemployed title inflated senior with 4 yrs exp ( one of which is freelance) failed every single technical interview since last year any advice ? 🥹