标签：#iOS

My first CLAUDE.md for a client project ran 400 lines: architecture diagrams, the full MVVM-vs-TCA debate, a style section that just repeated SwiftLint's config in prose. Claude Code reads that file in full on every single turn, and it still missed rules buried near the bottom, because by line 340 they're competing with everything else for the model's attention. I cut it to 60 lines over two weeks. Same team, same codebase, fewer violations of the rules that actually mattered. It's not documentation The instinct is to treat CLAUDE.md like a README: a place to record everything true about the project. A README gets read once by a human who skims for the one section they need. CLAUDE.md gets read in full, by a model, every turn, and every line you add dilutes every other line's share of attention. That's the whole design constraint, and most CLAUDE.md files ignore it. What earns a line Non-obvious conventions. Not "we use MVVM," that's visible in five minutes of reading the code. "ViewModels never import UIKit" earns its place only if it's a rule someone actually broke once and it cost a day. Constraints invisible in the diff. App Store review requirements, a minimum OS version the code doesn't yet reflect, a performance budget on one screen because a past ship got rejected for jank. An agent has no way to infer any of that from the code alone. Repo-specific workflow gotchas. Which branch triggers a real deploy, which test suite is a known-flaky non-gate versus a hard one, where the actual source of truth lives when two files disagree. I run a merge gate across a few of my own repos, code only merges once CI is green and review found nothing blocking, and the single highest-value line in each CLAUDE.md is the sentence explaining that the gate exists and why a raw git merge is bypassing something on purpose. What the agent never touches unsupervised. For me that's deploy config and anything security-sensitive. Naming the boundary explicitly is cheaper than discovering

Zack Bartel has developed Tether, an open-source project designed to integrate Apple Continuity features with Linux workstations. Tether allows users to send iMessages, sync clipboards, and view iOS notifications directly on Linux. It uses secure local network communication and a custom Bluetooth stack to ensure reliable connectivity and robust security in cross-platform interactions. By Olimpiu Pop

The problem I'm a heavy sleeper. Not "hit snooze once" heavy. I would turn off three stacked alarms in my sleep and wake up an hour late with zero memory of doing it. The problem was never hearing the alarm. It was that turning it off had become a reflex I could do half-asleep, from bed, without ever really waking up. So I built Mornio. The idea Mornio moves the off switch away from the bed. You pick a QR code or a household barcode (the back of a cereal box, a sticker on the bathroom mirror, the label on your coffee tin) and place it across the room. When the alarm goes off, the only way to stop it is to physically get up, walk over, and scan that exact code with your phone. If you try to silence it without scanning, the alarm comes back. And a few minutes after you scan, Mornio runs a second stay-awake check, because getting out of bed once doesn't mean you won't faceplant back into it. How it's built AlarmKit (iOS 26) for scheduling and the reliable, system-level ringing. This was the big unlock: a normal third-party app can't reliably ring like a real alarm, and AlarmKit finally makes that possible. The camera for scanning the QR code or barcode, matched against the specific code you registered the night before. Everything stays on-device. No account, no ads. The codes you pick never leave your phone. What I learned The hard part wasn't the scanning, it was trust. An alarm has exactly one job, and if it fails once, you delete it forever. Most of the work went into making the ringing bulletproof and making the "I dismissed it without really scanning" edge cases impossible to game while half-asleep. Try it, or tell me I'm wrong It's live on the App Store (iPhone, iOS 26.1+): https://apps.apple.com/app/id6780983853 Site: https://mornioapp.com I'd love feedback from other heavy sleepers or shift workers: Does scan-to-dismiss sound like it would actually get you up, or annoying enough you'd rage-delete it? If you've tried it: was the first-morning setup (placing a co

On our new Real World AI stage, we’ll be focusing on the intersection between the digital and physical, and all the ways we’ll continue to see a blending of the two.

