District Approved Apps List: How to Build, Publish and Keep One Current
An approved apps list tells teachers, families and IT which apps are cleared for students. Your device allowlist should come straight from it, never typed up separately.
What a district approved apps list is, and what it is not
People search for "list of approved apps", "blocked apps list" and "what is district app" and mean different things. Agree on four terms before you build anything.
Approved apps list
The public decision record. One row per product, with grade bands, purpose, platform IDs and the date it was last reviewed. Teachers check it before planning a lesson.
Blocked apps list
Apps and categories that may not run on district devices. Most of it comes from category blocklists, so new clones are caught without anyone typing IDs.
Unapproved apps
Apps nobody has reviewed yet. They are not banned, simply not cleared. A request form moves them into review instead of into a teacher's personal workaround.
The "district app"
Some families mean the district's own app for news, calendars and lunch menus. Keep that separate. Link the approved list from it, but host the list on the official website.
Five statuses that cover every app request
Yes or no is not enough. Many apps are fine for high school with a school account but wrong for second graders. Each status should map to a concrete action on devices.
Cleared for the listed grade bands with no extra conditions.
Device action: deploy through the MDM or allow install from the managed store.Cleared only with limits, such as a school sign-in, a teacher-led class or certain grades.
Device action: deploy only to the matching groups and note the condition in the list.Requested and in the vetting queue. Not for student use yet.
Device action: none. Do not push it to pilot groups before the review ends.Reviewed and declined, with a one-line reason and, ideally, an approved alternative.
Device action: add to the blocklist so it cannot be installed or opened.Was approved, now replaced, unused or no longer under an agreement.
Device action: remove from devices and ask the vendor to delete student data.Build the first list in six steps
Most districts already have an approved list in practice: it is whatever is installed on devices. Start from that inventory instead of a blank page.
- 1
Export what is already on devices
Pull the installed app inventory from every MDM you run, plus the Chrome apps and extensions report from the Google Admin console. Merge by bundle ID and package name, not by display name.
Owner: device teamOutput: raw inventory - 2
Ask teachers what they actually use
A short survey per school finds web tools and apps that the inventory misses. Ask for the product name, grade, subject and whether students sign in.
Owner: curriculumOutput: usage list - 3
Group duplicates by purpose
Ten quiz apps doing the same job is ten agreements to manage. Group by purpose (quizzes, reading, coding, video creation) and pick one or two per group to keep.
Owner: curriculum and ITOutput: shortlist - 4
Vet the shortlist
Check instructional value, privacy, data sharing, accessibility, age rating and contract terms for each product. Our edtech app vetting process gives you a scoring rubric to use.
Owner: privacy and ITOutput: scored reviews - 5
Assign status and grade bands
Give every row one of the five statuses and the grade bands it covers. Note the condition in plain words, for example "school Google account only".
Owner: review committeeOutput: draft list - 6
Sign off, publish and deploy
Get sign-off from whoever owns instructional technology, publish the list, then generate the device allowlist from the same file. Announce the request form at the same time.
Owner: director of technologyOutput: published list and allowlist
Sample approved apps list table format
One row per product, with every platform ID in its own column. The statuses below are examples of how a district might record decisions, not our recommendations for these products.
| App | iOS bundle ID | Android package | Grades | Status | Purpose | Agreement | Next review |
|---|---|---|---|---|---|---|---|
| Google Classroom | com.google.Classroom | com.google.android.apps.classroom | K-12 | Approved | Assignments, class stream | Platform agreement | Aug |
| Canvas Student | com.instructure.icanvas | com.instructure.candroid | 6-12 | Approved | Learning management | Signed | Aug |
| Seesaw | me.see-saw.classroom | Look up | K-5 | Approved | Portfolios, family updates | Signed | Aug |
| Khan Academy | org.khanacademy.Khan-Academy | org.khanacademy.android | 3-12 | Conditions | Math practice | Signed | Jan |
| Quizlet | com.quizlet.quizlet | com.quizlet.quizletandroid | 6-12 | Conditions | Flashcards | Signed | Jan |
| Kahoot! | no.mobitroll.kahoot.controller | no.mobitroll.kahoot.android | 3-12 | Approved | Class quizzes | Signed | Aug |
| Libby | com.overdrive.dewey | com.overdrive.mobile.android.libby | 6-12 | Pending | Library e-books | In review | Nov |
| Epic | com.getepic.Epic | com.getepic.Epic | K-5 | Approved | Reading | Signed | Aug |
| Microsoft Word | com.microsoft.Office.Word | com.microsoft.office.word | 6-12 | Approved | Writing | Platform agreement | Aug |
| Discord | com.hammerandchisel.discord | com.discord | None | Not approved | Chat and voice | None | Yearly |
| Character.AI | ai.character.app | ai.character.app | None | Not approved | AI companion chat | None | Yearly |
"Look up" means no Android package is recorded for that row yet. Find it with the package name lookup, and confirm iOS IDs with the bundle ID lookup.
Columns worth keeping in the master file
Rules that keep the file clean
From approved list to allowlist on devices
The list is for people. Devices need it as settings. Each platform handles the allowlist differently, so export one file per platform from the same master.
iPad and iPhone
- Buy or assign approved apps through Apple School Manager and push them from your MDM.
- On supervised iPads, use a restrictions profile that shows only allowed apps, or one that hides blocked apps.
- Turning off app installation removes the App Store icon. Your MDM can still install the approved apps.
- See Apple School Manager app management for the license side.
Android devices
- Approve apps in Managed Google Play so students only see what the district cleared.
- Use the package names from the master file, never a search by name.
- Block unknown sources so apps cannot be sideloaded from files.
- For BYOD and staff phones, a work profile keeps the rules inside school apps. Details are in blocking apps in an Android work profile.
Chromebooks
- In the Google Admin console, set app and extension installs to allow only the IDs on your list.
- Android apps on Chromebooks come through Managed Google Play, so they use the same package names.
- Web apps need the domain column, since many tools run only in the browser.
- Step by step: Chromebook apps and extensions.
Allowlist the core, blocklist the rest. Strict allowlists suit young grades and shared devices. Older students often need more freedom, so many districts allow the approved list plus general apps, and block risky categories. The trade-offs are compared in app allowlist vs blocklist.
App request and review workflow
Without a request path, teachers find their own workarounds. Make the path short and visible, and tell the requester what happened at every step.
Teacher submits the form with app name, store link, grades and lesson purpose.
IT checks if it is already on the list or if an approved app does the same job.
Privacy, accessibility, age rating and data sharing checks, scored with the rubric.
Committee sets the status, grade bands and any condition.
Device team deploys to the right groups or adds the app to the blocklist.
Requester gets the decision, the reason and an alternative if it was declined.
Set your own target for each step and publish it. Teachers plan around a known wait far better than around silence.
What to publish, and where
Families search "district app or official website" because they are unsure which source is current. Publish the list on the official website and link to it from everywhere else.
Public page for families
Staff portal
Some states require districts to post their list of operators and signed agreements. Check what your state asks for, and the context in student data privacy and apps.
Keep the list current all year
An approved list goes stale fast. Apps change owners, update privacy terms and pick up new features such as AI chat. Put the reviews on a calendar.
- Import the monthly category blocklist update
- Clear the request queue
- Check for approved apps removed from the stores
- Compare installs against the list
- Retire apps nobody opened
- Ask schools about new needs
- Re-vet every approved app
- Renew or end agreements
- Refresh the published page before school starts
- New owner or merger
- New privacy terms or a breach notice
- New AI or chat feature added
The blocked side: categories that sit next to the approved list
An approved list says what is in. Category blocklists handle what is out, including apps that did not exist when you wrote the policy.
Messaging and calling apps
Chat and calling apps outside the district's own tools. Our Email and Messaging category covers the large ones and the look-alikes.
Dating apps
Rarely an issue for elementary devices, a real one for teenagers. See the dating apps list with verified IDs.
Malicious and suspicious apps
Apps flagged in our Malware / Phishing / Suspicious category, plus the risky groups covered in dangerous apps for students.
VPN, proxy and anonymizers
The category students use to get around web filtering. Clones appear every month, which is why a category list beats a typed one.
AI chat and companions
Decide by grade band. Our page on AI apps on student devices covers the policy options.
Games, social and streaming
Usually blocked in class hours or for younger grades. Age-rated blocks for apps listed 17+ in the App Store catch many of them.
Google Workspace and Microsoft apps on the list
Platform suites cover dozens of apps under one agreement. List the suite once, then record which pieces students can use.
| Suite piece | How to record it | Device side |
|---|---|---|
| Google Workspace for Education core services (Classroom, Drive, Docs and others) | One row for the suite under your education agreement, with each mobile app ID listed underneath | Push the mobile apps, for example com.google.Docs and com.google.Drive on iPad |
| Google additional services (such as YouTube and Maps) | Separate rows, since these are consumer services with their own terms and can be turned on or off per organizational unit | Match the on or off setting in the Admin console with the status in the list |
| Microsoft 365 apps (Word, OneNote, Teams) | One row for the suite, with the apps you license listed underneath | For example com.microsoft.onenote and com.microsoft.skype.teams on iPad |
| New features inside a suite | Note AI assistants and chat features separately, since they may need their own decision | Check the current admin console for per-feature switches |
Google says changes to additional services can take up to 24 hours to apply. Admin menu names change, so check the current admin console before writing staff instructions.
Questions districts ask about approved apps lists
What is a district app?
The phrase has two meanings. It can be the official app a district publishes for families, or any app the district has approved for students. This page covers the second: the approved list.
Is an approved apps list the same as an allowlist?
No. The list is the decision record for people. The allowlist is the MDM setting that lets only certain apps run. Generate the allowlist from the list so they never drift apart.
Should the blocked apps list be public?
Publish the approved list and the blocked categories. A long public list of blocked IDs reads like a menu of things to try, and it adds nothing for families.
How often should we review the list?
Monthly for requests and blocklist updates, each term for usage, and a full re-vetting once a year. Review at once when an app changes owner, privacy terms or reports a breach.
Can one list cover websites and mobile apps?
Yes. Keep one row per product and record the iOS app, Android app, Chromebook extension and website. Approval applies to the product. The platform columns tell IT what to deploy.
How do we handle an app approved for some grades only?
Set the grade bands in the row, then assign the app only to device groups for those grades. Block it for the other groups so a student cannot install it from a shared catalog.
Can we import the list into Intune or Jamf?
Export the platform columns as plain lists of bundle IDs or package names. Our blocklist files come ready for Intune, Jamf and other MDMs. See blocking apps in Intune for the import steps.
Where do we find bundle IDs and package names?
Use the free lookup tools on this site. Paste an app name or store link and copy the iOS bundle ID, App Store ID and Android package into the master file.
Keep the blocked side current without typing IDs
The Districts and IT Providers plan gives you separate blocklist files per school for iOS, iPadOS and Android, updated monthly, plus the App Lookup API for checking request forms against our app data.
Apple, iPad, iPhone and App Store are trademarks of Apple Inc. Google, Google Workspace, Google Classroom, Google Play, Chromebook, YouTube and Android are trademarks of Google LLC.
Microsoft, Microsoft 365, Word, OneNote, Teams and Intune are trademarks of Microsoft Corporation. Jamf is a trademark of Jamf Software, LLC. Canvas, Seesaw, Khan Academy, Quizlet, Kahoot!, Libby, Epic, Discord and Character.AI are trademarks of their respective owners.
Names are used only to identify the products discussed. AppBlockList is not affiliated with, sponsored or endorsed by these companies.