Imprtent update to the post (17.07.10)

I now came across David smith’s post on the REvolution blog, pointing to instruction on the R wiki for how to install R on the iPhone!
I didn’t try it myself since it both requires jailbreaking the iPhone, and I don’t have an iPhone. But it is still interesting to know of.

Preface – I don’t use Mac

I don’t use Mac! Not that there is anything wrong with that, but I don’t use Mac…

Yet at the same time, wonderful people like my wife, my brother, my thesis advisor and even my mother-in-law – all use mac. So one can’t help but wonder if I might be missing out on something.

Still, for a Windows user like me it is a bit difficult to understand the hype around the iPhone 4 release:

Such releases tend to look to me more like this spoof video about the release of the apple “i”.

So while not using apples product, I have a deep respect for the impact it has made in peoples lives. Which begs the question: Could you use R on an iPhone (or an iPad) ??

Can R be run on iPhone/iPad ?

This question (and the motivation for this post) was raised in an R help mailing list thread a week ago.

After receiving permission from the threads author, I am republishing the content that was presented there in the hopes it might be of interest to other R community members.

And here is what “Marc Schwartz” wrote:

Marc Schwartz on R and iPhone/iPad

Hi all,

There have been posts in the past about R being made available for the iPhone and perhaps more logically now, on the iPad. My recollection is that the hurdle discussed in the past was primarily a lack of access to a CLI on the iPhone’s variant of OSX, compelling the development of a GUI interface for R specifically for these devices. R itself, can be successfully compiled with the iPhone development tools.

Well, now there is another, clearly more profound reason.

The FSF has recently communicated with Apple on the presence of a GPL application (GNU Go) in the iTunes store because the iTunes TOS infringes upon the GPL. Apple, given a choice, elected to remove the application, rather than amending their TOS.

The FSF also informed the developers of the iPhone port of GNU Go that their distribution is in violation of the GPL. R Core and any others considering an iPhone/iPad port of R, if you are not already aware, take note…

More information is here:

http://www.fsf.org/news/2010-05-app-store-compliance/

with an update here:

http://www.fsf.org/news/blogs/licensing/more-about-the-app-store-gpl-enforcement

So, until Apple amends their TOS agreement, it looks like there will be no GPL apps available for the iPhone/iPad, since the only way to make applications available for these platforms is via the iTunes store (unless you unlock the device). Hence, no R for these devices in the foreseeable future.

Marc Schwartz second massage

Hi all,

Thanks to an offlist e-mail from Thomas (Lumley), I have spent the past few days getting a bit more edumacated on additional restrictions on the opportunity for R to appear on the iPhone/iPad. These in fact go well beyond the GPL issue that I raised in my initial post, which in and of itself, is not trivial by any means. I now know, or at least think I know, more about these issues than I probably wanted, but I also want to present a better picture of the situation.

Note that I am not a lawyer and am not intending to represent my findings from a legal perspective. I am reporting them here using a common sense approach from my own reading of the relevant Apple iPhone SDK language, as well as being based upon specific examples and discussions that I located on the web.

So, in summary, here are the key issues. I will follow each with some additional details below, but note that all such restrictions would need to be removed or otherwise overcome, before R could in fact appear on these two platforms, at least through Apple approved means in the App Store.

1. Distribution of GPL covered applications is not permissible via the App Store due to the Apple Terms of Service language, which infringes upon rights granted under the GPL.

‘Nuff said.

2. The use of FORTRAN is precluded (explicitly from SDK version 4.x forward)

Version 3.x of the iPhone SDK has the following language:

3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

Apple of course does not offer a FORTRAN compiler, as those who build R from source on OSX, as I do, are keenly aware. Thanks to Simon, we have one to use for OSX, but one is not officially available for the iPhone/iPad in the SDK.

Note that there is an important distinction here. The ability to build R versus the ability to have the resultant application pass Apple’s review to be able to appear in the App Store.

The above language has also been interpreted to apply to Java/Flash, precluding those environments from appearing on the iPhone/iPad.

However, the beta release of the 4.x version of the iPhone SDK has the following language in the same section:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Thus, in fact, one can only use Objective-C, C, C++ or JavaScript to develop applications for the iPhone/iPad. No FORTRAN, upon which of course, R is dependent. The above language has also been interpreted to further reinforce restrictions specifically on Java/Flash.

3. The implementation of programming language interpreters, of which R is one, is precluded.

The following language appears in version 3.x of the iPhone SDK:

3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).

The above language has been (pardon the pun) interpreted to restrict the implementation of programming language interpreters on these devices. Some sites I found have narrowly focused on the “No interpreted code may be downloaded” part of the language as an “out” of sorts. However, upon review, they seem to ignore the “or used” wording, which would seem to be independent of the action of downloading. If the language was “and used”, then one could envision the use of locally stored or entered code, but this is not the case. In either case, of course, R would not be one of Apple’s “built-in” interpreters.

