An English tutoring app is a record of every lesson, not a video call with a calendar.

What the lesson record has to hold

Model the lesson, not the booking. A booking says a slot is taken. A lesson record says what happened in it: what you covered, what the student produced, what you corrected, what you set as homework, and the line you want to open with next time. That last field is the one generic tools leave out, and the one that saves the first five minutes of the next lesson.

Level belongs on the student, and it should point at a published scale instead of your own adjectives. The Common European Framework of Reference gives six levels from A1 to C2, and ESL coursebooks, exam preparation and job adverts already speak in them. Store a level per skill rather than one for the student, because reading often sits a step above speaking, and a plan built on the average of the two helps nobody.

Then the two lists tutors genuinely reread: words the student has met, and errors that keep returning. A word is learned and drops off the list. A recurring error, the dropped third person s, the missing article, the past simple used where the present perfect belongs, stays until it stops appearing, so give it a status and a date rather than deleting it. Six weeks later you want to know whether it went away or whether you stopped noticing.

Time zones and cancellations, in that order

English tutoring is the case where the student is often in another country, so the stored time is the first thing to get right. Keep the instant in UTC together with the time zone name for each side, the region and city form rather than an offset. An offset of plus two hours is only true until somebody's clocks change.

Daylight saving is what actually breaks recurring lessons. A weekly Tuesday at 18:00 in London is not a weekly Tuesday at the same local hour in Brazil, because the two places change clocks on different dates and some places do not change at all. A recurring slot held as a wall clock time on one side and shown as a fixed offset on the other drifts by an hour twice a year, and you learn about it when a student does not turn up. If recurring blocks, rooms and group timetables are the real problem, that is closer to a class schedule app than to a one to one tutoring tool.

Cancellation rules have to live in the data, not in a message you sent once in March. Record the notice period, what happens inside it, and whether the lesson is forfeited or moved. Then let the app apply the rule: a cancellation at four hours against a twenty four hour policy is either charged or forgiven, and the record should show which, so the conversation happens once.

Reminders are cheap to add and easy to get wrong. Send them relative to the lesson instant, formatted in the recipient's zone, or you will deliver a polite note at three in the morning.

How a tutor gets paid when the app cannot take the money

Start with the limit, because it is a real one. Newly has no built-in payments. An app it builds can hold the price of a lesson, the size of a package, what has been paid and what is outstanding, and it can open a payment link in the browser. It cannot charge a card itself, and no amount of prompting changes that.

For live tutoring this matters less than it sounds, because of one App Store rule. Guideline 3.1.3(d) covers "real-time person-to-person services between two individuals" and names tutoring students as its first example. For those, Apple says you may use purchase methods other than in-app purchase to collect the payment. A bank transfer, an invoice, a card link from whatever processor you already use, or cash at the table, are all allowed for a lesson with a human on the other end.

The same rule draws the line you need to see before you price anything. One-to-few and one-to-many real-time services must use in-app purchase. A live class with four students is not a person-to-person service, and neither is a recorded course or a subscription to study material. Those are digital content, and on iOS they go through in-app purchase, at Apple's commission, with a purchase flow somebody has to build.

So the honest design is narrow, and it works: sell live one to one lessons, take the money outside the app, and let the app keep the ledger of what was taught, what it cost and what has cleared.

App Store Review Guidelines, 3.1.3(d) person-to-person services

Android is worded differently, and packages change the app

Google's payments policy is written from the other direction, and the tutoring case is not spelled out in it. It requires Google Play's billing system for payment for access to in-app features or services, and its examples of subscription services that must use it include education. It then lists what must not use Play billing: physical goods, and physical services, with transportation, cleaning, airfare, gym memberships, food delivery and tickets for live events as the named examples.

A live one to one lesson with a human teacher appears on neither list. Treat that as unsettled rather than settled in your favour. If you take lesson payments outside the app on Android, check your own case against the current policy text before you publish, because the wording is what a reviewer applies, not the analogy you drew from Apple's guidelines.

What you sell changes the app more than the platform does. Single lessons are simple. Packages of ten, or a monthly plan with four lessons and unlimited written corrections, move you into subscription territory, and now every student needs a balance, an expiry and a renewal date, plus a rule for what happens to unused lessons. At that point a real part of what you are building is a membership management app that happens to teach English.

Google Play Payments policy, when Play billing is and is not required