9 ms·

Building and shipping Mac and iOS apps without opening Xcode

555 points by speckx 4mo ago

Schiendelman 4mo ago
I've been using essentially this process (with Claude Code) for about six months. There are a couple of places where I've opened xcode; mostly to update the simulators for new betas of xcode 27, and once to add a target for Apple Watch (and I think something for HealthKit). Interestingly, since about Opus 4.6, Claude has been able to reason its way into this process on its own. It was clunky until 4.7, and in 4.8 it's managed to find its way around every reason I had to open xcode myself.
Tiberium 4mo ago
It's kind of funny to be reading this: > I had Claude Code create mine: I told Claude, more or less: I want to archive, Developer ID-sign, notarize, staple, and install this app to /Applications without ever opening Xcode. Write me a script that does the whole chain and fails loudly if any step breaks. Even though the text we're reading is Claude talking to us as well :) Also it was weird to see the mention of "ask your LLM" at almost every stage in the blog post: > point Claude Code or your LLM coding tool of choice to this blog post, and let it figure it out > When in doubt, ask your LLM of choice about them and have it help you get set up. It’s the one that’s going to be using Xcode for you anyway. > The whole point of using the LLM in the first place is to avoid doing things manually that you don’t want to do. > Again, if in doubt, ask Claude Code or your LLM of choice to create this for you. > Again, this is why you talk to your LLM, tell it what you want, and have it help build your workflow.
- ryandrake 4mo ago
  Claude telling us to point Claude to a web site written by Claude so that we can use Claude to create a build environment...
  - ericol 4mo ago
    yo dawg
    - frollogaston 4mo ago
      Claudius Claudianus (aka Claudian)
    - natpalmer1776 4mo ago
      I heard you liked Claude, so I put extra Claude in your Claude so you can do more Claude.
      - lossyalgo 4mo ago
        I suppose it's easier to turn everyone into unwitting tokenmaxxers than it is to raise prices again.
      - deleted 4mo ago
        [deleted]
  - theParadox42 4mo ago
    … that Claude can use, because Claude can’t use the XCode gui very efficiently.
  - carimura 4mo ago
    "Claude was the only LLM to survive the LLM Wars."
  - throwaway613746 4mo ago
    [dead]
  - saw66 4mo ago
    I wrote the post myself. But thanks for assuming. :)
- quasarj 4mo ago
  The mistakes in the text made me doubt it was AI, but who knows, maybe it's doing that on purpose now
  - ImaCake 4mo ago
    It seems too concise to be AI. My (conscious) heuristic for AI writing is how much context is squeezed into a sentence. LLMs seem to be pretty bad at the kind of elegant compression of meaning humans can do when they have done a lot of writing practice. If I had to guess, I would say this is the human summarised conversation(s) with a bot.
    - saw66 4mo ago
      It wasn't Ai. It was me. I wrote it.
      - ImaCake 4mo ago
        Sorry if my speculation was bad! When I wrote it I meant it as a compliment. Raw LLM output is awful and really needs a human to "translate" the useful content to something worth reading.
  - saw66 4mo ago
    1) tell me what they were then, 2) It wasn't AI. It was me
- saw66 4mo ago
  Claude didn't write this post. I did.
  - jkmcf 4mo ago
    Like we need another reason not to write and publish!
- resonious 4mo ago
  "This is the part where you think/learn" and "this is the part where you just let the LLM figure it out" is a fine format for advice nowadays I think. I am getting a little tired of every single HN comment being about how the linked article is written by an LLM.
- hansvm 4mo ago
  > Even though the text we're reading is Claude talking to us as well :) I'm not getting that vibe from this one; I'd bet money on it at least being substantially human edited. What are the tells you're seeing?
sgt 4mo ago
Although this has been well known for years and documented.
- dylan604 4mo ago
  Yeah, but not only was this "on a computer" but "with an AI" so it's not the same at all. /s
LatencyKills 4mo ago
I spent seven years as a dev on the Xcode team and this is pretty much my exact workflow these days.
- sunnybeetroot 4mo ago
  Thank you for your service. Xcode gets a bad rap from developers but for beginners, it doesn’t overwhelm them, giving them a great entry experience into app development.
  - LatencyKills 4mo ago
    Thank you for your comment. Prior to Apple, I worked on the Visual Studio team for 10 years. Now that is a complex app now matter how experienced you are. ;-)
mrbombastic 4mo ago
This is cool but also makes me worried about the tendency with llms for all of us to make bespoke solutions rather than building a better community tool or extending an existing tool to solve the problem. fastlane exists to solve exactly this problem in the mobile space.
- ryandrake 4mo ago
  Also, shell scripts as part of a build are usually a little worrying. I'd at least want the build steps to be all integrated into my Makefile or CMakeLists.txt
- vl 4mo ago
  Bespoke solutions are better in many cases. They do exact things required for the project without taking extra dependency. Reducing dependencies is beneficial, because dependencies require management. So with llms economy of taking dependency shifted.
  - SoftTalker 4mo ago
    ... avoiding this problem: https://xkcd.com/974 https://xkcd.com/974
  - mrbombastic 4mo ago
    everything has tradeoffs, on the one hand you are right you have one less dependency, on the other hand the maintenance of said dependency is now on you. many times app store connect has changed some api and fixing our release process was a matter of updating fastlane because the community had already dealt with it, that's on you if you have a bespoke delivery solution.
- doug_durham 4mo ago
  The llm is the better community tool. The important change is that you don't have to settle with someone developing a monolithic tool that happens to do what you need it to do. That was the way things used to need to be done because of the cost.