I found two interesting examples of how Apple has either approved or rejected applications that can be considered interpreters. It is not clear where Apple drew the line between these two, such that it might enable one to better differentiate the reasoning and therefore design an app that would pass muster with them. Thus, one complication may be Apple’s lack of internal consistency in making decisions on allowing or disallowing apps in the App Store.

The first is an application which was intended to be a BASIC interpreter on the iPhone and which was apparently rejected by Apple under the name BasicMatrix:

http://smartcalc.coollittlethings.com/?p=3

After the author substantially restricted the functionality of the application to being an “enhanced calculator” under the name “SmartCalc”, Apple approved the application.

However, a contrarian example is “Frotz” which is a game type of an application currently available at no cost in the App Store for both the iPhone and the iPad. It is in fact an interpreter of so-called “Z code” (http://en.wikipedia.org/wiki/Z-machine) to create interactive fiction adventures. The web page for the app is:

http://code.google.com/p/iphonefrotz/wiki/FrotzMain

The app was initially accepted by Apple. A later version however was rejected, because the updated version could download new game files (Z code files) via the internet. Once the author removed the download functionality, Apple accepted the updated version of the app.

Frotz is also a GPL’d application, so its longevity in the App Store is logically in question and I sent an e-mail to the author to be sure that he was aware of the FSF’s recent actions.

The additional implications for R here, vis-a-vis Frotz, would be the ability to download, install and use CRAN packages. I will touch on this issue again below.

4. The implementation of anything resembling the CRAN network, to facilitate add-on packages for R, would be highly problematic for multiple reasons.

The following language appears in version 3.x of the iPhone SDK

3.3.3 Without Apple’s prior written approval, an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store.

For those who have an iPhone/iPad and are familiar with so-called “In App” purchases, this refers to the mechanism approved by Apple to provide add-on functionality to already installed applications. The notion of In App purchases is somewhat misleading, as in fact the activity may involve no actual direct monetary cost to download the additional component(s).

Thus, arguably between the SDK language, which would preclude a CRAN type network unless approved by Apple, combined with the relevant language I reference from 3.3.2 above, there would be substantive restrictions on the ability of a “default” R installation from being able to download and utilize add-on R packages.

Further, since one cannot compile programs on the iPhone/iPad, there would have to be some means to pre-compile any add-on packages for R on these two platforms, similar to what is done for Windows and OSX presently on CRAN to create package binaries. Further, packages that use FORTRAN, tcl/tk, Java, Perl or other such libraries would of course, also be problematic, both from a functional and where appropriate, a GPL perspective.

Even if one got by some of those issues and pre-compiled add-on packages were to be made available via some distribution process, the entire process of R package installation, updating and management would have to be re-written specifically for these platforms. Thus, there would be a meaningful amount of development work that some group of folks would have to undertake.

That all being said, it is clear that a remote client/server implementation of R would be possible, as long as the client-side R GUI application on the iPhone/iPad meets Apple’s requirements. Anyone using the WolframAlpha app ($1.99 U.S.) on the iPhone or iPad (I do on the former) will understand this model. See http://products.wolframalpha.com/iphone/ and http://products.wolframalpha.com/ipad/index.html for more information. Somebody just has to be willing to fund the backend server farm to provide the service.

Needless to say, a fully browser based client/server implementation would also work and be cross-platform, provided that the input/output web pages are appropriately scaled for the mobile displays. WA also provides a free alternative to their dedicated apps via a mobile site at http://m.wolframalpha.com/ as an example. Similar considerations here, as above, for the backend server platform would be applicable. The key advantage of the dedicated app is a more efficient keyboard layout providing easier access to special character sets, rather than scrolling through them using the default keyboard.

I hope that the above is helpful to folks. Needless to say, I do not present the above as being the definitive reference, but it seems to be at least a logical interpretation of the current situation.

Marc Schwartz’s reply to Ken Williams reply to Marc’s original post

Ken,

See comments inline.

On Jun 1, 2010, at 2:25 PM, Ken Williams wrote:

> Hi Marc,
>
> I want to debate a couple points from your post:
>
>> 1. Distribution of GPL covered applications is not permissible via the App
>
>> Store due to the Apple Terms of Service language, which infringes upon
> rights
>> granted under the GPL.
>>
>> ‘Nuff said.
>
> I’m not sure I agree with this, but there’s so much wiggle room in
> interpreting what the GPL means that there would probably be no way to
> decide without a courtroom & judge, so I’ll leave this part alone. =) I
> also haven’t yet read your other post where you discuss this.

Please do, including the links therein. It’s not my interpretation, it is the FSF’s action and Apple’s response to that action, which sets at least an operational precedence, if not one that could also affect any future litigation pertaining to GPL’d apps in the App Store. That all just took place within the past week or so, which is what prompted my initial post on the matter, since it would be relevant to any R offering via that channel.

