In October 2026, two iOS apps I had in review received a rejection in a form I'd never seen before. It cited Guideline 4.3 (spam) and 4.2.6 (apps created from a commercialized template or app generation service) together, and then asked: if you believe your app meets the requirements, don't resubmit, but reply with answers to all of the following nine questions.

For both apps, I answered the nine questions by reply alone, without resubmitting or withdrawing. The results split. The shrine visit log app went live 15 days after my reply. The certification exam prep app got a boilerplate response 23 days after my reply, and didn't pass.

This post is the record of those two apps: what the nine questions are, the answers I actually sent, why the results differed, how to read Apple's replies, and what to do before you ship your next app. How I overturned 4.3(a) twice by appeal in September is in part 1.

What you'll learn

  • What the nine-question questionnaire for 4.3 and 4.2.6 asks
  • The answers I actually sent (with English excerpts), and the rules I kept while answering
  • Where the line fell between the app that passed by reply and the one that didn't
  • How to read the outcome from the last sentence of Apple's reply
  • What to do before the questionnaire arrives, before you even submit

The short version

If you get the questionnaire, don't resubmit or withdraw. Reply, and answer all nine questions honestly. Questions 5 to 7 ask directly about the other apps on your account and about shared code. Denying the sharing there is the worst move you can make.

But even with honest answers, the series app that shared its whole engine didn't pass. It shared the engine for questions, scoring, progress and storage with the exam app it was ported from. Even the app that passed had about a fifth of its lines identical to its sibling app when counted line by line. Most of those, though, were boilerplate, and the only things it shared as components were generic ones like purchases and photo resizing. The dividing line wasn't the share of lines but whether the app's core was shared. Even an engine you wrote yourself seems to make Apple see the app as "made from a template" if it's the same as one of your apps already on the store. If you plan a series of apps on the same engine, it's safest to plan on only the first one getting through.

What happened

My account has more than ten apps. I reused generic components, such as purchases and photo resizing, across them.

Date What happened
Sep 25 Resubmitted the exam prep app from part 1 (a port of my published exam app to a different certification) on its own, rebuilt from the screen skeleton up
Oct 6 The exam prep app was rejected with the nine-question questionnaire. Replied with answers the same day
Oct 11 Submitted a shrine visit log app for the first time
Oct 13 The visit log app got the same questionnaire. Replied with answers the same day
Oct 22 A tide app for anglers, submitted the day before, got an ordinary 4.3(a), not the questionnaire. Appealed by reply
Oct 23 The tide app's 4.3(a) was withdrawn. It passed and went live
Oct 28 The visit log app went live (15 days after my reply)
Oct 29 A boilerplate response for the exam prep app. It didn't pass (23 days after my reply)
Nov 2 Decided not to resubmit the exam prep app in its current form, and not to appeal to the App Review Board

The visit log app isn't part of a series the way the exam apps are. But the same account has a map app for places you want to visit, built in the same shape ("drop a pin on a map and attach photos"), and the two shared generic components. My read is that the questionnaire goes to accounts that have a sibling app with a similar shape (a guess based on only two cases).

What the nine questions ask

