UPDATE:

Wolfram Player for iOS is out of beta! You can download it from the App Store today. Learn more in this blog post.

It’s been a long road. To some degree, we’ve been working on a Wolfram notebook front end for iOS for about six years now. And in the process, we’ve learned a lot about notebook front ends, a thing we already knew a lot about. Let’s rewind the tape a bit and review.

In 1988, Theo Gray and Stephen Wolfram conceived the idea of the notebook front end for use with the Mathematica system. My first exposure to it was in 1989, when I first saw Mathematica running on a NeXT machine at university. That was 27 years ago. Little did I suspect that I would someday be spending 20 years of my life (and counting) working on it.

It’s interesting to see how relevant today the basic concepts we started with are. We have a document we refer to as a notebook. The notebook is structured into cells. Cells might be designated for headings, narrative, code or results. Cells with code are considered input, which generate outputs inline in the document. While the word “notebook” evokes the idea of a laboratory notebook, it easily encompasses educational documents, literate programs, academic papers, generated reports and experimental scratch pads.

One might have thought that the web would make notebooks obsolete. HTML exposes many similar concepts as notebooks at a lower level. Editing environments such as various Markdown editors or the WordPress environment expose many of these concepts at a higher level. But those environments don’t accomplish inline computation, and the world is increasingly recognizing how much inline computation with immediate feedback really matters.

And even the notion of what “computation” is has evolved over time. It seems that in the 1990s and 2000s, we were in a cycle where many in the software field thought that inline computation was merely for a few math tricks of the sort that could be done by Mathematica or Excel, while hardcore computation required some sort of compile or deployment step. I remember the immediate feedback of line-by-line programming from my youth in the 1980s, although it had actually begun much earlier. But by the time I graduated university, this wasn’t considered “serious programming” anymore. In computer science, there’s a fancy name for this: a read–evaluate–print loop, or REPL. And while the REPL fell out of fashion, the humble notebook continued to present its REPL-plus-narrative structured content.

In 2010, as iPhones and iPads evolved into general computing platforms, they became an obvious platform for notebooks. But iOS came with some very different constraints from the desktop system—so much so that it seemed an impossible task to try to adapt our existing notebook technology to the platform. So, we decided to try to recreate the notebook experience from scratch in a way that both fit within the constraints of the platform and played to its strengths. Seemed straightforward. Cells. Evaluation. Maybe some basic Manipulate support. Surely it wouldn’t take long to get that up and running, we thought.

That was the second notebook front end. Since then, there have been others. A short while later, another Wolfram development team started contacting me, asking about notebook front ends. Turned out they were working on this web thing, and wanted a bit of advice. But it can’t be that hard. A small skunk works project.

Even outside Wolfram’s doors, people were adapting to notebook-oriented computing. REPLs started becoming fashionable in software development circles again. Variants of Markdown started to become the language of document creation on the web, and many of those documents looked a lot like notebooks. There was even a significant open-source project that recreated some of our major concepts, down to the use of cells and the Shift + Enter evaluations.

All of these projects ran into some trouble, though. It turns out that the “cells and notebooks” concept wasn’t as easy to recreate as we all thought it would be. Above and beyond the basic technology hurdles, it turns out that we had evolved notebooks to do things we’re no longer willing to sacrifice.

Notebooks today support typesetting. Mathematical typesetting. Typesetting of code. Typesetting that you can properly interact with. Some of this is about the math. Typeset math has had broad appeal to our users, well beyond a core math education market. But making the math and the code coexist while remaining fully interactive and easy to read is a challenge requiring extreme attention to a large number of details.

Notebooks today are dynamic documents that can be generated, transformed and manipulated at the language level. Many core features rely on being able to read and write raw notebook content from the language, and we quickly discovered just how many notebooks in the wild would stop working without this functionality. We use this functionality prolifically to enable our user interfaces. In retrospect, this shouldn’t be too surprising, since we’ve been active exploiting this capability of our product since 1996.

Notebooks today offer a truly interactive experience with computation. We’ve been doing this since 2007 with Manipulate and Dynamic functionality, but it’s easy to undersell the achievement. When I slide a slider, I learn so much more about what I’m doing from instant feedback than I do from waiting for a web server to respond. Our devices are so powerful today that there is simply no reason for me to wait for computation when it can and often should be done on my local device. And we can create incredibly sophisticated and general interactive interfaces with just a single line of code. The ability to do this allows for novel applications. For example, I find myself using Manipulate to understand bugs and test features while doing notebook front end development.

And that brings us to today. iOS has been a challenging platform to bring a proper notebook experience to, and in order to do so, we’ve been creating a brand-new front end from scratch. In terms of CPU power and memory, this new front end is running on the most diminished platform we support today, but we’ve worked hard not to sacrifice the notebook experience. More than any previous front end, this new notebook front end uses its environment incredibly efficiently. It uses more CPU cores, less energy and less memory to get its job done.

And so what we have today is a product that displays and plays notebook content that we’re extremely proud of. It’s just entered into beta for the iPad, and we’re hoping to have a version that works well on the iPhone coming out soon. It’s been a long time coming, but I think the technology we’ve developed is worth the wait.