[caption id="attachment_139213" align="aligncenter" width="1783"] Apple WWDC 2016[/caption] Apple has begun cracking down on app developers who update apps outside of the normal review process, sending reminder messages that it's against the rules. Specifically, Apple says SDKs that allow a developer to fix bugs or other issues without re-submitting to the App Store violate the App Store Review Guidelines, section 2.5.2, which states: “Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other iOS, watchOS, macOS, or tvOS apps.” In its letter to one developer, Apple clarified the issue:

This includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior or call SPI, based on the contents of the downloaded script. Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app.

The apps made by that developer use an SDK called Rollout, which lets developers fix bugs after deployment, but without the need to re-submit to the App Store. On its website, Rollout shows how it can fix simpler issues such as crashes or UI color schemes inside a game. Using JavaScript, a developer alters some executable code in the app, and changes are reflected when the user opens the app again... but those same handy features leave the door open for someone else to intervene. A MiTM attack seems to be the heart of the matter for Apple. It allows someone to intervene in an app’s designed workflow to execute (possibly) nefarious services. For example, a hacker might get ‘in the middle’ and create a permission for the Photos app, then upload all of your images without ever telling you what was happening. You may have accepted the permission request because the app said it wanted to save screenshots or something similar, but it was really some black-hat hacker who has a measure of control somewhere down the pipeline, unbeknownst to the developer or user. [caption id="attachment_139520" align="aligncenter" width="2989"] Apple Platforms[/caption]

Apple, Security and Rollout

In poking through the comments associated with the letter posted to Apple’s developer forums, it seems this issue is contained to Rollout. So far, we haven’t seen letters sent to developers from Apple regarding other SDKs with similar functionality. Rollout says it’s aware of the problem, and is pursuing a fix. In an emailed statement, CEO Erez Rusovsky stated: “While Apple has not modified its guidelines, it appears that these guidelines are now being interpreted in a more restrictive way. "We are disappointed that Apple has made this change before we have had an opportunity to address any concerns,"Rusovsky added. "We have already reached out to Apple and are committed to adjusting our offering as needed to remain in compliance under the more restrictive interpretation of the guidelines.” If that wasn't enough, Rusovsk added: “Our SDK is installed in hundreds of live apps and our customers have fixed thousands of live bugs in their apps. We are contacting Apple in order to get further clarification on why Rollout doesn't fall under the clause that lets developers push JS to live apps as long as it does not modify the original features and functionality of the app.” On its website, Rollout says it “isn’t intended to push new features or functionality. It is meant to tweak or fix them.” Intent on the part of Rollout or the developer who built an app isn’t in question; it's a question of security. Developers are wringing their hands, though, especially those who use React Native, which has become a familiar friend for JavaScript developers who want to pursue the "write once, deploy everywhere" dream. Part of React Native’s attraction is JavaScript, and also that third-party services similar to Rollout are available. React Native doesn’t directly access any of the methods Apple detailed in its letter to the developer using Rollout, but many React Native developers use CodePush, a popular tool for deploying mobile updates. CodePush doesn’t seem to be under Apple’s microscope at this point, suggesting it doesn’t have the same security implications as Rollout. Some are wondering if Apple is actually taking aim at JavaScript itself to bolster Swift. Most studies and surveys note Swift is doing just fine on its own, and the problem seems to be with tools like Rollout. A bolder theory being floated is that Apple is clearing the way for a similar, more secure (and native) service at WWDC. But considering the security concerns with those kinds of services, that seems unlikely.

The Solution? Swift (and Objective-C)

‘Hot code push’ services are like slingshots full of code lobbed into Apple’s famed walled garden. They were always against the rules; why Apple has decided to enforce it now is beyond our scope, but it shouldn’t be surprising. Though React Native has a ton of upside, it’s often billed as something that allows developers to update their apps without going through the review process. That’s a touch misleading; it’s actually third-party tools that do that, not React Native itself. Apple isn’t going after a language, just tools that sidestep the rules. This line-in-the-sand from Apple has everything to do with security, and services similar to Rollout should expect the ban-hammer to fall on them, as well. Apple has made efforts to accelerate the app review process, which may have been a precursor to this. (It’s hard to ask developers to use a process that was severely bottlenecked.) The only real solution is Swift, and using Apple’s own services and methodology. Even if Apple launches a safer version of ‘hot code push’ at WWDC, it will undeniably lean into Swift and Objective-C libraries, and encompass Apple’s own best-practices. In the Apple Developer Program License Agreement, section 3.3.2, we get a different take on the kerfuffle regarding Rollout, and where Apple may make concessions down the road for its own tooling:

Except as set forth in the next paragraph, 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 exceptions to the foregoing are scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store. For macOS Applications submitted to Apple for distribution on the App Store, an Application may install or run interpreted or executable code (e.g., plug-ins and extensions) for use in conjunction with the Application only so long as such code: (a) does not change the Application's submitted binary or would not otherwise be considered an update (as determined in Apple’s sole discretion); and (b) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.

If something Rollout-ish were to launch at WWDC, it’d have to bring some of the macOS concessions to iOS so developers could roll out non-executable code changes without seeing App Store review. It’s not clear where in the sand Apple would draw that particular line, but given the popularity of services that allow continuous integration, it would be welcome by developers in attendance. But like all things Apple, security won’t take a backseat, even if it means forcing developers to update apps like it’s 2009. Rollout seems to have made some concessions on security, and Apple caught up with it. While handy, those services can lead to exploitation, so it’s best to stick to approved methods – even if they are less exciting.