Apple appears to relax ban on apps fetching, running extra code – remains aloof as always

Analysis In conjunction with the commencement of its Worldwide Developer Conference and the release of developer builds of planned operating system updates, Apple has revised its Developer Program license agreement, for better or worse.

It could be either, given that Apple itself decides when its rules get applied and how they get enforced. And Apple does not provide guidance to clarify the extent of its rules, at least publicly. The Register asked Apple to explain the new cruelty, and you know how that goes.

However, several software makers who spoke with The Register believe the changes are for the better and will allow a broader range of apps to be created.

Developer Anders Borum, creator of iOS Git client Working Copy, called out the changed wording via Twitter on Monday, suggesting the revised language will help makers of iOS development tools.

The portion of the agreement at issue, Section 3.3.2, outlines the circumstances under which applications can download and run executable code and interpreted code.

Executable code refers to code that can be run directly – compiled binary files – and interpreted code refers to code that must be processed by an interpreter to generate an executable form. Code written in JavaScript, Lua, and Python, for example, is interpreted.

Borum, in an email to The Register, explained that Apple for years has prohibited apps from downloading new behavior as binary code or an interpreted script, presumably as a security precaution.

"For programming environment apps that allow editing and executing programs in some language (Pythonista for Python, Codea for Lua) this is a serious restriction," Borum said. "These apps are allowed to include example programs and they can let the user type in arbitrarily complex programs, but such an app could not make it easy to import source code."

Borum contends this policy has held back iOS apps focused on programming because many of them, in the absence of clear guidance from Apple, have had trouble getting through the App Review process.

"But even more than hurting the existing development apps, these rules have deterred any larger efforts to make development tools on iOS," said Borum. "It is very risky to invest lots of money on a project that might not even be allowed on the App Store. The Swift Playgrounds apps would not be allowed by a third-party developer."

One company that suffered from these rules is Rollout.io, which offered a hot-patching service that allowed developers to inject code into approved apps, to revise interfaces, fix bugs, and implement other changes. In March, Apple began cracking down on hot-patching, a decision that a month later forced Rollout.io to abandon that particular approach and start anew with a service called Rox.

Erez Rusovsky, CEO of Rollout, in an email to The Register, said he wasn't certain whether the revisions would make the old incarnation of Rollout acceptable to Apple.

"This is a difficult question to answer because the changes are open to interpretation, and because Apple has not made itself available to us to clarify its policies," said Rusovsky.

"In fact, we felt that the policy always did allow Rollout and other hot patching solutions, and still should. Apple did not change its guidelines in March when it notified Rollout customers that apps built on our framework would not be allowed in the App Store. In fact, it only reinterpreted the guidelines already in place. The portion of the guidelines that most directly impacts Rollout [Section 3.3.2, along with separate App Store Guidelines, Section 2.5.2] did not change then, or now."

Rusovsky observed that Section 3.3.2 of the Developer Program license agreement previously said apps may not download or install executable code, except through Apple's WebKit or JavaScriptCore, which the disallowed version of Rollout used.

What's new, Rusovsky said, is that Apple no longer specifies allowable Javascript frameworks. "Instead of making an exception only for code downloads via Apple's built-in WebKit framework or JavaScriptCore, Apple now has opened the ability to download code to any Javascript framework," he said.

"The change does seem to loosen the requirement on downloaded code, specifically around the framework and language of the downloaded interpreted code, which means that other scripting languages not using Javascript language are allowed for injection, such as Lua, RubyMotion, and the like."