Pretty big news for bug testing apps: https://code.claude.com/docs/en/desktop-ios-simulator

How does the community feel about this potentially opening the door to even more AI slop in the app store?

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.

When I put a symbol on the edge, iOS neatly rearranges the content to fit around it. How do I recreate this on the other side with my own content, without the complications of using frame where anything too small will cut off, anything to large will look stupid, and the ideal threshold is changing as different sized content replaces?

I've built the engine for a paint-by-number iOS app but I can't work out where the hundreds of competing apps source thousands of flat vector images. Is there an actual B2B licensing vendor for this, or is everyone doing in-house art teams / AI generation / cloning each other?

Hey everyone,
I’m currently setting up a dedicated Mac server environment designed specifically for iOS developers who need cloud access to real Mac hardware for Xcode building, testing, or automated CI pipelines.
Before opening it up officially, I need a few active iOS devs to stress-test the remote access, latency, and hardware performance.
What I'm looking for:
3 to 5 developers building or testing iOS apps (especially those who don't have a secondary Mac, need remote build machines, or want to offload heavy compilation).
Devs willing to try using a remote Mac environment and give honest feedback on build speeds, remote desktop/SSH responsiveness, and overall setup experience.
What you get:
Free, full remote access to dedicated Mac hardware to run Xcode, test builds, or set up workflows (no credit card required).
Direct support from me to help configure the environment, setup remote tools, or tune performance for your project.
If you want free access to Mac hardware for your Xcode workflow, drop a comment or send a DM with what you're working on and your current build setup!

Hi, I was reading about this case study on the legacy IoT app optimization project that Beetroot consultants did for an established healthtech leader. The legacy codebase was riddled with critical bugs and the application suffered from serious performance bottlenecks and a confusing user experience that was tanking user engagement.

They created a dedicated team to address this under a flexible team extension model: 2 iOS developers, 2 Android developers, 1 QA automation engineer and 1 manual QA engineer with UI/UX design support. They ran into the classic dilemma: instead of choosing the expensive, risky rewrite from scratch, they took the hard way. They decided to refactor the legacy codebase to get rid of technical debt and squash the core bugs.

Crucially, they embedded deep product analytics tools like Firebase, Amplitude, and Smartlook directly into the new architecture. This let them track exactly how the app interacted with IoT medical hardware. For medical applications this deliberate refactoring approach is super interesting. What are your primary indicators for deciding whether to refactor the existing code or drop everything and start a full rewrite?

Posted the SpeechAnalyzer vs Whisper benchmark here recently and a few of you asked about Parakeet V2/V3. Ran both through the same harness, plus MOSS-Transcribe-Diarize which someone on HN suggested. Same 5,559 LibriSpeech utterances, same normalizer and scorer as round 1.

Results (WER, clean / other):

• Parakeet TDT v2 int8: 2.01 / 3.40 (wins)
• MOSS: 2.07 / 4.68
• SpeechAnalyzer: 2.12 / 4.56
• Parakeet TDT v3 int8: 2.51 / 4.28
• Whisper Small: 3.74 / 7.95

The stuff that actually matters if you're picking an engine:

Integration was easy. Parakeet ran via FluidAudio (Swift package, CoreML, runs on the ANE). We already link it for diarization so adding it to the benchmark was maybe 50 lines. If you have an AVAudioPCMBuffer pipeline already it's an afternoon.

Budget for the quantization tax though. NVIDIA's published 1.69/3.19 is bf16 on GPU. The int8 CoreML port you'd ship scores 2.01/3.40. Still the most accurate thing you can run on-device, but a decent chunk of its paper lead over Apple's free engine evaporates once it's actually shippable.

v3 gives you 25 languages for a real English accuracy cost (2.51 vs 2.01 clean). Still beats Whisper Small everywhere though.

MOSS does transcription + diarization in one pass and the speaker labels were perfect in a small controlled test. But there's no Swift or CoreML path (Python/MLX only), it's 1.7GB with ~2.7GB RAM, and it can't stream. Not output-streaming, I mean it literally cannot start transcribing until it has the complete recording, so anything with live captions needs a second engine anyway. Also fun: audio where speech starts at exactly t=0 returns an empty transcript, deterministically. Prepend a second of silence and it's fine.

This benchmark got Whisper removed from our app btw. Parakeet v3 replaced it as the downloadable engine (beats Whisper Small everywhere at a similar size, 25 languages), and for English Auto still prefers SpeechAnalyzer: 0.11 points, zero bundle bytes, improves with the OS. The cost-benefit section of the article is probably the useful part if you're making this call yourself.

Article + raw per-utterance transcripts if you want to rescore: https://get-inscribe.com/blog/parakeet-moss-apple-speech-benchmark.html

Disclosure: I build Inscribe (ships the Apple engines + Parakeet, formerly Whisper), all engines ran through identical production code paths.

Please help me,

Apple IAP submission has bug lately on submission, it doesnt accept any device screenshot of IAP

Aggregate data from 123 real App Store / Play listings scored by an ASO grader between May and July, in case it's useful for prioritizing your own store listing work:

• Titles: 81% of apps grade A or better. Median title uses 90% of available characters. If you're reading ASO advice about title optimization, you're reading advice everyone already follows.
• Descriptions: 90% grade A or better, median 2,418 characters.
• Localization: 94% grade D. 88% of apps have zero localized metadata. Median localization score 10/100 vs 100/100 for titles.
• About half of apps keyword-stuff descriptions, which is useless on iOS since Apple doesn't index the description field at all.
• No app in the sample scored above 81/100 overall (median 74).

The practical takeaway: adding localized metadata (title/subtitle/keywords per storefront, without translating the app itself) is statistically the least-crowded optimization left. Apple also indexes keywords from some extra localizations in the same storefront (e.g. en-GB + es-MX both count in US search), which most of that 88% are leaving on the table.

Caveat: self-selected sample (devs who checked their own score), so real-world numbers are likely worse than this.