Bayer — ESMO oncology library and live congress news for iPad

Brief

ESMO — the European Society for Medical Oncology — produces the reference literature that oncologists across specialisations work from. The brief, sponsored by Bayer, was to put the complete ESMO publication library on an iPad in a form doctors could actually use in their daily clinical environment. During the annual ESMO congress, the application also served as a news feed: an editorial team on the ground at the event published text updates and announcements directly into the app throughout its duration.

The key word was use. Not browse when convenient. Use — including in the parts of a hospital where mobile signal does not reach: radiology suites, imaging departments, the diagnostic zones where oncologists spend a significant part of their working day and where a web-based tool would simply not function. The offline library needed to carry its content with it. The live congress feed needed to reach users wherever they were when the event was running.

The constraints

The clinical environment defined the architecture before a line of code was written. Hospitals are not offices. Signal coverage is uneven by design — the same shielding that protects sensitive imaging equipment attenuates the signals that a connected application depends on. An oncologist consulting treatment guidelines mid-discussion with a radiologist cannot wait for a page to load or accept a “no connection” state. The content had to be local.

This meant the application needed to download the complete ESMO oncology library at installation and keep it current — a substantial data payload by 2012 standards for a mobile application. That decision, which was the correct clinical decision, became the central obstacle to publication.

Apple’s App Store review team rejected the application. Their position was that the app downloaded an excessive quantity of data. From the perspective of a standard app review process in 2012, the flag was not unreasonable: large upfront downloads were associated with abuse patterns, not with medical reference tools designed for use in signal-dead hospital environments.

The problem was that the download was not a side effect of the design. It was the design.

Approach

The development was native iOS in Objective-C — the only viable path for a production iPad application in 2012. The offline library, the content rendering, and the update mechanism were all built within that stack. The application itself was not technically complex by the standards of what it needed to do; the engineering was solid and the app functioned correctly.

What consumed the most time and attention was not the code. It was Apple.

The exchange with the App Store review team was extended. The rejection arrived with a rationale that was technically accurate but contextually wrong: yes, the app downloaded a large amount of data; no, that was not a problem to be solved by reducing the download. The entire value of the application to its users depended on having that data available locally, in full, before they walked into a radiology department and lost connectivity.

We went back repeatedly. We explained the clinical use case — what hepato-oncology consultations look like, where they happen, what the signal environment of a diagnostic imaging suite is, why an oncologist in that context cannot rely on a live connection. We explained who the users were and what they were doing with the data. We made the case that the download was not a technical indulgence but a clinical requirement.

Eventually, the review team understood. The application was approved.

What we delivered

• A native iPad application in Objective-C carrying the complete ESMO publication library
• Full offline functionality: the entire content set available without network connection after initial download
• A congress news module: text updates and announcements published by an editorial team on the ground during the annual ESMO event, delivered directly into the app
• Content update mechanism for keeping the library current as new ESMO publications were released
• Successful App Store publication after sustained engagement with Apple’s review process

Outcome

The application ran. Oncologists used it. In the years since — more than a decade now — we have encountered clinicians who remember it with genuine appreciation and express disappointment that it is no longer available. That is not a common reaction to a 2012 enterprise mobile application.

Bayer eventually decided not to continue the sponsorship. Without commercial backing, the app was withdrawn from the store. The content it carried was not replaced by anything equivalent. The oncologists who had it noticed.

What we took away

Two things.

The first is about platform gatekeepers. An App Store rejection is not always a signal that something is wrong with the application. Sometimes it is a signal that the reviewer does not yet understand what the application is for. The correct response is to explain it — clearly, persistently, and in terms that are meaningful to the person reading the review — until they do. This takes longer than fixing a bug. It is sometimes the most important work on the project.

The second is about what makes something worth building. The application no longer exists. The infrastructure is gone, the sponsorship ended, the download links are dead. What remains is that oncologists working in a specific, constrained clinical environment had a tool that helped them do their job, and they remember it. That is a reasonable definition of success for a piece of software, regardless of what happened to it afterwards.