FAQs and Coming Up Next

in General

Here I’ll try to answer the most frequent questions, and give an outlook on what will come in version 1.1.

Frequently Asked Questions

“How can I sync Notebooks via Dropbox?”

Well, you can’t.

Apple does not allow apps (with embedded interpreters) to download any executable code from external sources. All code must be either bundled with the app (e.g., the sample notebooks), or created within the app. Since IPython notebooks contain Python code, they count as code, hence no notebook sync.

This is of course a huge limitation. Computable with notebook sync would be so much more useful. But I don’t think Apple will ever relax these restrictions, so there will probably never be notebook sync.

“What’s Dropbox sync for, then?”

For syncing input and output data files.

The intended behavior is like this:

  • Set up Dropbox sync in the settings panel. This will create an “Apps/Computable” folder in your Dropbox. Computable will now sync any files in this folder to and from your Dropbox.
  • When editing a Python cell, the import navigation bar button gets enabled. Tapping this button will open a Dropbox browser panel, where you can browse the directory structure inside the “Apps/Computable” folder.
  • Selecting a file in the Dropbox browser will insert the Dropbox-relative path at the current cursor position. This way, functions that accept input or output filenames can read or write to your Dropbox folder.

Note: I just found that this doesn’t work at all in version 1.0.0. Sorry, I will fix this in the next update.

“Again, why no code import? Other apps do this as well.”

Many users have asked “Other similar apps offer a way to import code, why doesn’t Computable allow that?”

As I understand it, these apps are violating Apple’s Developer Program Agreement. Here’s the relevant excerpt from the iOS Developer Program License Agreement, Section 3. Your Obligations, 3.3 Program Requirements (emphasis mine):

“3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built- in WebKit framework, provided that such scripts …”

To me, that’s a pretty clear statement. If code is bundled with the app, that’s Ok. Code injected into an app from any external sources is not Ok.

And a little further down in this document, in section 8. Revocation:

“You understand and agree that Apple may cease distribution of Your Licensed Application(s) … at any time. By way of example only, Apple might choose to do this if at any time:

… (e) You breach any term or condition of this Agreement or the Registered Apple Developer terms and conditions;”

There’s absolutely no technical barrier here, I could implement notebook sync in just a few hours. I would just fear that section 8 would be enforced by Apple should they find out that Computable allowed some way to import code.

To summarize: I could easily implement two-way notebook sync, but I’m just not allowed so.

“What does it cost?”

Ten bucks. More precisely, the app is free with in-app purchase. The free download will let you open, edit, and and run the bundled sample notebooks, to give you an idea of how the app works and what it is capable of. To create your own notebooks, you will have to make an in-app purchase of $9.99, however.

Note: As mentioned in the previous post, I totally screwed up the in-app purchase process in the initial release. Computable 1.0.0 comes fully unlocked. The next update will bring this back to the intended behavior.

Coming up Next

Computable 1.0 is a minimum viable product in many respects, lacking convenience and features in many places.

For Computable 1.1, I plan to improve in the following areas:

  • Code editor improvements: Right now, the Python code editor is merely a text view with syntax highlighting. This definitely needs improvement. For 1.1, I plan to build at least code completion into the Python editor, and possibly some other convenience features as well.
  • Faster notebook rendering: You will have noticed that notebook rendering is pretty slow right now. That’s because the Markdown rendering is HTML-based at the moment. Markdown markup gets translated into HTML, which is then rendered in a web view. TEX and LATEX are handled by the same web view, via MathJax. I intend to get rid of both, and introduce a native TEX renderer instead. I’ve already started work on this, and it looks promising.
  • Stability improvements: Right now, I have about 20 crash logs sitting in my inbox. I will try to fix as many as possible of these for the next version.

I don’t have an estimate yet for the availability of version 1.1. I will ship it when it feels ready.

In the short term, a bugfix-update 1.0.2 addressing the most frequent crashes will be released soon.

Note: This post will probably be updated from time to time, should new questions arise.