Does Our Church Need an App? 

A vendor at a ministry conference hands your communications volunteer a phone. Prayer requests arrive as push notifications, the alerts that appear on a locked screen. Last Sunday’s sermon plays on the drive to work. Giving takes two taps.

It demos beautifully. It is also running on a phone belonging to someone who already loves that church, someone who heard the name, found it in a store, and waited for a download. Every feature in the demo assumes all of that already happened.

An app only reaches people who already installed it

Put your service times on your website and a stranger can read them at eleven on a Saturday night. Put the same service times in an app and that stranger first has to hear about your church, decide they trust you enough, open a store, search for you by name, and wait for a download. That is a lot to ask of somebody who has not decided to visit yet.

So the app is competing for attention from people who already come. Keeping regulars connected is a real job, and some churches are genuinely bad at it. The ice-storm cancellation goes out at six in the morning to whoever happens to be awake. An app is a real answer to that, and a demo blurs it with the other thing you want, which is being found.

Search sits outside the app entirely. Google Maps and Google Search return web pages and Business Profiles, the listing with your hours, photos and reviews. Whatever lives only inside your app is out of reach of the thing that brings new families to you, which is why getting the basics of how churches show up in local search right pays off ahead of anything an app can do.

The stores have rules your app has to keep meeting

Two of them keep repeating after launch.

Apple’s App Store Review Guidelines say in guideline 4.2 that an app “should include features, content, and UI that elevate it beyond a repackaged website,” UI meaning the screens a person actually taps through. The same guideline adds that an app without “some sort of lasting entertainment value or adequate utility” may not be accepted. Guideline 4.2.2 says that other than catalogs, apps “shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” A budget app that is your existing site in a frame is what those lines were written about. Apple also states that apps which stop working or offer a degraded experience may be removed from the App Store at any time.

Google’s side is a calendar. Every Android app declares which version of Android it was built for, which Google’s target API level page calls the target API level, and Google requires that number to keep moving. By 31 August 2026, an existing app had to say it was built for Android 15 or higher to stay available to new users on phones running a newer version of Android than the app was built for. From that same date, any new version of a phone app you submit has to say Android 16 or higher. Watch, TV and car apps have lower floors of their own.

Miss the deadline and nothing dramatic happens to the people who already have the app. They keep it and can re-install it, which Google limits to Android versions the app still supports. What changes is what a newcomer sees. Google’s page describes what a person on a newer phone sees when they follow a link to the store page for an app that has fallen behind: Google Play tells them the app “is not available to install on their device because it was made for an older version of Android.” Google notes the actual screen may look different. Google does flag it to you, as a policy warning inside Play Console, which is one more account somebody has to be logging into. Google says that warning is where the form for an extension to 1 November 2026 appears, though the same page says those forms will show up in Play Console “later this year.”

Google raised that target in 2025 and again in 2026. Budget as though it moves again, because an app ages out of the store quietly enough that nobody on staff notices until someone new tries to install it.

Giving inside the app needs Apple’s approval first

Guideline 3.2.1(vi) lets approved nonprofits fundraise directly within their own apps. The conditions Apple spells out include four you can check yourself: the fundraising has to offer Apple Pay support, disclose how the funds will be used, follow all required local and federal laws, and ensure tax receipts are available to donors.

The word carrying the weight there is “approved,” and it has a concrete meaning. The guideline links to Apple’s Apple Pay for Donations page, which lists four things an organization needs before it can take donations this way: a payment provider, an Apple Developer Program membership, approval to accept donations with Apple Pay, and Apple Pay actually built in. Apple’s list says app or website, so the same donate button works on your site. The approval is the part that happens outside Apple, which is why it is easy to leave out of a quote. A nonprofit based in the United States gets it by holding a Candid Seal of Transparency, a free badge from Candid that in Apple’s words “gives donors insight into your organization,” and Apple says every seal holder is approved. A nonprofit outside the US applies instead through Benevity, which asks for basic details plus the Team ID, the membership number listed in your developer account. Apple charges no fee or commission on Apple Pay transactions.

Without that approval, guideline 3.2.2(iv) applies: money for charities and fundraisers has to be collected outside the app, “such as via Safari or SMS,” and the app itself has to be a free download. A giving button that opens a browser still takes the gift. It also adds a tap, an address bar, and a page that has to look like it belongs to you, which is exactly the difference a vendor is selling when they say “in-app giving.” Ask which one is in the quote, and whether earning the seal is on their list or yours.

Where the money actually goes

Apple’s enrollment page puts the Apple Developer Program annual fee at 99 USD. Google’s developer-account registration page lists “a US$25 one-time registration fee.”

Apple’s fee-waiver page sets out who can request a waiver of the 99 USD, and says Apple reviews each request and may ask for more documentation before approving it. The conditions are worth reading before anyone gets excited. You have to be a legal entity that qualifies as a nonprofit officially recognized by a relevant authority in its region, which Apple illustrates with the Internal Revenue Service in the United States. You cannot be an individual, a sole proprietor, or a single-person business. You cannot currently have the agreement that permits paid apps and in-app purchases in place, though Apple says you still qualify if you signed it and have since terminated it. And you cannot sell digital goods or services through any of your apps.

So the store bill is 25 USD once if the waiver comes through, and 99 USD a year on top of that if it doesn’t. Treat the waiver as a maybe until the approval arrives. Either way, the numbers that move are the monthly subscription and the person shipping an update every time Google raises the target. Picture how that ends. The subscription renews on the card it was set up with, the volunteer who owned the login moves away, and the update nobody scheduled never ships.

That same arithmetic is why a church website’s monthly cost is mostly maintenance. An app adds a second bill beside that one.

When an app earns its place

Some churches should have one. The pattern looks like this:

• You have a job only push notifications can do. Service cancelled for ice, or a volunteer gap somebody has to fill by morning.
• You have enough committed members for installs to add up. If the install list ends up smaller than your volunteer roster, it’s an expensive group text.
• You have a person, not a season of enthusiasm. Someone whose actual job includes the app a year from now.
• Your website already does its job. Service times, address, what happens to your kids, how to give, all findable in one tap from a phone. If that is not true yet, an app is the second thing to fix.

If the only thing pushing the decision is that a larger church down the road has one, spend the money on the pages a first-time visitor actually reads instead.

Five questions before you sign anything

1. What does this do that our mobile website cannot? If the answer is only push notifications, price the app against a text-message service.
2. Will giving happen inside the app, and who is earning the Candid seal that lets it? Get it in writing.
3. Who submits the update when Google next raises the Android version an app has to be built for, and is that in the monthly fee?
4. What happens to our content and our member list if we leave?
5. What does the store listing look like a year after somebody stops paying attention to it?

Ask three and five last, and notice whether they sound prepared.