A fundraising app for schools is a donation page with two gates in front of it.
A fundraising app for schools is not a harder version of a donation page. It is a donation page with two gates in front of it. The first is Apple's rule on collecting money for a cause: an app that is not an approved nonprofit must be free and take the money outside the app. The second fires the moment a pupil appears on screen. Everything past those gates is the same work as other fundraising apps, and it is the easy part.
This page covers which of your users count as children in law, what the Kids Category costs a donation flow, how the money moves from a parent to the PTA account, and what a school fundraiser app should do instead of what people usually ask for.
See which rules your feature list turns onThe short version
The app is the easy part. The two gates in front of it are not.
Two rules decide the shape of a school fundraiser before a screen is designed. App Store guideline 3.2.2(iv) blocks collecting funds in the app for a charity or fundraiser unless you have been through nonprofit approval. And any part of the product a child uses pulls in children's privacy law, which the App Store then enforces on its own terms as well.
Neither rule is negotiable and neither is discovered cheaply. Most teams meet both in App Review, after the build, in the week the fundraiser was meant to launch.
Work out who the users actually are
Write down who will open the app. For most school fundraisers it is parents, grandparents, a few staff, and whoever a parent forwards the link to. Children are the subject of the app rather than users of it. That distinction decides which law applies, so settle it before anyone argues about features.
The Children's Online Privacy Protection Rule is explicit about its own scope. Under 16 CFR 312.3 it is unlawful for any operator of a website or online service directed to children, or any operator that has actual knowledge that it is collecting or maintaining personal information from a child, to collect personal information from a child in a manner that violates the rule. A child is defined in 16 CFR 312.2 as an individual under the age of 13. Two triggers, then: the service is aimed at children, or you know you are collecting from one.
An app where adults donate and adults type the data usually hits neither. Add pupil logins, pupil written messages or pupil uploaded photos and the second one fires. Then 312.3 requires notice of what you collect, verifiable parental consent before any collection, a reasonable means for a parent to review and refuse further use, no conditioning participation on extra data, and reasonable security. Consent is per child and it comes first, not at the end of the campaign.
What the Kids Category costs a donation flow
If the app really is aimed at pupils, the App Store has a category for it and a price for entering. Guideline 1.3 says these apps must not include links out of the app, purchasing opportunities, or other distractions to kids unless reserved for a designated area behind a parental gate. A donate button is a purchasing opportunity. A link to your payment page is a link out. Both have to sit behind an adult level task, and the app has to keep meeting the rules in later updates even if you deselect the category.
The same guideline says Kids Category apps may not send personally identifiable information or device information to third parties, and should not include third-party analytics or third-party advertising. The exceptions are narrow: analytics that transmit no IDFA and nothing identifying children, their location or their devices, and contextual advertising human reviewed for age appropriateness. A payment SDK, a crash reporter and an analytics SDK are the first three things most teams install.
Guideline 5.1.4 makes the point people miss. It says the parental gate requirement is generally not the same as securing parental consent to collect personal data under these privacy statutes. So for almost every school fundraiser the answer is to stay out of the category, build the donation app for adults, and if you want something for pupils make it a separate app with no money in it.
App Store Review Guidelines, 1.3 Kids Category and 3.2.2(iv)
Try it
Which rules your feature list turns on
Tick what the app will do. Each one pulls in a rule you have to design around, and none of them is cheap to discover during App Review.
Nothing extra so far
An adults only donation app that links out to a hosted checkout is the plainest version of this product, and the fastest to ship.
How the money actually moves
Apple's position on collecting money for a cause is short, and it is the rule school apps discover late. Guideline 3.2.2(iv) lists as unacceptable the collecting of funds within the app for charities and fundraisers, unless you are an approved nonprofit or otherwise permitted under 3.2.1(vi). Apps seeking to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.
Guideline 3.2.1(vi) is the way through. Approved nonprofits may fundraise directly within their own apps or third-party apps, provided the campaigns follow the guidelines and offer Apple Pay support. Those apps must disclose how the funds will be used, abide by required local and federal laws, and make sure tax receipts are available to donors. If the fundraiser runs through a district or a booster club rather than your own recognised charity, find out whose registration the app would trade on before designing a checkout.
For most schools the boring answer wins: the app opens a hosted checkout in the browser, the money lands in the account that already receives it, and the app never touches a card number. The people side is a separate product and usually the one that fails first, so shifts, reminders and no-show records belong in a volunteer management app. Splitting them keeps permissions simple, because a parent signing up for a two hour shift has no business seeing donation records.
What a school fundraiser app should actually do
Ask what the fundraiser fails on today and it is rarely the payment. It is that nobody knows the running total, the same twelve parents do everything, and the class comparison is out of date by the time it is printed. So the useful build is small: a live total, a breakdown by class or form group, a share link a parent can send to relatives, a list of pledges that never converted, and a way to record cash and cheques next to the card donations. None of it needs a child to log in.
A classroom fundraising app for one teacher and thirty families is a far smaller thing than a district platform, and it is usually the one that gets used. Scope it to the fundraiser you are running now and let the second one tell you what to add.
A fundraiser is one week out of a relationship that runs all year, so the same audience tends to want a parent teacher communication app next. Whether that is one app with two tabs or two apps is a real decision, and it turns on who administers it. A PTA committee that changes every September is not the same operator as the school.
What each route gives a school fundraiser
| Route | Takes card donations | Records cash and cheques | Live totals by class | Your own fields and rules |
|---|---|---|---|---|
| Paper form and a cash box | No | Yes | No | Yes |
| A hosted donation page | Yes | No | No | No |
| A school fundraising platform | Yes | usually | Yes | No |
| A spreadsheet the treasurer keeps | No | Yes | when it is retyped | Yes |
| An app you build, checkout in the browser | in the browser | Yes | Yes | Yes |
Building one for your own school
School fundraising platforms are built for districts and priced for them, often as a cut of what you raise plus a per campaign fee. A single school running two fundraisers a year pays for onboarding, reporting and integrations it will never use, and still cannot add the one field its own fundraiser turns on: a house, a form group, a bus route, a sibling discount.
Newly is an AI app builder. You describe the app, including the fields your fundraiser actually has, and it writes a real React Native and Expo project you own, running it on a cloud simulator while it builds. Plans start at $25 a month and there is no free plan. iOS goes out through TestFlight and App Store Connect on your own Apple Developer account, and the Deploy tab has an Android section that builds, signs and uploads to Google Play internal testing in one press, as well as producing a standalone release APK you can install on a phone directly.
There are no built-in payments, which here is closer to a feature than a gap, because the design that clears guideline 3.2.2(iv) sends the donor to a hosted checkout anyway. Before you add anything involving a pupil, read up on handling data about children and decide what you store, for how long, who can export it, and how a parent asks for it to be deleted. That decision costs an afternoon now and far more after the first parent asks.
Questions people ask about school fundraising apps
Only if you are an approved nonprofit. Guideline 3.2.2(iv) lists collecting funds within the app for charities and fundraisers as unacceptable unless you are approved or otherwise permitted under 3.2.1(vi), and says apps raising money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS. Approved nonprofits may fundraise in app under 3.2.1(vi) if the campaign offers Apple Pay support, discloses how the funds will be used and makes tax receipts available.
Describe the fundraiser you actually run
Write down the fields your school uses, who is allowed to see the totals, and where the money lands, then build the app around that rather than around a template.
Start building