I had been using Xcode for iOS development until one day I changed computers. Downloading Xcode took nearly two hours, and after unzipping, I found only 20GB left on the hard drive. Every major version update involved over ten gigabytes of downloads, plus Simulator and various iOS SDKs, so a 256GB Mac soon required cleaning up space. Later, a new teammate arrived with a Windows laptop and wanted to write iOS code, but the Mac configuration hadn't been approved yet. The threshold of iOS development being tied to Mac and Xcode is indeed not flexible for many scenarios. So I began to wonder: can iOS development be done without Xcode? Are there lighter alternatives? Several Alternative Paths Without Installing Xcode I first tried the approach of VS Code plus remote Mac compilation. Write code on Windows, connect to a remote Mac via SSH, and execute xcodebuild. The coding environment problem was solved, but the debugging phase is unavoidable—running on a real device requires Xcode to handle provisioning profiles and signing, so ultimately a Mac with full Xcode is still needed. Moreover, after each code change, the three steps of local editing, remote compilation, and syncing to the device made the workflow longer than developing directly in Xcode. I also tried the CI approach. Codemagic and GitHub Actions can automate build packaging, suitable for continuous integration before releases. However, frequent debugging and modifications during daily development—changing a line of code and running to see the result—cannot be pushed to CI every time and wait a few minutes. Its coverage is limited. I also considered AppCode, but it essentially still depends on Xcode's toolchain, and JetBrains has discontinued its maintenance. Another Approach: KXApp IDE KXApp has built the compilation toolchain into the IDE, allowing iOS applications to be compiled and signed without installing Xcode on the system. It uses VS Code as its editor layer, with shortcuts, interface layout, and plugin

Once, just to change an interface field, I spent nearly half an hour switching back and forth between several tools. The code was modified in VSCode. Because the project includes not only Swift but also Flutter modules and some script files. After making changes, I switched back to Xcode to compile, then the test package was handed over to an automation script, and finally I had to open another tool to upload. That day I suddenly realized something: many developers are actually no longer completely dependent on Xcode. To be more precise, it's not that they 'don't use Xcode,' but that the development workflow is being broken apart. Editors, compilers, build tools, and upload tools are each taking on different responsibilities. What many people really want to replace is not Xcode itself When discussing Xcode alternatives, we actually need to know what developers really want to replace. Xcode actually contains many parts: code editing, project management, compilation and building, simulator, on-device debugging, Archive, signing and distribution. Some people want to replace the editing experience, some want to reduce dependence on a full IDE, and others simply want to put different technology stacks into a unified workflow. Therefore, many current 'alternatives' are not complete replacements, but rather split some of these aspects. VSCode: The most common alternative Now more and more iOS developers use VSCode to write code. The reason is that many projects are no longer just native Swift; Flutter, Node services, Shell scripts, JSON configuration, and Web frontends may all be in the same repository. If everything is handled in one editor, the development context becomes more continuous. Swift plugins, Git plugins, and AI-assisted tools have also made VSCode increasingly used in iOS projects. However, it mostly replaces the 'editor' layer. When it comes to compilation and runtime, many projects still return to the Xcode toolchain. AppCode: Another route with a JetBrains

Our tool transcribes audio in the browser — Whisper running locally via transformers.js , no upload. It worked fine, until analytics showed something too clean to be a coincidence: .mov uploads on mobile failed 100% of the time. Not 90%. Every single one. Desktop had never reported a single .mov failure. This is what I found, and how it got fixed without pulling in ffmpeg.wasm or WebCodecs. The 30-second reproduction I took one AAC audio track and put it in two containers — same encoder, same bytes for the audio itself, only the wrapper differs: const buf = await file . arrayBuffer (); await new AudioContext (). decodeAudioData ( buf ); On an iPhone 17 Pro simulator (iOS 18.7 / Safari 26.5): File iOS Safari Chromium sample.mov (ftyp qt ) EncodingError: Decoding failed OK sample.mp4 (ftyp isom ) OK OK So it isn't the codec. It's the container. The obvious fix that doesn't work First instinct: it's the brand in the ftyp box. Patch qt → isom , four bytes, done. It still fails. I'm writing this down so nobody else burns an afternoon on it. The ftyp brand is not what Safari looks at. The difference lives inside moov . The actual root cause Dig down to moov → trak → mdia → minf → stbl → stsd — the sample description that tells the decoder how the audio is encoded. Both files carry an mp4a entry. They are not the same mp4a entry: QuickTime writes: MP4 expects: version = 1 <— version = 0 compressionID = -2 (fffe) <— compressionID = 0 + 16 bytes of v1 extension <— (absent) esds wrapped in a 'wave' box <— esds is a direct child extra 'chan' channel layout (absent) iOS Safari's decodeAudioData only accepts a version 0 audio sample entry. Chromium accepts both — which is exactly why desktop never saw this and mobile never survived it. That version field is a uint16 . Two bytes decide whether the file plays. The fix: rebuild the container, don't touch the codec Since the audio bitstream is already valid AAC, nothing needs to be re-encoded. The job is pure byte plumbing: extract

