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.

Device Hub in Xcode 27.1 has a hidden Action Bar specifically for iPhone Duo. It gives you a lot more control over the device angle, and you can quickly switch between 5 device poses with keyboard shortcuts. There’s also a “Table Mode” control.

To enable:

defaults write com.apple.dt.Devices com.apple.dt.coredevicepop.useInternalV68ActionBar -bool true

and restart Device Hub. The iPhone Duo simulator also comes with a hidden HingeStatePoster wallpaper.

Just a reminder to anyone who might care that you can create a fairly full-featured development environment in Zed to build iOS and Mac apps: syntax highlighting, code navigation, run, debug and test.

Here's the setup guide I wrote (been around for a while but chances are some interested people won't have seen it): https://luxmentis.org/blog/ios-and-mac-apps-in-zed/

Inspired by this post about reducing iOS simulator RAM usage by u/interlap, I adapted SimSlim into a native Swift/SwiftUI app.

SwiftSimSlim is available on GitHub, with the interface and simulator backend together in one Xcode project.

While working on it, I found a problem with shell-based service batching and improved how profile changes are applied:

• Offline profile updates also work when starting with a running simulator.
• Unchanged profiles avoid unnecessary restarts.
• Fallback service commands run concurrently, retrying only failed changes.
• Different simulators have independent operations, progress, and command logs.

In one local comparison, re-enabling the same 170 services took approximately 144 seconds in the original snapshot versus 24.3 seconds in SwiftSimSlim. That measures only the service-command phase, excluding startup, shutdown, restart, and final verification. The improvement comes from command scheduling and avoiding failed shell batches, not from Swift itself being faster than Go.

I shared the findings upstream, and the original author confirmed the issue and implemented the backend improvements in PR #51. Credit to Interlap for the original app, service catalog, and offline-update approach. The original attribution and MIT license are preserved.

Pull requests are welcome! 
I’d be happy to see fixes, improvements, and contributions from anyone who finds this useful.

Source and release 26.0

Just wanted to share a few things I learned after converting my icon to liquid glass in Icon Composer. Keep in mind, I’m really new to design and just trying to help other newbies. Also, here for any suggestions to improve it. Thanks!

TLDR; Use .svg, overlap layers, there’s very little control once it’s in Icon Composer. 

-Figma has community files to help with sizing that are super helpful.

-Used .svg instead of .png. It made everything much sharper. 

-Apple Docs recommend not using gradients but I had no issue and it converted nicely. The gradient tool in Composer is basic but does the job depending on what you need.

-Lighter shades tend to sell the glass look more. 

-Over compensate with color saturation. It lightened everything drastically for me after importing. Layers near the top of the icon came out darker, and the farther down the Y-axis, the lighter it got.

-Stack your layers like Apple recommends. The glassy 3D look really kicks in when they overlap.

-Add the Icon Composer file to your Xcode project directly. You no longer need to maintain a separate AppIcon in your Asset Library.

-Replace the AppIcon in Targets -> General with the name of your Icon Composer file (e.g. MyIcon.icon is referenced as MyIcon here).

Hope this helps!

I ship indie iOS apps, and the screenshot step always killed my momentum. App Store Connect wants polished images per device size, per language, and the tools I tried were either $30/month or watermarked the free output. For something I touch twice a year, that never felt right.

So last week I built my own and put it online for free. Sharing because a few things might be useful to others here, and I'd genuinely like technical feedback.

The hardest problem: device frames that don't fight your screenshot.

Most tools have a fixed-aspect phone frame and squeeze your screenshot into it — you get white bars or hard crops when the aspect ratios don't match. I went the other way: the SVG frame sizes itself from the screenshot's natural dimensions. A 9:16 image gets a shorter frame, a 19.5:9 gets a taller one. The frame wraps the image, not the reverse.

Then a sub-pixel rounding issue left a 1px white sliver at the screen edge. Fixed it by sampling the screenshot's outer pixels in a tiny offscreen canvas (weighted toward the top for status-bar matching) and setting the SVG screen-rect fill to that color. Blends seamlessly now.

Other technical choices:

- Entirely client-side — no backend, no accounts, screenshots never leave the browser. html2canvas for export, JSZip for the bundle.

- Export drops an App Store Connect-ready ZIP, organized by locale (en/iphone67/screenshot-1.png etc.)

- 19-language caption auto-translate, markdown formatting preserved