recsv-heredoc 4mo ago
Having to have Xcode installed is more than half the problem. It makes Visual Studio look lightweight.
- ryandrake 4mo ago
  Xcode does have (or had, haven't checked for a while) a lightweight "command line tools only" installer. Unfortunately, that installer omits a lot of the actual useful command line tools, like the notary and stapler tools. I also recall that the command line tool only installer leaves out things like the metal compiler, too. Not sure what the point of it is.
  - dylan604 4mo ago
    > Not sure what the point of it is. My only familiarity with it is because it's needed by brew. I honestly never looked into exactly what is in the package, but I assumed things like what is installed with -devel packages of yum/apt-get/dnf/etc. Lots of repos have common list of things to install like gcc/make/etc. Again, just guessing, but it's one of the first things I've always run on a new Mac to get it usable for CLI usage.
  - saagarjha 4mo ago
    It lets you build basic UNIX-like tools.
- gumby 4mo ago
  It’s mostly all the emulators and platform APIs. I’m not defending Xcode (I hate it), just clarifying.
CharlesW 4mo ago
If it's okay to mention my own complementary open source project, Axiom¹ does a good job of helping coding harnesses know how to do this effectively for Apple OS development. In addition to a deep roster of skills and agencts, Axiom includes several for-LLM tools². xclog, xcprof, xcsym, and xcui are designed to be used by LLMs, and expose capabilities in a token-efficient way. These tools are equally helpful for non-Axiom skills/agents. ¹ Axiom: https://charleswiltgen.github.io/Axiom/ https://charleswiltgen.github.io/Axiom/ ² Axiom CLI tools: https://charleswiltgen.github.io/Axiom/tools/ https://charleswiltgen.github.io/Axiom/tools/
- semiquaver 4mo ago
  Axiom is excellent, thanks for making it!
  - CharlesW 4mo ago
    I'm glad that it's been valuable for you!
- zuzululu 4mo ago
  will it work with flutter ?
  - CharlesW 4mo ago
    Axiom covers only native APIs and tools, but the Flutter team maintains what looks like a nice set of skills at https://github.com/flutter/agent-plugins https://github.com/flutter/agent-plugins, and the Dart team at https://github.com/dart-lang/skills https://github.com/dart-lang/skills.
- lprd 4mo ago
  Silly question, but do you reckon it'll function decently in a Kotlin multiplatform codebase? There's swift native code, but I'm not sure how it would perform with some logic being shared.
  - 4mo ago
schainks 4mo ago
I just set up my pipeline to do this exact thing for both the Apple and Android ecosystems, dispatching loads to my mac studio or Linux box accordingly. I moved the runners off GitHub because uptime for GitHub actions has been trash lately, and the Apple Silicon runners are pricey. Claude was great at figuring out what was broken when and either fixing it, or clicking as far as it could until it needed me. You could say I'm mostly just IRL hands for the AI now.
hyperhello 4mo ago
Being outside of the approved development loop has rough edges. How do you keep the app from putting up that permission to access documents folder all the time while you rebuild it?
- saagarjha 4mo ago
  They're a paid developer, so they are probably signing the app with a stable identity that avoids this.
rvz 4mo ago
By using "Claude Code"* * and giving Anthropic all your secrets, env vars, certificates and your source code to them.
- kstenerud 4mo ago
  Not if you've got a good sandbox.
  - saagarjha 4mo ago
    Do you have one?
    - kstenerud 4mo ago
      Yup, I built one! https://github.com/kstenerud/yoloai https://github.com/kstenerud/yoloai You can even run simulators in it if you choose the Tart backend.
      - thoughtl3ss 4mo ago
        And how is your vibe coded sandbox better than 1000 other sandboxes?
        kstenerud 4mo ago
        You'll never know. And that's fine.
- simonw 4mo ago
  What bad things to you anticipate Anthropic doing with your secrets, env vars, and certificates?
  - owebmaster 4mo ago
    Is this a joke? Anthropic isn't great at keeping stuff private as we saw with the Claude Code leak. The more information they get access to the bigger the risk.
stephenhuey 4mo ago
Thought this was going to be about the new Ruby Native! https://rubynative.com https://rubynative.com “From bundle install to your phone in minutes. To the App Store and Google Play without a line of native code.“
- zuzululu 4mo ago
  holy hell $299/app is wild
  - incanus77 4mo ago
    One time?! That's amazing.
    - stephenhuey 4mo ago
      Per year, but still amazing. I'd like to think of myself who knows what he is doing, but I just launched a Rails-based platform for a client on web, iOS and Android, and had to spend an annoying amount of time in Google Play and App Store Connect. $299 would be a tiny fraction of the billable hours I'd have to spend messing around in there, and that's not counting mobile app dev time at all, so I'm on the lookout for a good candidate project to try Ruby Native on!
    - chrisweekly 4mo ago
      per app per year
saagarjha 4mo ago
Making your app buildable from the CLI is not something I do personally to use on my Mac but it is very useful when you're automating your CI. If you have GitHub Actions set up to build your app, so can Claude, assuming you have the right signing setup on your machine.
pupppet 4mo ago
Doesn't that mean you need to distribute the app (TestFlight) before you can preview your app? How do you test locally without the simulators?
- simonw 4mo ago
  For a macOS app you don't need a simulator. For an iPhone app I've seen Claude Code launch the simulator without me needing to open Xcode.
  - nwienert 4mo ago
    I built an iOS simulator simulator, though only for RN. Runs in browser but covers 100% of the API of RN, iOS UI, and the top 1k native libraries basically now. Been an ongoing agentic experiment of mine that's about ready to release. Kind of fun, you can develop iOS and Android both without a build step and without a Mac even.
- turtlebits 4mo ago
  Testing != Distribution. You can run directly on a connected iOS device, without setting up anything related to the app store.
overgard 4mo ago
Oh god, the app store does not need more slop. If you can't be bothered to open XCode (which I agree is a dumpster fire, but), you shouldn't be bothered to submit an app that a person has to review and another person has to filter out of their search results.
- pclowes 4mo ago
  Counterpoint: XCode is such slop that an app made by a developer with the taste to avoid it has a higher probability of being less "sloppy" than average.
  - ulfw 4mo ago
    The 'developer' isn't even developing much of anything tho
  - saagarjha 4mo ago
    This is generally not true
  - overgard 4mo ago
    I don't know if that's really practical unless you're full-on-vibe coding or you avoid all the native frameworks. You kinda need XCode for a lot of things. I personally really dislike XCode after having to use it for like a decade and having it crash six times a day, so I feel people's pain in wanting to avoid it, but I also think slopping up the app store with vibe code monstrosities is not something that should be encouraged. Bad ideas are better made inconvenient..
exographicskip 4mo ago
Skimmed the article. Pretty close to my workflow using fastlane with tauri. Useful sanity check!
kxxx 4mo ago
I've been building and testing my iOS app just for fun via Linux only. Surprisingly, it's very easy. This works like a charm: https://github.com/xtool-org/xtool https://github.com/xtool-org/xtool You do not need to upload to TestFlight or the App Store; you can just install the app locally to your iPhone via usb -- even from Linux! When in doubt, just ask your coding agent of choice to help you create and upload a Hello World iOS app. It's really easy.
- sdicker 4mo ago
  I’ve been doing the same except that my linux installation is via WSL on Windows. I’ve been using sideloadly to move my IPA over to my phone. Works great.
- GaryBluto 4mo ago
  Does the iPhone need to remain tethered if it is transferred via USB?
  - drakythe 4mo ago
    Dev apps need to be re-loaded every week (or two?) last time I did sideloading. The idea behind a dev app, in Apple's mind, is that it is for limited testing, so they have an expiration when not signed/installed through the App store.
    - judge2020 4mo ago
      That is specifically for apps installed with a personal signing certificate, when you haven't paid for a developer account. If you pay the $99 program fee, you get 365 days of validity.
- amelius 4mo ago
  Do the coding agents know about this tool?
  - Yiin 4mo ago
hyzyla 4mo ago
Check also Sweetpad CLI. It’s basically wrapper around xcodebuild, but humans and agents. It’s my next project after Sweetpad VSCode extension for developing iOS/Swift applications in VSCode. Cli is still in beta, but I see on my own project that it’s already quite pleasant to use 1. https://sweetpad.hyzyla.dev/ https://sweetpad.hyzyla.dev/ 2. https://github.com/sweetpad-dev/sweetpad https://github.com/sweetpad-dev/sweetpad
tdhz77 4mo ago
I do something similar in GitHub actions. Every new app is setup in a few minutes to star getting rejected by iOS and Android.
josefrichter 4mo ago
Wait, I am not aware that I've done ANY of those setup steps, yet I'm building iOS and macOS apps without XCode. Both Claude and Codex handle it just fine and didn't ask me for any setup steps.
datadrivenangel 4mo ago
I've built a few small MacOS dock widgets now by just telling Claude/OpenCode to build them. Works well enough if you're very explicit. The most useful one is a little weather sparkline to show local temperature forecasts. Useful every day.
- esafak 4mo ago
  What framework was it written in, and does it trigger a scary warning from the OS when you try to install it?
mulmboy 4mo ago
I went to build an open source app from GitHub and was pretty surprised that it requires Xcode and that Xcode can't really be installed without an apple id. I do not want to make one and I certainly will not sign my computer into one. I did end up somehow installing Xcode via some shady download and was on my way. But the whole ordeal left a very sour taste.
- sneak 4mo ago
  Though the primary way of installing Xcode is via MAS (requiring Apple ID login), Xcode can be downloaded from the Apple Developer website without an ADP membership, though you do have to log in to the website with an Apple ID. You don’t have to log into the Mac with an Apple ID though, you can then install and use it on a Mac without an Apple ID (though you will need one inside Xcode to sign apps to get them to run on an iOS device).
- swiftcoder 4mo ago
  Running a Mac without an Apple ID feels like an exercise in masochism. I wasn’t aware one could even still it through first run without
  - xyzzy_plugh 4mo ago
    Why do you need one?
    - balder1991 4mo ago
      I think because the only places you can download it from are either from the App Store or logging into Apple’s developer’s website.
- everfrustrated 4mo ago
  Heck you can't even compile against many of the Mac APIs without a cert unlocked by a paid developer account.
murlax 4mo ago
Tangentially, I despise Xcode and love the Expo ecosystem and all the lovely tooling that they have built. It is React Native but Expo honestly makes it so trivial to build stuff from the CLI without ever needing to open that abomination of an app. And with AI, I have built a lot of side project apps onto my iPhone, like a homelab app for monitoring my cameras with push notifications whenever someone is at the door, starting my irrigation and a whole lot more. Plus Tailscale of course. Kind of a crazy world that we live in now.
- sefrost 4mo ago
  Yes, I remember React Native being quite painful before Expo! Upgrading from one version to the next especially so. Expo seems to shield you from a lot of issues, without really taking any power away from you either.
sneak 4mo ago
You still have to open Xcode (to get the certs), and you still have to accept the Xcode EULA. Title is quite misleading if not outright false.
- embedding-shape 4mo ago
  As someone who tried my very best to not open Xcode for building and shipping Mac and iOS apps, I agree, there are things there are literally no way around opening the GUI, not even terminal utilities for. You cannot do this 100% headless, which is what I attempted at first.
coverband 4mo ago
Regardless of the vibe coding aspect, there's good information here for anyone new to the mac/ios build/distribution workflows.
onesandofgrain 4mo ago
Don't make apps for iOS. The apple ecosystem is horrendous
mvkel 4mo ago
In my experience, the better long-term choice if you're going to vibe code an app is to use Expo. Its basis is React, so the code output quality is much higher than Swift because there is much more React code in LLM training data. Everything is in the command line, and debugging is a breeze because it's a web view. But once it's compiled to native iOS, it feels like any other native app. Expo + Fastlane = fully automated iOS submission and deployment. I issue one command and see a new version in the App Store.
- hetspookjee 4mo ago
  Some parts when creating a new app cannot be automated right? Eg registering the app itself for example.
  - fragmede 4mo ago
    You can have your AI agent use computer-use to click around on in a browser open on developer.apple.com if that's counts as automated to you.
- esafak 4mo ago
  This one?? https://expo.dev/ https://expo.dev/ Our code broke It looks like there was an error we need to look at. Sorry about the inconvenience.
  - cobbzilla 4mo ago
    HN hug of death? seems to be back now. fwiw, expo seems solid; the uptime of expo.dev won't affect an app built with it.
pzo 4mo ago
You can as well make it simpler and use those skills: https://github.com/software-mansion/argent https://github.com/software-mansion/argent or https://github.com/callstack/agent-device https://github.com/callstack/agent-device both callstack and swmansion are mostly react native shops but those should work even in native ios/android as well
isodev 4mo ago
In addition to the challenged Xcode, just using Swift seems to require a lot more tokens for both coding and dealing with build/platform quirks. Probably not super significant on indie scale but for anything more robust, it builds up quickly. React Native and Flutter seem to be much more predictable for the bots (and more fun for humans, since they have actual hot reload).
theraven 4mo ago
Interesting this is coming across as novel. This is how CI build machines for Apple’s platforms have been setup in perpetuity.
- frollogaston 4mo ago
  True, but it'd take me a while / forever to figure out how. Reminds me of when I yelled at Gemini until it'd make me a Minecraft Bukkit plugin without installing anything besides the JDK, way easier task but it was still insisting on Gradle for a while.
- matwood 4mo ago
  Not just build machines. Years ago I scripted the entire build process to create hundreds of apps based on parameters and submit them. It was an attempt to work around the horrible App Store search. The original app had packages of content that could be purchased, but it was hard to convey from the single app listing. Eventually Apple said don't do that and we reverted back, but at that point we had moved on to something completely different.
prakashrj 4mo ago
[dead]
martinbfine 4mo ago
[dead]
dools 4mo ago
Shout out to fastlane! I would have loved to have found it sooner in my app shipping journey.
VaporJournalAPP 4mo ago
[flagged]
grahar64 4mo ago
I thought this would be a flutter post. Love flutter, ... , well I like flutter compared to Kotlin and Swift
- busymom0 4mo ago
  Last I used flutter, editable text views was where it wasn't acceptable for me. On iOS, the default text view comes with a lot of built in stuff automatically such as cut copy paste, lookup definition, translate etc. Flutter's didn't have these.
ChrisMarshallNY 4mo ago
Technically, you are using Xcode. Xcode is a [buggy as hell] GUI wrapper for a lot of system-level UNIX utilities and apps [which are generally, not so buggy]. Using CLI to release apps is a pretty old practice; at least as long as I've been doing it (I released my first Xcode app in 2012).
- quasarj 4mo ago
  That's good to hear. I never even tried to make anything for macOS because I opened Xcode and.. well, you know.
  - ChrisMarshallNY 4mo ago
    Nah. I usually use Xcode GUI, but there's been a lot of discussion about using a CLI workflow, for many years. Should be easy to find. Hope you like long argument lists. xcodebuild has a crazy long parameter list. https://developer.apple.com/documentation/xcode/xcode-command-line-tool-reference https://developer.apple.com/documentation/xcode/xcode-comman...
    - jamesfinlayson 4mo ago
      From my experience the CLI works but is not well documented.
      - ChrisMarshallNY 4mo ago
        They rely on manpages, but using CLI tools is old enough, that there’s been plenty of online discussion on the practice. LLMs will often use CLI tools. In my experience, they loves their CLI.
    - 1vuio0pswjnm7 4mo ago
      Text-only, no Javascript https://developer.apple.com/tutorials/data/documentation/xcode/xcode-command-line-tool-reference.md https://developer.apple.com/tutorials/data/documentation/xco... 2011: https://manpagez.com/man/1/xcodebuild/ https://manpagez.com/man/1/xcodebuild/ 2016: https://keith.github.io/xcode-man-pages/xcodebuild.1.html https://keith.github.io/xcode-man-pages/xcodebuild.1.html Source code for xcodebuild not public ?
codazoda 4mo ago
One down-side to this is that it does require you to run the agent on your Mac instead of in a Sandbox. I do this too and there are lots of problems I can't solve in a sandbox. I know a lot of you are throwing your hands up at the years of security practices we're throwing out the window when we do that. The fact that xAI uploaded someone's home directory, including their SSH keys, is giving me serious pause at my choices here. Generally, I don't worry about my machine being "blown up". I don't have a TON of unreproducible stuff on my machine. Everything is backed up, committed to git, and the like. I can restore most of it in a couple hours. That said, I really, really don't want my .SSH directory sent to an AI agent and it's silly to prompt your way around that. You need to block it at the system level. I'm considering a separate user and then 700 permissions on my home directory. I feel like we're back to 1990's security here. The double-edged sword is that it's helping us get things done at a pace like never before. I'm not throwing shade here, I'm among the guilty.
- pianopatrick 4mo ago
  You could move your SSH keys onto a password encrypted usb drive that you physically remove from the computer.
  - wrxd 4mo ago
    An alternative is to use ssh keys stored in the Secure Enclave with tools like https://secretive.dev/ https://secretive.dev/
    - pianopatrick 4mo ago
      Seems to me a tool like that would stop the agent from sending those specific keys elsewhere. But a tool like that would not stop the agent who is acting as you from using the SSH keys via the CLI. You would want to combine that with other tactics like having the agent run as some other user.
      - samhclark 4mo ago
        Secretive (and the similar built-in functionality [1]) both allow you to require TouchID too. I found an okay balance using two SSH keys: one for commit signing (w/o TouchID) and one for everything else (requires TouchID, or PIN on Linux) So, the actions that I really don't want the agent to take (establishing an SSH connection, pushing to a git remote) always require my manual intervention. [1] https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb4acf https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb...
awaseem 4mo ago
I’ve done this forever on Foqos. Have a makefile, never even open Xcode and the instructions are in the agents md
tomaskafka 4mo ago
I find it hard to believe xcodegen is in a state where it would reliably generate xcodeproj for all edge states (widgets, watchos app, notification extensions …) - it certainly wasn’t when I last tried it for Weathergraph few years ago. That said, it might be well enough for simpler apps.
- tptacek 4mo ago
  What's a not-simple app? I've had Claude generate: * A Markdown viewer (obviously pretty simple) * A menu bar Apple TV remote (surprisingly complicated) * A menu bar and desktop temperature tracker for the silly Tapo temperature trackers I have all over my house (a little complicated because multiple user interfaces, a backing database, scheduling, and multiple local/remote protocol interfaces) * A graphical CAS calculator frontend to Sage Math with LaTeX math rendering * An LLMwiki implementation that uses macOS filesystem extensions to reflect a SQLite database into a local filesystem for agents to traverse (basically the new macOS way to do FUSE, fussy enough that the app has to run out of /Applications to work) * An agent-driven Music.app replacement with AirPlay streaming support managing Apple Music catalogs and tracks All of these have worked without me ever once touching the xcode UI, except one time to generate Apple Developer certificates, which I then drove exclusively from CLI tools. These are all pretty modern SwiftUI applications.
  - tomaskafka 4mo ago
    Afaik these are all single target apps. I was talking about extensions, watchos companion apps ...
waynecochran 4mo ago
The main iPhone app I maintain for work is 100% claude edited now ... I don't touch the code anymore ... I do occasionally look at it. It does a way better job than I could. I do have Xcode open as claude does its thing ... and I occasionally sign and deploy with Xcode. No coding though.
gwking 4mo ago
I have one weird trick for people who are exploring this vein. I last opened an Xcode project about five years ago so I could be way behind the times. Having spent many years fighting with Xcode professionally, I was thrilled when swift build came out, and then appalled at how badly Xcode adopted it. Eventually I realized that you can set up your entire app as a swift package, and then the Xcode project with a single main source file that calls some `app_main()` (or whatever you want to call it) function in your package. I cannot remember exactly but there was something annoying about setting up a new project; I think by default Xcode assumes that you want a swift package to be treated as a dependency that is checked out from git, but there was a way to drag and drop a local dependency in the same project directory and then it worked. What this buys you is that files are no longer tracked by Xcode, so renames/merges no longer trigger project.pbxproj surgery. Instead you specify the swift package directories and are done. I used this for some large personal projects and was very happy with it. At one point I also wrote my own build tool that imitated all of the steps that Xcode took so that I could truly be Xcode-free. That also worked (and was not even that hard) but I went back to Xcode because the debugger UI was better than what I could get out of VS Code at the time, and especially because I was playing around with the Metal debugger.
- andrekandre 4mo ago
  > set up your entire app as a swift package, and then the Xcode project with a single main source file that calls some `app_main()` this is basically how i do all apps nowadays (at home and at $work), all settings for the ios side of things is in a xcconfig file and keeps things simple and working with multiple people is much more a breeze this way
franze 4mo ago
built cable detective like this https://apps.apple.com/at/app/cable-detective/id6765963737?l=en-GB&mt=12 https://apps.apple.com/at/app/cable-detective/id6765963737?l... and the soon to come https://aifcc.franzai.com/ https://aifcc.franzai.com/ which is more ambitious honestly would not even know what to do / click in xcode
supermatt 4mo ago
> Without Ever Opening Xcode "Next, open Xcode"
zerr 4mo ago
The thing is, in a perspective, who would need any apps at all? Users will get what they want from AI directly.
philocalyst 4mo ago
Or use https://swiftbundler.dev/ https://swiftbundler.dev/ ?
WhitneyLand 4mo ago
Everyone will still need to use Xcode for at least some debugging, no way around that. As for the builds, your agent probably already knows how to do a lot of this from the command line, although explicit suggestions can help it build faster for different situations. As for XcodeGen, you may find it unnecessary overhead if you're already using Xcode file system synced groups. For iOS my biggest suggestion would be to enable App Store Connect skills for your agent (https://github.com/rorkai/App-Store-Connect-CLI https://github.com/rorkai/App-Store-Connect-CLI). With this not only do you not need Xcode all the time, you also don't even need to be near a MacBook. Just make changes via Codex on your iPhone, the tell asc to build and upload to TestFlight, download and run the new version, iterate.
- dostick 4mo ago
  There’s complete lldb debugging for Swift as plugin for VSCode.
- bobthebob 4mo ago
  I’m chiming in here to say I did pretty much build an entire iOS app with agents, and it launched it on the App Store for me, along with a social push. I only used Xcode to preview the builds on my device and then guide the prompts more
  - saw66 4mo ago
    Thank you. I don't understand why this is so controversial (and why everything thinks Claude wrote my post).
octavore 4mo ago
Shameless plug: I've been working on strudel [0], a CLI that uses a lot of the same ideas in this post and allows you to build/sign/notarize Mac (and iOS) apps without touching Xcode. It has a dry run mode so you can see the actual commands being run, which was important to me to have so there's no mystery about what's happening. I should blog about more this, but I also went to some effort to add support free iOS provisioning with just an Apple ID (using internal APIs); and creating a nice DMGs for macOS app distribution (reverse engineered .DS_store files for this). And there's also a built-in command to install skills for coding agents, which was fun. This [1] is an example app I built with it, a simple utility to manage macOS file extension handling. [0] https://github.com/octavore/strudel https://github.com/octavore/strudel [1] https://github.com/octavore/tots.app https://github.com/octavore/tots.app
- deleted 4mo ago
  [deleted]
myko 4mo ago
I prefer Tuist (writing Project.swift) to XcodeGen but otherwise, yeah, this tracks
zitterbewegung 4mo ago
Xcode 27 which is in beta ships a much better codex integration. There are problems in Xcode that are frustrating . Also, git integrations are a nice touch that allow you to force push too. Would be interesting to find out how well this works in a team based setting.
dvduval 4mo ago
What continues to bother me is just that developers who don’t have the budget are pretty much pushed out of iOS development because they can’t afford a Mac. And every time that Apple increases the price of their products, more people are blocked from being able to develop on them.
- geraneum 4mo ago
  People not having access to tech is bothersome, but nowadays Apple offers affordable machines compared to the same/worse specs from competitors. For example a MacBook Air with Apple Silicon and a moderate amount of memory.
  - MindSpunk 4mo ago
    Why should you need a Mac to build for iOS at all? What makes Apple so special here? Cross-compilation toolchains aren't forbidden alien technology. Forcing people onto Macs is such a pathetic way of extracting rent from developers and makes workflows worse. No you can't just build and debug your app from your Windows or Linux workstation because we want you to buy hardware you don't need. Sorry we only support Xcode on the latest version of MacOS, how else will your build machine roll out of the OS support window and make you replace a functioning machine? It's especially nice when you work on projects that aren't iOS/Apple native and you don't get Mac workstations. You end up with this wonderful mess of shared machines and half assed tools because you just need the bare minimum to push a build to a phone.
    - geraneum 4mo ago
      I don't disagree with you, but we're talking about affordability which is a different topic. > It's especially nice when you work on projects that aren't iOS/Apple native and you don't get Mac workstations. If you develop natively for macOS, then you probably need the OS for it. It's the same for Linux and Windows. But building is not the biggest hurdle because you can build in your usage-based-billed/free CI as well the same way you do for other platforms. For complete native development (system APIs, OS interactions, native UI) against macOS/iOS on PC, Apple needs to open those OSes for PCs/Pixels/Samsungs/etc. This is a software issue, not hardware. Otherwise Apple silicon Macs are less restrictive than PC hardware in general!
js2 4mo ago
> notarytool authenticates using a stored keychain profile that you create once, interactively — it prompts for an app-specific password, and there’s no way around the prompt. You can use `--password <password>` (yeah, yeah, passwords on the command line are bad; I'm just challenging "there's no way around the prompt.") Later (contradicting itself): > The one step that stays interactive is notarytool store-credentials, and that’s a choice rather than a limitation: you could pass --password and script it, but that means putting an app-specific password in your shell history. You can configure your shell to ignore history when needed. https://stackoverflow.com/questions/6475524/how-do-i-prevent-commands-from-showing-up-in-bash-history https://stackoverflow.com/questions/6475524/how-do-i-prevent... https://superuser.com/questions/352788/how-to-prevent-a-command-in-the-zshell-from-being-saved-into-history https://superuser.com/questions/352788/how-to-prevent-a-comm... (And if it's in a script, it won't be in your history anyway.) > These passwords go stale silently whenever you change your Apple ID password You can use an ASC API key instead. This can be either a team key ("developer" access level) or an individual key. https://developer.apple.com/documentation/appstoreconnectapi/creating-api-keys-for-app-store-connect-api https://developer.apple.com/documentation/appstoreconnectapi...
myHNAccount123 4mo ago
Xcode 27 beta 3 has been the most stable release I've ever used. The type checking improvements were understated so I gotta laugh at this xcode avoidance. Areas they could improve - what ever the heck is going on in their diffing ui for source control.
matthewmueller 4mo ago
Very cool! Does this assume you're never editing code by hand or can you use editors like VSCode or Cursor as well?
qpx2022 4mo ago
I use this script to build and notarize macOS apps, you might find it useful as well: https://github.com/muquit/NotarizeMacApp https://github.com/muquit/NotarizeMacApp
canthonytucci 4mo ago
If you’re paying the $100/year to publish to the store you also get access to Xcode cloud, which you can point at a repo and it will build snd archive for you to distribute to testflight. I opened xcode to test locally in simulator the first time but haven’t had to since. Using godot iOS export. For regular old native ios dev replacing Xcode i don’t think i would do it.
stevenhubertron 4mo ago
This is how i am developing keptrecipes.com. Been a pleasure this way TBH.
deleted 4mo ago
[deleted]
inopinatus 4mo ago
If you prefer your builds composed of declarative and incremental targets, see https://github.com/inopinatus/sublime_url/blob/main/Makefile https://github.com/inopinatus/sublime_url/blob/main/Makefile Same shit with a bit of structure.
21-DOT-DEV 4mo ago
The comments here clearly point out that building and shipping have been the automatable parts (and for some time now). To anyone who's chased a crash that only reproduces on a physical device knows the fix was never more log statements added by ai but rather a breakpoint, the debugger, and thirty unglamorous minutes of stepping through code line-by-line (terminal lldb technically counts, but barely).
samso26 4mo ago
[flagged]
aabajian 4mo ago
I shipped my iOS app without opening Xcode (well, I had to open it to get some provisioning stuff to work). I still use Visual Studio Code to kick off the simulator, but other than that, I use no IDE at all. Claude writes all the code in Flutter. IDEs are dead, prove me wrong.
bilekas 4mo ago
Honestly I thought this was the standard because god help me Xcode is terrible.
searls 4mo ago
I've been using agents to develop Mac and iOS apps for over a year now and I would say this post is bad advice, particularly because the excellent Xcode MCP requires Xcode to be running. The MCP tool gives you faster, better access to a number of functions for which xcodebuild is much slower and much chattier and a number of others (like the #Preview generation and rendering) that aren't possible at all while Xcode is closed. Also, in Xcode 27, the MCP & built-in agents are able to drive simulators with DeviceHub extremely well. (If you haven't been following, DeviceHub replaces Simulator.app and as far as I can tell, it's actually scrutable by agents without relying on hacking at the accessibility APIs with tools like axe.) Xcode MCP is not perfect, by any stretch (stupidly, it issues a permission prompt on every single agent launch—something I defeated with a Keyboard Maestro hack to auto-accept it), but Xcode 27 is such a huge leap forward in the ergonomics of vibe coding with Xcode that I've actually stopped dealing with the MCP and (after an afternoon of futzing) have started using the app's own agent UI for driving Codex because that harness better steers the model to take advantage of the tools available. All of this redounds to two things: faster feedback and more robust verification. The two things that matter most.
- dostick 4mo ago
  There’s Xcode-mcp-proxy that proxies Xcode’s mcp and adds clicking dialog and reconnects. How do you deal with macOS app testing? Do you use Peekaboo or plain screenshotting automation?
  - sunnybeetroot 4mo ago
    Can you link it? Quick google search didn’t reveal it
    - dostick 4mo ago
      Gave the wrong name, this is it- https://github.com/lynnswap/XcodeMCPKit https://github.com/lynnswap/XcodeMCPKit
      - sunnybeetroot 4mo ago
gnachman 4mo ago
Not using Xcode is the greatest improvement in quality of life I have known aside from recovering from a debilitating back injury. So good.
scosman 4mo ago
small issue: xcodebuild will just randomly fail sometimes. And the solution is to... open and close Xcode. I wish this wasn't true, but it is.
- notimetorelax 4mo ago
  Can LLM do this too? If yes, then it’s annoying but is not a blocker.
chrisvenum 4mo ago
React Native + Expo is also a good option if you want to touch the iOS/Android IDEs as little as possible. You use Xcode and Android studio to install the device sims and then expos tool chain handles the rest, even for deploying to stores. If you are on a windows computer and can’t install Xcode, you can even run your iOS app directly on an iPhone with their managed app. Ignite is a great starter using RN and Expo. Some great people maintaining it. https://github.com/infinitered/ignite https://github.com/infinitered/ignite
- alana314 4mo ago
  +1 for Expo, their Expo Application Services are great and have a free tier. npx expo run:ios --device #runs a build on my iphone and shows logs in the terminal eas build --platform ios --profile preview #builds in the cloud and gives me a QR code to install a build on my device with a custom certificate eas build --platform ios --profile production --auto-submit #auto increments and submits a production build to the app store.
mctwo 4mo ago
I don't see the point of this, if you use Claude or whatever frontier LLM you like, you need Xcode only to start emulators / install app on phones or to upload a binary.
landseer100 4mo ago
[dead]
NamlchakKhandro 4mo ago
Or use Gondolin, or SmolVMs
eptcyka 4mo ago
What about debugging?
resonious 4mo ago
This seems like a lot. I told my oh-my-pi agent to build my ios app for me and send it to me remotely. After some chugging, it gave me a tailscale funnel link. And it worked. I didn't have to dig into any of this stuff. I didn't use the words "Developer ID-sign", "notarize", or "staple" in my prompt.
pjmlp 4mo ago
The pain people go through not to use XCode, for me it does the job.
- eschaton 4mo ago
  It’s incredible to me the lengths these people will go to just to avoid using the standard tools.
  - andrekandre 4mo ago
    the path of most resistance... sometimes i wonder if apple's insistence on a mac + paid membership is a kind of intentional filter, like they want someone who's devoted enough to invest 100 bucks + a mac etc
qiaobax 4mo ago
[flagged]
jkwang 4mo ago
[flagged]
gen2brain 4mo ago
I have a nice setup on my Linux for iOS apps. I compiled the OSXCross toolchain, and also copied iPhoneOS.sdk and iPhoneSimulator.sdk from the macOS VM. With some wrappers, I can compile iOS apps (Obj-C) on my Linux machine, sign them with zsign, and use go-ios to install them on the device. At first, I just used simulator builds to test (and debug) on the macOS VM, in the simulator, but that was slow and painful. Finally, I bought a used iPhone, all bruised, just so I could test it on a real device. The main issue for me was signing, one cannot register a macOS VM (maybe with some kext hacks?), I managed to enable developer mode on the phone (crazy process, but it worked with Xcode in a VM), I registered the phone on the website, and paid those damn 99$. I used that for my cross-platform UI library with native controls, based on IUP. Now, future users of the UI toolkit do not need to care about Mac, iOS, or tooling; it just works. You can check the toolkit (WIP) here https://github.com/gen2brain/iup-go https://github.com/gen2brain/iup-go .
maxehmookau 4mo ago
I don't know why XCode gets the hate it does. It's a solid IDE which I've used for years with only minimal issues. It's certainly no more or less buggy than anything JetBrains releases.
qpe0 4mo ago
I do it exactly like described here. Nice to see an article about it.
mailship 4mo ago
[flagged]
pmarreck 4mo ago
The first Mac app I ever built, which was at least 6 months ago using only AI, was purely LLM without XCode at all.
zm2529 4mo ago
I mainly run the app from Xcode because it’s the easiest way to view the logs. If I build and install the app this way instead, what’s the best way to view the logs?

555 points by speckx 4mo ago

I've been using essentially this process (with Claude Code) for about six months. There are a couple of places where I've opened xcode; mostly to update the simulators for new betas of xcode 27, and once to add a target for Apple Watch (and I think something for HealthKit). Interestingly, since about Opus 4.6, Claude has been able to reason its way into this process on its own. It was clunky until 4.7, and in 4.8 it's managed to find its way around every reason I had to open xcode myself.

Tiberium 4mo ago

It's kind of funny to be reading this: > I had Claude Code create mine: I told Claude, more or less: I want to archive, Developer ID-sign, notarize, staple, and install this app to /Applications without ever opening Xcode. Write me a script that does the whole chain and fails loudly if any step breaks. Even though the text we're reading is Claude talking to us as well :) Also it was weird to see the mention of "ask your LLM" at almost every stage in the blog post: > point Claude Code or your LLM coding tool of choice to this blog post, and let it figure it out > When in doubt, ask your LLM of choice about them and have it help you get set up. It’s the one that’s going to be using Xcode for you anyway. > The whole point of using the LLM in the first place is to avoid doing things manually that you don’t want to do. > Again, if in doubt, ask Claude Code or your LLM of choice to create this for you. > Again, this is why you talk to your LLM, tell it what you want, and have it help build your workflow.

ryandrake 4mo ago
Claude telling us to point Claude to a web site written by Claude so that we can use Claude to create a build environment...
- ericol 4mo ago
  yo dawg
  - frollogaston 4mo ago
    Claudius Claudianus (aka Claudian)
  - natpalmer1776 4mo ago
    I heard you liked Claude, so I put extra Claude in your Claude so you can do more Claude.
    - lossyalgo 4mo ago
      I suppose it's easier to turn everyone into unwitting tokenmaxxers than it is to raise prices again.
    - deleted 4mo ago
      [deleted]
- theParadox42 4mo ago
  … that Claude can use, because Claude can’t use the XCode gui very efficiently.
- carimura 4mo ago
  "Claude was the only LLM to survive the LLM Wars."
- throwaway613746 4mo ago
  [dead]
- saw66 4mo ago
  I wrote the post myself. But thanks for assuming. :)