Getting a rejection email from App Review feels personal. It usually isn't. Apple runs the same review process against every submission, and most rejections trace back to a small number of guidelines that come up again and again. Knowing which ones, and what they actually mean, turns a vague rejection into a fixable checklist. How often this actually happens Apple's own 2024 App Store Transparency Report puts real numbers on this. Out of 7.77 million app submissions reviewed that year, 1.93 million were rejected, roughly 25%. Of those, 295,109 were fixed and approved on resubmission. Separately, 82,509 already-live apps were removed after the fact, most commonly for guideline or design violations (42,252), followed by fraud (38,315). Apple hasn't published a breakdown of rejections by specific guideline number, so treat any listicle claiming "62% of rejections are X" as unsourced. What Apple has said, in its own commentary alongside the report, is that the most common drivers, in order, are performance and bugs, legal issues, design problems, business-model (payment) violations, and safety risks. That ordering lines up with the specific guidelines below. The guidelines that actually catch people These are pulled directly from Apple's current App Store Review Guidelines, not paraphrased from a third party. Guideline 2.1, App Completeness. Covers crashes, obvious bugs, placeholder content, broken demo accounts, and non-functional in-app purchases. If a reviewer can't get past your login screen or your app crashes on launch, this is the line it gets cited under. It's the single most avoidable category, because it's the one you can actually test yourself before submitting. Guideline 4.2, Minimum Functionality. Your app has to be more than "a repackaged website." Apple wants "lasting entertainment value or adequate utility." A thin wrapper around a web view, with no native functionality added, gets flagged here. A sub-clause, 4.2.6, specifically targets apps built from c

Transferring files and data across platforms is more straightforward than ever.

An AI agent phone is a real, or cloud-hosted, smartphone that an LLM-powered agent can operate on its own. It sees the screen, taps, swipes, types, opens apps, and completes multi-step tasks the same way a person would. Instead of calling an API, the agent uses the phone directly, the same Instagram, banking, or delivery app you'd use, driven by a model instead of a thumb. The phrase gets used two ways in 2026. Some products sell phone numbers for AI agents, voice and SMS. That's not this. Here, an AI agent phone means the device itself as something an agent controls, a full Android or iOS handset that becomes an autonomous actor. If you've heard the pitch give your AI agent a phone, this is it. Why a phone, not a browser? Most agent tooling lives in the browser, or in desktop computer use. That misses where people actually are. The world is mobile-first, and a huge share of real workflows are app-only, ride-hailing, food delivery, mobile banking, two-factor prompts, creator tools, regional super-apps. A browser agent can't install an APK, respond to a push notification, read an SMS one-time code, use the camera, or drive a native app that never ships a web build. A phone can. And there's a second reason: fidelity. When an agent operates the same app a customer uses, you're automating the real thing, not a mock, not some undocumented internal endpoint that breaks next release. How it works A mobile AI agent runs a perception-decision-action (PDA) loop against the device. The agent builds its understanding from two sources. First, the accessibility tree, the structured hierarchy of on-screen elements the OS exposes for screen readers, which gives precise, machine-readable targets. Second, vision, a screenshot passed to a multimodal model for anything the tree misses, canvas UIs, games, custom widgets. Together, the tree gives coordinates and vision gives context. The agent gets a goal in natural language, reasons about the current screen, picks the next action, and e

Turning an iOS app into a React web app is no longer the hard part. Modern coding agents can generate a convincing first version quickly. The hard part is answering three less glamorous questions: Did we discover every important screen and state? Did the generated app preserve the source behavior and data? Is the result actually close to the native UI, or does it merely look plausible? I built Grounded iOS-to-Web Harness to make those questions auditable. 🔗 GitHub: https://github.com/tiezhu0415/grounded-ios-to-web-harness What it is Grounded iOS-to-Web Harness is an experimental, lightweight grounding + verification layer for migrating iOS apps into complete, interactive, mobile-sized WebApps. Claude Code remains the primary implementer. The Harness does not prescribe the React component tree, choose a state-management library, or replace the coding agent. Instead, it establishes source facts and verifies the result against evidence from the original app. iOS source + Assets + code graph + runtime states ↓ locked source facts ↓ per-screen implementation context ↓ agent builds the React WebApp ↓ coverage + truth + behavior + critical VRT ↓ bounded repair, then human review Why prompt-only migration is not enough A prompt such as “convert this iOS app to React” can produce a good demo. But on longer tasks, an agent may miss screens, implement only one state, invent data or assets, choose navigation that differs from iOS, forget earlier facts, or optimize a screenshot while breaking real interaction. This project treats the iOS source and Assets as the truth for content and behavior, while runtime screenshots provide evidence for what the result should look like. The pipeline 1. Discover and reconcile source facts Static source inspection, codebase-memory, and necessary iOS runtime exploration are combined into machine-readable facts for screens, UI states, actions, navigation outcomes, cross-screen flows, real data and asset origins, and source confidence. Facts are l

