One morning I bundled a few small fixes and went to submit an update, only to find App Store Connect refusing to move forward. Every one of my live apps was showing the same notice at once: "Please respond to the age rating questions."
The deadline was January 31, 2026. Until the answers were complete, no further updates could be submitted. Even a quiet genre like wallpaper apps was no exception. As someone running several apps in parallel as an individual developer, it was an unglamorous but unavoidable gate.
This article is a step-by-step record of what I noticed while actually working through it. Apps you publish with Rork or Rork Max pass through the same gate, so I hope it also serves as background reading if you are about to ship to the store for the first time.
The rating tiers themselves changed first
The old set of 4+ / 9+ / 12+ / 17+ has been revised into finer steps. The 12+ and 17+ tiers are gone, and 13+, 16+, and 18+ have been added.
| Before | After |
|---|---|
| 4+ | 4+ (unchanged) |
| 9+ | 9+ (unchanged) |
| 12+ | Folded into 13+ and re-evaluated |
| 17+ | Split into 16+ / 18+ |
The easy thing to miss is that existing apps are re-evaluated automatically, and the store listing can change before you touch anything. In my case, some apps that had been 4+ stayed 4+, while others sat in a held state until I completed the re-evaluation. I would suggest comparing each app's current rating in both the store and App Store Connect before you submit.
Four new question categories
The heart of this update is not the naming of the tiers but the questions themselves. A new, required set of questions now applies to every app, across four categories.
| Category | What it asks | My call for a wallpaper app |
|---|---|---|
| In-app controls | Whether age-based limits or parental controls exist | Not applicable. But apps with report/block can answer "yes" |
| Capabilities | Presence and frequency of user-generated content, web views, messaging, AI chat, etc. | Carefully reviewed how web views are handled |
| Medical or wellness | Whether the app covers medical or wellness topics | Not applicable |
| Violent themes | Presence and frequency of violent themes | Not applicable |
Even for a mild app, the place where the rating can quietly creep up was the Capabilities section. Here you declare, among your app's features, how frequently user-generated content, external web display, and AI assistant or chat functionality might expose sensitive material.
For example, even an implementation that only opens your terms-of-use web page from the settings screen can drift toward a higher tier if you answer "displays web content" too broadly. I had to check the real reach of each feature, one capability at a time.
Apple asks developers to consider how all features, including AI assistants and chatbot functionality, affect the frequency of sensitive content. As more of us fold generative AI into apps, this has become a section to answer more carefully than before.
New room to set a higher minimum age
Another element added in this update is the ability for developers to set a minimum age higher than the rating Apple calculates.
You use this when your app's own policy requires a higher age than Apple's assigned rating. After answering the questions, you can choose a higher tier from the App Information section in App Store Connect.
I did not need to raise it for my wallpaper apps, but for apps with community features or subscription-gated services, it strikes me as a useful option for keeping your policy and your displayed rating aligned.
Back up in-app controls with real implementation
Your answers for "in-app controls" and "capabilities" need to match your actual implementation, not just a verbal declaration. If you handle user-generated content, the honest path is to build protections such as reporting and blocking, and then answer accordingly.
The thinking is the same for apps built with Rork or Rork Max. If you want a minimal reporting path in React Native / Expo, something like this is a starting point.
// A minimal report / block path.
// Backs up answering "there are in-app controls."
import { useState } from "react";
import { Alert } from "react-native";
async function reportContent(itemId: string, reason: string) {
const res = await fetch("https://YOUR_API_HOST/api/reports", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ itemId, reason, at: new Date().toISOString() }),
});
if (!res.ok) throw new Error("report_failed");
}
export function useModeration() {
const [blocked, setBlocked] = useState<string[]>([]);
async function onReport(itemId: string) {
try {
await reportContent(itemId, "inappropriate");
Alert.alert("Received", "We will review this within 24 hours.");
} catch {
Alert.alert("Send failed", "Please try again in a little while.");
}
}
function onBlock(userId: string) {
setBlocked((prev) => (prev.includes(userId) ? prev : [...prev, userId]));
}
return { blocked, onReport, onBlock };
}What matters is that the declaration and the implementation agree. Answering "controls present" without a reporting path creates a discrepancy at review. Conversely, forgetting to declare a protection you do have can push you into a higher tier than necessary.
If you handle a user's age, note that a separate Declared Age Range API exists to receive an age band without collecting a birthday. The rating declaration and user-side age verification serve different purposes, so keeping them mentally separate makes the whole thing easier to reason about.
The steps I actually followed
Here is the flow, as it was, from checking my apps one at a time.
| Step | What to do |
|---|---|
| 1 | In App Store Connect's App Information, check the current rating and any unanswered questions |
| 2 | Answer the four categories to the extent your implementation supports (avoid answering too broadly) |
| 3 | Inventory each capability: web views, external links, purchases, reporting paths |
| 4 | Review the calculated rating and raise the minimum age if your policy requires it |
| 5 | Check the store-side rating too, and reconcile any mismatch with your expectations |
Going one app at a time, I noticed that even apps with the same structure ended up with slightly different answers. The presence of a web view, the number of external links, the type of purchases: those small differences fed straight into the final tier.
What I took away
What stayed with me after finishing was the sense that a rating is no longer a one-time setting; it has become something you maintain, revisiting it each time features grow.
When you later add features such as AI chat or user posts, whether you keep the rating impact in mind makes a real difference to friction at review. Adding a single line, "impact on the rating questions," to the checklist of a feature PR made the next submission considerably smoother.
The next time I ship a new app, I plan to revisit these four categories while designing features, not right before release. It is a small bit of preparation, but it had a real effect in sparing me a scramble at the deadline. I hope it helps with your own implementation, and thank you for reading.