Why we will not put your app on the App Store this week
An honest walk through Apple's requirements — the membership, the review of every version, and rule 4.2, which exists to reject apps like the ones we generate today.
Somebody asked us to put their app on the App Store recently, and the honest answer took three paragraphs. Here it is properly, because the same answer is owed to everybody.
First: is your app a website in a box?
Today, technically, yes. The app we build wraps your web app in a native shell. Google is relaxed about this and such apps pass routinely. Apple has a guideline — minimum functionality, commonly called 4.2 — which exists specifically to reject apps whose only content is a website.
We could dress this up. We would rather say it plainly, because the consequence of being wrong lands on you: a rejection after you have paid for a developer membership and waited weeks for a business verification.
Second: the account has to be yours
An Apple Developer membership costs money every year, and if it is a company account, Apple wants a business registration check that takes weeks. We do not hold it on your behalf. The arrangement we think is right is that you own the account and add us to your team, so you can remove us at any time and we never hold your signing key.
Third: every version gets reviewed
Not just the first one. That means the ten-second change you are used to becomes a change, a build, a submission and a wait. Which is fine, as long as nobody told you it would be instant.
What we do instead of guessing
Before any submission we check the app ourselves twice, and the two checks are deliberately different.
The first is mechanical: does the code actually use something a phone can do that a browser cannot — a camera, a location, a fingerprint, real offline use. Instant, and it runs before you pay anything.
The second is a reading of the app, asked the real question: would a customer lose anything by using the website instead? That check exists because the first one cannot tell a real capability from a token one — and on the very first app we ran this on, the mechanical check found an offline capability present while the reading found it only cached one page for a faster reload. Both were looking at the same file. A reviewer would have called that a token.
The decided answer, and when
Notifications. A shop or a clinic has a genuine use for them, Apple treats them as meaningful functionality, and they cannot be done from a browser tab on an iPhone. That is the next capability to build, and it should be built before a first submission rather than after a first rejection.
Until then: the free home-screen route works today, on every iPhone, and nobody reviews it.
Build the thing this is about
Ask for access and a person reads it. You start with 300 free sparks, about forty changes.
Request access Take the free founder test
Access is by invitation and a person reads every request. The founder test is free, takes a few minutes, and tells you what you are getting before you commit to anything.