Apple's Walled Garden, Claude Code, and the Future of AI Editors

Tim Williams: Hello and welcome to a fresh episode of the Rubber Duck Radio, ringing in the new year with Paul Mason once again at my side. Tim Williams: I am the venerable host, Tim Williams, and today I'm frustrated. Hopefully this one doesn't go into a full blown rant, but I apologize if it does. Tim Williams: Anyway, Paul, how are you sir, and how was your holiday break? Paul Mason: Hey Tim, great to be back again to kick off 2026, we talked a little before the show, but why not dive right in? What's got you bothered? Tim Williams: Apple and their frustrating governance for App Store submissions. Paul Mason: Oh yeah? I didn't realize you were working on something new. Tim Williams: Yeah, over the break with my time off from my main gig I spent a bunch of time dialing in one of my pet projects "Falconry Journal Pro" Paul Mason: Oh yeah! You have spoken about that one, what happened? Tim Williams: I submitted it, and have had it rejected twice now. Paul Mason: What?! Tim Williams: Yeah. Do you remember the Epic Games v. Apple lawsuit in which Apple was force to loosen their rules around forcing revenue through the App Store? Paul Mason: Vaguely Tim Williams: Well, I thought I had read through their current policies, but apparently I missed how they are getting around the spirit of that lawsuit. Tim Williams: To summarize, In 2020, Epic Games sued Apple after deliberately adding its own payment system to Fortnite on iPhones to avoid Apple's standard in-app purchase fees, which led Apple to remove Fortnite from the App Store. Tim Williams: Epic claimed Apple's rules,like forcing apps to use Apple's payment system and taking up to a 30% cut,were unfair and anticompetitive. Tim Williams: Apple counter-sued, saying Epic knowingly broke its contract to trigger a legal fight. Tim Williams: A 2021 trial mostly sided with Apple, ruling Epic violated its agreement and rejecting most of Epic's antitrust claims, Tim Williams: but did find Apple's "anti-steering" rules (which stopped apps from mentioning outside payment options) unlawful. Tim Williams: Apple was ordered to let developers link to alternative payment methods, though it initially tried to keep taking fees from those payments. Tim Williams: Appeals largely upheld the ruling, and the U.S. Supreme Court declined to review it, leaving Apple in control of its App Store but with new requirements around external payment links. Tim Williams: To me this means the courts basically ruled due to Apple's market dominance that if developers create apps where subscriptions were managed off platform, they couldn't force their thirty percent cut. Paul Mason: Seems reasonable, so what happened? Tim Williams: Ok, so I built "Falconry Journal Pro" with this exact model in mind. I would link out to an external subscription service to manage my users subscription payments. Tim Williams: My market is extremely niche, so this application isn't ever going to be a huge revenue generator, each iteration of it is designed to pay for its own operating costs. Paul Mason: So how did Apple force the issue? Tim Williams: Here's what they're doing to force it. First, instead of opening up the marketplace so that applications can be deployed globally that have externally managed subscription services, their compliance with the judge has be applied to ONLY United States App Store listings. Paul Mason: Ooooh, not good Tim Williams: So this means, you have to make the choice: do I restrict distribution of my app to the United States and lose out on a massive set of markets? Or do I bite the bullet and spend all of the time and money to integrate both subscription management options. Paul Mason: Right, and for a niche market, it's hard to justify spending that kind of development effort. Tim Williams: Exactly, but that's not all. If you are offering subscription services within the app through this methodology, Apple's policy (and I think this is the biggest violation) is to force you to provide BOTH methods of subscription. Paul Mason: So you're saying even if you stick to the United States as your ONLY market, Apple is forcing you into providing both solutions? That does seem like a direct violation of the ruling. Tim Williams: Exactly right. Effectively, you cannot monetize in a native application unless you implement Apple's In App Purchases. This means Apple is forcing their cut whether you comply with the spirit of the ruling or not. Paul Mason: They're basically lawyering their way around the ruling with obtuse implementation requirements. I can see why you would be mad about this. This is crazy. Tim Williams: Yeah, so here's the first time this happened; after my second App Store rejection I got an actual CALL from Apple. A real person who apparently was the person who implemented the department and policies around app approval. Paul Mason: Wow, I didn't realize they did that. Tim Williams: To me, this makes me think that they know the policy is in violation of the lawsuit, and the call was an intimidation call. Paul Mason: So how did the call go? Were you right? Tim Williams: I think so. The call basically revolved around reinforcing their decision to reject the application and then explain the guidelines extensively. Tim Williams: He was nice, and I appreciate that, but this doesn't change the fact that they are forcing me to either give up on the project or spend a lot more development time and lose out on an additional 30%. Paul Mason: I can see why you're frustrated. A single developer can hardly go up against Apple and its legal teams. Did you think about reaching out to the Judge Rogers? Tim Williams: The thought has crossed my mind, but I can't imagine supporting the continued fight for a single developer is, from her perspective, going to be worth her time. Paul Mason: You never know until you try, right? Tim Williams: True. I am keeping the option in the back of my pocket, but I don't think I can reasonably wait until all of that plays out to get this app to market. The revenue (basically zero) doesn't justify that kind of effort. Paul Mason: So are you going to implement Apple In App Purchases? Tim Williams: I basically have to. I don't see another way around it. This is precisely what Apple's hoping, but the profit they're going to make off me is so paltry. I wish they at least had some sort of minimum threshold before they impose their extortion fee. Paul Mason: right, right. That would at least solve the issue of pissing off thousands of small development shops and alienating people who are developing applications that enrich their ecosystem. Tim Williams: I think it would. At least if they had a minimum threshold I seriously doubt me and my tiny audience would hit it. Now I have to decide if I'm going to pass on the extra costs to my users, or find some way to eat it. Paul Mason: that doesn't seem fair. Now, to lighten it up a bit, don't you wish Microsoft had been the winner back when smartphones were budding? Tim Williams: Not to disparage your employer, but I don't doubt Microsoft would play the same games. Granted, Microsoft has garnered a lot more goodwill from the developer community at large lately than Apple. Paul Mason: Microsoft has put out a TON of open source work that enriches the ecosystem for developers. But you're right, we'll never know exactly what their App Store presence would've been like. Tim Williams: Let's be optimistic and just give them the benefit of the doubt that at least they wouldn't be as bad as Apple with their walled garden policies and extortion fees. Paul Mason: Anyway, let's pivot. Back to the hot topic. I played with Claude Code a TON over the holiday break, have you had a chance to tinker with it? Tim Williams: I have, nothing super serious yet, but I spun it up on my computer to evaluate it on some small parallel tasks. I'm impressed so far, but I can see some limitations. Paul Mason: So here's what I think is better about Claude Code than Cursor. Claude's tool calling functionality seems to fail a lot less. One of my gripes with Cursor is that a lot of my token costs are burned up on failed tool calls. Tim Williams: Yes, same gripe. Paul Mason: I think this is because Claude has the advantage of training their models alongside the team implementing the Claude Code tools, meaning their datasets, testing loops and training are all within the same realm. This give them a particularly solid advantage. Tim Williams: Exactly, and Anthropic has been focused on the dev space primarily all this time. They have an advantage. Paul Mason: Opus is truly the strongest offering in the AI software development space whether you are a true engineer or vibe coder. Tim Williams: absolutely agreed. Opus is magnificent. I wish Anthropic would put out something open source that's competitive with GPT OSS 120B. As far as local open source models go, that thing is a beast. Paul Mason: I still haven't played a ton with local models, what do you use that for when you have subscriptions to basically every AI provider? Tim Williams: Anything that even has a whiff of private information in it I am extremely careful. I coach my developers and preach about AI security practices, so I uphold them to the best of my ability myself. Tim Williams: Some specific examples are; if I want to reply to an email chain and I want help rewording it, and help making sure I'm not missing key points I'll do that all locally on my machine with GPT OSS 120 B. Tim Williams: And I have to say, for purposes like this, it's absolutely just as capable as ChatGPT or Gemini. Paul Mason: Interesting, I guess that part of my daily workflow hasn't touched AI much. I prefer to craft that stuff by hand. Tim Williams: Don't get me wrong, I only use it to help me rephrase and sharpen clarity, I do not let it speak for me. Just like with my code I use it as a tool to refine what I want, not create it. Paul Mason: That philosophy makes sense, but I'm still going to bang out emails by hand. I don't see that changing in the near future. Tim Williams: Fair enough. Funny tangential question; which one of us do you think deals with more email? Paul Mason: Oh, I see where you're going with this, ha ha. I guess my email workload isn't huge. Tim Williams: I win then. I need all the help I can get, but still I'm not willing to turn the reigns over to AI to do it for me, it just isn't good enough, and I don't see that changing. Tim Williams: So back to Claude Code, what did you build with it? Paul Mason: Yeah, actually. I decided to finally scratch an itch I've had for a while. I built a small internal dependency-mapping tool for one of our older services. Tim Williams: Oh nice, like a real one, not just a README diagram that's been lying to people for five years? Paul Mason: Exactly that. We've got this service that's been around forever, lots of tentacles, lots of "don't touch that" areas, and no one really knows which jobs, queues, and downstream services are actually coupled anymore. Tim Williams: The classic haunted house architecture. Paul Mason: Yep. So the goal was pretty simple: crawl the repo, inspect config files, job definitions, queues, environment flags, and spit out a dependency graph that was at least directionally correct. Tim Williams: That's a non-trivial problem, especially when half of the coupling lives in environment variables and tribal knowledge. Paul Mason: Exactly. And that's where Claude Code actually surprised me. I gave it a very scoped task,"analyze this repo, identify service boundaries, infer dependencies, and generate a machine-readable graph",and it stayed remarkably on task. Tim Williams: Interesting. So not just vibes, but actual structured output. Paul Mason: Yeah. JSON graph, nodes, edges, metadata about confidence levels. It even flagged areas where it wasn't sure and told me why,like, "this queue name appears in three places but isn't declared anywhere obvious." Tim Williams: That's huge. That's the kind of thing that normally lives in some senior engineer's head who's been there eight years. Paul Mason: Right. And to be clear, it wasn't right about everything. But it got me about 70–80% there in an afternoon, which is way faster than me spelunking through a decade of commits. Tim Williams: That's the sweet spot though. That's the "save your brain for the last 20%" use case. Paul Mason: Exactly. I still had to sanity-check it, correct a few assumptions, and fill in the gaps,but I wasn't starting from zero. And importantly, it didn't constantly blow up trying to call tools that didn't exist. Tim Williams: Yeah, that tracks with what you said earlier. Cursor sometimes feels like it's rolling the dice every time it reaches for a tool. Paul Mason: With Claude Code, the failure rate was noticeably lower. When it didn't know something, it asked. When it made an assumption, it told me. That alone saved a ton of token churn. Tim Williams: That's honestly the difference between something you tolerate and something you trust. Paul Mason: Exactly. I still wouldn't hand it the keys to production, but as a co-pilot for archaeology work? That's where it shines. Tim Williams: That's a great example. And it reinforces something I keep coming back to,AI is incredible at accelerating understanding, but only if you already know what "understanding" is supposed to look like. Paul Mason: Yep. If you don't know when it's wrong, you're in trouble. Tim Williams: And that, folks, is why senior engineers aren't getting replaced anytime soon. Tim Williams: So this actually brings us to the real tension between Cursor and Claude Code, which isn't really about model quality at all,it's about where each tool lives in your workflow. Paul Mason: Yeah, and this is where I think Claude Code has a real challenge. For all its strengths, it kind of screams "vibe coder's tool" to me. Tim Williams: Totally. And not because it's bad,because it's detached. It lives in the terminal. It's a TUI. It doesn't sit beside your code, it replaces your context with its own. Paul Mason: Exactly. When I'm in Claude Code, I'm not really "in my editor" anymore. I'm in this separate universe where the AI is the primary interface and my code is almost… secondary. Tim Williams: Which is wild, because historically the editor has always been the center of gravity. Everything else,orbits that. Git, debuggers, linters, test runners,they all exist to support the code view. Paul Mason: And Claude flips that. The AI becomes the surface area, and the code becomes something you dip into when needed. Tim Williams: That's why it feels like a vibe coder tool. It's optimized for "tell me what you want and I'll go do it," not "I'm actively shaping this system line by line." Paul Mason: Compare that to Cursor, which,even as they push agents harder,still fundamentally lives inside the editor. Your code is always there. The AI is additive, not dominant. Tim Williams: Right. Cursor feels like an IDE with a very opinionated assistant bolted on. Claude Code feels like an AI product that happens to touch code. Paul Mason: And you can see Cursor struggling a bit with that identity shift. They're clearly trying to move developers toward agent-driven workflows,panels, sidebars, long-running tasks,but it sometimes feels like it's fighting the muscle memory of how developers actually work. Tim Williams: Yeah. Developers don't want their code hidden behind a chat log. We want the code front and center, and the AI to be contextual, not authoritative. Paul Mason: That's the key word,contextual. Cursor's superpower is that I can glance at the file, make a change myself, reject a suggestion, tweak it, re-run the agent,all without leaving my mental flow. Tim Williams: Whereas Claude Code asks you to fully surrender your flow. You're effectively saying, "You drive for a bit, I'll watch." Paul Mason: Which is great for certain tasks. Refactors, repo-wide analysis, dependency mapping,awesome. But for day-to-day engineering? It feels like wearing oven mitts. Tim Williams: That's a great analogy. Powerful, safe, but clumsy when you need precision. Paul Mason: And I think that's Claude's challenge going forward. If they want to win over senior engineers,not just vibe coders,they need to meet developers where they already live, not ask them to relocate their entire workflow to a terminal UI. Tim Williams: Because no matter how good the model is, if it obscures the code instead of illuminating it, it's always going to feel slightly… wrong. Paul Mason: Yep. Tools should disappear. The moment the tool becomes the star of the show, something's off. Tim Williams: And ironically, that's the exact same lesson we've learned over decades of IDE design,just now, we're relearning it with AI. Tim Williams: So if neither extreme really works,AI-as-the-driver on one side, and AI-as-a-chat-box duct-taped to an editor on the other,what does the ideal hybrid UI actually look like? Paul Mason: I think the first rule is simple: the code never leaves center stage. Ever. Tim Williams: Agreed. The editor is sacred ground. The moment your primary interaction surface stops being the code, you've lost most experienced developers. Paul Mason: Exactly. The AI should feel less like a co-pilot grabbing the yoke and more like… power steering. It amplifies what you're already doing without changing how you drive. Tim Williams: That's a great way to put it. The AI shouldn't obscure intent,it should surface options. Suggestions, diffs, implications, tradeoffs. Paul Mason: Right. Instead of "I changed these 37 files for you," it should be "here's what would change if we did X," with a confidence score and a preview. Tim Williams: And crucially, everything should be reversible and inspectable. No magic. No hidden state. Every action should map cleanly to a diff you can reason about. Paul Mason: That's where a lot of agent tools fall down today. They optimize for autonomy instead of trust. Senior engineers don't want autonomy,we want control with leverage. Tim Williams: Exactly. Give me the ability to zoom out when I want,repo-wide analysis, architectural insight,but snap me right back to the exact line of code that matters. Paul Mason: And the UI should respect intent switching. Sometimes I'm exploring. Sometimes I'm executing. Sometimes I'm debugging. The AI should know which mode I'm in,or at least make it dead simple for me to tell it. Tim Williams: That's huge. Exploration mode can tolerate speculation. Execution mode cannot. Mixing those is how you get hallucinated production bugs. Paul Mason: Another thing I think is missing: long-lived, local context. Not chat history,working memory. "This is the style of this repo. These files are fragile. This subsystem is off-limits." Tim Williams: Yeah. Almost like a per-project constitution the AI has to follow. Paul Mason: Exactly. And it should be visible. Editable. Versioned. If the AI messes up, I want to know whether it violated a rule or whether I never wrote the rule down. Tim Williams: That's the difference between a tool you grow with and a tool you constantly fight. Paul Mason: And finally,and this is probably the hardest part,the AI needs to know when not to help. Tim Williams: Oh man, yes. The highest signal feature would be an assistant that says, "This change is small enough that you'll be faster doing it yourself." Paul Mason: Or, "I don't have enough confidence here. Let's step through it together." Tim Williams: That's when it stops feeling like a gimmick and starts feeling like craftsmanship. Paul Mason: Exactly. The ideal hybrid UI doesn't replace the developer. It sharpens them. Tim Williams: And ironically, that's how you actually win over senior engineers,by respecting their judgment instead of trying to automate it away. Tim Williams: So if we project this forward a bit, I think the interesting question isn't "who wins, Cursor or Claude," but where they're inevitably going to meet. Paul Mason: Yeah, because neither of them can stay where they are and keep serious developers happy. Tim Williams: Exactly. Cursor can't keep pushing agent-first workflows without risking alienating the very people who like it because it feels like a real editor. Paul Mason: And Claude can't stay terminal-first forever if they want to move beyond power users and vibe coders who are comfortable living in a TUI. Tim Williams: My bet is that they converge on the same shape from opposite directions. Paul Mason: Cursor will pull back slightly,less "let me do everything for you," more "here's scoped, inspectable leverage inside your existing flow." Tim Williams: And Claude will move toward the editor. Not necessarily by building a full IDE, but by embedding itself where code already lives,files, diffs, test output, PRs. Paul Mason: Yeah. Claude's biggest advantage is reliability and reasoning. The moment that's available inline, without hijacking your workflow, it becomes a completely different tool. Tim Williams: I also think both of them will be forced to get serious about modes. Exploration, execution, refactor, review,explicit states, not vibes. Paul Mason: Because that's how you earn trust. You don't surprise developers. You tell them what kind of help you're about to provide. Tim Williams: And I think agents will survive,but they'll become quieter. Less "look what I did," more "here's what changed and why." Paul Mason: Tools that brag don't last. Tools that disappear do. Tim Williams: Exactly. The endgame isn't an AI that writes your software. It's an AI that makes you more you as a developer. Paul Mason: And the moment either Cursor or Claude forgets that, the other one will eat their lunch. Tim Williams: That feels like a good place to land it. Paul Mason: Agreed. If 2025 was the year of AI novelty in dev tools, 2026 is going to be the year of restraint. Tim Williams: And honestly, that's a good thing. Paul Mason: Yeah. Less magic. More craftsmanship. Paul Mason: On that note, thanks for tuning in to Rubber Duck Radio. If you liked this episode, or if you violently disagreed with us, we'd love to hear about it. Paul Mason: And if Apple rejected your app this week, Tim's DMs are open. Tim Williams: Misery loves company. We'll see you next time.