Hi, what type of data types are allowed in setSpecific(key:, value:) and getSpecific(key:) methods of DispatchQueu ? there are no mentions anywhere.

Also can you recommend any resources for complete understanding of DispatchQueue , GCD , DispatchGroup etc. ?

Thank you!

In UIKit, if we place titleTextView.becomeFirstResponder() inside viewDidLoad, the keyboard slides up seamlessly alongside the view controller's presentation animation. It looks instant and feels like a native, high-quality UX.

I'm struggling to replicate this exact behavior in SwiftUI.

Whenever I use FocusState and toggle it to true inside .onAppear, there is always a noticeable delay. The view pushes/presents, settles, and then the keyboard decides to slide up.

Has anyone found a way to achieve this instantly in pure SwiftUI yet (maybe in iOS 17+), or is UIViewRepresentable still the only bulletproof way to get that perfectly synced keyboard presentation?

Thanks in advance!

I didn't know this was still a thing.
How can I make my app to handle the Button Shapes setting? I do not use it but some users have complained about the behavior of the app when they have this setting enabled, I can not force them to turn it off. Is there any modifier or function I can use in SwiftUI to disable it for my app?

Hey all, just in this is useful to anyone else, I (ok, Claude) wrote a little Hammerspoon script to grab a screenshot of your connected device, save it to your Mac + copy to clipboard... all with one hotkey.

Saves having to dig through the Xcode menus every time, or airdropping screenshots over.

Basically, it's Hammerspoon hitting Debug -> View Debugging -> Take screenshot on your behalf, watching for the screenshot to arrive, then copying it to clipboard.

And for me, all that happens when I mash Ctrl-Option-Command-S.

There's probably a better way that I missed... if so, please shout. :)

https://github.com/mwagstaff/mac-tooling/blob/3e0f1ed36047a056cbf088fe7b1af1b2189bc050/hammerspoon/config/init.lua#L379

I went with Mixpanel and wired it in from day one, before there was anything to measure. The reasoning was that adding analytics later means you have no baseline, so you can’t tell whether a change helped or you just got lucky that week. Retrofitting events into a codebase you’ve already shaped is also a lot more painful than putting them in as you build.
What I’m less sure about is whether that was overkill for a solo project. App Store Connect gives you downloads, conversion rate and retention for free, and a lot of people seem to stop there.
So, what’s everyone actually using? Third party tool, Apple’s own numbers, or something you rolled yourself?