>> 3.3.1 Applications may only use Documented APIs in the manner
> prescribed by
>> Apple and must not use or call any private APIs.
>
> I believe that language only refers to *Apple’s* APIs. In other words, they
> don’t want you to call hidden functions that aren’t supposed to be exposed
> to developers. If it meant no use of any APIs private to the developer, it
> would rule out pretty much every application in existence, considering that
> a call from one function to any other is an API call.

I am not in disagreement on that point. The key issue to date has been the lack of a compatible FORTRAN compiler, at least off the shelf, based upon what I can tell. Arguably, that is at least a notable deterrent to use FORTRAN on the iPhone for now.

There are other programming language tools for current iPhone development, but nothing for FORTRAN that I can find.

I can find no references to anyone building iPhone apps using FORTRAN (even in part) and the few queries that I can find that even mention an interest in doing so, reference the same issues that I have. Some have referenced f2c, but it is not clear to me that such an approach would work for R, not to mention the development overhead and the extensive testing of any conversion of critical functionality.

That all changes with the new language in 4.x.
– Show quoted text –
The key wording change relevant to R (and of course for other iPhone developers and tool providers) in 4.x is:

“Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine”

Ignore the other wording pertaining to API’s and other layers for the time being.

The app must be written natively in one of those four languages. There appears to be no interpretation that I can find that differentiates a scenario where a library of low level functions, written in a language such as FORTRAN, may be called from a higher level language such as those listed above.

Unless there is some subtlety in differentiating the abstraction layers within which the application is executed on the iPhone, I see no recourse here.

Note that the entities that provide iPhone cross-compilation/framework tools (eg. MonoTouch, Titanium, unity3D, Rhodes, etc.) which convert other code directly to native iPhone apps are also trying to figure out where they stand. Similarly, folks who develop natively in other languages are also having headaches over the new SDK wording.

There is even a question relevant to cross-compilation tools that take another language and convert it to, for example, Obj-C, as an intermediate step, before subsequent compilation to an iPhone native binary.

So the message that everyone is coming away with is, if you want to develop for the iPhone, write your code using one of these four languages, period. No doubt, some folks will test the boundaries and we will get more definitive answers in time.

Is it possible that the SDK language will change before 4.x is released as a stable OS/SDK? Sure, but that does not seem likely.

>> 3.3.2 An Application may not itself install or launch other executable
> code
>> by any means, including without limitation through the use of a plug-in
>> architecture, calling other frameworks, other APIs or otherwise. No
>> interpreted code may be downloaded or used in an Application except for
> code
>> that is interpreted and run by Apple’s Documented APIs and built-in
>> interpreter(s).
>
> I think this indeed pretty effectively rules out installation of packages
> from CRAN, which is a bummer – unless those modules are downloaded &
> installed through the app store. Not sure if that would even work though,
> since they’re not apps.

As I note, between 3.3.2 and 3.3.3, any add-on functionality, such as CRAN packages, would be problematic any way you read it.

> As for the “interpreted code” stuff, there’s so much murkiness about what
> constitutes interpreted code that I don’t know if this is a deal-breaker or
> not. At one extreme, it could prohibit pressing buttons in an app and then
> “interpreting” those presses as commands for the app to “do something.” At
> the other extreme, Somewhere in the middle, it would seem to cover language
> translation apps. The notion of “interpreted” is just not very
> well-defined. For instance, most people think of Perl as an interpreted
> language, but it compiles to bytecode before executing just like Java (it
> just doesn’t typically save it to a bytecode file).

I would say that, beyond the SDK language parsing issues relevant to interpreters, given that Apple rejected BasicMatrix and that there are no other programming language interpreters in the App Store, these are pretty goods sign that R would not pass Apple’s review under these parameters. I take a fairly pragmatic approach there.

> Finally, I do agree with the general tone implied in your post – it is a
> major major hassle that Apple’s overlords control the distribution channel
> for software on non-jailbroken iDevices. I don’t like it at all, for the
> exact reason that people like you & me & the rest of the world now have to
> sit around speculating whether our helpful apps will pass muster with the
> cabal.

As I noted in my closing comments in my second post, if one has a desire to make R’s functionality available on smartphones (iPhone, Android, etc.) or iPad-class devices, then a client/server approach may be the most efficient means to do so. That approach also avails you of more powerful computing platforms than the client side mobile devices have, at least at present, which will also limit aspects of portable functionality.

Regards,

Marc

And lastly Gustaf Rydevik reply

Indeed, the client/server approach is what is used in MatLab Mobile,
which is now on sale in the app store.
See

http://blogs.mathworks.com/desktop/2010/05/24/introducing-matlab-mobile-%E2%80%93-an-iphone-app-to-connect-remotely-to-your-matlab/

If matlab can do it, then surely the R community can as well.

Regards,
Gustaf

———————–

I hope the above will be interesting/useful to some of you in the future.
Best,
Tal