This article is more than 1 year old
Apple appears to relax ban on apps fetching, running extra code – remains aloof as always
Arbitrary exes, no, but friendlier rules for dev tools
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.
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.
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."