If you are building an iOS app with Kotlin Multiplatform (KMP) or Compose Multiplatform, you might have opened your generated Shared.h header at some point and wondered why it is 20,000+ lines long. I ran into this recently while optimizing one of my personal KMP apps. I kept seeing Objective-C classes generated for every single theme color, dimension constant, and internal state model, even though my Swift code never touched any of them. To get a clear picture of what was actually going on, I built a small Gradle plugin called kmprofiler . It parses the generated Objective-C header, scans your Swift source files, and highlights which exported declarations have zero call sites in Swift. The numbers on my app caught me off guard, but cleaning it up took just a few minutes. Why does Kotlin/Native export so much? In Kotlin, declarations are public by default. When targeting iOS, the Kotlin/Native compiler looks at every public class, top-level function, and property in your shared module and creates an Objective-C class interface and runtime method trampolines in the framework binary. The compiler cannot dead-strip these automatically because Objective-C relies on dynamic dispatch. It has to assume Swift or Objective-C could call them at runtime. If your UI is built with Compose Multiplatform or your Swift app only interacts with a couple of high-level bridge interfaces, most of those exported Objective-C wrappers end up being dead weight. The Audit: 459 Exports, 282 Unused When I ran kmprofiler on my app (Framed), it gave me this breakdown: ### 📊 KMP iOS Export Profile Export surface: 459 Kotlin declarations exported to Objective-C. No direct Swift call site found for 282 of them (61.4% uncalled). The unused exports mostly fell into three buckets: File Facades ( *Kt classes): Top-level properties in files like Dimens.kt (38 spacing constants) or Color.kt generated synthetic Objective-C classes like DimensKt with static getters for every single constant. Internal UI St

From halting my doomscrolls to automating air-quality checks, Apple’s streamlined Shortcuts app is my favorite iOS 27 feature.

An iOS app can feel slow even when its interface looks well-designed and responsive. The problem may not always be the UI or the code running on the device. Often, the real issues are hidden in network requests, API responses, WebSocket connections, and background activity. For developers, finding these problems requires visibility into what is happening behind the screen. This is where Owlse , a network inspection and debugging tool for iOS and macOS developers, can help. 1. What Actually Makes an iOS App Feel Slow? Several hidden network issues can affect an app's performance: Slow API responses Too many network requests Large data payloads Connection delays Failed or repeated requests Background network activity A user may simply see a loading screen or delayed response, while several network operations are happening in the background. Understanding these operations is the first step toward finding the actual cause of the problem. 2. Why Traditional Debugging Can Make These Issues Hard to Find Network-related problems are not always easy to identify through standard debugging. Developers may need to switch between different tools to inspect requests, analyze timing, investigate WebSockets, and understand application issues. When an app generates hundreds of requests, finding one problematic request can also take considerable time. Without a clear view of network activity, developers often have to rely on assumptions. A dedicated network debugging workflow can make this process much easier. 3. Meet Owlse: Network Debugging for iOS & macOS Owlse is built to give iOS and macOS developers greater visibility into their application's network activity. Instead of treating network behavior as something happening in the background, Owlse helps developers inspect and understand it. With features including live request streaming, request inspection, timing analysis, WebSocket inspection, mocking, crash reporting, search, HAR export, and timeline debugging, Owlse brings impo

"I will tear apart this forest and bring back what it took from me."

Sonos released an update to its mobile app that finally introduces support for iOS' Live Activities, giving iPhone users quick access to playback controls on their lockscreen. The added functionality is a "much requested, anticipated, and needed feature," according to a post Sonos shared to Reddit today that was spotted by 9to5Mac. While some features […]

