What happens depends on the product, the feature and whether the required content and session state were available before the connection dropped. A page that remains visible is not proof that answers are saved, and an offline question bank does not imply offline AI tutoring. Test the exact workflow you expect to use.
This article is a proposed test protocol dated 19 September 2026, not a report of completed disconnection experiments. It contains no measured failure rates and does not claim that iatroX or any competitor lost work. Its purpose is to make an ordinary purchasing question testable.
Distinguish three situations that all look like offline use
First, a product may offer an explicit download function. The user prepares the material while connected and then uses supported features without a connection.
Second, a page may remain visible because it was already loaded. That establishes availability of that displayed content in that moment, not a supported offline workflow for new questions, explanations or saving.
Third, the connection may fail during an action. The question is then whether the action completed locally, reached the service or remains uncertain. A displayed selection and a saved account record are not necessarily the same observation.
These distinctions are the proposed framework for the test. Actual behaviour must be observed rather than inferred from the category.
Read the published promise precisely
As checked on 19 September 2026, AMBOSS's mobile product page advertises offline Library access and the ability to continue Qbank sessions without Wi-Fi. That is meaningful functionality to include in a comparison. It does not establish that every AMBOSS feature, including all AI-assisted functions, operates offline.
The iatroX September 2026 launch description describes web and native-app availability with shared progress. Availability across platforms is a different claim from uninterrupted offline operation. This article does not infer an offline guarantee from it.
Record the exact function described by the provider, the platform and any preparation requirement. Do not reduce a detailed statement to a yes-or-no label that loses those conditions.
Build the test around a small revision journey
Use a test account or normal learning account in accordance with the service's terms, with permitted educational material and no patient data. Record the device, application or browser version, entitlement, connection and test date.
Prepare the content using the provider's documented method. Then select a sequence that includes opening material, answering, inspecting the explanation and leaving the session. Define the points at which connectivity will be interrupted before the test begins.
This should be a controlled personal-device experiment, not interference with a hospital network or a live clinical service. Do not introduce disruption into patient care to test a revision product.
Test before, during and after an answer
In the first run, disconnect before opening the prepared question. Does it load, and is the expected content available? Record which material was downloaded or previously viewed so the result can be interpreted.
In the next run, interrupt connectivity after selecting an answer but before there is a clear confirmation. Record the interface state and any message. Do not assume success merely because the selection remains highlighted.
In a further run, disconnect after confirmed submission and try to inspect the explanation. A product might preserve the answer but require a connection for additional material. That is a more specific finding than "offline failed".
Each run should use a defined starting state. If the tester repeatedly loads the same material, caching may change the result. Record that condition rather than treating all attempts as equivalent.
Reconnect and check the record
After connectivity returns, establish whether the application resumes, requires a retry or asks the learner to make a choice. Inspect whether answers and progress appear once, more than once or not at all in the relevant history.
If the product supports access on another device, check the account state there through an authorised route. A discrepancy may concern delayed synchronisation, a misunderstood display or a genuine failure. Preserve the observation and ask the provider where necessary; do not assign a cause the test has not established.
Also note whether elapsed time includes the disruption. A timed practice result affected by connectivity should not be interpreted as a clean measure of the learner's speed. The product's treatment of the timer and the educational meaning of the result are separate questions.
Test live functions separately
A reference page, a question explanation, a generated Tutor response and a voice simulation are different workloads. Do not assume that success for one establishes availability for another.
For a live interaction, record whether the user can tell that the connection is unavailable, whether input remains accessible and what happens on recovery. An understandable interruption message may be preferable to an interface that appears to accept work but leaves its status unclear.
This protocol does not claim that a particular recovery design is implemented by iatroX or another provider. It specifies observations that would make a comparison useful to the learner.
Report the result at the level tested
A useful future finding would identify the function, preparation, device and outcome: "After documented download on this version, the selected question and explanation remained available during this run; the result was confirmed after reconnection." That is an example of reporting syntax, not an observation from this article.
Avoid extrapolating one successful run into a reliability percentage. Repeated attempts across meaningful conditions are needed to investigate consistency, and a small convenience test cannot represent every network, device or account.
Keep failed and ambiguous attempts in the record. Excluding them because the next attempt worked would answer a more flattering but less useful question.
Choose according to the situation in which you study
This article is published by iatroX and includes iatroX under the same proposed checks. For a learner regularly without connectivity, documented and successfully tested offline functions may make another resource preferable for that part of revision. For connected study, explanation quality and interactive learning may matter more.
A mixed approach can be sensible: use material verified for offline access during travel and reserve live tutoring or simulation for a reliable connection. That is a proposed workflow, not evidence that every product will resume seamlessly between the two.
Before subscribing, test the required task through the permitted sample and ask the provider to clarify any unresolved condition. The right question is not whether an app "works offline" in the abstract, but whether your intended session remains usable and its outcome can be verified.
Frequently asked questions
Does a visible page prove that my answer has been saved?
No. Check the relevant confirmation and account record rather than inferring persistence from the screen alone.
Does an offline Qbank mean its AI tutor works offline?
Not automatically. Verify the specific feature and platform because downloaded content and live generation are different functions.
Are the examples in this article observed product results?
No. They describe a test method and reporting format; actual results require a documented run.