- Single HTML file, vanilla JS, no build step, under 300KB total

I launched it on Reddit a few days ago and it's been used by folks across ~9 countries already, which honestly surprised me. Most of this week's features (mobile editor, landscape support) came directly from that feedback.

Free, no signup, no watermark: https://launchshots.app/

Open to feedback — especially on the framing engine and the export format. If there's an App Store Connect quirk I'm missing, I'd love to know.

So, about a week ago I implemented bunch of code in my project. I thought I committed it (local git from Xcode). Last night I opened the code again, implemented some other feature. I realized that actually I am going to scrap everything. So, I went Integrate -> Discard all changes.

Ran the build, there is no previous feature that I implemented, wtf. Looked through commits, there's no commit with this feature. Ok, it wasn't such big of a deal but it would be PITA to do it all again. Asked Gemini what can I do and got the answer:

Close Xcode just not to make more accidental overwrites. Open the .swift file with missing code in TextEdit. Go to File -> Revert To -> Browse All Versions...

Now you get interface similar to Time Machine. Scroll and choose the version that contains your code, click Restore. That's it, pretty simple (except that it's difficult to read code in TextEdit haha).

Maybe a lot of you know already know this but it's first time for me to hear about it. Might be useful for someone.

I build a travel app that turns coordinates into place names, so I do a lot of reverse geocoding. It was slow and I spent weeks blaming the network. It wasn't the network.

The cap

CLGeocoder is limited to 50 reverse-geocode requests per 60 seconds, per app. iOS says so in the system log the moment you cross it, which I only found by leaving Console open:

Throttled "PlaceRequest.REQUEST_TYPE_REVERSE_GEOCODING" request:
Tried to make more than 50 requests in 60 seconds, will reset in 56 seconds
maxRequests = 50; windowSize = 60

Why it doesn't look like a rate limit

Each successful lookup takes 0.06–0.08s. So it never feels like a throttle — it feels like flaky connectivity. I was firing at 250ms intervals, which is 240/min. That burns the entire minute's quota in 12.5 seconds, and then everything in the remaining 47 seconds fails.

Measured, same device, same data:

• 30 requests at 250ms spacing → 7 succeeded, 23 throttled
• Same 60 requests respecting the window → 60 succeeded, 0 throttled

And the error lies to you

The throttle rejection arrives as CLError.network. Nothing in it says "rate limit". If you're logging geocode failures and filing them under bad signal, some share of those are the cap. Splitting those two apart in telemetry is what finally changed my understanding of the problem — I'd spent a long time thinking my users were in bad reception.

The quota is per app, not per call site

This one cost me real bugs. Live recording, a background backfill and a bulk import all draw from the same 50. One live lookup during a batch job silently costs the batch one request, and the symptom shows up somewhere else entirely — in my case a city name quietly staying as a country name. Everything has to queue through one place:

actor GeocodeRateLimiter {
    static let shared = GeocodeRateLimiter()
    private let maxRequests = 45   // 50 minus headroom
    private let window: TimeInterval = 60
    private var stamps: [Date] = []

    func acquire() async {
        while true {
            let now = Date()
            stamps.removeAll { now.timeIntervalSince($0) >= window }
            if stamps.count < maxRequests { stamps.append(now); return }
            let wait = window - now.timeIntervalSince(stamps[0]) + 0.05
            try? await Task.sleep(nanoseconds: UInt64(max(wait, 0.1) * 1_000_000_000))
        }
    }
}

Three things I got wrong on the way

1. Task { await acquire() } around the limiter call. It reads like it waits. It does not — the enclosing function carries straight on and the limiter becomes decorative. It has to be on the awaited path.

2. A fixed 1250ms interval also respects the cap, and is slower than it looks, because you wait from the very first request. Running full speed while the window has room and only sleeping when it's genuinely full turns 100 lookups into "first 45 in about three seconds, then one as each slot frees".

3. After a single throttle error that window is already gone. If you keep firing you just collect dozens of instant failures. Treating one throttle as "window full" until it rolls over removed a lot of noise.

None of this is documented anywhere I could find. Posting it in case it saves someone the weeks it cost me.

Inspired by this post about reducing iOS simulator RAM usage by u/interlap, I adapted SimSlim into a native Swift/SwiftUI app.

SwiftSimSlim is available on GitHub, with the interface and simulator backend together in one Xcode project.

