An app for class schedule that survives a room change.
An app for class schedule has a simple job in week one: show five courses on a grid. Its real job starts in week three, when a lecture moves rooms, a lab is cancelled and two deadlines land on the same Friday. Most campus portals show the timetable; almost none keep a student in the right room. That gap is the same one that decides whether educational app development pays off for a department, and it is why this page is about the records underneath a class schedule app rather than the colours on top of it.
Below: the fields a timetable actually needs, how recurring classes and their exceptions are modelled in the calendar standard every phone already reads, what a room-change notification has to do, what a campus safety button can honestly promise, and where the data comes from when the portal will not give it to you.
See what a class schedule app needs to holdThe short version
Recurring rules, recorded exceptions, and a push that reaches the phone.
A class schedule app needs the term dates, each section's meeting pattern (days, start and end time, room, type), the exceptions to that pattern (a cancelled session, a moved room, a change for the rest of term), the student's enrollment in those sections, the deadlines that hang off each course, and a notification path that tells exactly the students affected when something changes. A timetable app for students, a student portal app and a campus safety app are different slices of the same records. The rest of this page is what each piece looks like, with the calendar standard and the regulations that shape it.
The fields
What a class schedule app needs to hold.
A student schedule app that only stores "Statistics, Tuesday, 9am" is a screenshot with a login. The version that survives the term stores the following, and most of it is invisible to the student until something changes:
- Term dates: the first and last teaching day, plus every break, so a weekly rule knows when not to fire
- Sections, not just courses: STAT 201 has a lecture, a tutorial group and a lab, each with its own pattern and room
- A meeting pattern per section: days of the week, start and end time, building and room, session type, and the weeks it applies to
- Exceptions recorded against a specific date: cancelled, moved to another room, moved to another time
- Rest-of-term changes recorded from a date forward, without rewriting the sessions that already happened
- Enrollment: which student sits in which section, since this is what turns a department timetable into a personal one
- Deadlines per course: title, due date and time, how it is submitted, and whether this student has marked it done
- Announcements with an author, a timestamp and an audience: one section, one course, or the whole department
- Who is allowed to change what: the office edits rooms, an instructor edits deadlines, a student edits only their own preferences
- Notification preferences: room changes and cancellations immediately, deadline reminders on a schedule, digests for the rest
The list is longer than a schedule builder's, and the difference is in the middle of it. Exceptions and enrollment are what let the app answer the only question that matters on a Thursday morning: has anything about my 9am changed?
Try it
A week that can change under you
Tap any class to see what the app holds behind the block. Then move one session and watch what has to happen: the block, the detail card, and a notification to the 24 students in that section, and nobody else.
STAT 201 · Statistics
Lecture · Section 02
- When
- Thu 9:00 to 10:30, every week until the last teaching day
- Room
- B204
- Enrolled
- 24 students, the only people a change reaches
- Next deadline
- Problem set 3, Thursday 2 October, 23:59
The data model
Five courses, fifteen weeks, one rule each.
The wrong way to store a timetable is to create every session as its own row, fifteen weeks times a dozen meetings, and edit them one by one when a room changes. The calendar standard that phones, Google Calendar and Outlook all read, iCalendar (RFC 5545, published in 2009), settled this long ago: a recurring event is one record with a recurrence rule, and changes are recorded as exceptions to that rule. A class schedule app that borrows the same shape gets exports and calendar subscriptions almost for free.
| What happens in the term | How iCalendar records it | What the app has to do |
|---|---|---|
| STAT 201 meets Tuesday and Thursday at 9:00 for fifteen weeks | One event with a recurrence rule: FREQ=WEEKLY;BYDAY=TU,TH;UNTIL=<last teaching day> (RRULE, section 3.8.5.3) | Store one pattern per section and expand it into the week view on the fly |
| Reading week: no classes | EXDATE lists the dates the rule should skip (section 3.8.5.1) | Term breaks live on the term record, not on every section |
| Thursday's lecture moves to Room C110, this week only | A single overriding instance identified by RECURRENCE-ID, carrying the new location (section 3.8.4.4) | Record the change against that date, keep the rule intact, notify the enrolled students |
| From week eight the lab moves to a new building | End the original rule at week seven and start a new one from week eight | A from-this-date-forward change that never touches sessions that already happened |
| A student joins a tutorial group | A new event in that student's calendar, not a change to the course | Enrollment is a link between a student and a section; the section's pattern does not change |
Rule and exception properties from RFC 5545, the iCalendar specification. Its own example of a class-shaped rule is "Weekly on Tuesday and Thursday for five weeks": RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH.
The payoff of getting this right: any timetable stored this way can be published as an .ics feed that a phone calendar subscribes to, which is often the fastest way to give a whole department a schedule on their phones before an app exists. The thing a feed cannot do is push. A subscription refreshes on the phone's own timer; it does not ring when a room changes at 8:40.
When something moves
The room-change workflow an app has to run.
A room change is the smallest possible event with the largest possible consequence: two hundred students walking to the wrong building. In a class schedule app it is a workflow, not a notification, and each step is a rule the app enforces.
- 1
Someone with authority records it
The department office or the instructor changes the room on the specific session, or from a date forward. Nobody edits a student's copy, because there is no student's copy, only the section's pattern and its exceptions.
- 2
The app works out who is affected
Only students enrolled in that section, and only if the change touches a session that has not happened yet. A change to a past session is a correction to the record, not a notification.
- 3
It pushes the change with enough to act on
Course, day, time, old room, new room, and whether it is this week only or from now on. A push that says only "schedule updated" sends two hundred people back into the app to find out what moved.
- 4
The week view marks it
The block is highlighted until the session has passed, so a student who swiped the push away still sees the change on the grid at 8:50.
- 5
The record keeps who changed it and when
When the wrong room was announced, the question is who said so and at what time. An app that cannot answer that will be blamed for it.
Deadline reminders follow the same shape with a timer instead of a person: a push at a set interval before the due time, to the students who have not marked the item done. How a native app registers for, receives and shows those alerts is its own topic, covered in the guide to push notifications in mobile apps, and it is the first implementation detail worth reading before you describe a schedule app to anyone.
The data source
Portal, LMS, feed, or a person typing.
Every option for a class schedule is really a decision about where the timetable lives and who is allowed to change it.
The student portal app
The student portal app is the mobile face of the student information system, the registrar's database. It is the only source of truth for official sections and enrollment, which is why its timetable view is right and why its notifications are usually weak: the system was built for registration and records, not for telling a phone that a room moved. If your institution's portal pushes room changes, use it and stop reading.
The LMS app
Learning management systems hold the other half: assignments, due dates, course announcements. Their mobile apps are good at deadlines and poor at rooms, because a room is not a thing an LMS knows about. Many LMS platforms publish a calendar feed, which is the cheapest way to get deadlines next to the timetable.
A calendar subscription
If either system exports an iCalendar feed, a phone calendar can subscribe to it and the week shows up in the app students already open. The gap, again, is push: a feed refreshes when the phone decides to refresh it, not when the office changes a room.
The department or club version
This is the case the portal does not cover, and it is more common than it looks: a department that runs its own tutorials and labs, a student society with a weekly programme, a language school with three hundred students and a timetable in a PDF, a training centre. Someone in an office knows the schedule and types it in, and the app's job is to make that typing reach three hundred phones the moment it changes. The same office often wants the neighbouring tools too, a flashcard app for revision or a tutoring app for booking peer sessions, but those are separate builds with their own data. A schedule app should stay a schedule app.
| Option | Official timetable | Room change reaches the phone | Deadlines | Safety button | Fits a department or club | Who maintains it |
|---|---|---|---|---|---|---|
| Student portal app (SIS) | Yes | only if the SIS pushes it | no, the LMS holds them | sometimes | No | central IT and the vendor |
| LMS app | partly, course events only | No | Yes | No | No | the vendor |
| Calendar subscription (.ics feed) | yes, if a feed exists | on the next refresh, no push | yes, with the LMS feed | No | yes, anyone can publish a feed | whoever publishes the feed |
| Student planner app | whatever the student types in | No | yes, typed in | No | No | the vendor |
| Custom-built class schedule app | yes, from the source you choose | Yes | Yes | Yes | Yes | you |
The first four rows are the right answer for most students most of the time, and it is worth being honest about that. The last row exists for the office that has to run a schedule the first four cannot hold: its own sections, its own room changes, its own people to notify.
Campus safety
What a campus safety button can honestly promise.
Almost every brief for a student app includes one: a red button that calls campus security. It is worth being precise about what that is and what it is not, because the words "campus safety app" carry a legal meaning for the institution.
Emergency notification is the institution's job
For US institutions that take part in federal student aid programmes, the Clery Act regulations at 34 CFR 668.46(g) require procedures to "immediately notify the campus community upon the confirmation of a significant emergency or dangerous situation involving an immediate threat to the health or safety of students or employees occurring on the campus", including how the institution confirms the emergency, decides who to notify, writes the message and activates the system. That system belongs to the institution and its campus safety office. A department or club app can carry those alerts only if it is wired into that system, and it must never look like the official channel while being a copy someone updates by hand.
What the call button actually does on a phone
The button itself is a tel: link. Apple's documentation on phone links says that when a native app opens a tel URL, iOS 10.3 and later "displays an alert and requires user confirmation before dialing", and that if the Phone app is not installed on the device, iOS shows a warning instead. Two consequences for a build: the number must be right at the source, and the button has to be tested on a real iPhone. A browser preview or a simulator cannot prove that the call goes through, so treat "the button dials" as unverified until someone has stood in a corridor and tapped it.
What the safety screen should hold
- Campus security's direct line, confirmed with the campus safety office, not copied from a website
- The local emergency number as a separate button, never behind the same tap
- The right numbers for the right campus, since multi-campus institutions have more than one
- A link to the institution's official alert channel, not a hand-updated copy of it
- What happens after the call: where to go, who to tell, and where the nearest help point is
Student data
A personal timetable is an education record.
In the United States, FERPA's definitions at 34 CFR 99.3 make education records those 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". The same section lists directory information, the items a school may release without consent unless a student opts out: name, address, telephone listing, email, photograph, date and place of birth, major, grade level, enrollment status, dates of attendance, activities and sports, degrees and honours, and the last institution attended. A class schedule is not on that list.
The practical reading for anyone building a student schedule app: which sections a named student attends is not public information, an app that holds it on the institution's behalf is a party acting for the institution, and the registrar decides how it may be shared. Show a student their own week, show staff what they need, never publish an enrolled list, and get the registrar in the room before a department app pulls enrollment from the portal. Outside the US, your institution's data protection rules take the same role.
Free vs. paid
Is there a free app for class schedule?
For a student, yes, and it is probably already on the phone: the portal app and the LMS app cost nothing beyond tuition, and a calendar subscription costs nothing at all. Student planner apps with a free tier work for one person typing in their own week. The paid case is the other side of the desk: a department, school or club that needs a schedule it controls, with room changes pushed to the right people. Building that on a platform like Newly starts at $25 a month with no free plan, which is the price of not asking central IT to add your tutorials to a system that was never going to hold them.
When to build your own
Building a class schedule app that fits your campus.
The reason a department builds its own schedule app is rarely features and almost always fit. The portal cannot hold your tutorial groups. The LMS does not know rooms. The vendor's campus app is licensed to the whole institution and configured by someone else. When the process does not fit the tool, the office ends up on email and a PDF, which is where the wrong-room problem comes from in the first place. That gap is what Newly is for: describe the schedule you actually run, the sections, the rules for who edits what, and what gets pushed when a room moves, and it builds a real native app around that process instead of a generic planner.
Two product facts matter for a student audience before you start. On v2 the iOS build goes to App Store Connect, where you attach it to a version and submit it for review, and there are no Android release builds yet; a campus-wide app that has to reach every student's phone needs that on the plan, while a department or club piloting with iPhone users can ship now. Nail the term record, the section patterns and the edit rules on paper first. They are the cheap part to change, and they decide everything the app does when a room moves.
Sources
Where the specifics came from.
Four things on this page come from a primary source rather than general industry consensus:
FAQ
Class schedule apps, answered.
For the official timetable, the best app is usually the one your institution already provides, the student portal app or the LMS app, because it is the only one wired to the registrar's data. If it does not show room changes on your phone, or it does not exist for your department, the next best option is a calendar subscription: subscribe to the timetable as an iCalendar feed so it appears in the phone's own calendar. A purpose-built class schedule app earns its place when it does the three things those cannot: pushes room changes and cancellations to the students enrolled in a section, holds deadlines beside the timetable, and gives a department or club a schedule it controls.
Start with the term, not the grid.
A class schedule app lives or dies on the boring records: term dates, section patterns, and a room change that reaches the right 24 phones. Get those right, then build the app around them in Newly.