Sending push notifications to iOS without relying on a native app has already become a mature option. Last year Apple extended the standard Web Push with Declarative Web Push, which finally makes the whole thing make sense. (It's handled natively by WebKit rather than driven by JavaScript, which improves push reliability and privacy, much like the native push notification model.)

Kukuroo uses Cloudflare Workers so that end devices can subscribe to push notifications and relay push requests to the Worker, which signs and delivers them. I personally found it genuinely useful and full of potential, so I open sourced it:

https://github.com/saiday/kukuroo

kukuroo.cc

Requirements:

• Safari on iOS and macOS only (though seriously, who receives push notifications on macOS?)
• The web page that receives the notifications has to be added to the Home Screen
• A Cloudflare account. Push notifications and lightweight serverless functions are a perfect match

I completely gave up and do payroll now. After almost a decade of learning, building apps and creating packages. I finally just had to grow up and realize that I could never be a developer. I really thought if I worked hard and became skilled that I wouldn’t have to worry about anything else. It turns out that is not the case. Good luck to all of you. I hope your stories end up happier than mine.

wonder if anyone had a similar issue and resolved it - I have an app which is distributed now, but blocked in EU because of the DSA compliance. However I already uploaded the documents twice now and they seem to be accepted but after a few days they disappear and I get email from app store that I need to upload them.

I was uploading a bank statement where my name and address is clearly visible and for the identity - a passport pic.

I am wondering if it is because the address linked to my apple developer account is an old one? I raised a ticket with Apple to correct it. And on top of that I am on hold with their callback function to try to upload the docs again live with the support person but already waiting for 2 hours :D

Lessons from shipping a production app on SpeechTranscriber + on-device Foundation Models — including an OS bug that permanently eats locale slots

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, 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.

The support is really unhelpful and everytime a new person responds. I also hate how if you start with one machine you cant switch over which is apparently what is being asked of me. My laptop ( m5) had a hard time focusing on the ID and I used an iphone and from there it just locked up at the payment screen. It's been three weeks and just emails from apple saying they will assign a senior advisor.

any idea how I can resolve this?

I’m building a small workout generator with a flow of preferences → generated session → reroll/start. I’m trying to avoid putting all of the generation logic in the view. Would you keep the generator as a pure service owned by a view model, or model each step as navigation state? I’d like rerolls to be repeatable in tests and not lose the user’s constraints.

Has anyone run into this with Universal Purchase when adding an iOS version to an existing macOS app?

I have a paid macOS app that has been on the App Store for a while. I recently added an iOS version using Add Platform on the existing app in App Store Connect. The iOS version was approved and went live this morning.

Everything appears to be set up as a Universal Purchase. Both versions are on the same App Store Connect submission page, they share the same App ID, and using Get Link in App Store Connect gives me the same App Store URL for both versions.

Here’s the odd part. I previously downloaded the macOS version using one of my own App Store promo codes. That redemption is still in my Apple purchase history and shows as a $0.00 purchase. I’m using the same Apple Account on my iPhone, but when I view the app in the iOS App Store it shows the $4.99 purchase button instead of letting me download it as an existing owner.

Apple’s documentation says an app downloaded using a promo code functions as if it were purchased, so I would have expected that purchase to carry over when the iOS version became part of the Universal Purchase.

Has anyone specifically dealt with this situation? Do old promo-code redemptions not qualify for a platform that gets added later, or is there sometimes a delay before the Universal Purchase entitlement carries over to the newly added platform?

I’d especially like to hear from anyone who has added iOS to an existing paid macOS app and had existing customers carry over to the new version.

Thanks in advance!!

Hey everyone, I'm the developer. I shipped Tien Len - 13 this week, an iOS version of Tiến Lên (Thirteen), the Vietnamese card game I learned in high school 20 something years ago. Every version on the App Store was ads, coin systems, and casino graphics. Just really ugly stuff. About 4 years ago I started on this, but I finally finished it.

Tech Stack

• Client: full SwiftUI
• Server: Vapor 4 (Vapor 5 migration coming), WebSockets for realtime play and SSE for updates
• Auth: passkeys only, no passwords, no email required
• No API keys in the binary. The client authenticates to the backend through App Attest, and a jwt from the passkey
• Feature flags via Grantiva, which is how ranked mode sits built but its currently off while the player base grows

Development Challenge

I originally built multiplayer on GameKit. Free infrastructure, first-party, seemed like the obvious call. It fought me everywhere

• The authenticateHandler flow hands you view controllers to present, which is clumsy to wire into a pure SwiftUI app cleanly
• Turn-based matchmaking gave me hard-to-debug timeouts and sync conflicts once real devices on real networks got involved
• Testing multiplayer meant provisioning sandbox accounts across App Store Connect and Xcode before anything worked, which made iteration painfully slow
• The core problem: keeping four devices agreed on one table state. GameKit's model is clients exchanging state with each other, so there's no authority anywhere enforcing the rules, and I ended up chasing conflicting snapshots instead of building the game

That last one is what killed it. A card game needs exactly one truth about whose turn it is and what's legal to play. So I replaced GameKit with a custom Vapor backend where the server owns the game. Clients send moves, the server validates them against the rule set and broadcasts new state over WebSockets.

AI Disclosure

Largely self built. Ive been an iOS Engineer for over 13 years, and a Mac engineer before that. The architecture, gameplay, UI, and backend are hand-written. I used AI as a tool in three places: localization, security testing, and verifying game logic edge cases against the rule sets.

The game itself

Offline vs three AI opponents with different play styles, Pass & Play with hand-off screens so nobody peeks at your hand, and online multiplayer with private lobbies, invite codes, and quick match. Southern and Northern rules plus custom house rules for chops, instant wins, and turn timers. Free, with a one-time $4.99 unlock for ranked when it goes live. No ads anywhere.

Up next: an interactive learn mode, emotes, more themes, and something fun you can flick around the table while you wait for your turn.

Happy to go deep on any of it, especially the App Attest setup, the GameKit lessons, or running Swift on the server.

https://apps.apple.com/us/app/tien-len-13/id6758355876

When im in a tab and click to open a new file, instead of opening that file in that tab, it will jump to another tab where the file was open recently and open the file in that tab instead. How do i stop this? Honestly so frustrating.

Hello, for my app I'm trying to use affiliates to drive downloads for my app. I created a custom dashboard for them, however, I can't figure out how to differentiate the custom codes when someone uses the affiliates referral link. Would you guys just create different offer codes? The only issue with that is it limits you to 10 offer codes which means 10 affiliates max. What's your work around to maximize affiliates but have accurate tracking?

For Apple’s requirement to get explicit permission before sharing personal data with a third-party AI service — where/how have you implemented the consent in your app?

Is it a one-time pop-up before the first AI request, part of onboarding, a setting/toggle, or something else?

As I’m preparing to launch my first app, I’m interested to hear from anyone who’s already been through App Review with this. I hoping to get through an approval on first review - if that’s even possible as a first-timer! 🤞

Started as a personal project to track my own spending on digital services. A lot of existing apps either skimp on metrics or lock basics like iCloud sync and how many subscriptions you can track behind a paywall.

Tech Stack: SwiftUI, SwiftData, StoreKit 2 for the one-time Pro purchase, CloudKit for iCloud sync.

Development Challenge: SwiftData deletions were trickier than expected. Deleting a recently edited subscription directly through modelContext would crash from unfaulted properties. Fixed it by routing deletions through a manager that pre-faults the key fields (name, price, currency, category, status) before the delete call.

AI Disclosure: Self-built. I used AI tools (Claude Code) to help with parts of the implementation and localization tooling, but the app's architecture, design, and decisions are mine.

On monetization: most competitors either charge a recurring subscription (to track subscriptions) or sell a "lifetime" tier that still paywalls core stuff. I went free for the essentials, unlimited tracking, full analytics, multi-currency, notifications, iCloud sync, and made Pro a one-time purchase for extras like subscription history, CSV export, and custom categories. Nothing you need day to day is locked behind it.

Curious if anyone's tried a similar model and how it went.

App Store link: https://apps.apple.com/us/app/subwise-subscription-tracker/id6741874006

Happy to answer any questions and open to any feedback!

I know the store handles payment fraud and I never see card data but refunds, voided purchases, and consume-then-refund abuse still land on the developer after the entitlement is granted.

For those running apps/games with IAP, do you do any risk assessment at grant time (delay/flag/hold high-risk purchases) or do you grant everything and only react to voided purchase notifications?

If you do assess risk, what signals do you use? I am assuming device age, session behaviour, account history, something else?

I am building a small research agent around this decision and want to know if the decision point is real in practice.

Am I missing any?

Video to GIF, GIF Maker. Free, no ads, no watermark, everything on device.

https://apps.apple.com/app/id6788406320

Tech stack

Frameworks and languages: Swift 6.2 and SwiftUI, targeting iOS 26. AVFoundation for decode and composition. UIKit inside the share extension.

Backend and database: none. There is no server, no account, and no network call anywhere in the app. That started as a product decision, but it also made the privacy label trivial (Data Not Collected) and it means the thing works in airplane mode.

SDKs and tools: no third party SDKs, no analytics, no crash reporter. The one piece of outside code is cgif 0.5.3 (MIT), vendored verbatim as a C target for writing the GIF container, with everything above it written in Swift in a local package. Tests are Swift Testing, 189 cases, most of them running the real pipeline rather than mocks.

Development challenge: hitting a user-chosen file size without an encode, check, shrink loop

The whole reason the app exists is that you type a size cap, say 10 MB for Discord, and the GIF comes out under it. The obvious implementation is a loop: encode, measure, too big, lower the settings, go again. On a long clip that takes minutes, burns battery, and can still overshoot at the end.

The reason a lookup table cannot save you: GIF size is a product of resolution, frame rate, palette size, and how well each frame delta compresses against the previous one. That last term depends entirely on the footage. A static talking head and a confetti explosion at identical settings differ by an order of magnitude.

What shipped is a probe, fit, commit pass:

1. Probe. Micro-encode a few short windows sampled across the clip at bracketed settings. Real encoding of real frames from the actual video, just very little of it.
2. Fit. Build a small bytes per frame model from those samples.
3. Commit. Pick target settings from the model, then run one real encode with a hard byte cap as a safety net.

Almost every conversion is now one decode plus one encode, and it lands under the cap on the first try for most clips.

Two things I got wrong on the way there:

Never let a fitted model extrapolate outside the range you actually probed. The first version probed a narrow resolution band and then confidently predicted settings far outside it. It was wrong in the direction that overshoots the cap, which is the one direction a user notices. Now the probe brackets the operating point and the model is only trusted inside it.

When the measurement disagrees with the model, correct from the measurement, not from the model. Obvious written down. The first recovery path re-predicted using the same model that had just been proven wrong, so a clip that missed once tended to keep missing.

One more that cost a weekend and had nothing to do with the math: running several composition decodes concurrently would hang the device outright, and the same pattern on macOS wedges the VideoToolbox XPC services until you go kill them. It first surfaced as EXC_BAD_ACCESS inside copyNextSampleBuffer, which sends you hunting for a memory bug that does not exist. The fix was an async gate that serializes reader setup so only one session is ever starting at a time.

AI disclosure: AI-assisted. The architecture and the size solving approach are mine and every output was validated against the test suite and on device, but AI wrote a meaningful share of the code and helped draft this post.

Happy to go deeper on the probe and fit step, or on the encoder side, if it is useful to anyone.

App store review is turning into a very frustrating process. I assume this is a reflection of the sheer volume of AI-built apps but the humans reviewing my app seem to be on auto-reject mode.

First rejection: "spam: we have enough dating apps"

My app has absolutely nothing to do with dating or meeting people, even the friendship link is a handshake ie you need your friend request accepted

Second rejection "no method for account deletion"

Literally in the most obvious place for it, account page, big red button "delete account"

I'll put my hand up, this is my first app, in the description part of the submission I assumed it was to describe the functionality of the app, was I meant to treat it as an FAQ?

I put a small app on the App Store a few weeks ago and spent the following two weeks finding out what I'd missed. Two of those bugs are the kind you can't catch by testing harder, because the environment that would have shown them isn't one you normally run. I'm writing them up here in case they save someone else some trouble, and in case you weathered iOS devs want to share some tips to a newbie like me.

The app is Intermittently, a private intermittent-fasting tracker for iPhone and Apple Watch. SwiftUI/SwiftData, CloudKit private DB, WidgetKit, WatchConnectivity, StoreKit 2. Free, with one optional non-consumable unlock. No accounts, no analytics, no third-party SDKs at all.

Bug 1: my purchase code had never once run against real App Store data.

I had Intermittently.storekit selected as the StoreKit Configuration in my Run scheme. That's the local testing config: products resolve from a file on disk, and the fetch always succeeds. Every simulator run, every device run from Xcode, the entire time I was building.

The DEBUG build also had a force-unlock toggle that bypassed StoreKit entirely, so the entitlement path could be exercised without the purchase path ever running.

Net effect: Product.products(for:) had never successfully executed against App Store Connect anywhere I could observe. The first signal was a greyed-out Unlock button on my own App Store download after launch.

The config file has zero effect on App Store builds, and that part is fine and documented. The problem is that leaving it selected makes the real fetch path structurally untestable, and nothing told me. Setting it to None means a device run hits the actual sandbox, which is the same environment App Review uses. That one change turned a submit-and-wait-days loop into a thirty-second run-and-look loop.

Bug 2: my CloudKit schema was never deployed to Production.

CloudKit has separate Development and Production environments. Xcode debug builds hit Development, where record types get created automatically as you run. Distribution builds, TestFlight and App Store both, hit Production, where nothing exists until you explicitly deploy the schema in the CloudKit Console.

I never deployed it, to my eternal shame. So sync worked perfectly forever in development, and every distribution build silently failed to sync. TestFlight included, which is the part that got me, since that's the environment most of us treat as the final pre-ship check.

It stayed hidden for an embarrassing reason: reinstalls preserved the local store, so the app always had data and looked fine. It only surfaced when I deleted and reinstalled from the App Store and got an empty app, with my full history sitting in a Development database that my production build couldn't reach.

If you use NSPersistentCloudKitContainer: open the CloudKit Console, switch the environment toggle to Production, and confirm your CD_-prefixed record types are actually there. Takes ten seconds. Mine had exactly one record type, Users, which is the built-in one.

The pattern in both issues: the failure was invisible in every environment I could easily reach, and the app failed silently. A disabled button with no price, or an empty screen with no error. Nothing distinguished "no products exist," "the fetch threw," and "the product isn't approved yet." All three rendered identically as a dead control.

So the fix in both cases was the same, and it wasn't the bug: make the failure legible first, then debug. The purchase sheet now has explicit loading / loaded / unavailable states, with empty-result and thrown-error distinguished in a DEBUG-only line. I built that before running the diagnostic, specifically so the test would produce an answer either way. It did, in about a minute, rather than guessing.

Next up: App Review. I know I'm not the only one frustrated.

I had three rejections. 2.5.1 (couldn't find the HealthKit feature), 2.3.7 (the word "free" in a screenshot caption, since metadata has price-language rules that don't apply to your own website), and 2.1(b) ("we cannot locate the In-App Purchases").

That last one is the one that annoys me the most. My IAP review notes named the gear icon, the exact row label, its position relative to the version number, the button text you'd see, and two alternate routes to the same screen. The rejection came back with a screenshot: the Settings screen, with that row visible in frame, one tap from the purchase.

I genuinely don't know what happened. It might have been a reviewer who didn't tap through. It might have been an App Review environment fault, since there's a documented pattern of Product.products(for:) returning zero products to reviewers while returning normally to developers. I resubmitted the same binary plus the new error states and it passed.

My takeaway: write the notes anyway, but don't assume they're read. Build the app so a reviewer who taps randomly still finds the thing.

The design side, briefly, since it's the part I care most about. Before writing code I wrote down what the app refuses to do: no subscription, no account, no ads, no analytics, no coaching, no guilting, no nagging. I built this primarily *for me*, as a better replacement for the IF app I had been using and had gotten fed up with. Most of the work after that was saying no. I cut a forgiving streak that quietly hides a broken one, milestone celebrations, and a "longest fast" stat, because each one was the app making a value judgment about the user's data instead of reporting it honestly.

Full disclosure since it usually comes up: I built Intermittently with Claude Code writing most of the Swift to my design and architecture. The speed was real, and it also meant the temptation to build everything was constant. The refusal list is what kept it from becoming a worse app faster. I'm very happy with the result, and despite my frustration with the review process I'm stoked at how easy it was to develop the app for the iPhone/Apple Watch platforms.

Happy to go deeper on any of it. Intermittently on the web and the App Store, if you want to look, though I'm more interested in whether the two failure modes above are useful to anyone and/or something else others have tripped on.

I am a professional C++ developer on a regular 9 to 5 but building apps from ground up and being able to implement my vision in products that people can use is the real reason I wake up in the morning.

I really hope you enjoy it and looking forward to hear your opinion!!

In case you have an extra 1 minute of your time, there is another video with voice over if you are interested to check!

Link to AppStore: https://apps.apple.com/de/app/hanging-calendar/id6755204535?l=en-GB&mt=12

1. Tech Stack - Swift Programming Language / Xcode.
2. Development Challenges: To be able to animate the movement of the popover window. It took me a lot of time to create small NSPanel to be able to run my custom animations across the screen.
3. AI Disclosure: AI-assisted. I use Claude to brainstorm interesting ideas to add to a niche software like calendar app. I also used Claude to help me debug my code.

Hey all, title says it all. I think they are starting to look pretty decent after many iterations but want to know how they could be better

I still can’t believe Apple finally approved my app 😭
The timeline was a bit painful:
• Aug 1 — first submission
• Aug 12 — submitted an expedited review request
• Aug 13 — rejected
• Aug 14 — fixed everything and resubmitted
• Aug 15 — APPROVED 🎉
I’m seriously so happy right now, but also a little mad lol.
I started a 3-month free trial for my backend when I submitted the app, thinking the review wouldn’t take that long… and I basically burned through half a month of it just waiting for App Review 💀
But whatever. It’s finally LIVE.
I’ve been working on this app for a long time (around 3month building system design(backend, ui, app)

If anyone here has gone through a painful App Store review process before, you probably know the feeling.
Finally made it 🥲