quasarj 4mo ago
The mistakes in the text made me doubt it was AI, but who knows, maybe it's doing that on purpose now
- ImaCake 4mo ago
  It seems too concise to be AI. My (conscious) heuristic for AI writing is how much context is squeezed into a sentence. LLMs seem to be pretty bad at the kind of elegant compression of meaning humans can do when they have done a lot of writing practice. If I had to guess, I would say this is the human summarised conversation(s) with a bot.
  - saw66 4mo ago
    It wasn't Ai. It was me. I wrote it.
    - ImaCake 4mo ago
      Sorry if my speculation was bad! When I wrote it I meant it as a compliment. Raw LLM output is awful and really needs a human to "translate" the useful content to something worth reading.
- saw66 4mo ago
  1) tell me what they were then, 2) It wasn't AI. It was me
saw66 4mo ago
Claude didn't write this post. I did.
- jkmcf 4mo ago
  Like we need another reason not to write and publish!
resonious 4mo ago
"This is the part where you think/learn" and "this is the part where you just let the LLM figure it out" is a fine format for advice nowadays I think. I am getting a little tired of every single HN comment being about how the linked article is written by an LLM.
hansvm 4mo ago
> Even though the text we're reading is Claude talking to us as well :) I'm not getting that vibe from this one; I'd bet money on it at least being substantially human edited. What are the tells you're seeing?

