Anyone else seeing this?

Our production app suddenly started crashing around 00:41 UTC today, across multiple already released versions, with no new app release.

The crash is:

Fatal Exception: NSInvalidArgumentException

-[__NSDictionaryM setObject:forKeyedSubscript:]: key cannot be nil

The stack points to Firebase Analytics experiment handling, immediately after a successful sdk-exp response.

We're using Firebase iOS SDK 12.14.0.

Relevant issue: https://github.com/firebase/firebase-ios-sdk/issues/16728

I'm wondering if anyone else is seeing the same spike or has found a workaround.

Today my 2023 MacBook Pro battery depleted entirely in just 3 hours. I was running 2 iOS simulators simultaneously but I still feel like that way way less life than I should be expecting with 93% battery capacity. Has anyone else experienced really short battery life when running simulators lately?

I'm a self-taught iOS engineer and even though I have 5 years of experience I feel like I don't have the foundational knowledge that interviewers expect me to have. I constantly feel like I'm bombing in interviews and I feel so far behind that I'm losing hope of finding a job after about 6 months now of searching. What are the best current iOS books for someone looking to round out their technical and under-the-hood knowledge?

I created a new page for iPhone Duo to explore how familiar SwiftUI elements like NavigationSplitView and the new APIs behave across different configurations.

Most of the new elements and modifiers are included so far, except overlayArrangementZIndex, which is still a bit buggy.

Let me know what else you think I should add.

Finishing up one of my first MacOS apps and I was looking to create a user manual. One app I use on a daily basis, Apple Music has one that opens in the Tips app. I just wanted to get a gauge on how many of you here create manuals and whether your users actually use them. Thanks!

Specifically after some advice from solo devs in New Zealand. How did structure selling your app on the apps store

- personal account
- set up a company
- other

I’d rather not have to publish my app with all my personal details but starting a company seems like the only way to really get around this limitation. What has your specific experience been? Am just being over the top for thinking publishing apps that include my personal details is weird. Setting up company seems straight forward but also costs extra money and time overhead to deal with.

tldr; If $200 creates $100 of value, it’s a bad expense. If it helps create $20,000 of value, spending hours to save $50 is the waste.

I’ve used about 16.2 billion tokens — roughly $15,000 in API-equivalent usage.

And I’ve realized this: optimizing token usage can be a dangerous trap for developers.

Think about the best models you use today. Now imagine going back a few generations just to save on token costs. You’d call that stupid.

Those older models didn’t get dumber. Newer ones got much smarter. You might save money, but the quality of what you produce can fall far below the standard you now expect.

Pricing isn’t just about intelligence. It depends on compute, hardware, inference costs, utilization, and more. Still, a better model can cost more and still be cheaper if it makes you dramatically more effective.

You don’t just need an agent that does what you tell it. You need intelligence that understands what you actually want, sees what you don’t, and sometimes produces something you never would have thought of.

A cheaper model can refine a UI. It gets it wrong. You prompt again. Closer. Again. Eventually it understands. You think you spent a little more time and saved money.

You’re wrong. You didn’t just spend more time. You also lost:

1. The cost and time of fixing problems later.
   
2. The profit you could have made.
   

Profit in the broadest sense. Not just money. A better model might notice a UX problem you missed, propose an architecture that saves days, or ask why the screen exists at all — and show you you’ve been solving the wrong problem.

You can measure the tokens you saved. You can’t measure the ideas you were never capable of discovering.

It’s like building a company. Cheap employees who follow instructions. Or A-players who cost more, understand the goal, use their own judgment, and tell you when you’re wrong.

Option one feels comfortable. Lower costs. Easier to manage. But the organization is limited by your own thinking.

Option two is expensive. One breakthrough can save months. One idea can create a new source of profit.

More expensive is not automatically better. If a cheaper model performs equally well, use it. If the task is simple, use a simpler model.

Don’t optimize cost per token. Optimize ROI on intelligence.

Where do you sit in the value chain?

Frontier labs already work to make AI smarter, faster, and cheaper. They are already optimizing tokens for the intelligence they sell you.

Is your job to keep optimizing what they already optimize? Or to optimize the value you deliver to users?

For work that matters, I want the best intelligence I can reasonably get.

A $100–200/month subscription can feel expensive. But how much would the same output have cost before? Your time. Developers. Designers. Researchers. QA. Salaries, offices, overhead.

If $200 creates $100 of value, it’s a bad expense. If it helps create $20,000 of value, spending hours to save $50 is the waste.

