The best app builder for nonprofits is the one whose donate button can leave the app, because both stores say it has to.
The best app builder for nonprofits is the one that can ship a free app to both stores and hand the donation off to a web page. That comes from store policy, not from feature lists. Apple's App Review Guidelines, read today, say that unless you are an Apple approved nonprofit, an app raising money for a cause must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS. Google is blunter: Play's billing system must not be used for tax exempt donations. Most advice about apps for small organisations skips that and starts with templates.
So the decision turns on two things rather than twenty. If you want a real app on the App Store and Google Play, and you want to keep the code when the volunteer who built it moves on, Newly is the pick, and this page says where it is not. If what you are building is a shift rota or a food bank stock list, a web app is cheaper to live with and nobody has to install anything. If a visual canvas matters more than owning a codebase, Adalo's own pricing page puts native publishing at $36 a month. And if supporters only ever tap one donate button, the honest answer may be no app at all.
Work out which route is yoursThe short version
A donation is not an in-app purchase, and both stores put that in writing.
This is what the ranking pages leave out, and it rules tools in and out. A charity app does not need a paywall or a subscription engine, because a donor who gives you money receives nothing unlockable in return. So a nonprofit app builder is judged on three cheap things: can the app be free in the store, can it open an external page, and does it look like your organisation. That is a low bar, which is good news. You get to choose on output format, on price and on who holds the code, rather than on payment features you will never switch on.
The uncomfortable half is that both carve outs have conditions. Apple's in-app route is open only to nonprofits it has approved, and that route requires Apple Pay support. Google's wording is tax exempt donations, which is narrower than fundraising. If your money is raffle tickets, event entry or a membership that gives people something back, you are not inside the exception, and the rules for selling apply instead.
What Apple's guidelines actually say about donations
Start with the rule that does not apply. Guideline 3.1.1 is the in-app purchase rule, and it is about unlocking things. If you want to unlock features or functionality within your app, it says, you must use in-app purchase, and its examples are subscriptions, in-game currencies, game levels, access to premium content and unlocking a full version. A donation unlocks nothing. The donor gets no feature and no tier, so the clause that pushes paid content through Apple's purchase sheet never reaches a donate button.
Donations have their own clause. Guideline 3.2.1(vi) says approved nonprofits may fundraise directly within their own apps or third-party apps, provided those campaigns adhere to all the guidelines and offer Apple Pay support. It also asks the app to disclose how the funds will be used, to abide by local and federal law, and to make sure appropriate tax receipts are available to donors. App Review can ask for more information. A platform that connects donors to other nonprofits must put every nonprofit it lists through the approval process, and Apple links out to its own page on becoming an approved nonprofit.
Then the clause most charities will live under. Guideline 3.2.2(iv) lists as unacceptable collecting funds within the app for charities and fundraisers, unless you are an approved nonprofit or permitted under 3.2.1(vi). It adds that 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. Read the two together and there are two legal shapes. Approved nonprofit, in-app donation, Apple Pay included. Or everyone else, free app, donate button that opens a browser.
Apple, App Review Guidelines, guidelines 3.1.1, 3.2.1(vi) and 3.2.2(iv)
Google Play goes further: billing must not be used
Google Play's Payments policy sets out what it requires, then what it forbids. Apps taking payment for in-app features or services must use Play's billing system, and the examples given are items such as virtual currencies and extra lives, subscription services, app functionality such as an ad-free version, and cloud software and services. After that comes a list of cases where Play's billing system must not be used. It covers physical goods, physical services, credit card and utility bill remittance, and payments that include peer-to-peer payments, online auctions and tax exempt donations.
Two words in that bullet carry the weight: tax exempt. A registered charity is clearly in scope. A raffle, an event ticket or a school fundraising app selling wristbands may not be, because a ticket looks a lot more like a sale. If what you collect is not a tax exempt donation, do not assume the exception, and read the payments and subscriptions policies as a seller instead. Apple's free app and outside funds route is the conservative answer in the same situation.
The effect is that no store purchase system sits in the path of the money, so your builder only has to open a URL. That makes the tool question smaller than the roundups suggest. You are shopping for an app that can be free, can open your existing donation page, carries your branding and does one thing a web page cannot. The donate flow itself, the receipt and the thank you screen, is a separate job, and it is in taking donations.
Google Play Console Help, Payments policy, Monetization and Ads
What a nonprofit app has to do before any of this matters
With the money settled, building an app for a nonprofit comes down to one question: who opens it twice? Nonprofit app ideas usually hide two products. One faces supporters: your story, a campaign total, an event, a donate button. The other is an operations tool: shift rotas, food bank stock, home visit logs, volunteer sign-ups. The first has to look right and be findable. The second has to be quick to change, and nobody cares how it looks in a store listing.
That split decides more than any feature table. A supporter-facing app belongs in both stores, because that is where someone looks after reading your newsletter. An operations tool often needs no listing at all, and a review queue is pure cost when a form has to change on Tuesday. Push notifications, offline data and the camera are the honest reasons to cross back: a volunteer logging a delivery in a basement with no signal cannot use a browser tab.
The data question sets your running costs and your duties. A campaign page with a donate button needs no accounts and no server. A shift list that twelve volunteers share needs sign-in, a database and syncing, so it also needs a privacy policy that matches what you collect, a rule about who can delete a record, and someone to call when it breaks at the weekend. Charities carry that weight more heavily than most, because the data is often about people in difficulty.
Two questions
Which route is yours
How does the money move?
Who opens it twice a week?
A free store app with a donate link
This is the common shape, and the one both policies point at. Keep the listing free, open your existing donation page for the payment, and let the app do the thing a web page cannot.
The alternatives, and the case for each one
Glide is the one to look at for the operations half. Its own pricing page, read today, lists a free plan that publishes no apps, Basic at $25 a month with 100 credits and two published apps, Plus at $50 a month, Pro at $125 a month and a custom Enterprise tier. Glide builds from a spreadsheet, a prompt or a document, and its own documentation on apps describes mocking up, building, previewing and publishing with no App Store or Google Play step in it. For a stock list your team opens from a link, that is a feature and not a gap.
Adalo is the drag and drop answer. Its own pricing page says app store publishing starts at $36 a month on Starter, that it generates native builds, naming IPA and APK files, and that one version publishes as a progressive web app, a native Android app and a native iOS app. Its free plan builds and tests with up to 500 records per app. FlutterFlow suits anyone with a developer in the room: its pricing page puts project source code download, APK download and one-click App Store deployment on Basic at $39 a month, with the free plan capped at two projects and web publishing. The same trade-offs turn up on our best app builder for small business page.
Two things to check before you commit to any charity app builder. Not one of those pricing pages lists a nonprofit or charity tier, so budget the list price and then ask each sales team what they do for registered charities. And the Apple Pay requirement in 3.2.1(vi) only bites on the approved nonprofit route, so if in-app giving is the plan, get a straight answer about Apple Pay from any vendor before you pay for a year.
The case for no app at all is strong, and roundups rarely make it. If the plan is a donate button, a newsletter signup and a map of your shops, a mobile-friendly page on your own site does all three, costs nothing extra and cannot be rejected by a reviewer. Build an app when something needs the phone: a notification supporters opted into, a form that works with no signal, a photo taken on a visit, a scanner at the door of an event.
What each option gives a nonprofit, from its own pages
| Option | What its own pages say you get | Cheapest plan that publishes | Free plan | Do you get the source code |
|---|---|---|---|---|
| Newly | A React Native and TypeScript project you own, built on cloud iOS and Android simulators, shipped to TestFlight and Google Play internal testing | $25 a month | None | Yes, as a ZIP, through two-way GitHub sync or with the CLI |
| Adalo | Native iOS and Android builds, named as IPA and APK, plus a progressive web app from one version | $36 a month, Starter | Build and test, up to 500 records per app | Not published on its pricing page |
| FlutterFlow | A Flutter project with source code and APK download, and one-click App Store deployment | $39 a month, Basic | Two projects, web publishing only | Yes, code download from Basic up |
| Glide | Apps built from a spreadsheet or a prompt and published from GlideOS, with no store step in the docs we read | $25 a month, Basic, two published apps | Builds, but publishes no apps | Not published on its pricing page |
| No app, a page on your own site | A mobile-friendly donate page, signup form and shop finder, on the site you already run | Nothing beyond your current hosting | Not applicable | You already have it |
Where Newly fits, and where it does not
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, then ships it to TestFlight and to Google Play internal testing. It is $25 a month and there is no free plan. New apps start local-first, keeping their data on the phone with no accounts and no server, which fits a campaign app that has nothing to protect. The agent adds Newly Backend, with sign-in, an API service, a Postgres database per environment and file storage, only when the app needs accounts, shared data, syncing or payments.
Ownership matters more for a charity than for a startup, because volunteers move on, grants end and agencies finish their contract. The code comes out as a ZIP from project Settings, through the two-way GitHub sync under Deploy, or with the CLI, so the next person inherits an ordinary React Native project instead of a login nobody can find. The submission stays yours too. The upload goes to App Store Connect and TestFlight, and you press submit for review from your own developer account.
Where it does not fit. Our built-in payments path is a Connect RevenueCat card for subscriptions and paywalls, which is in-app purchase, and in-app purchase is the wrong instrument for a donation. For giving, the donate button opens the donation page you already run. If in-app Apple Pay as an approved nonprofit is the plan, treat that as work to scope with any tool rather than a box to tick. And if the app is really an internal spreadsheet with buttons, a web app will beat us on cost and on how fast you can change it.
Questions nonprofits ask before picking an app builder
No, and both stores say so. Apple's guideline 3.1.1 ties in-app purchase to unlocking features or content, which a donation does not do. Guideline 3.2.2(iv) says an app raising money for a cause must be free and may only collect funds outside of the app, such as via Safari or SMS, unless it is an approved nonprofit. Google Play's Payments policy lists tax exempt donations among the cases where Play's billing system must not be used.
Describe the app, keep it free, send donors to your own page
Write down the one thing your app does that your website cannot, who opens it twice a week, and which donation page the button should open. Then build it, keep the listing free, and press submit yourself.
Start building