sgt 4mo ago

Although this has been well known for years and documented.

dylan604 4mo ago
Yeah, but not only was this "on a computer" but "with an AI" so it's not the same at all. /s

LatencyKills 4mo ago

I spent seven years as a dev on the Xcode team and this is pretty much my exact workflow these days.

sunnybeetroot 4mo ago
Thank you for your service. Xcode gets a bad rap from developers but for beginners, it doesn’t overwhelm them, giving them a great entry experience into app development.
- LatencyKills 4mo ago
  Thank you for your comment. Prior to Apple, I worked on the Visual Studio team for 10 years. Now that is a complex app now matter how experienced you are. ;-)

mrbombastic 4mo ago

This is cool but also makes me worried about the tendency with llms for all of us to make bespoke solutions rather than building a better community tool or extending an existing tool to solve the problem. fastlane exists to solve exactly this problem in the mobile space.

ryandrake 4mo ago
Also, shell scripts as part of a build are usually a little worrying. I'd at least want the build steps to be all integrated into my Makefile or CMakeLists.txt
vl 4mo ago
Bespoke solutions are better in many cases. They do exact things required for the project without taking extra dependency. Reducing dependencies is beneficial, because dependencies require management. So with llms economy of taking dependency shifted.
- SoftTalker 4mo ago
  ... avoiding this problem: https://xkcd.com/974 https://xkcd.com/974
