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.
> 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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Not silly at all. For Compose Multiplatform, Axiom won't do much for code review or generation. It might be useful for operations on the built app: console capture, crash symbolication, simulator UI/accessibility driving, CPU profiling, plus the whole shipping layer (signing, privacy manifests, submission).
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.
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?
What could go wrong? Might Apple change something across five ecosystems and leave you in the lurch, and now you have to go through all the slop to try to fix it?
I've used opencode on a plane with local models to make small updates to local MacOS apps. It's not fast or amazing, but it does work well enough to do trivial changes.
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!
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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).
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.
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.
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.
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).
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.
If you write Qt applications, Qt Creator is perfectly usable and as it's cross-platform you only need to be familiar with one IDE. It ships with its own deploy command which packages the app. You still need to run code signing/notarization last time I checked, but if the complaint is the XCode GUI then no problem there.
Xcode’s a lot more than a wrapper for UNIX utilities. For example, it has an entire build system. It doesn’t just invoke xcodebuild under the hood—and even if it did, xcodebuild uses the exact same code to build your projects as the IDE.
Most of the problems that I saw people have with Xcode over the two decades that I worked on it were the result of one fundamental problem: They wanted to work a different way than Xcode is designed to work, and jumped through a ton of hoops to do so, and then blamed Xcode for not accommodating their intentional working at cross-purposes.
A good example: An app that considered itself “large” because it had a thousand tiny static library targets each with only one to three or so ObjC classes. Far smaller than Xcode itself, but because they insisted on working that way—for no real articulable benefit besides “that’s how we want to work”—their project took hours to build from scratch instead of minutes like much larger projects that have many fewer targets.
In my experience, it’s quite “crashy.” It often locks up so bad, that I need to force-quit (or force-restart the Mac). I end up doing that once a day, or so. I suspect that many of the performance and stability issues, have to do with resource usage. It’s a damn big app.
It can also end up in strange states, where portions of the UI fall “out of sync,” and the app needs to be restarted. Some operations (like opening a storyboard, or stopping at a breakpoint) introduce massive delays.
It’s not a denigration, calling something a UI shell. I’m working on one, right now. The engine and backend were done in April (started in February), and all the work since, was on the UI shell. I probably could have shipped something that “ticked all the boxes,” in May. It’s almost done, but there’s still a couple of months of testing, ahead.
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.
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.
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.
I've been working on a wrapper harness that runs claude as a separate user named `agent`. I tried this about a year ago and couldn't get it to work because of OAuth and the keychain, but took another pass recently and claude had enough self-knowledge about recent changes to say we could do it with CLAUDE_CODE_OAUTH_TOKEN. It has required building a some tooling around permissions setup with ACLs but it works on macOS today.
In terms of risk, I see it as halfway between stock claude with the sandbox and full-blown container or machine isolation.
I was recently thinking that as Claude's own sandbox gets better I'm doubting the ROI on my belt-and-suspenders project, but your comment reminds me why I'm doing it.
It is not currently published open source but I'm happy to talk about it with strangers.
Many people have created Mac VM projects to do exactly this, I was working on one but was stalled too often because before I started using claude I bought a new laptop with what I KNEW was enough disk space.
The 100 GB or so I need to comfortably do the VM stuff just isn't available on my mac.
I've been running my agents in a docker sandbox that automatically mounts the current directory. It's been a bit of a pain to figure out and maintain the set of tools I provision into the sandbox- but it's fun to watch codex go to the ends of the earth trying to figure out solutions using nodejs (the only runtime).
> require you to run the agent on your Mac instead of in a Sandbox
You don't have to! All recent Macs come with nearly zero perf cost virtualization. You can easily run Mac or Linux VMs assuming same architecture. Use it all the time for development and whatever.
Use Tart [1] or VirtualBuddy [2], both open-source, for a packaged solution. Or in the spirit of this post, vibe code your own wrapper around the OS API [3]
More recently, there are also Apple containers [4]
>> I feel like we're back to 1990's security here.
> vibe code your own wrapper around the OS API
Maybe stick with one of the existing projects? Throwing out all of the edge cases and hardening that went into a security-related project just to burn a bunch of resources to generate a worse one you have to maintain yourself is 90s-level security with 2026-level inefficiency, IMO.
If the below sounds too complex to work with, can review more basics first. Can start with a Swift tutorial
virtualMachine.start(completionHandler: { (result) in
if case let .failure(error) = result {
fatalError("Virtual machine failed to start with \(error)")
}
})
RYO is the best way to learn, if you have the time to learn. After building one own solution one is able to assess the strengths and weaknesses of what other more experienced people built. Without the learning phase those other solutions are incomprehensible black boxes. The trick is not to skip the phase in which one researches available solutions.
> RYO is the best way to learn, if you have the time to learn
The problem is that nowadays, people roll their own solution, don’t take the time to learn (somewhat understandably, given the complexity of today’s stuff. You simply cannot learn all details about your hardware, OS, and third-party libraries anymore) but immediately deploy things in production.
Eating your own dog food can be good, but for security related stuff, it can easily be disastrous.
all community projects (specially the ones maintained or opensourced by model owners) will certainly have the security-convenience trade offs set all the way to convenience while advertising all the (off by default) security features
Yes! That is arguably the killer feature. You can virtualize macOS in macOS with (nearly) native speed and this is officially supported. Heck, even can run multiple of them at the same time.
The limit is two. You are not allowed to run more than two macOS VMs. Also Tart VMs have problems with signing into icloud and other things that need a real secureID enclave.
I run my AI headless in a docker container and give it access to git – it can only contribute code - when it needs a secret I put it in a docker container in vault. when it needs infra, it makes me a jira ticket. that's my workflow.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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!
I'm not really sure how any machine is more affordable than the $0 it should cost because you shouldn't need a Mac. It's absolutely true that you can get by with a base spec Mac Mini, but often you can't with bigger projects and the cost skyrockets because Apple prices memory like kidneys (current market conditions aside, they've always done it).
I have nothing against the hardware. I despise how artificial the problem is. It's not even like Apple just refuse to provide tools and leave it up to the community. They force you to use a Mac in the terms of service.
For context I work on the mobile team for a large AAA game engine. This is going to colour my opinion because we're very Windows centric, but my experience wouldn't exist if it weren't for Apple. I need to sync code on two different machines and build half the project on Windows and the other half on the Mac. If we could just build and debug the iPhone on Windows none of this mess would be needed.
We don't develop for MacOS, we develop for iOS. Just debugging the app requires several hoops across multiple machines because of Apple's policy here. Just because a base spec Mac Mini is cheap doesn't make this whole problem any less stupid. I don't need a vendor's special-sauce computer to build for consoles. Cross compilation and remote debugging has existed for decades, this problem should not exist.
Calling it more affordable because Mac Minis aren't junk anymore is really just accepting Apple's ridiculous requirement because "I guess it could be worse right?".
Because it would cost Apple a substantial amount of money to make it possible to build your code for iOS on other platforms in any sort of supported fashion. So all the stuff they invest very substantial amounts of money into creating and maintaining are only going to be licensed for use on the hardware they sell under the latest operating system it runs. Asking for more is asking them to spend more money without any evidence of a commensurate return.
If you can produce a properly structured submission to the App Store ingestion pipeline without using a Mac, then I doubt Apple will care. But that doesn’t mean they’re obligated to help you, and especially not to spend millions of dollars to do so.
The Apple developer terms of service require all app submissions to come from a Mac.
Apple could've chosen to offer no tools and leave it to the community to build their own. I think that's reasonable. I don't expect Microsoft to bring MSVC to Linux.
But Apple take the explicit position that you must purchase a Mac in order to ship apps for iOS.
It’s not really that onerous for a platform to require that, to develop for it, you need to actually take part in it. For Apple platforms that means becoming a Mac user. For IBM i and z that also means getting substantial hardware or paying for accounts and licenses (once you want to go beyond learning).
You can develop for Linux and BSD and Haiku and all sorts of other platforms for free. If the cost is what matters to you, then just do that. If you’re doing it as a business, though, consider that you’re extremely lucky to be able to just buy a low-end device and a low-end system and that’s all the capital investment needed (plus the US$100/year membership as recurring opex).
> 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.
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.
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.
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).
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.
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.
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?
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.
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.
we are building revyl.com for exactly this. You should check out our CLI: https://github.com/RevylAI/revyl-cli, it lets your agents xcode build and spin up multiple simulators in parallel (all in the cloud). Would love your feedback!
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.
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 .
Schiendelman | 14 hours ago
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 | 14 hours ago
> 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 | 14 hours ago
ericol | 13 hours ago
natpalmer1776 | 13 hours ago
lossyalgo | 11 hours ago
frollogaston | 7 hours ago
theParadox42 | 13 hours ago
carimura | 11 hours ago
saw66 | 4 hours ago
quasarj | 11 hours ago
ImaCake | 10 hours ago
If I had to guess, I would say this is the human summarised conversation(s) with a bot.
saw66 | 4 hours ago
saw66 | 4 hours ago
saw66 | 4 hours ago
resonious | 3 hours ago
I am getting a little tired of every single HN comment being about how the linked article is written by an LLM.
hansvm | 3 hours ago
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 | 14 hours ago
dylan604 | 14 hours ago
LatencyKills | 14 hours ago
sunnybeetroot | 3 hours ago
mrbombastic | 14 hours ago
ryandrake | 14 hours ago
vl | 13 hours ago
SoftTalker | 12 hours ago
doug_durham | 13 hours ago
recsv-heredoc | 14 hours ago
ryandrake | 14 hours ago
dylan604 | 14 hours ago
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 | 13 hours ago
gumby | 14 hours ago
I’m not defending Xcode (I hate it), just clarifying.
CharlesW | 14 hours ago
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/ ² Axiom CLI tools: https://charleswiltgen.github.io/Axiom/tools/
semiquaver | 14 hours ago
CharlesW | 11 hours ago
zuzululu | 13 hours ago
CharlesW | 12 hours ago
lprd | 11 hours ago
CharlesW | 10 hours ago
smashah | 11 hours ago
CharlesW | 10 hours ago
schainks | 14 hours ago
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 | 14 hours ago
saagarjha | 13 hours ago
rvz | 14 hours ago
* and giving Anthropic all your secrets, env vars, certificates and your source code to them.
kstenerud | 13 hours ago
saagarjha | 13 hours ago
kstenerud | 13 hours ago
You can even run simulators in it if you choose the Tart backend.
thoughtl3ss | 13 hours ago
kstenerud | 9 hours ago
simonw | 13 hours ago
Danox | 13 hours ago
datadrivenangel | 12 hours ago
But also yes this is a real concern.
stephenhuey | 14 hours ago
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 | 13 hours ago
incanus77 | 13 hours ago
stephenhuey | 12 hours ago
chrisweekly | 12 hours ago
saagarjha | 13 hours ago
pupppet | 13 hours ago
simonw | 13 hours ago
nwienert | 13 hours ago
Kind of fun, you can develop iOS and Android both without a build step and without a Mac even.
turtlebits | 13 hours ago
overgard | 13 hours ago
pclowes | 11 hours ago
ulfw | 9 hours ago
saagarjha | 8 hours ago
exographicskip | 13 hours ago
Useful sanity check!
kxxx | 13 hours ago
Surprisingly, it's very easy. This works like a charm: 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 | 12 hours ago
GaryBluto | 12 hours ago
drakythe | 12 hours ago
judge2020 | 7 hours ago
amelius | 10 hours ago
Yiin | 10 hours ago
thephyber | 9 hours ago
This is the perfect use case for a skill: one person takes the hit to create the skill and then anyone else who wants the tool can use the skill.
timcobb | 9 hours ago
hyzyla | 13 hours ago
1. https://sweetpad.hyzyla.dev/
2. https://github.com/sweetpad-dev/sweetpad
tdhz77 | 13 hours ago
josefrichter | 13 hours ago
datadrivenangel | 12 hours ago
The most useful one is a little weather sparkline to show local temperature forecasts. Useful every day.
esafak | 10 hours ago
mulmboy | 12 hours ago
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 | 12 hours ago
swiftcoder | 12 hours ago
xyzzy_plugh | 11 hours ago
balder1991 | 8 hours ago
everfrustrated | 12 hours ago
murlax | 12 hours ago
sefrost | 12 hours ago
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 | 12 hours ago
embedding-shape | 10 hours ago
coverband | 12 hours ago
onesandofgrain | 12 hours ago
mvkel | 12 hours ago
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 | 12 hours ago
fragmede | 11 hours ago
esafak | 10 hours ago
cobbzilla | 9 hours ago
fwiw, expo seems solid; the uptime of expo.dev won't affect an app built with it.
pzo | 12 hours ago
https://github.com/software-mansion/argent
or
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 | 12 hours ago
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 | 12 hours ago
frollogaston | 8 hours ago
dools | 11 hours ago
ChrisMarshallNY | 11 hours ago
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 | 10 hours ago
ChrisMarshallNY | 8 hours ago
Hope you like long argument lists. xcodebuild has a crazy long parameter list.
https://developer.apple.com/documentation/xcode/xcode-comman...
jamesfinlayson | 2 hours ago
ChrisMarshallNY | 19 minutes ago
LLMs will often use CLI tools. In my experience, they loves their CLI.
throwaway219450 | 2 hours ago
saw66 | 4 hours ago
eschaton | 2 hours ago
Most of the problems that I saw people have with Xcode over the two decades that I worked on it were the result of one fundamental problem: They wanted to work a different way than Xcode is designed to work, and jumped through a ton of hoops to do so, and then blamed Xcode for not accommodating their intentional working at cross-purposes.
A good example: An app that considered itself “large” because it had a thousand tiny static library targets each with only one to three or so ObjC classes. Far smaller than Xcode itself, but because they insisted on working that way—for no real articulable benefit besides “that’s how we want to work”—their project took hours to build from scratch instead of minutes like much larger projects that have many fewer targets.
ChrisMarshallNY | 26 minutes ago
In my experience, it’s quite “crashy.” It often locks up so bad, that I need to force-quit (or force-restart the Mac). I end up doing that once a day, or so. I suspect that many of the performance and stability issues, have to do with resource usage. It’s a damn big app.
It can also end up in strange states, where portions of the UI fall “out of sync,” and the app needs to be restarted. Some operations (like opening a storyboard, or stopping at a breakpoint) introduce massive delays.
It’s not a denigration, calling something a UI shell. I’m working on one, right now. The engine and backend were done in April (started in February), and all the work since, was on the UI shell. I probably could have shipped something that “ticked all the boxes,” in May. It’s almost done, but there’s still a couple of months of testing, ahead.
codazoda | 11 hours ago
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 | 11 hours ago
wrxd | 10 hours ago
pianopatrick | 10 hours ago
samhclark | 10 hours ago
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/5f59f1783e3eaf1a2d4cd8e952bb...
danielheath | 7 hours ago
fragmede | 11 hours ago
gwking | 11 hours ago
In terms of risk, I see it as halfway between stock claude with the sandbox and full-blown container or machine isolation.
I was recently thinking that as Claude's own sandbox gets better I'm doubting the ROI on my belt-and-suspenders project, but your comment reminds me why I'm doing it.
It is not currently published open source but I'm happy to talk about it with strangers.
colechristensen | 10 hours ago
You can also use native Mac VMs.
Many people have created Mac VM projects to do exactly this, I was working on one but was stalled too often because before I started using claude I bought a new laptop with what I KNEW was enough disk space.
The 100 GB or so I need to comfortably do the VM stuff just isn't available on my mac.
ghjnut | 10 hours ago
arianvanp | 10 hours ago
999_cirno | 10 hours ago
You don't have to! All recent Macs come with nearly zero perf cost virtualization. You can easily run Mac or Linux VMs assuming same architecture. Use it all the time for development and whatever.
Use Tart [1] or VirtualBuddy [2], both open-source, for a packaged solution. Or in the spirit of this post, vibe code your own wrapper around the OS API [3]
More recently, there are also Apple containers [4]
[1] https://tart.run/
[2] https://github.com/insidegui/VirtualBuddy
[3] https://developer.apple.com/documentation/virtualization
[4] https://github.com/apple/container
DrewADesign | 7 hours ago
> vibe code your own wrapper around the OS API
Maybe stick with one of the existing projects? Throwing out all of the edge cases and hardening that went into a security-related project just to burn a bunch of resources to generate a worse one you have to maintain yourself is 90s-level security with 2026-level inefficiency, IMO.
999_cirno | 7 hours ago
But it is to note that the OS APIs do the heavy lifting, the projects are just wrappers
DrewADesign | 7 hours ago
999_cirno | 7 hours ago
On "Hacker" News of all places :)
ben_w | 6 hours ago
vs
> vibe code your own wrapper around the OS API
999_cirno | 6 hours ago
https://developer.apple.com/documentation/virtualization/run...
If the below sounds too complex to work with, can review more basics first. Can start with a Swift tutorial
pmontra | 4 hours ago
Someone | 3 hours ago
The problem is that nowadays, people roll their own solution, don’t take the time to learn (somewhat understandably, given the complexity of today’s stuff. You simply cannot learn all details about your hardware, OS, and third-party libraries anymore) but immediately deploy things in production.
Eating your own dog food can be good, but for security related stuff, it can easily be disastrous.
iririririr | 6 hours ago
NamlchakKhandro | 4 hours ago
I love how people say this like Apple finally created a native solution...
They didn't. It's just a linux vm running normal docker engine.
sunnybeetroot | 3 hours ago
999_cirno | 2 hours ago
OCI compatible, but not docker
https://github.com/apple/container/blob/main/docs/technical-...
Actually makes use of Virtualization.framework mentioned above.
user43928 | 21 minutes ago
Linux VMs are not relevant here. For downloading Xcode and building apps, I believe one needs to sign in with their Apple account.
Does this work well with a macOS VM?
999_cirno | 14 minutes ago
See docs here: https://developer.apple.com/documentation/virtualization/vir...
And projects like Tart, VirtualBuddy, etc. provide convenient wrappers for these APIs.
fragmede | 6 minutes ago
theredleft | 10 hours ago
saagarjha | 8 hours ago
danielheath | 7 hours ago
mikodin | 6 hours ago
0xcrypto | 6 hours ago
NamlchakKhandro | 4 hours ago
aetch | 5 hours ago
justincormack | 22 minutes ago
grahar64 | 11 hours ago
busymom0 | 10 hours ago
awaseem | 11 hours ago
tomaskafka | 10 hours ago
That said, it might be well enough for simpler apps.
tptacek | 10 hours ago
* 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.
waynecochran | 10 hours ago
gwking | 10 hours ago
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.
franze | 10 hours ago
honestly would not even know what to do / click in xcode
supermatt | 10 hours ago
"Next, open Xcode"
zerr | 10 hours ago
philocalyst | 10 hours ago
WhitneyLand | 9 hours ago
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).
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.
bobthebob | 6 hours ago
I only used Xcode to preview the builds on my device and then guide the prompts more
saw66 | 4 hours ago
dostick | an hour ago
octavore | 9 hours ago
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
[1] https://github.com/octavore/tots.app
myko | 9 hours ago
zitterbewegung | 9 hours ago
dvduval | 8 hours ago
geraneum | 4 hours ago
MindSpunk | 2 hours ago
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 | 2 hours ago
> 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!
MindSpunk | an hour ago
I have nothing against the hardware. I despise how artificial the problem is. It's not even like Apple just refuse to provide tools and leave it up to the community. They force you to use a Mac in the terms of service.
For context I work on the mobile team for a large AAA game engine. This is going to colour my opinion because we're very Windows centric, but my experience wouldn't exist if it weren't for Apple. I need to sync code on two different machines and build half the project on Windows and the other half on the Mac. If we could just build and debug the iPhone on Windows none of this mess would be needed.
We don't develop for MacOS, we develop for iOS. Just debugging the app requires several hoops across multiple machines because of Apple's policy here. Just because a base spec Mac Mini is cheap doesn't make this whole problem any less stupid. I don't need a vendor's special-sauce computer to build for consoles. Cross compilation and remote debugging has existed for decades, this problem should not exist.
Calling it more affordable because Mac Minis aren't junk anymore is really just accepting Apple's ridiculous requirement because "I guess it could be worse right?".
eschaton | an hour ago
If you can produce a properly structured submission to the App Store ingestion pipeline without using a Mac, then I doubt Apple will care. But that doesn’t mean they’re obligated to help you, and especially not to spend millions of dollars to do so.
MindSpunk | an hour ago
Apple could've chosen to offer no tools and leave it to the community to build their own. I think that's reasonable. I don't expect Microsoft to bring MSVC to Linux.
But Apple take the explicit position that you must purchase a Mac in order to ship apps for iOS.
eschaton | an hour ago
eschaton | an hour ago
You can develop for Linux and BSD and Haiku and all sorts of other platforms for free. If the cost is what matters to you, then just do that. If you’re doing it as a business, though, consider that you’re extremely lucky to be able to just buy a low-end device and a low-end system and that’s all the capital investment needed (plus the US$100/year membership as recurring opex).
js2 | 8 hours ago
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...
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...
myHNAccount123 | 8 hours ago
Areas they could improve - what ever the heck is going on in their diffing ui for source control.
matthewmueller | 8 hours ago
qpx2022 | 8 hours ago
canthonytucci | 8 hours ago
Using godot iOS export.
For regular old native ios dev replacing Xcode i don’t think i would do it.
stevenhubertron | 8 hours ago
inopinatus | 8 hours ago
https://github.com/inopinatus/sublime_url/blob/main/Makefile
Same shit with a bit of structure.
21-DOT-DEV | 7 hours ago
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).
aabajian | 7 hours ago
IDEs are dead, prove me wrong.
bilekas | 7 hours ago
searls | 5 hours ago
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 | 5 hours ago
sunnybeetroot | 3 hours ago
dostick | an hour ago
leo150 | 5 hours ago
gnachman | 5 hours ago
scosman | 5 hours ago
notimetorelax | 5 hours ago
chrisvenum | 4 hours ago
Ignite is a great starter using RN and Expo. Some great people maintaining it. https://github.com/infinitered/ignite
alana314 | 3 hours ago
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 | 4 hours ago
landseer100 | 4 hours ago
NamlchakKhandro | 4 hours ago
eptcyka | 3 hours ago
resonious | 3 hours ago
pjmlp | 2 hours ago
eschaton | an hour ago
gen2brain | an hour ago
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 .