iOS simulators start a lot of background daemons that you often don't need for development or CI. Siri, Spotlight, widgets, photo analysis, iCloud stuff, etc.

The good news is that Apple gives us a way to disable them.

For example:

xcrun simctl spawn <udid> launchctl disable system/com.apple.PosterBoard

Then reboot the simulator:

xcrun simctl shutdown <udid>
xcrun simctl boot <udid>

That disable is persisted in the simulator so the next time it boots, PosterBoard won't start.

Do this for enough unnecessary services and you can save a pretty decent amount of RAM.

The harder part is figuring out what is actually safe to disable, what breaks when you disable it, and then managing that across multiple simulators.

I ended up building SimSlim around this:

https://github.com/MobAI-App/simslim

It has a list of around 180 daemons that are safe to disable, grouped by feature, plus some convenient commands for slimming/restoring simulators and managing different profiles for local use or CI.

It's free and open source. Give it a try.

I just released v0.2.0 of enriched-markdown-ios - SwiftUI Markdown renderer powered by TextKit 2.

New in this release:
🔸 GFM Tables
🔹 Task lists
🔸 Superscript & subscript support

💎 Available via Swift Package Manager!

.package(
  url: "https://github.com/software-mansion-labs/enriched-markdown-ios.git", 
  from: "0.2.0"
)

Added a quick demo video in the comments so you can see it in action!

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

What features or syntax support would you like to see next? I'd love to hear your thoughts! If you find the library useful, a ⭐️ on GitHub is always appreciated.

Hey guys need advice

Starting my business finally and want to convert my developer account to my business

https://developer.apple.com/contact/request/migrate-individual-account

Is this the only thing I need to do ? What else ?

I have all my numbers and documents ready to go.

I ship a small object detector inside an iOS app and I export it two different ways depending on the model generation, so the Swift side has to cope with both. The approach that ended up working is to branch on the output tensor shape rather than on a flag I carry around:

• An end-to-end export gives me [1, 300, 6] — x1, y1, x2, y2, score, class — with decoding and NMS already inside the graph. Nothing to do in Swift but scale the boxes back through the letterbox.
• A raw export gives me [1, 84, N]: 4 box terms plus 80 class scores per anchor, transposed, which I still have to decode and run NMS on myself.

So the predictor reads prediction.shape, checks that the last dimension is at least 6 and the second-to-last is non-zero, and picks the decoder from that. It means adding a new model export never touches the call site, and a bad export fails visibly at the guard instead of quietly producing zero boxes.

Two things I would have liked to read before starting:

1. A silent failure mode is the normal failure mode here. An export that "succeeds" tells you nothing. The only test that means anything is printing the input and output shapes and comparing them to what your decoder expects. I lost real time to an export that ran fine and detected nothing, because the decoder was reading a layout the model no longer produced.
2. coremltools 8+ has no usable Windows path. I develop on Windows, so my entire export chain lives in a Colab notebook and the resulting .mlpackage gets committed and wired into the Xcode project from there. If your CI or your daily machine is not macOS or Linux, plan for that on day one rather than discovering it two weeks in.

On the app side the camera preview is a native platform view and the detection overlay is drawn on top by the UI layer, so no frame data is ever copied out of the capture pipeline.

Curious how others handle the versioning problem: do you keep the decoder generic like this, or pin one export format per app release and refuse anything else?

when you utilized external testers for test flight did you do a public link or did you do a private email list?

also how did you find testers?

I've been building React Native apps with Expo using Claude Code, and my biggest frustration is that Claude can't see what it's building on the native side, which means a lot of back-and-forth on layout and visual issues that a web-based workflow wouldn't have. I just can't seem to loop on the build and see the visuals as well as it can building a web app using the browser.

I recently learned about the Expo MCP server's local capabilities (screenshots, view geometry, tap automation) and Software Mansion's "Argent" as two options for giving the agent eyes on the running simulator, but I'm curious what the community is actually using in production workflows. Is anyone running a setup where Claude or another AI coding agent can self-validate UI changes against the live simulator, and if so, what's working? Also interested in non-RN solutions. If there's a better answer here by building fully native in Swift/Xcode, is this still a problem, or does the native toolchain solve it?

I had my app got rejected because I forgot to add my IAP to my app. The subscription group was added but not the lifetime purchase. Now I want to add that IAP to my review but I only get to option 'add for review' and it opens a new review but then I cant add my app to it. Everytime I update the app for review it sends it in without the IAP and gets rejected. Any help? I find this new update confusing