The rejection cited three guidelines: 4.3(a), 4.3(b) and 4.2.6. It then asked for answers to the following nine questions (paraphrased, not Apple's exact wording):

  1. What does the app do, and what problem does it solve? (No recycled marketing copy)
  2. Who is it for?
  3. What gap in the market does it fill?
  4. Did you run a beta test? What did you change based on the feedback?
  5. Is it a standalone product, or part of a series?
  6. Could it be offered as an in-app purchase or added feature of another app?
  7. Does it share code or assets with your other apps?
  8. Does it share code or content with other companies' apps?
  9. Was it made for a client or partner, or did you use a template?

Questions 1 to 3 are about the app itself, and 4 is about how you made it. The crux is 5 to 7. They ask straight out about your relationship to the other apps on your account, whether the app could be folded into another one, and whether you share code. Questions 8 and 9 check for code or templates brought in from outside.

The answers I actually sent

Before writing the replies, I settled on these rules:

  • Don't resubmit. The rejection says plainly to reply with answers instead of resubmitting
  • Don't withdraw. In September, with another app, once I withdrew it I could no longer reply in the Resolution Center. Your path to appeal closes
  • Disclose sharing honestly. If you deny it and it comes out later, you lose trust for your whole account, not just that app
  • Don't make anything up. For question 4, if you didn't run a beta test, say you didn't

I drafted the replies with Claude Code, and before sending them I checked them myself for anything that wasn't true. Both replies open by saying the app had not been resubmitted.

Thank you for the detailed questions. We have not resubmitted the app.
Our answers to all nine questions follow.

In the English excerpts below, app names and similar details are replaced with [ ].

Questions 1–3: be specific, in the domain's own vocabulary

For question 1, I wrote in the domain's own terms instead of about "useful features." For the shrine visit log, I started from the problem: a paper goshuin book (the book of handwritten shrine seals that visitors collect) can't show you where you've been, how many times, or how many prefectures you've covered. Then I listed the shrine database I built myself from open data, and a map of Japan's prefectures that fills in as you visit. For the exam prep app, I described what's hard about that exam (applying the figures in the legal provisions to cases) and the calculation features for practicing it.

For question 3, I didn't name competing apps. I described them by type, for example: existing shrine apps are mostly information services.

Question 4: if you didn't run a beta, say so

Neither app had been through an external TestFlight beta. So I said so, and then listed what I had fixed through my own testing on a real device and through automated tests.

4. Beta testing
We did not run an external TestFlight beta for this version. The developer
tested development and Release builds on a personal iPhone from late September
until submission, alongside automated tests (46 unit tests, and UI tests for
the main flows). Changes made as a result of this testing include:
- an automatic cropping feature for goshuin photos did not work reliably on
  real photos, so we removed it rather than ship it;
- there was no way to tell whether iCloud sync was working, so Settings now
  shows the iCloud status with guidance;
(...)
We do not have external beta feedback to report.

Questions 5–7: name the components you share

Before replying, I compared the source against the sibling app and counted the sharing component by component. Counting identical lines alone also picks up lines that show up even in unrelated apps, such as boilerplate SwiftUI. I subtracted those and worked out what was really shared as components.

For the visit log app, here's how much the number changes depending on how you count:

How it was counted Share identical to the map app
All identical lines, excluding blank and short lines about 21%
Of those, excluding boilerplate lines that also appear in my other, unrelated apps about 8%
Components shared almost as-is (7, including purchases, photo resizing and location; 243 lines) about 5%

The exam prep app shared its engine for questions, scoring, progress, storage and purchases with the exam app it was ported from. Component by component, the engine parts were 65–100% identical, and the screens and calculation features were 0–57%. Across the whole app, about 30% of the lines were the same as in the original. On line share alone, that's not very different from the visit log app's 21%. What was different was that the matching part was the app's core. I said exactly that in question 7, and listed what wasn't shared (the questions and explanations, the calculators, the mock exams, the design of every screen).

7. Code and assets shared with our other apps
Yes. This app shares an internal quiz engine, which we wrote ourselves, with
[our other exam app]:
- question repository: loads the bundled question files;
- quiz engine: builds sessions by unit, tag or mock-exam composition, shuffles
  the answer options and scores;
- progress tracking: mastery tags, daily goal and streak;
- data persistence: SwiftData models for answers and progress;
- purchase manager: StoreKit 2 handling of a single non-consumable unlock.
Most of the source in these components is the same. Not shared: all question
content, explanations, study notes and frequency data; the two calculators;
(...) all screens and the visual design, which were rebuilt for this app; and
the app icon, screenshots and description. Overall, roughly a quarter to a third
of this app's source lines also appear in the other app.

For question 6 (could it be folded into another app), I admitted it was technically possible, and then explained why I hadn't done it.

6. Consolidation into another app
Technically, this question bank could be sold as content inside [our other exam
app], because both use the same quiz engine. We did not consolidate them because
the two audiences do not overlap, and candidates find exam apps by searching for
the exam's name
(...)

The visit log app's answer to question 7 covered only generic components.

7. Code and assets shared with our other apps
Yes. [The app] was written first, and when we built [our map app] we reused
some of its general-purpose components, which we wrote ourselves:
- purchase manager: StoreKit 2 handling of a single non-consumable unlock (our
  other apps use a similar one);
- photo processing: resizing and compressing attached photos;
- location service: When-In-Use permission and the current location;
(...)
These components are about 5% of [the app]'s source. Counting all identical
lines, about a fifth of [the app]'s source also appears in [our map app], mostly
common SwiftUI layout code. Not shared: the shrine database and the scripts that
build it, search, the map screens and pins, the prefecture map, the goshuin book,
the ledgers, the almanac calculations, statistics, the yearly summary, the route
replay, the widgets, onboarding, the visual design, the icon, the screenshots and
all text.

For question 6, I wrote that the app's core (the shrine database, the prefecture map, the goshuin book and so on) is specific to shrines, so putting it inside the map app would mean building a separate app inside that app. I also wrote that the people looking for each app, and the words they search with, are different.

Questions 8–9: list what came from outside

For question 8, I listed the frameworks each app uses: only Apple's own for the exam prep app, and the same plus one anonymous analytics SDK for the visit log app. If you use open data, also explain how you comply with its license.

For question 9, I answered that the app wasn't made for a client or a partner, and wasn't built with a commercial template or an app generation service, and added that I was submitting it as the provider of its content. Guideline 4.2.6 rejects apps created from a commercialized template or app generation service unless they're submitted by the provider of the app's content. I write my code with AI assistance, but since that wasn't asked, I didn't mention it in the replies.

Length

Answering every question makes for a long reply. The visit log app's reply came to about 9,700 characters in English. In case the input field rejected it, I decided in advance where to split it into two messages: just before question 5.

Result: the app that passed and the app that didn't

Shrine visit log (passed) Exam prep app (didn't pass)
Sibling app with a similar shape A map app for places you want to visit The exam app it was ported from
What it shared 7 generic components (purchases, photo resizing, location and others; about 5% of the whole) The engine for questions, scoring, progress, storage and purchases (65–100% identical per component)
Share of identical lines about 21% (mostly boilerplate) about 30%
Question 6 (could it be one app?) The core is specific to shrines, so it can't be merged Admitted it could technically be sold inside the other app
Apple's reply A short note saying they would continue the review Boilerplate that didn't address the nine answers (23 days after my reply)
Outcome Went live 15 days after my reply Won't pass in its current form

Apple's reply for the visit log app was short: thanks for the information, they would continue the review, and they would let me know if any further issues came up. After that, the app went live.

The reply for the exam prep app was boilerplate that didn't touch any of my nine answers. Its point was that apps built from a template of an app already on the App Store tend to offer a similar experience, which makes them "a form of spam."

The text of Guideline 4.3(a) itself already says, in essence: instead of releasing a separate app for each location, sports team, university and so on, consider putting them into one app and offering the variations through in-app purchase. In question 6, I had answered that the exam prep app could technically be sold inside the other app. By answering honestly, I had admitted that it was exactly the shape the guideline recommends consolidating.

As I wrote in part 1, I had decided not to merge the exam apps into one, but to rebuild the presentation and ship them one at a time, spaced apart. Rebuilding from the screen skeleton up and shipping it alone didn't get it through as long as it shared the engine. It's a read from just two results, but I believe a series that shares an engine won't get through the questionnaire, as long as you answer honestly. I took it to mean that even an engine you wrote yourself gets treated as a "template" if it's the same as one of your apps already on the store.

I also considered appealing to the App Review Board. But given the guideline's wording and my own answer to question 6, I had nothing to argue with. The exam was close, so even if the app passed now, there would be almost no selling season left. I decided not to release this app this year.

Even so, I think answering honestly was the right call. If you get through by misrepresenting things and it comes out later, it becomes a problem for your whole account.

You can read Apple's reply from its last sentence

Apple's replies are mostly boilerplate, but the closing sentence told me the outcome.

Situation How the reply closed What happened next
September: appealed an ordinary 4.3(a) and won Waiting for "your resubmission" (of this app) I fixed a separate issue (2.3.7) and resubmitted
October: questionnaire answers that passed "We will continue the review" Review continued without a resubmission, and the app went live
October: questionnaire answers that didn't pass Waiting for "your future submissions" (other, later submissions) This app won't pass in its current form

The two that passed both kept talking about this app. Only the reply that didn't pass moved on to the next, different submission. When a reply arrives, read the last sentence first.

An ordinary 4.3(a), without the questionnaire, fell to a single reply

On October 22, my tide app for anglers got an ordinary 4.3(a), not the questionnaire. It came within a day of submission, with the Extended Review warning that mentions removal from the Developer Program. The comparison was with apps from "you or other developers." Tide and fishing apps are a crowded genre, with more than 100 released in 2026 alone.

I had submitted this app with the answers to the nine questions already in the review notes. It didn't prevent the rejection. In question 7 of those notes, beyond the components it shared (11 files, about 10% of the code), I had even volunteered that about 32% of its lines, counted one by one, also appear in my other apps (mostly one-line SwiftUI boilerplate). That number may have caught the reviewer's eye. From a single case, though, there's no way to know.

The reply didn't repeat the nine answers from the review notes. I narrowed it to four things:

  1. The processing only this app does, described concretely (it reads tide tables on the device and draws the tide curve; it computes the traditional Japanese lunisolar calendar in Japan time by itself, with tests that check it against the tables of the National Astronomical Observatory of Japan; and so on)
  2. Where on screen the reviewer can see all this in two minutes
  3. The scope of the shared code, stated honestly (11 files, about 10%)
  4. A request: if they judged it similar to specific apps, please name them

When "other developers" are part of the comparison, I first said that I know the genre is crowded, and then laid out the differences.

We know that tide apps are a crowded category in Japan and that our account
has published several apps, so we want to show concretely what this app does
and where it differs.
(...)
If the decision is based on specific apps, ours or another developer's, we
would be grateful if you could name them, so we can answer the actual overlap.

The day after my reply, the 4.3(a) was withdrawn, and the app passed and went live. No changes to the code or the build. Even with about 32% identical lines, an app whose core processing was its own got through. That's the third ordinary 4.3(a) I've overturned by reply alone, after the two in part 1. If your app's concept is independent, the standard play is to appeal by reply first, even in a crowded genre.

Don'ts

  • Resubmitting. The questionnaire says explicitly to reply instead of resubmitting. You're also warned that repeatedly resubmitting apps rejected under 4.3 can get you removed from the Developer Program
  • Withdrawing. The reply thread closes, and you can no longer appeal
  • Denying the sharing. A false answer to questions 5 to 7 damages trust in your whole account
  • Claiming a beta test you didn't run. For question 4, "we didn't" is fine
  • Submitting new apps from the same account one after another while you wait. In September, right after I submitted new apps in quick succession, the new apps in review went down together (part 1). Updates to apps already on the store, on the other hand, kept going through even while the dispute was open

Before you submit

  • Count what you share with sibling apps, component by component. You'll be able to answer question 7 by naming the components, and you can check whether you share too much before you ship. The number changes a lot depending on how you count (21% of identical lines became about 5% as components), so keep both. More important than any percentage is whether you share the core processing
  • Run an external TestFlight beta. For both apps, I ended up writing "we didn't" for question 4. If you're shipping apps of a similar shape one after another, bringing in external testers from the start makes that question easier to answer
  • With a series on the same engine, assume only the first one gets through. If you want to expand by swapping only the subject, plan from the start on one app with in-app purchases for each variation, as 4.3(a) suggests
  • Assume the questionnaire can come just because you have an app of a similar shape. The visit log app wasn't part of a series. There was only an app with a similar shape on the account

Summary

  • The nine-question questionnaire for 4.3 and 4.2.6 came to an account that had a sibling app with a similar shape (both times)
  • Without resubmitting or withdrawing, I answered all nine questions honestly by reply. The visit log app, which shared only generic components, went live in 15 days. The exam prep app, which shared its engine, didn't pass. The identical-line shares were about 20% and about 30%; the dividing line was whether the core was shared
  • You can read Apple's reply from its last sentence. "We will continue the review" or "your resubmission" means they're still talking about this app. And "your future submissions" means it won't pass in its current form
  • An ordinary 4.3(a) without the questionnaire fell to a single reply, even in a crowded genre
  • Before you ship a new app, count what you share component by component, and get an external beta done

How it all started, with three apps rejected under 4.3(a) at the same moment in September, is in part 1.

Part of a series on indie iOS development from Japan. Japanese original: App Store 4.3の「9問の質問票」｜返信で通った・通らなかった. Related in English: Automating App Store Connect Metadata With the API. More: Village Gazette in English.