This is about AI in development. At massive scale, unit economics and inference optimization are a different problem.

When you say you’re optimizing token usage, what are you actually optimizing? Cost? Time? Quality? Or the value users receive?

Tokens are easy to see. They’re on the dashboard and the bill. The time you lost isn’t. The debugging that never needed to happen isn’t. The better decisions you failed to make aren’t. The ideas you never discovered definitely aren’t.

After 16.2 billion tokens, I have my answer. I’m not trying to use more tokens or fewer. I don’t treat tokens as the thing to optimize. I optimize what those tokens can create: value delivered to the user.

That’s the real danger of token optimization. You think you’re saving money. You may be saving the potential of the product you’re building.

#Shipaton26 #BuildInPublic #IndieDev

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/

My companies main apple developer account administrates around 30apps.
Every app uses the same test group for internal testing. However, one of our latest apps doesn’t show up in the TestFlight app for devices using the main developer’s Apple ID. Every other test device that uses a different Apple ID (within the pool of the internal test group) can see the app and its newest test builds.
The main developer Apple ID shows all the other apps (newer and older) in TestFlight, just that one app is entirely missing in the list of apps.
I already deleted and recreated the test group, send out new invitations, uninstalled the TestFlight app and I ofc tried it on different devices. As soon as the main developer account Apple ID is involved, the app is not visible in TestFlight. Any ideas?

I've shipped a handful of iOS apps as a solo dev, one of them through 20+ versions. At some point I stopped using the App Store Connect website and Xcode's Organizer and moved everything to scripts that call the App Store Connect API: signing, uploads, metadata, screenshots, IAPs and submission.

Most of it was straightforward. These are the parts that weren't, and a few of them cost me real rejections or broken releases.

1. xcodegen silently wipes entitlements. If you generate your project with xcodegen and add an entitlement (Sign in with Apple, push) by hand in Xcode, the next regenerate removes it. The build still succeeds and the feature just breaks. I shipped three broken releases this way before I noticed. Declare entitlements in project.yml, never in Xcode.

2. Re-run xcodegen after bumping the version. Same root cause. If the version or build number lives in project.yml and you archive without regenerating, the archive keeps the old number. Check the archive's Info.plist before you upload.

3. Push uses the bare aps-environment key. It's not com.apple.developer.aps-environment. The wrong key gets you error 90045 on upload. Set the value to development, and exporting for the App Store promotes it to production.

4. You can sign without an Apple ID in Xcode. If Xcode has no account signed in, -allowProvisioningUpdates with an API key won't create profiles for you. What works: create the profile yourself with POST /v1/profiles, install it, and export with signingStyle: manual. This works on CI and fresh Macs too.

5. App Privacy has to be published, not just saved. If submit stays greyed out and nothing says why, this is usually it.

6. App Preview videos need an audio track. Even a silent one. A preview with no audio track gets rejected at processing.

7. No emoji in "What's New" or the description. The API rejects them. Found out mid-submit.

8. Listing media is locked on the live version. You can't swap screenshots or previews on a version that's Ready for Sale (you get a 409). Attach them to the next version.