- mrbombastic 4mo ago
  everything has tradeoffs, on the one hand you are right you have one less dependency, on the other hand the maintenance of said dependency is now on you. many times app store connect has changed some api and fixing our release process was a matter of updating fastlane because the community had already dealt with it, that's on you if you have a bespoke delivery solution.
doug_durham 4mo ago
The llm is the better community tool. The important change is that you don't have to settle with someone developing a monolithic tool that happens to do what you need it to do. That was the way things used to need to be done because of the cost.

recsv-heredoc 4mo ago

Having to have Xcode installed is more than half the problem. It makes Visual Studio look lightweight.

ryandrake 4mo ago
Xcode does have (or had, haven't checked for a while) a lightweight "command line tools only" installer. Unfortunately, that installer omits a lot of the actual useful command line tools, like the notary and stapler tools. I also recall that the command line tool only installer leaves out things like the metal compiler, too. Not sure what the point of it is.
- dylan604 4mo ago
  > Not sure what the point of it is. My only familiarity with it is because it's needed by brew. I honestly never looked into exactly what is in the package, but I assumed things like what is installed with -devel packages of yum/apt-get/dnf/etc. Lots of repos have common list of things to install like gcc/make/etc. Again, just guessing, but it's one of the first things I've always run on a new Mac to get it usable for CLI usage.
- saagarjha 4mo ago
  It lets you build basic UNIX-like tools.
gumby 4mo ago
It’s mostly all the emulators and platform APIs. I’m not defending Xcode (I hate it), just clarifying.

CharlesW 4mo ago

If it's okay to mention my own complementary open source project, Axiom¹ does a good job of helping coding harnesses know how to do this effectively for Apple OS development. In addition to a deep roster of skills and agencts, Axiom includes several for-LLM tools². xclog, xcprof, xcsym, and xcui are designed to be used by LLMs, and expose capabilities in a token-efficient way. These tools are equally helpful for non-Axiom skills/agents. ¹ Axiom: https://charleswiltgen.github.io/Axiom/ https://charleswiltgen.github.io/Axiom/ ² Axiom CLI tools: https://charleswiltgen.github.io/Axiom/tools/ https://charleswiltgen.github.io/Axiom/tools/

semiquaver 4mo ago
Axiom is excellent, thanks for making it!
- CharlesW 4mo ago
  I'm glad that it's been valuable for you!
zuzululu 4mo ago
will it work with flutter ?
- CharlesW 4mo ago
  Axiom covers only native APIs and tools, but the Flutter team maintains what looks like a nice set of skills at https://github.com/flutter/agent-plugins https://github.com/flutter/agent-plugins, and the Dart team at https://github.com/dart-lang/skills https://github.com/dart-lang/skills.
lprd 4mo ago
Silly question, but do you reckon it'll function decently in a Kotlin multiplatform codebase? There's swift native code, but I'm not sure how it would perform with some logic being shared.
- 4mo ago

schainks 4mo ago

I just set up my pipeline to do this exact thing for both the Apple and Android ecosystems, dispatching loads to my mac studio or Linux box accordingly. I moved the runners off GitHub because uptime for GitHub actions has been trash lately, and the Apple Silicon runners are pricey. Claude was great at figuring out what was broken when and either fixing it, or clicking as far as it could until it needed me. You could say I'm mostly just IRL hands for the AI now.

hyperhello 4mo ago

Being outside of the approved development loop has rough edges. How do you keep the app from putting up that permission to access documents folder all the time while you rebuild it?

saagarjha 4mo ago
They're a paid developer, so they are probably signing the app with a stable identity that avoids this.

rvz 4mo ago

By using "Claude Code"* * and giving Anthropic all your secrets, env vars, certificates and your source code to them.

kstenerud 4mo ago
Not if you've got a good sandbox.
- saagarjha 4mo ago
  Do you have one?
  - kstenerud 4mo ago
    Yup, I built one! https://github.com/kstenerud/yoloai https://github.com/kstenerud/yoloai You can even run simulators in it if you choose the Tart backend.
    - thoughtl3ss 4mo ago
      And how is your vibe coded sandbox better than 1000 other sandboxes?
      - kstenerud 4mo ago
        You'll never know. And that's fine.
simonw 4mo ago
What bad things to you anticipate Anthropic doing with your secrets, env vars, and certificates?
- owebmaster 4mo ago
  Is this a joke? Anthropic isn't great at keeping stuff private as we saw with the Claude Code leak. The more information they get access to the bigger the risk.

stephenhuey 4mo ago

Thought this was going to be about the new Ruby Native! https://rubynative.com https://rubynative.com “From bundle install to your phone in minutes. To the App Store and Google Play without a line of native code.“

zuzululu 4mo ago
holy hell $299/app is wild
- incanus77 4mo ago
  One time?! That's amazing.
  - stephenhuey 4mo ago
    Per year, but still amazing. I'd like to think of myself who knows what he is doing, but I just launched a Rails-based platform for a client on web, iOS and Android, and had to spend an annoying amount of time in Google Play and App Store Connect. $299 would be a tiny fraction of the billable hours I'd have to spend messing around in there, and that's not counting mobile app dev time at all, so I'm on the lookout for a good candidate project to try Ruby Native on!
  - chrisweekly 4mo ago
    per app per year

saagarjha 4mo ago

Making your app buildable from the CLI is not something I do personally to use on my Mac but it is very useful when you're automating your CI. If you have GitHub Actions set up to build your app, so can Claude, assuming you have the right signing setup on your machine.

pupppet 4mo ago

Doesn't that mean you need to distribute the app (TestFlight) before you can preview your app? How do you test locally without the simulators?

simonw 4mo ago
For a macOS app you don't need a simulator. For an iPhone app I've seen Claude Code launch the simulator without me needing to open Xcode.
- nwienert 4mo ago
  I built an iOS simulator simulator, though only for RN. Runs in browser but covers 100% of the API of RN, iOS UI, and the top 1k native libraries basically now. Been an ongoing agentic experiment of mine that's about ready to release. Kind of fun, you can develop iOS and Android both without a build step and without a Mac even.
turtlebits 4mo ago
Testing != Distribution. You can run directly on a connected iOS device, without setting up anything related to the app store.

overgard 4mo ago

Oh god, the app store does not need more slop. If you can't be bothered to open XCode (which I agree is a dumpster fire, but), you shouldn't be bothered to submit an app that a person has to review and another person has to filter out of their search results.

pclowes 4mo ago
Counterpoint: XCode is such slop that an app made by a developer with the taste to avoid it has a higher probability of being less "sloppy" than average.
- ulfw 4mo ago
  The 'developer' isn't even developing much of anything tho
- saagarjha 4mo ago
  This is generally not true
- overgard 4mo ago
  I don't know if that's really practical unless you're full-on-vibe coding or you avoid all the native frameworks. You kinda need XCode for a lot of things. I personally really dislike XCode after having to use it for like a decade and having it crash six times a day, so I feel people's pain in wanting to avoid it, but I also think slopping up the app store with vibe code monstrosities is not something that should be encouraged. Bad ideas are better made inconvenient..

exographicskip 4mo ago

Skimmed the article. Pretty close to my workflow using fastlane with tauri. Useful sanity check!

kxxx 4mo ago

I've been building and testing my iOS app just for fun via Linux only. Surprisingly, it's very easy. This works like a charm: https://github.com/xtool-org/xtool https://github.com/xtool-org/xtool You do not need to upload to TestFlight or the App Store; you can just install the app locally to your iPhone via usb -- even from Linux! When in doubt, just ask your coding agent of choice to help you create and upload a Hello World iOS app. It's really easy.

sdicker 4mo ago
I’ve been doing the same except that my linux installation is via WSL on Windows. I’ve been using sideloadly to move my IPA over to my phone. Works great.
GaryBluto 4mo ago
Does the iPhone need to remain tethered if it is transferred via USB?
- drakythe 4mo ago
  Dev apps need to be re-loaded every week (or two?) last time I did sideloading. The idea behind a dev app, in Apple's mind, is that it is for limited testing, so they have an expiration when not signed/installed through the App store.
  - judge2020 4mo ago
    That is specifically for apps installed with a personal signing certificate, when you haven't paid for a developer account. If you pay the $99 program fee, you get 365 days of validity.
amelius 4mo ago
Do the coding agents know about this tool?
- Yiin 4mo ago

hyzyla 4mo ago

Check also Sweetpad CLI. It’s basically wrapper around xcodebuild, but humans and agents. It’s my next project after Sweetpad VSCode extension for developing iOS/Swift applications in VSCode. Cli is still in beta, but I see on my own project that it’s already quite pleasant to use 1. https://sweetpad.hyzyla.dev/ https://sweetpad.hyzyla.dev/ 2. https://github.com/sweetpad-dev/sweetpad https://github.com/sweetpad-dev/sweetpad

tdhz77 4mo ago

I do something similar in GitHub actions. Every new app is setup in a few minutes to star getting rejected by iOS and Android.

josefrichter 4mo ago

Wait, I am not aware that I've done ANY of those setup steps, yet I'm building iOS and macOS apps without XCode. Both Claude and Codex handle it just fine and didn't ask me for any setup steps.

datadrivenangel 4mo ago

I've built a few small MacOS dock widgets now by just telling Claude/OpenCode to build them. Works well enough if you're very explicit. The most useful one is a little weather sparkline to show local temperature forecasts. Useful every day.

esafak 4mo ago
What framework was it written in, and does it trigger a scary warning from the OS when you try to install it?

mulmboy 4mo ago

I went to build an open source app from GitHub and was pretty surprised that it requires Xcode and that Xcode can't really be installed without an apple id. I do not want to make one and I certainly will not sign my computer into one. I did end up somehow installing Xcode via some shady download and was on my way. But the whole ordeal left a very sour taste.

sneak 4mo ago
Though the primary way of installing Xcode is via MAS (requiring Apple ID login), Xcode can be downloaded from the Apple Developer website without an ADP membership, though you do have to log in to the website with an Apple ID. You don’t have to log into the Mac with an Apple ID though, you can then install and use it on a Mac without an Apple ID (though you will need one inside Xcode to sign apps to get them to run on an iOS device).
swiftcoder 4mo ago
Running a Mac without an Apple ID feels like an exercise in masochism. I wasn’t aware one could even still it through first run without
- xyzzy_plugh 4mo ago
  Why do you need one?
  - balder1991 4mo ago
    I think because the only places you can download it from are either from the App Store or logging into Apple’s developer’s website.
everfrustrated 4mo ago
Heck you can't even compile against many of the Mac APIs without a cert unlocked by a paid developer account.

murlax 4mo ago

Tangentially, I despise Xcode and love the Expo ecosystem and all the lovely tooling that they have built. It is React Native but Expo honestly makes it so trivial to build stuff from the CLI without ever needing to open that abomination of an app. And with AI, I have built a lot of side project apps onto my iPhone, like a homelab app for monitoring my cameras with push notifications whenever someone is at the door, starting my irrigation and a whole lot more. Plus Tailscale of course. Kind of a crazy world that we live in now.

sefrost 4mo ago
Yes, I remember React Native being quite painful before Expo! Upgrading from one version to the next especially so. Expo seems to shield you from a lot of issues, without really taking any power away from you either.

sneak 4mo ago

You still have to open Xcode (to get the certs), and you still have to accept the Xcode EULA. Title is quite misleading if not outright false.

embedding-shape 4mo ago
As someone who tried my very best to not open Xcode for building and shipping Mac and iOS apps, I agree, there are things there are literally no way around opening the GUI, not even terminal utilities for. You cannot do this 100% headless, which is what I attempted at first.

coverband 4mo ago

Regardless of the vibe coding aspect, there's good information here for anyone new to the mac/ios build/distribution workflows.

onesandofgrain 4mo ago

Don't make apps for iOS. The apple ecosystem is horrendous

mvkel 4mo ago

In my experience, the better long-term choice if you're going to vibe code an app is to use Expo. Its basis is React, so the code output quality is much higher than Swift because there is much more React code in LLM training data. Everything is in the command line, and debugging is a breeze because it's a web view. But once it's compiled to native iOS, it feels like any other native app. Expo + Fastlane = fully automated iOS submission and deployment. I issue one command and see a new version in the App Store.

hetspookjee 4mo ago
Some parts when creating a new app cannot be automated right? Eg registering the app itself for example.
- fragmede 4mo ago
  You can have your AI agent use computer-use to click around on in a browser open on developer.apple.com if that's counts as automated to you.
esafak 4mo ago
This one?? https://expo.dev/ https://expo.dev/ Our code broke It looks like there was an error we need to look at. Sorry about the inconvenience.
- cobbzilla 4mo ago
  HN hug of death? seems to be back now. fwiw, expo seems solid; the uptime of expo.dev won't affect an app built with it.

pzo 4mo ago

You can as well make it simpler and use those skills: https://github.com/software-mansion/argent https://github.com/software-mansion/argent or https://github.com/callstack/agent-device https://github.com/callstack/agent-device both callstack and swmansion are mostly react native shops but those should work even in native ios/android as well

isodev 4mo ago

In addition to the challenged Xcode, just using Swift seems to require a lot more tokens for both coding and dealing with build/platform quirks. Probably not super significant on indie scale but for anything more robust, it builds up quickly. React Native and Flutter seem to be much more predictable for the bots (and more fun for humans, since they have actual hot reload).

theraven 4mo ago

Interesting this is coming across as novel. This is how CI build machines for Apple’s platforms have been setup in perpetuity.

frollogaston 4mo ago
True, but it'd take me a while / forever to figure out how. Reminds me of when I yelled at Gemini until it'd make me a Minecraft Bukkit plugin without installing anything besides the JDK, way easier task but it was still insisting on Gradle for a while.
matwood 4mo ago
Not just build machines. Years ago I scripted the entire build process to create hundreds of apps based on parameters and submit them. It was an attempt to work around the horrible App Store search. The original app had packages of content that could be purchased, but it was hard to convey from the single app listing. Eventually Apple said don't do that and we reverted back, but at that point we had moved on to something completely different.

prakashrj 4mo ago

[dead]

martinbfine 4mo ago

[dead]

dools 4mo ago

Shout out to fastlane! I would have loved to have found it sooner in my app shipping journey.

VaporJournalAPP 4mo ago

[flagged]

grahar64 4mo ago

I thought this would be a flutter post. Love flutter, ... , well I like flutter compared to Kotlin and Swift

busymom0 4mo ago
Last I used flutter, editable text views was where it wasn't acceptable for me. On iOS, the default text view comes with a lot of built in stuff automatically such as cut copy paste, lookup definition, translate etc. Flutter's didn't have these.

ChrisMarshallNY 4mo ago

Technically, you are using Xcode. Xcode is a [buggy as hell] GUI wrapper for a lot of system-level UNIX utilities and apps [which are generally, not so buggy]. Using CLI to release apps is a pretty old practice; at least as long as I've been doing it (I released my first Xcode app in 2012).

quasarj 4mo ago
That's good to hear. I never even tried to make anything for macOS because I opened Xcode and.. well, you know.
- ChrisMarshallNY 4mo ago
  Nah. I usually use Xcode GUI, but there's been a lot of discussion about using a CLI workflow, for many years. Should be easy to find. Hope you like long argument lists. xcodebuild has a crazy long parameter list. https://developer.apple.com/documentation/xcode/xcode-command-line-tool-reference https://developer.apple.com/documentation/xcode/xcode-comman...
  - jamesfinlayson 4mo ago
    From my experience the CLI works but is not well documented.
    - ChrisMarshallNY 4mo ago
      They rely on manpages, but using CLI tools is old enough, that there’s been plenty of online discussion on the practice. LLMs will often use CLI tools. In my experience, they loves their CLI.
  - 1vuio0pswjnm7 4mo ago
    Text-only, no Javascript https://developer.apple.com/tutorials/data/documentation/xcode/xcode-command-line-tool-reference.md https://developer.apple.com/tutorials/data/documentation/xco... 2011: https://manpagez.com/man/1/xcodebuild/ https://manpagez.com/man/1/xcodebuild/ 2016: https://keith.github.io/xcode-man-pages/xcodebuild.1.html https://keith.github.io/xcode-man-pages/xcodebuild.1.html Source code for xcodebuild not public ?

codazoda 4mo ago

One down-side to this is that it does require you to run the agent on your Mac instead of in a Sandbox. I do this too and there are lots of problems I can't solve in a sandbox. I know a lot of you are throwing your hands up at the years of security practices we're throwing out the window when we do that. The fact that xAI uploaded someone's home directory, including their SSH keys, is giving me serious pause at my choices here. Generally, I don't worry about my machine being "blown up". I don't have a TON of unreproducible stuff on my machine. Everything is backed up, committed to git, and the like. I can restore most of it in a couple hours. That said, I really, really don't want my .SSH directory sent to an AI agent and it's silly to prompt your way around that. You need to block it at the system level. I'm considering a separate user and then 700 permissions on my home directory. I feel like we're back to 1990's security here. The double-edged sword is that it's helping us get things done at a pace like never before. I'm not throwing shade here, I'm among the guilty.

pianopatrick 4mo ago
You could move your SSH keys onto a password encrypted usb drive that you physically remove from the computer.
- wrxd 4mo ago
  An alternative is to use ssh keys stored in the Secure Enclave with tools like https://secretive.dev/ https://secretive.dev/
  - pianopatrick 4mo ago
    Seems to me a tool like that would stop the agent from sending those specific keys elsewhere. But a tool like that would not stop the agent who is acting as you from using the SSH keys via the CLI. You would want to combine that with other tactics like having the agent run as some other user.
    - samhclark 4mo ago
      Secretive (and the similar built-in functionality [1]) both allow you to require TouchID too. I found an okay balance using two SSH keys: one for commit signing (w/o TouchID) and one for everything else (requires TouchID, or PIN on Linux) So, the actions that I really don't want the agent to take (establishing an SSH connection, pushing to a git remote) always require my manual intervention. [1] https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb4acf https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb...

awaseem 4mo ago

I’ve done this forever on Foqos. Have a makefile, never even open Xcode and the instructions are in the agents md

tomaskafka 4mo ago

I find it hard to believe xcodegen is in a state where it would reliably generate xcodeproj for all edge states (widgets, watchos app, notification extensions …) - it certainly wasn’t when I last tried it for Weathergraph few years ago. That said, it might be well enough for simpler apps.

tptacek 4mo ago
What's a not-simple app? I've had Claude generate: * A Markdown viewer (obviously pretty simple) * A menu bar Apple TV remote (surprisingly complicated) * A menu bar and desktop temperature tracker for the silly Tapo temperature trackers I have all over my house (a little complicated because multiple user interfaces, a backing database, scheduling, and multiple local/remote protocol interfaces) * A graphical CAS calculator frontend to Sage Math with LaTeX math rendering * An LLMwiki implementation that uses macOS filesystem extensions to reflect a SQLite database into a local filesystem for agents to traverse (basically the new macOS way to do FUSE, fussy enough that the app has to run out of /Applications to work) * An agent-driven Music.app replacement with AirPlay streaming support managing Apple Music catalogs and tracks All of these have worked without me ever once touching the xcode UI, except one time to generate Apple Developer certificates, which I then drove exclusively from CLI tools. These are all pretty modern SwiftUI applications.
- tomaskafka 4mo ago
  Afaik these are all single target apps. I was talking about extensions, watchos companion apps ...

waynecochran 4mo ago

The main iPhone app I maintain for work is 100% claude edited now ... I don't touch the code anymore ... I do occasionally look at it. It does a way better job than I could. I do have Xcode open as claude does its thing ... and I occasionally sign and deploy with Xcode. No coding though.

gwking 4mo ago

I have one weird trick for people who are exploring this vein. I last opened an Xcode project about five years ago so I could be way behind the times. Having spent many years fighting with Xcode professionally, I was thrilled when swift build came out, and then appalled at how badly Xcode adopted it. Eventually I realized that you can set up your entire app as a swift package, and then the Xcode project with a single main source file that calls some `app_main()` (or whatever you want to call it) function in your package. I cannot remember exactly but there was something annoying about setting up a new project; I think by default Xcode assumes that you want a swift package to be treated as a dependency that is checked out from git, but there was a way to drag and drop a local dependency in the same project directory and then it worked. What this buys you is that files are no longer tracked by Xcode, so renames/merges no longer trigger project.pbxproj surgery. Instead you specify the swift package directories and are done. I used this for some large personal projects and was very happy with it. At one point I also wrote my own build tool that imitated all of the steps that Xcode took so that I could truly be Xcode-free. That also worked (and was not even that hard) but I went back to Xcode because the debugger UI was better than what I could get out of VS Code at the time, and especially because I was playing around with the Metal debugger.

andrekandre 4mo ago
> set up your entire app as a swift package, and then the Xcode project with a single main source file that calls some `app_main()` this is basically how i do all apps nowadays (at home and at $work), all settings for the ios side of things is in a xcconfig file and keeps things simple and working with multiple people is much more a breeze this way

franze 4mo ago

built cable detective like this https://apps.apple.com/at/app/cable-detective/id6765963737?l=en-GB&mt=12 https://apps.apple.com/at/app/cable-detective/id6765963737?l... and the soon to come https://aifcc.franzai.com/ https://aifcc.franzai.com/ which is more ambitious honestly would not even know what to do / click in xcode

supermatt 4mo ago

> Without Ever Opening Xcode "Next, open Xcode"

zerr 4mo ago

The thing is, in a perspective, who would need any apps at all? Users will get what they want from AI directly.

philocalyst 4mo ago

Or use https://swiftbundler.dev/ https://swiftbundler.dev/ ?

WhitneyLand 4mo ago

Everyone will still need to use Xcode for at least some debugging, no way around that. As for the builds, your agent probably already knows how to do a lot of this from the command line, although explicit suggestions can help it build faster for different situations. As for XcodeGen, you may find it unnecessary overhead if you're already using Xcode file system synced groups. For iOS my biggest suggestion would be to enable App Store Connect skills for your agent (https://github.com/rorkai/App-Store-Connect-CLI https://github.com/rorkai/App-Store-Connect-CLI). With this not only do you not need Xcode all the time, you also don't even need to be near a MacBook. Just make changes via Codex on your iPhone, the tell asc to build and upload to TestFlight, download and run the new version, iterate.

dostick 4mo ago
There’s complete lldb debugging for Swift as plugin for VSCode.
bobthebob 4mo ago
I’m chiming in here to say I did pretty much build an entire iOS app with agents, and it launched it on the App Store for me, along with a social push. I only used Xcode to preview the builds on my device and then guide the prompts more
- saw66 4mo ago
  Thank you. I don't understand why this is so controversial (and why everything thinks Claude wrote my post).

octavore 4mo ago

Shameless plug: I've been working on strudel [0], a CLI that uses a lot of the same ideas in this post and allows you to build/sign/notarize Mac (and iOS) apps without touching Xcode. It has a dry run mode so you can see the actual commands being run, which was important to me to have so there's no mystery about what's happening. I should blog about more this, but I also went to some effort to add support free iOS provisioning with just an Apple ID (using internal APIs); and creating a nice DMGs for macOS app distribution (reverse engineered .DS_store files for this). And there's also a built-in command to install skills for coding agents, which was fun. This [1] is an example app I built with it, a simple utility to manage macOS file extension handling. [0] https://github.com/octavore/strudel https://github.com/octavore/strudel [1] https://github.com/octavore/tots.app https://github.com/octavore/tots.app

deleted 4mo ago
[deleted]

myko 4mo ago

I prefer Tuist (writing Project.swift) to XcodeGen but otherwise, yeah, this tracks

zitterbewegung 4mo ago

Xcode 27 which is in beta ships a much better codex integration. There are problems in Xcode that are frustrating . Also, git integrations are a nice touch that allow you to force push too. Would be interesting to find out how well this works in a team based setting.

dvduval 4mo ago

What continues to bother me is just that developers who don’t have the budget are pretty much pushed out of iOS development because they can’t afford a Mac. And every time that Apple increases the price of their products, more people are blocked from being able to develop on them.

geraneum 4mo ago
People not having access to tech is bothersome, but nowadays Apple offers affordable machines compared to the same/worse specs from competitors. For example a MacBook Air with Apple Silicon and a moderate amount of memory.
- MindSpunk 4mo ago
  Why should you need a Mac to build for iOS at all? What makes Apple so special here? Cross-compilation toolchains aren't forbidden alien technology. Forcing people onto Macs is such a pathetic way of extracting rent from developers and makes workflows worse. No you can't just build and debug your app from your Windows or Linux workstation because we want you to buy hardware you don't need. Sorry we only support Xcode on the latest version of MacOS, how else will your build machine roll out of the OS support window and make you replace a functioning machine? It's especially nice when you work on projects that aren't iOS/Apple native and you don't get Mac workstations. You end up with this wonderful mess of shared machines and half assed tools because you just need the bare minimum to push a build to a phone.
  - geraneum 4mo ago
    I don't disagree with you, but we're talking about affordability which is a different topic. > It's especially nice when you work on projects that aren't iOS/Apple native and you don't get Mac workstations. If you develop natively for macOS, then you probably need the OS for it. It's the same for Linux and Windows. But building is not the biggest hurdle because you can build in your usage-based-billed/free CI as well the same way you do for other platforms. For complete native development (system APIs, OS interactions, native UI) against macOS/iOS on PC, Apple needs to open those OSes for PCs/Pixels/Samsungs/etc. This is a software issue, not hardware. Otherwise Apple silicon Macs are less restrictive than PC hardware in general!

js2 4mo ago

> notarytool authenticates using a stored keychain profile that you create once, interactively — it prompts for an app-specific password, and there’s no way around the prompt. You can use `--password <password>` (yeah, yeah, passwords on the command line are bad; I'm just challenging "there's no way around the prompt.") Later (contradicting itself): > The one step that stays interactive is notarytool store-credentials, and that’s a choice rather than a limitation: you could pass --password and script it, but that means putting an app-specific password in your shell history. You can configure your shell to ignore history when needed. https://stackoverflow.com/questions/6475524/how-do-i-prevent-commands-from-showing-up-in-bash-history https://stackoverflow.com/questions/6475524/how-do-i-prevent... https://superuser.com/questions/352788/how-to-prevent-a-command-in-the-zshell-from-being-saved-into-history https://superuser.com/questions/352788/how-to-prevent-a-comm... (And if it's in a script, it won't be in your history anyway.) > These passwords go stale silently whenever you change your Apple ID password You can use an ASC API key instead. This can be either a team key ("developer" access level) or an individual key. https://developer.apple.com/documentation/appstoreconnectapi/creating-api-keys-for-app-store-connect-api https://developer.apple.com/documentation/appstoreconnectapi...

myHNAccount123 4mo ago

Xcode 27 beta 3 has been the most stable release I've ever used. The type checking improvements were understated so I gotta laugh at this xcode avoidance. Areas they could improve - what ever the heck is going on in their diffing ui for source control.

matthewmueller 4mo ago

Very cool! Does this assume you're never editing code by hand or can you use editors like VSCode or Cursor as well?

qpx2022 4mo ago

I use this script to build and notarize macOS apps, you might find it useful as well: https://github.com/muquit/NotarizeMacApp https://github.com/muquit/NotarizeMacApp

canthonytucci 4mo ago

If you’re paying the $100/year to publish to the store you also get access to Xcode cloud, which you can point at a repo and it will build snd archive for you to distribute to testflight. I opened xcode to test locally in simulator the first time but haven’t had to since. Using godot iOS export. For regular old native ios dev replacing Xcode i don’t think i would do it.

stevenhubertron 4mo ago

This is how i am developing keptrecipes.com. Been a pleasure this way TBH.

deleted 4mo ago

[deleted]

inopinatus 4mo ago

If you prefer your builds composed of declarative and incremental targets, see https://github.com/inopinatus/sublime_url/blob/main/Makefile https://github.com/inopinatus/sublime_url/blob/main/Makefile Same shit with a bit of structure.

21-DOT-DEV 4mo ago

The comments here clearly point out that building and shipping have been the automatable parts (and for some time now). To anyone who's chased a crash that only reproduces on a physical device knows the fix was never more log statements added by ai but rather a breakpoint, the debugger, and thirty unglamorous minutes of stepping through code line-by-line (terminal lldb technically counts, but barely).

samso26 4mo ago

[flagged]

aabajian 4mo ago

I shipped my iOS app without opening Xcode (well, I had to open it to get some provisioning stuff to work). I still use Visual Studio Code to kick off the simulator, but other than that, I use no IDE at all. Claude writes all the code in Flutter. IDEs are dead, prove me wrong.

bilekas 4mo ago

Honestly I thought this was the standard because god help me Xcode is terrible.

searls 4mo ago

I've been using agents to develop Mac and iOS apps for over a year now and I would say this post is bad advice, particularly because the excellent Xcode MCP requires Xcode to be running. The MCP tool gives you faster, better access to a number of functions for which xcodebuild is much slower and much chattier and a number of others (like the #Preview generation and rendering) that aren't possible at all while Xcode is closed. Also, in Xcode 27, the MCP & built-in agents are able to drive simulators with DeviceHub extremely well. (If you haven't been following, DeviceHub replaces Simulator.app and as far as I can tell, it's actually scrutable by agents without relying on hacking at the accessibility APIs with tools like axe.) Xcode MCP is not perfect, by any stretch (stupidly, it issues a permission prompt on every single agent launch—something I defeated with a Keyboard Maestro hack to auto-accept it), but Xcode 27 is such a huge leap forward in the ergonomics of vibe coding with Xcode that I've actually stopped dealing with the MCP and (after an afternoon of futzing) have started using the app's own agent UI for driving Codex because that harness better steers the model to take advantage of the tools available. All of this redounds to two things: faster feedback and more robust verification. The two things that matter most.

dostick 4mo ago
There’s Xcode-mcp-proxy that proxies Xcode’s mcp and adds clicking dialog and reconnects. How do you deal with macOS app testing? Do you use Peekaboo or plain screenshotting automation?
- sunnybeetroot 4mo ago
  Can you link it? Quick google search didn’t reveal it
  - dostick 4mo ago
    Gave the wrong name, this is it- https://github.com/lynnswap/XcodeMCPKit https://github.com/lynnswap/XcodeMCPKit
    - sunnybeetroot 4mo ago

gnachman 4mo ago

Not using Xcode is the greatest improvement in quality of life I have known aside from recovering from a debilitating back injury. So good.

scosman 4mo ago

small issue: xcodebuild will just randomly fail sometimes. And the solution is to... open and close Xcode. I wish this wasn't true, but it is.

notimetorelax 4mo ago
Can LLM do this too? If yes, then it’s annoying but is not a blocker.

chrisvenum 4mo ago

React Native + Expo is also a good option if you want to touch the iOS/Android IDEs as little as possible. You use Xcode and Android studio to install the device sims and then expos tool chain handles the rest, even for deploying to stores. If you are on a windows computer and can’t install Xcode, you can even run your iOS app directly on an iPhone with their managed app. Ignite is a great starter using RN and Expo. Some great people maintaining it. https://github.com/infinitered/ignite https://github.com/infinitered/ignite

alana314 4mo ago
+1 for Expo, their Expo Application Services are great and have a free tier. npx expo run:ios --device #runs a build on my iphone and shows logs in the terminal eas build --platform ios --profile preview #builds in the cloud and gives me a QR code to install a build on my device with a custom certificate eas build --platform ios --profile production --auto-submit #auto increments and submits a production build to the app store.

mctwo 4mo ago

I don't see the point of this, if you use Claude or whatever frontier LLM you like, you need Xcode only to start emulators / install app on phones or to upload a binary.

landseer100 4mo ago

[dead]

NamlchakKhandro 4mo ago

Or use Gondolin, or SmolVMs

eptcyka 4mo ago

What about debugging?

resonious 4mo ago

This seems like a lot. I told my oh-my-pi agent to build my ios app for me and send it to me remotely. After some chugging, it gave me a tailscale funnel link. And it worked. I didn't have to dig into any of this stuff. I didn't use the words "Developer ID-sign", "notarize", or "staple" in my prompt.

pjmlp 4mo ago

The pain people go through not to use XCode, for me it does the job.

eschaton 4mo ago
It’s incredible to me the lengths these people will go to just to avoid using the standard tools.
- andrekandre 4mo ago
  the path of most resistance... sometimes i wonder if apple's insistence on a mac + paid membership is a kind of intentional filter, like they want someone who's devoted enough to invest 100 bucks + a mac etc

qiaobax 4mo ago

[flagged]

jkwang 4mo ago

[flagged]

gen2brain 4mo ago

I have a nice setup on my Linux for iOS apps. I compiled the OSXCross toolchain, and also copied iPhoneOS.sdk and iPhoneSimulator.sdk from the macOS VM. With some wrappers, I can compile iOS apps (Obj-C) on my Linux machine, sign them with zsign, and use go-ios to install them on the device. At first, I just used simulator builds to test (and debug) on the macOS VM, in the simulator, but that was slow and painful. Finally, I bought a used iPhone, all bruised, just so I could test it on a real device. The main issue for me was signing, one cannot register a macOS VM (maybe with some kext hacks?), I managed to enable developer mode on the phone (crazy process, but it worked with Xcode in a VM), I registered the phone on the website, and paid those damn 99$. I used that for my cross-platform UI library with native controls, based on IUP. Now, future users of the UI toolkit do not need to care about Mac, iOS, or tooling; it just works. You can check the toolkit (WIP) here https://github.com/gen2brain/iup-go https://github.com/gen2brain/iup-go .

maxehmookau 4mo ago

I don't know why XCode gets the hate it does. It's a solid IDE which I've used for years with only minimal issues. It's certainly no more or less buggy than anything JetBrains releases.

qpe0 4mo ago

I do it exactly like described here. Nice to see an article about it.

mailship 4mo ago

[flagged]

pmarreck 4mo ago

The first Mac app I ever built, which was at least 6 months ago using only AI, was purely LLM without XCode at all.

zm2529 4mo ago

I mainly run the app from Xcode because it’s the easiest way to view the logs. If I build and install the app this way instead, what’s the best way to view the logs?