A student app portal is a window onto records you do not own.
Almost every student app portal is a window, not a system. The timetable, the term grades, the holds and the balance already live in a student information system the app cannot change. The app's whole job is to show the correct slice of that to the correct person on a phone. That is what separates it from the rest of educational app development: you are not designing the data, you are designing access to it.
This page covers what counts as an education record under federal law, how the rights move from a parent to a student, what campus sign in has to look like inside a native app, and what your app is allowed to leave on the phone afterwards.
See who may open which screenThe short version
A portal is eight screens and one very hard permission question.
Count the screens on any student portal app and you get a short list: schedule, grades, balance, holds, announcements, a directory, an ID card. Most of them are lists, and lists are not where the work is. The work is that every field on them belongs to a named student, is held in a system of record somewhere else, and sits under a federal rule about who is allowed to read it.
The second surprise is that the answer moves. In a district the parent holds the rights. On the student's eighteenth birthday, or on their first day at a college, the rights pass to the student and the parent account has to change behaviour unless the student says otherwise. A portal that treats roles as fixed will be wrong for part of its audience on any given day.
What counts as an education record
The Family Educational Rights and Privacy Act, 20 U.S.C. 1232g, and its regulations at 34 CFR Part 99 govern education records. The definition in 34 CFR 99.3 is records that are directly related to a student and maintained by an educational agency or institution, or by a party acting for the agency or institution. That second clause is the one builders miss. The moment your app holds a grade, a schedule or a hold on the institution's behalf, it is holding education records, and having written it in house changes nothing.
Disclosure normally needs written consent. The exception a portal runs on is the school official exception: the institution may disclose to other school officials, including teachers, whom it has determined to have legitimate educational interests. An outside party can be treated as a school official if it performs a function the institution would otherwise use employees for, is under the direct control of the institution with respect to the use and maintenance of education records, and is subject to the redisclosure limits in 34 CFR 99.33(a). If a vendor or a contractor is building the portal, that is the clause the contract has to satisfy.
Then comes the sentence that is really your technical specification. The institution must use reasonable methods to ensure that school officials obtain access to only those education records in which they have legitimate educational interests, and an institution that does not use physical or technological access controls has to make its administrative policy effective instead. Read plainly: either the system enforces the boundary or a person does, and sooner or later somebody will ask which one you chose.
One further rule shapes the product rather than the plumbing. Under 34 CFR 99.10 a parent or eligible student must be given the chance to inspect and review the records, and the institution has to comply within a reasonable period and no more than 45 days after the request. A portal that shows a student their own record is part of how the institution meets that obligation, which is a decent argument for building it properly rather than bolting it on.
34 CFR 99.31, when prior consent is not required to disclose information
Try it
Who may open which screen
Pick who is holding the phone. The same three screens answer differently, and the difference is federal law rather than a setting.
Below 18 and outside higher education, the parent exercises the rights.
The rights move from the parent to the student
FERPA calls the second kind of person an eligible student: a student who has reached 18 years of age or is attending an institution of postsecondary education. Either condition is enough on its own. A 17 year old in their first semester at a university is an eligible student, and the parent has no automatic right to the record. Build a school portal app and the parent is the primary account. Build a campus portal app and the parent is a guest the student invites.
That invitation is a real feature, usually called proxy or delegated access. The student names a person, chooses which records that person may see, and can withdraw it later. Model it as a grant held against the student, with a scope and an end date, rather than as a role on the parent's account. Roles describe job titles. Grants describe consent, and consent gets revoked.
Staff need the same treatment for the same reason. An instructor sees the roster for their own sections, not the institution. An advisor sees their advisees. A dean of students sees a case, not a cohort. The one screen nearly everyone may see is the timetable, which is why a standalone class schedule app is often the first thing a campus ships and the full portal is the second.
Directory information is the one category an institution may publish without consent, and even that carries conditions. Under 34 CFR 99.37 the institution must have given public notice of the types of information it designates as directory information, of the right to refuse that designation, and of the window for saying so in writing. An opt out filed while the student was in attendance has to keep being honoured after they leave. So a directory screen needs a flag per student, not one switch for the institution.
Signing in against the campus identity provider
A portal does not own the password. It hands sign in to the institution's identity provider, gets a token back, and uses the token. On a phone that pattern has a specific rule attached. RFC 8252, published as BCP 212, states that native apps must not use embedded user agents to perform authorization requests, and notes that authorization endpoints may take steps to detect and block requests that come from them. In practice that means the system browser view, ASWebAuthenticationSession on iOS and Custom Tabs on Android, rather than a web view you drew yourself.
The reasons are practical as well as formal. An embedded web view cannot reuse the session the student already has in the browser, so they sign in again for no reason. It tends to break the identity provider's own multi factor and passkey flows, because those depend on the real browser. Worst of all it teaches students to type an institutional password into a screen an app controls, which is precisely the habit phishing depends on.
Session length is a product decision rather than a default. A laptop in a library and a phone in a coat pocket are different risks. Decide how long a session lives, whether the sensitive tabs ask for a device unlock before they open, and how the help desk signs out a phone that has been lost. Those three answers are cheap to build in at the start and painful to retrofit in the second year.
What the app is allowed to leave on the phone
Offline is where a portal quietly turns into a data store. Cache a schedule so it opens on the shuttle and you are holding a copy of an education record outside the institution's own systems. That is not forbidden, but it has to be deliberate: name what is cached, say how long it lives, purge it on sign out, and keep tokens in the operating system keychain or keystore rather than in ordinary app storage.
Push notifications have the same problem in public. A lock screen is readable by whoever is standing next to the student. A notification saying the BIOL 210 grade is a C is a disclosure to a lecture hall. Send the trigger and not the value: a new grade is available, a hold was added, a payment posted. The number belongs behind the sign in, where the permission check already runs.
Emergency alerts are the exception that proves the pattern. They are urgent, they go to everyone, and they usually carry no student specific data at all, which is why they tend to live in a campus safety app or at least on a separate channel with its own rules about opting out.
Once you can list every screen, every field on it, and the one role or grant that unlocks that field, you have written the specification for the back end. The remaining question is enforcing that list on the server instead of hiding fields in the app, which is a question about who is allowed to see which record at the level of the database itself.
What each way of showing student records gives you
| Option | Good on a phone | Live record data | Roles and consent you control | Fits local rules |
|---|---|---|---|---|
| Vendor mobile app from the SIS | Yes | Yes | No | No |
| Campus web portal in a browser | clunky | Yes | No | No |
| Email and PDF letters | No | No | manual | slowly |
| Low code tool over nightly exports | Yes | stale copy | partial | some |
| A portal app you build | Yes | if the SIS has an API | Yes | Yes |
Building one that fits your own institution
Student information system vendors ship their own mobile apps, and those apps are shaped around the vendor's data model and the vendor's release calendar. They stop fitting the moment the thing students ask about is local: the shuttle, the dining balance, the one form the registrar wants signed, a hold that only your institution issues. Single districts and small colleges feel this hardest, because they are nobody's priority customer and the roadmap is decided somewhere else.
The build itself is less exotic than it sounds. You need an integration layer that reads the system of record, and the first thing to establish is whether the vendor exposes a real API or whether you are getting a nightly export, because that answer changes the whole design and it is not something to discover in month three. You need a server that owns the permission rules, federated sign in, a push service, and a cache policy. The screens are the cheap part. Before any of it, write the table: screen, field, who may see it, and why.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and uploads iOS builds to TestFlight through your own Apple Developer account. The Deploy tab has an Android section: one press builds, signs and uploads the app to Google Play internal testing, and it also builds a standalone release APK you can download and install on a phone directly. Plans are $25 a month and there is no free plan. There are no built in payments, so a tuition or dining top up needs a payment provider of your own. The code is yours to pull down: install the CLI with npm i -g @newly/cli, then run newly pull with your project id.
Questions people ask about student portal apps
It is a mobile app that shows a student, and sometimes a parent, the records an institution already holds about them: the class schedule, grades, holds, account balance, announcements and a campus directory. It almost never owns that data. It reads from a student information system and presents the slice the viewer is allowed to see.
Describe the portal your students actually ask for
Write down every screen, the fields on it, and one line per field saying who may see it. That list is most of the app, and it is the part nobody else can write for you.
Start building