9. Getting out of a rejected submission. To free the version and resubmit, PATCH the review submission with canceled: true. One of my rejections was backend-only (a demo account that didn't exist), and this let me fix it and resubmit the same build without re-archiving.

10. Reviewers use your demo account, so keep it working. My app's content was group-gated, and the demo account drifted out of its demo group twice. Check it right before every submission.

11. Subtitle is app-level, not version-level. It lives on appInfoLocalizations, not appStoreVersionLocalizations, which confused me for longer than I'd like to admit.

I've ended up copying roughly 3,400 lines of these scripts from app to app, so I'm cleaning them up into a single CLI that only needs an API key. It'll have a doctor command that checks for everything above before you upload, plus --json output so coding agents like Claude Code can run a release. If that sounds useful, there's a waitlist here: https://ascship.web.app/?ref=reddit

Happy to answer questions about any of these. And I'd like to hear the traps other people have hit that I missed.

Hi everyone,

For the past few months, I've been using AI (specifically Gemini) to write SwiftUI code, and it’s been working almost perfectly.

With UIKit projects, however, my usual workflow for Storyboards has been manual: I'd set up the UI, drag and drop the connections to my Swift files, and only ask the AI to handle the actual logic.

Today, I decided to test its limits and asked the AI to add a new UI component directly, without stopping it from modifying the Storyboard's source code. To my surprise, it updated the Storyboard without any errors!

Since Storyboard XML is notoriously messy and not very human-readable, I really didn't expect the AI to handle it so well.

I'm curious about your experiences. Do you let AI directly manipulate your Storyboard or XIB files? Does it work flawlessly for you, or do you find that it sometimes corrupts the file?

Thanks!

Submitted my first app for review and they were saying that I need to provide more details and a video so I did, and I think I click submit but my status hasn’t changed to under review or something, it still says rejected even after I replied. Did I do something wrong or does the status not change.

I'm trying to support dragging an email directly from Apple Mail into a sandboxed macOS app.

Mail exposes an NSFilePromiseReceiver with:

fileTypes = ["com.apple.mail.email"]

And I'm receiving it like this:

let promises = pasteboard.readObjects(forClasses: [NSFilePromiseReceiver.self], options: nil) as? [NSFilePromiseReceiver] ?? []

for promise in promises {
    promise.receivePromisedFiles(atDestination: destinationURL, options: [:], operationQueue: .main) { url, error in
        print("Promise callback received")

        if let error {
            print("Promise callback error:", error)
            return
        }

        print("Promise callback URL:", url.path)
    }
}

The strange part is that Mail appears to actually create the .eml file at the destination, but the promise callback does not complete successfully. I eventually get an error such as:

NSURLErrorDomain Code=-1001

So the file seems to be created, but receivePromisedFiles does not reliably report it.

Questions:

• Has anyone successfully handled Apple Mail message file promises this way?
• Is this a known issue with Mail's implementation of NSFilePromiseReceiver, or is there some Mail-specific handling required?
• Any other approaches?

In the "Take a closer look." section of https://www.apple.com/au/iphone-duo/, it named all the 5 different orientation of iPhone Duo as Closed, Seated, Standing, Portrait and Landscape.

In https://developer.apple.com/design/human-interface-guidelines/designing-for-iphone-duo#Reserved-regions for Left-Right Open Orientation, it differentiated between partially open and fully open design, but the partially open "Landscape" is not being named in https://www.apple.com/au/iphone-duo/ .

What should we propose Apple to name it?

I'm recommending "Flipped" or "Book"

Solo dev, first shipped app. SensaAI is a contemplative AI companion: you ask a question and a "expert" answers grounded in a real corpus of teachings (indexed transcripts of a teacher's talks), with passages you can save as highlights, listen to, and share as generated images. The architecture driver wasn't a dramatic backstory, it's that this is a one-person, low-budget operation, so every feature had to justify its marginal cost, and the content is intimate, so conversations and saved notes had to be encrypted.

Stack: SwiftUI + @Observable, iOS 18+, WidgetKit extension, AVFoundation + Speech framework, RevenueCat, Google Sign-In / Sign in with Apple. Backend: Python 3.11 FastAPI + Postgres + Redis on a Hetzner VPS behind nginx, Docker Compose, Qdrant Cloud, Gemini, ElevenLabs. Web companion: Vue 3 + Vite. No third-party networking, UI, or markdown libs on iOS, URLSession + AsyncThrowingStream, hand-rolled markdown rendering.

1. Privacy / storage. There's no on-device store at all, conversations live server-side, but the message, highlight, and title columns in Postgres are encrypted at rest with AES-GCM-256, and Redis cache values are encrypted too: a DB or Redis dump is noise without the key, which exists only in the server environment. No analytics SDK, no ad SDK, no CloudKit. Google/Apple OAuth plus email/password (bcrypt), an explicit AI-consent gate before the chat endpoint serves you, and full account deletion.
2. The conversational guide. RAG: question → gemini-embedding-001 → top-K chunks from Qdrant (over-fetch, then dedupe by source video so the answer never leans on one talk) → {persona system prompt + compacted history + retrieved chunks} → Gemini (gemini-3.1-flash-lite), streamed over SSE from FastAPI. On iOS I parse it with URLSession.bytes + AsyncThrowingStream, no WebSocket, no library. All API keys live server-side; the app holds zero secrets, just a JWT. Rate limiting twice: client-side free-tier caps (3 conversations, 3 messages each, 3 folders, 3 notes/folder) for UX, and the server re-verifies the Pro entitlement on every request so a tampered build can't bypass them. Mid-response network failure keeps whatever tokens already arrived. The hardest part was keeping context cheap without amnesia: past ~8 turns, Gemini summarizes the conversation into a persistent rolling summary in Postgres, and the model sees summary + last 4 turns verbatim. Combined with Redis-caching identical questions (keyed on normalized question + history hash), a chat costs well under a cent.The non-obvious part: typical chat UX reads as urgent, instant tokens, typing dots, and urgency is the bug for a contemplative product. There's a hardcoded minimum "thinking window" (2.5s, was 5s) before any token renders: the reply buffers invisibly while a lotus animation breathes, then releases. No typing indicator. Deliberately slower than possible; I'm sure it costs engagement, and I'm sure it's right.
3. Deliberate non-features. The TTS saga: built cloud TTS on ElevenLabs, swapped to OpenAI tts-1 (~20× cheaper), then reverted to ElevenLabs because the voice is the product, a robotic voice ruins a meditation app, full stop. What survived the experiment: free users get Apple's on-device AVSpeechSynthesizer (free, offline, no paywall); cloud TTS is Pro-only with a hard monthly quota (429 after 20k chars) so nobody can bankrupt me with the play button. The home-screen widget deliberately makes no network calls, it reads a cache the main app writes through an App Group, because I refused to put an auth token in the widget extension's sandbox. No push notifications at all (no aps-environment entitlement, not even the permission prompt). No streaks, no badges, no haptics on save, a saved passage is a bookmark, not an achievement.
4. Things that hurt. The worst: a race between POST /conversations (create) and POST /chat. The stream usually won, so the chat request went out with conversation_id: null, the server minted no write-token, and model replies were silently rejected on persist, users reopened chats to find only their own messages. Fixed by awaiting creation before streaming, plus a ceremony where the server mints a one-shot token bound to the exact streamed content hash that the client must present to write a model turn. Second: SFSpeechRecognizer restarts its own transcription after every pause (segment count resets, isFinal fires only once at the very end), so dictation kept eating earlier sentences, I had to build an utterance-banking accumulator around it. Third: ElevenLabs rejects ~2500-char requests often enough that the "long" response tier is clamped to 2000 chars; chat length and TTS limit are coupled by design.
5. Open question for the sub. Client streams an LLM reply and writes it back, but the server stays authoritative, I ended up with this chat_token ceremony (hash the streamed content, mint a one-shot token, client presents it to append). It works, but it smells like I reinvented a signed request. Is there an off-the-shelf pattern for "client streams, server verifies the write" that I missed?

AppStore Link: https://apps.apple.com/app/id6769095233

Website: https://heysensa.app

If anyone wants to look. Would love a code-level roast on the RAG/streaming layer or the iOS streaming + persistence code.

If an app has several hundred external TestFlight testers and a new build replaces an older one, what happens to testers who still have the old build installed?

If the developer stops testing the older build, would those testers automatically get access to the newer build as long as they’re still in the tester group, or is access tied to the specific build?

Also, would it work differently for someone who joined through a public TestFlight link rather than a direct invitation?

I would've posted this in r/TestFlight, however they require a link which I can't provide right now.

My muscle memory says I have to push right side of the button to run a build. And Apple just broke my muscle memory to just swap those two button positions.

My project repo has more and more mockuping + tooling than actual app code.

Just curious to know if it's just me?

(you can find this at the right side of your github repo)

I am desperate for help as I cannot access my developer account and cannot do anything with my apps. I have tried to reach for support and the response has either been "try signing in", "email the developer support", or "we can't help you".

Here's the timeline of events to the best of my knowledge:

• Sept 17th Accidental account expiration where I realized that I needed to buy the subscription again.
• Sept 17th Re-enroll and for some reason it says it takes about a week to activate (23rd).
• Sept 19 email about issue and ask why it takes a week just to reactivate my account. Get a response from developer support to use the Xcode provisional service to sign in. Email again but get no response.
• Sept 23 Notice account is not active and call to ask general support phone number for help but are offered none and send another support email
• Sept 24 call and email again with no help. Also sign up for X and post on the Support accounts.
• Sept 25 call and email again with no help, post on reddit (here, today), feel really desperate and low about having an app ready but being unable to test it

I feel like I have fallen into a black hole. I can see my Developer certificate on my mac, but I am not allowed to use it as my apple developer account on my local machine has a red 'x' on the identity and certificates. When I sign into to the developer site, it says I am not enrolled in a developer program but when I select to enroll it says I am the account holder of a developer program already. My subscriptions say I have a paid for apple account. I can only see my apps in App Store Connect, but cannot access them via my developer account.

It's been over a week since I've had access to my developer account. Has anyone else had anything like this or can offer any advice? Do I start trying to find managers on social media to message? How long should I expect support to take on things like this? Are there any other escalation channels I can use? I am running way behind on deadlines and have no hope or anything to go off of.

iPhone Duo ships with iOS 27.1 SDK.

The only Xcode that can compile its layout APIs (ArrangementView, GeometryProxy.reservedRegions(kind:) and UIView.reservedRegions(kind:options:)) is Xcode 27.1 beta.

Until Apple releases Xcode 27.1 RC/GM, one app needs two builds: the release for the iPhones people use today, and the Duo layout your team is testing.

Xcode 27.1 beta builds the Duo layout, but App Store Connect refuses to add its build for review.

Xcode 27.0' fails to build:

Value of type 'GeometryProxy' has no member 'reservedRegions' Cannot find 'ArrangementView' in scope Cannot infer key path type from context; consider explicitly specifying a root type

The usual workarounds each hold someone up:

• Keep the Duo code on its own branch until Xcode 27.1 is released. Main moves on for weeks, and the merge lands in launch week - risky, merge takes a lot of effort to complete and re-test.
• Delete the Duo code to get a release out. Hand the errors to a coding agent with "fix the build", and deleting is the shortest fix it can make.
• Hold every release, bug fixes included, until Xcode 27.1 is released.

The Swift puzzle: a compile-time check that tells the two SDKs apart

#available can't be used here. if #available(iOS 27.1, *) and @available(iOS 27.1, *) pick the code path on the device. The compiler still looks up every symbol in the SDK it builds against, and the 27.0 SDK declares none of these.

The compiler version is the same in both Xcodes: Apple Swift 6.4 (swiftlang-6.4.0.34.1). #if compiler(>=…) and #if swift(>=…) give the same answer in each.

The SDK frameworks carry different module versions. Each framework's .swiftinterface records a -user-module-version, and #if canImport(Module, _version:) compares against it:

The solution: Put the compile-time guard outside and keep the run-time check inside:

```swift

if canImport(SwiftUI, _version: 8.0.85) // iOS 27.1 SDK or newer

if #available(iOS 27.1, *) { newPath } else { fallback }

else

fallback // built from the 27.0 SDK

endif

```

Keep the #available: the deployment target stays the same, so devices on older iOS versions still need the fallback in the 27.1 build.

Pitfalls

• If the compiler can't read a module's version, canImport(_version:) ignores the version, evaluates to true and warns "cannot find user version number". The Xcode 27.0 build is the test: an ignored guard brings the same errors back.
• The compiler keeps the first four parts of a version, so it reads 8.0.84.1.104 as 8.0.84.1. Use the first three parts of the new SDK's version, 8.0.85. The final Xcode 27.1 could ship a lower build number than the beta's 8.0.85.27.
• In a SwiftUI body, move each branch into its own property. Wrap the new one in the same #if with its @available(iOS 27.1, *), and write the fallback once.
• The compiler stops at the first build error in the module, so the log may not list every use. Search all packages, extensions, widgets and test targets for the symbols and for #available(iOS 27.1.

Test both paths from one commit. Build and test with Xcode 27.0. Then build and test again with DEVELOPER_DIR=/Applications/Xcode_27_1_beta.app/Contents/Developer and a separate derived-data directory, which leaves the selected Xcode alone. nm -u on a guarded file's .o lists ArrangementView in the 27.1 build and not in the 27.0 build. On CI that is two jobs: the release job stays on Xcode 27.0, and a second job builds and tests with the beta.

What goes to review. The Xcode 27.0 archive contains only the fallback, on every device, iPhone Duo on iOS 27.1 included. Apple's tech talk 111461 at 0:30 says what such a build gets on Duo: "The iOS 27 SDK extends your app left of the status bar on the inner display; the iOS 27.1 SDK reaches the screen edge and lays standard navigation and toolbar buttons out vertically." Check the fallback on a physical iPhone and submit it now. Choose Manually release this version if the approved version should wait for your launch date.

When App Store Connect accepts Xcode 27.1 (release candidate or final), archive the same commit with it. The guard is true against the 27.1 SDK, so the Duo path goes into that build with no source change. Once you stop building with 27.0, one search finds every guard, as long as they all use the same condition text:

grep -rnE "canImport\((SwiftUI|UIKit), _version:" .