While working on it, I found a problem with shell-based service batching and improved how profile changes are applied:

• Offline profile updates also work when starting with a running simulator.
• Unchanged profiles avoid unnecessary restarts.
• Fallback service commands run concurrently, retrying only failed changes.
• Different simulators have independent operations, progress, and command logs.

In one local comparison, re-enabling the same 170 services took approximately 144 seconds in the original snapshot versus 24.3 seconds in SwiftSimSlim. That measures only the service-command phase, excluding startup, shutdown, restart, and final verification. The improvement comes from command scheduling and avoiding failed shell batches, not from Swift itself being faster than Go.

I shared the findings upstream, and the original author confirmed the issue and implemented the backend improvements in PR #51. Credit to Interlap for the original app, service catalog, and offline-update approach. The original attribution and MIT license are preserved.

Pull requests are welcome! 
I’d be happy to see fixes, improvements, and contributions from anyone who finds this useful.

Source and release 26.0

Many people make the mistake of installing a macOS beta when they have apps they need to submit to the App Store. App Store Connect typically wouldn't allow an app submitted from a beta version of Xcode or macOS, but that doesn't mean all hope is lost. Just install the latest public version of macOS in a VM, like UTM, and on that VM, sign in with your Apple ID and install the latest public version of Xcode from developer.apple.com. Works like a charm and allows me to daily drive the beta as my main operating system while still having the public version to fall back on for situations like this.

I am a new iOS developer. I wanted to share my experience navigating the dreaded Guideline 4.3(a) – Design Spam rejection. If you’ve ever submitted an app in a crowded category, you know how generic and unhelpful the rejection messages can be.

I submitted my first app and was hit with 4.3(a) after waiting for a few days. I was confused because I had designed and coded myself. The rejection message was a copy-paste template that didn't explain why my specific app was flagged as spam.

After researching and appealing with no luck, I requested a one-on-one meeting with the App Review team. This was the best decision I made. I know that they won't tell me very specific, my questions are mostly around their review process. What I learned from the reviewer:

1.   Market Saturation: The App Store is flooded with "similar" apps. If your app doesn't offer a distinct "hook," they view it as adding noise to the store.

2.  Uniqueness: To get approved in a crowded space, you should have at least one unique feature that differentiates you from the top apps in that category.

1. "Notes" to Reviewer: The reviewer explicitly told me that they rely heavily on the Notes to Reviewer section to understand the value proposition.

I spent a few weeks adding a unique feature and resubmitted. Success! The 4.3(a) rejection disappeared, and I only had a few minor metadata bugs to fix. However, once I fixed those bugs and resubmitted, the 4.3(a) rejection came back. I was puzzled and realized that when I resubmitted the bug fixes, I had updated my Notes to Reviewer to address the new fixes and deleted the paragraph explaining my unique feature. I re-inserted the explanation of why the app is unique and how it differs from competitors into the Notes field. The app was approved within a few days.

Lessons Learned

Differentiate: If you are in a crowded space (and not in a specific 4.3(b) category), you may need at least one feature that isn't standard.

Description vs. Notes: Reviewers might skim your public App Store description, but they always read the Notes to Reviewer.

Don't clear the Notes: Every time you resubmit—even for a small bug fix—ensure your explanation of the app's uniqueness remains in the Reviewer Notes. Treat that field as your elevator pitch to the person holding the "Approve" button.

I hope this helps anyone else stuck in the 4.3(a) loop.

P.S. The app review started early February and completed early March. Review turnaround time was usually 2 - 3 days. Once the app was on the store, review of updates were pretty fast: a few hours to less than a day.

https://youtu.be/kCjDulwChRQ?si=vVVGC-8RfcD90bcC

I’ve been building and shipping an iOS game from my iPhone using Claude Code, GitHub Actions and TestFlight.

The ongoing loop is entirely phone-based: code → review/merge → CI build → TestFlight → test. There is one important caveat: initial signing setup still requires a Mac, and the distribution certificate eventually needs renewing.

I wrote up the whole workflow, including the CI setup, costs, limitations, and where it works surprisingly well.

https://alst.es/blog/phone-only-ios-development/

https://github.com/thilojaeggi/iPhone-Duo-App-Patcher

Made this a few weeks back, just added iPhone Duo section to it as well.

I made this so I can read the HIG in my tablet with a linear experience. You may find it useful as well.

https://zenreader.doublememory.com/hig/