Cloud-based AI has two persistent problems for mobile developers: latency, because every inference call is a round trip to a server, and privacy, because user data has to leave the device to be processed. By 2026, Apple has shipped enough of a native stack that bypassing the cloud entirely — architecting genuinely autonomous agents that run inference, reasoning, and action selection directly on-device — has moved from a theoretical exercise to a practical, documented architecture pattern. Why Local-First Is the 2026 Competitive Edge The clearest signal of how seriously Apple is treating this shift arrived at WWDC 2026 with Core AI, a new OS-level framework built directly into Apple Silicon. Core AI allows developers to load, specialize, and run AI models entirely on-device — including local language models up to 70 billion parameters — with zero server dependency and zero token cost. Models are automatically specialized for the hardware they run on, with ahead-of-time compilation support for fast load times. That's a meaningfully different proposition than earlier on-device AI efforts: it's Apple positioning local inference as genuinely competitive with cloud-scale models, not just a lightweight fallback for when connectivity is poor. The Three-Piece Agent SDK As of 2026, Apple effectively ships three developer-facing pieces that together form something close to a full AI agent SDK. The Foundation Models framework handles on-device inference — direct, programmatic access to the same large language model that powers Apple Intelligence itself, running on the device's Neural Engine rather than through a wrapped cloud API. App Intents exposes an app's actual capabilities to that intelligence, acting as the action layer an agent can call into. Private Cloud Compute (PCC) handles the cases that genuinely exceed on-device capacity, providing a scale fallback rather than a default path. The on-device model handles reasoning, App Intents handles action, and PCC handles scale

App Review rejected my iOS app under Guideline 2.1. The note said reviewers were unable to locate the App Tracking Transparency permission request when they tested the build. The prompt worked on my iPhone. Every single launch. It just didn't work on theirs. The cause turned out to be two properties of the ATT API that are easy to miss individually and genuinely nasty in combination: together they produce a bug that is invisible on a fast device and completely reproducible on a slow one. Your test device is fast. The reviewer's device is not necessarily. This post is the root cause, the fix I shipped, and the list of other things that silently suppress the prompt. The two facts that explain everything 1. iOS only presents the ATT prompt while your app is active Apple's documentation for requestTrackingAuthorization(completionHandler:) states, for iOS 15 and later: "Calls to the API only prompt when the application state is UIApplicationStateActive." That's UIApplication.State.active — not merely "in the foreground," and not "the code is running." During launch there is a window where your JS/UI is already executing but the app is still inactive : splash screen dismissal, the first render, a modal transition animating in or out. Call the API in that window and iOS declines to present. 2. When iOS declines to present, you don't get an error You get notDetermined back ( undetermined in expo-tracking-transparency ) — which is the exact same value you get when the user simply hasn't answered yet. There is no "I couldn't show it" signal. There is no thrown error. There is no presented: false flag. From the return value alone, "the user hasn't decided yet" and "iOS silently no-op'd your request" are indistinguishable. That's the trap. The API looks like it succeeded. The bug I shipped Reduced to its essentials: // Called during startup, while the splash screen was still going away. const { status } = await requestTrackingPermissionsAsync (); const granted = status === ' gr

This is a submission for Weekend Challenge: Dog Days Edition What I Built Pawford...

"How much does it cost to put an app on the App Store" gets answered inconsistently online because most answers either only count Apple's fee, or only count hardware, or quietly assume you're renting expensive cloud infrastructure you don't actually need. Here's every cost, split into what's mandatory and what's a choice. Mandatory: Apple Developer Program — $99/year This is the one cost nobody can avoid. To submit any app to the App Store — free or paid, one app or fifty — you need an active Apple Developer Program membership, which is $99/year, billed annually, direct to Apple. There's no one-time version and no way around it. (There is a free-tier Apple ID for personal on-device testing without paying this, but it doesn't let you submit to TestFlight external testers or the App Store — for an actual public release, the $99/year membership is required.) Required, but where you have genuine choices: building and signing To submit a build, something has to run Xcode's command-line signing and archive tools — that part isn't optional. Where you have a choice is what runs it: Option Cost Recurring? Buy a Mac ~$799+ (Mac mini, entry price) No Rent a cloud Mac ~$20–100+/month Yes GitHub Actions, public repo $0 No GitHub Actions, private repo $0 up to a monthly allowance, then per-minute Only if you exceed the free allowance The short version on that last row: on a public repo, this line item can legitimately be $0, indefinitely. Optional or one-time: the things people assume cost more than they do App Store screenshots and marketing assets. You can generate these yourself for free — from the Simulator or a physical device — no paid tooling required. A physical iPhone for testing. Not strictly required to submit, but you'll want one to sanity-check the finished app before release. TestFlight itself. Free, included in the $99/year membership. App Store listing itself. Free — no fee to list an app beyond the membership. Adding it up For someone shipping a side project on a