Vibe coding is great for the App Store economy, but Apple is still wary about its use without safeguards in place. It's a fine balance that's going to be hard to maintain.
The concept of vibe coding has risen in tandem with AI chatbots in recent years. Infiltrating many areas of the development process, it has turned the process of making an app into child's play.
However, while it has its benefits and issues, there are also some areas that Apple is really worried about. Stuff that it is really keen to avoid becoming a serious problem in the future.
It's something that Apple really wants to sort out now before it becomes a real issue.
What is vibe coding?
Vibe Coding, simply put, is the idea of making an AI chatbot create code for you. At its minimalist level, you tell a chatbot to make something, potentially with some basic specifications or guidance to follow, and it produces the app on its own.
It could be as simple a prompt as "Make me a driving game" or "Create an egg timer that can be adjusted to various durations, and with varying alarm sounds."
The idea is one that makes it extremely easy for anyone to make an app that they want to use. It takes away the harder elements of learning how to code, how to structure a program, or even knowing how to properly use a development environment like Xcode.
Connect ChatGPT to Xcode and you can ask the AI chatbot to help you make apps.
You could call it a natural but extreme extension of existing code-assistance tools developers already have access to for their work. A developer writing some script can be offered a ready-made element to complete the code, which can save them precious seconds of time.
Vibe coding goes multiple stages further, as you are effectively handing over the majority of the initiative over to an AI. It will follow whatever coding practices it has picked up when scouring the Internet, and produce an app in its own way, fulfilling your prompt.
In some cases, users simply ask for an app to be made and then use the app without examining code or questioning any element. They may give some feedback about a feature, such as asking for changes in font size or color, but the users may not even care about what processes have been undertaken.
The whole concept of telling an AI chatbot what to do goes beyond coding. You can also ask them to create designs and other things in apps, albeit with varying degrees of success.
When it comes to whether vibe coding is a good thing to allow or not, you have to look at it from two angles, as Apple currently does. There's the case for it being used to make apps, but then there's the issue of allowing vibe coding to occur beyond the App Store.
Vibe coding as an assistant
One of the areas that is completely fine to Apple is vibe coding outside of the App Store. Making apps to run on a Mac using an AI agent is perfectly fine to Apple.
Indeed, it even encourages it.
For quite some time, you could connect your choice of AI tool to a development environment to make edits to code. With increased integration, the developer environment can be used to the fullest extent by the AI agent, opening the door to full-blown project creation.
This was something that Apple introduced in Xcode 26.3. By enabling more access for AI services, it allowed for the creation of complete apps that followed Apple's developer guidelines.
This can be a shockingly fast process too. As I found out in February connecting ChatGPT to Xcode, I was able to build a simple Pomodoro timer app and see it working on the Mac screen within two minutes.
A few button presses later, and I saw the exact same app working on a connected iPhone.
Vibe-coding a Pomodoro app within minutes using a simple prompt in Xcode.
This entire process democratizes app development, since you don't need to know how to use Swift to create an app for your iPhone anymore. If you can describe it well enough to be understood by the AI, and if you don't care too much about the exact result you get, the app will be usable enough.
Of course, you don't have to settle for what the AI produces.
AppleInsider readers will be familiar with my development of a game, with the help of ChatGPT in Xcode. Rather than go full-on with vibe coding, I instead took the more careful route of making small and purposeful changes over time.
Every request was considered carefully, with the results checked thoroughly and corrected if needed before moving on. Less vibe coding, more being a project manager in control of a virtual programmer who knows everything about the topic.
It's entirely possible that someone can vibe code the same game without too much trouble. But at the same time, they won't know what will happen if something goes wrong and needs to be fixed.
They also won't necessarily have a result that matches their vision.
The same Pomodoro app on an iPhone, minutes later.
A vibe coder may want to include a feature in their app that they saw elsewhere, and simply ask the AI to do it. But, unless you know exactly how that feature operates and any other underlying elements the other app's developer took into account, and somehow explain that to the AI perfectly, it won't be a direct copy.
Sometimes, it's the execution that actually matters.
With the Xcode integration enhancements, it's safe to say that Apple is fine with people doing vibe coding in this way. Indeed, it's something that has helped send a surge of apps through to the App Store review submissions process.
For Apple, vibe coding means more apps in the App Store, and more opportunities to earn from it.
At least, this sort of vibe coding is the version it's fine with.
Beyond the App Store
The other kind of vibe coding that Apple has to deal with is the version that happens on an iPhone or iPad. This one is a problem because it's something Apple can't directly control.
Apple has consistently prevented anyone from being able to compile apps for the iPhone and iPad on the actual hardware. Sure, there's some coding capability in Swift Playground, but that is a carefully managed experience, and you can't create a separate standalone app.
This is not a technical limitation of the hardware, as an iPhone or iPad is a computer in its own right and easily capable. But it is a limitation of permissions for a few good reasons.
The App Store Review Guidelines, which app developers must follow, have rules preventing anyone from compiling code. That is, you can't submit an app that generates code that can then run on the same iPhone or iPad as an app in its own right.
The rules make sense if you consider why the App Store Review Guidelines exist. One of the reasons is to maintain security and privacy, which it does so by checking apps that are submitted to the App Store for potential dangers.
The App Store Review process does accept vibe-coded apps.
For an app capable of coding and compilation, that means it's possible for apps to be produced beyond the reach of the App Store Review Guidelines. Apple simply cannot check these generated-on-device apps at all.
The worst-case scenario is for someone to make malware on the iPhone or iPad directly, then use it to cause havoc.
With the capabilities of vibe coding as they are, if there are no guardrails in place, a user could create a prompt to make that hazardous software, with no oversight or protections in place.
There is also the argument that Apple would lose potential sales due to users making their own apps. But, in the face of possible malware generation and the potential harm to both the user's private data and those of other victims, it's not the one people should be worried about.
Of course, there are ways to enable vibe coding without running afoul of Apple's guidelines.
For a start, the compilation could happen off-platform. Think of someone making a web app that is hosted on a server elsewhere, but using an iPhone app as a means to design it.
With the more recent development of AI chatbot services where the AI controls a user's computer elsewhere based on prompts from a mobile app, it's the same sort of remote-compilation workaround.
Vibe-coding by telling an AI prompt on your iPhone to build something on your Mac isn't against Apple's App Store's rules.
Replit was hit by Apple's strict rules, but it fixed things and started getting updated again.
A timely example is Apple's handling of Replit, which saw updates to the app being declined in January. Apple pushed back because it wasn't happy with users being able to preview AI-built apps on the iPhone, which goes against rules about dynamically executed code.
In May, Replit made a number of changes to appease Apple and allow the app to be updated. The two "worked things out" without there being any real explanation of what changed, but it probably involved changes to that preview mechanism.
Right, but for how much longer?
Apple is, so far, handling the issue of vibe coding pretty well. Really, it's two issues, and it has gone with the right answer for each one.
Using vibe coding for apps entering the App Store is a completely natural and expected use of the technology. For Apple, the only real downsides are dealing with a greater influx of apps to check and the possibility of the app flood making the market tougher for developers to sell their apps.
These are issues that can be solved by coming up with new ways to process higher numbers of apps, and to aid users in discovering the best apps for their particular needs.
The other side of the equation, the whole business of making apps on an iPhone that aren't checkable by Apple's workforce, is also being handled appropriately right now.
Apple is the judge, jury, and executioner when it comes to the App Store's vibe coding apps.
Apple simply cannot check that a vibe-coded app theoretically running on the iPhone it was created on is actually safe. There are echoes of the whole third-party app storefront arguments when it comes to safety.
Again, I feel Apple is doing the right thing here. It doesn't want an uncheckable piece of world-destroying malware to be made on an iPhone.
It could be proposed to Apple that it handles apps on an iPhone in the same way as on Mac. A platform that has to deal with apps downloaded from the Internet thanks to a notarization process where Apple checks the app before it becomes downloadable.
There's more to the issue than that, but macOS proves that it can be done with relative success.
The real problem comes when the major AI players step in and demand that Apple allow for vibe-coded apps to be made and used on the same iPhone.
Despite protestations, Apple will eventually have to decide whether to allow them and deal with the safety and privacy issues, or risk losing out by angering OpenAI, Anthropic, and others.
It's a problem Apple will have to face and solve at some point down the road. With the rate of change in the AI field, that time could come sooner than anyone thinks.
