Matthew

Day 6 of getting an #ios app on the App Store by the end of the year. After a few straight days of doing Apple’s Scrumdinger tutorial, decided to take a detour and mess around building a wallpaper app. Won’t launch, just wanted to build something for a bit.

The @a0_dev app got taken off the store 3 months ago and we made SEVERAL appeals with Apple to get it back to no avail. We've since gone with a different solution. A lot of people seem to have no idea what's really happening here so I want to share my thoughts. Apple removed our app and is blocking updates / releases to many other apps for Guideline 2.5.2, this guideline prohibits downloading and executing code inside of an app that changes features of functionality of the app. Our app and many other apps download the code for a users app so that it can be previewed on a users device with native capabilities. It's a matter of convenience, we want users to be able to download one app so that they can quickly test the many apps that they are building. There are many other ways for users to preview their mobile apps that are a much worse experience. The other options include TestFlight, previewing on the browser, using the Simulator on Mac, and downloading an ad-hoc build to a users device. Using TestFlight means users have to sign up for a $99 developer account and create a store listing just to upload their build just to test the app they're trying to build. It requires too much effort and money for new users who just want to try the app they've built and there's no way to let other people test the apps without adding them to your developer account or submitting your app for external TestFlight review which can add a multi day delay. Previewing the app on the browser is another popular solution with many problems. The browser preview is ugly and can't access native functionality. There are MANY features that don't work on the browser and the app doesn't look or behave the same as it does on an actual device. It's helpful for our users building apps on our website but doesn't test the real app. Ad-hoc builds needs to be signed for a user's device and require a very convoluted process to get the user's Device ID which include entering developer mode on your phone, a security delay from apple, and can also require a paid developer account if you want the builds to last longer than a few days. It's easy to see why we and many other vibe coding apps have chosen to allow users to instead download a single app and execute the code for their app inside of it. It reduces friction, saves money, and time. The 2.5.2 Guideline already has an exception for Educational apps and I think it should be extended to support Developer Tools. For Apple this is simply a matter of control, they want app developers to buy a Mac, download Xcode, and use the Simulator or TestFlight just to preview an app they're trying to build. There are many people who are seemingly happy about this and think that this will help improve their app review times or stop 'vibe-coded' apps from entering the app store. Those people are fools. The decision has nothing to do with the quality or volume of apps or how they are made. It's about how hard it is to test them. The only thing that will improve your app review times is Apple hiring more reviewers or relaxing the rules. Apple is a nearly $4 trillion company. Trust me, they can afford to hire more reviewers. Instead they've chosen to make the app testing process harder in an attempt to keep more control. We will continue making apps anyway.

Apple Quietly Blocks Updates for Popular 'Vibe Coding' Apps macrumors.com/2026/03/18/app…