Rollout’s Statement on Apple Guidelines

I’m Erez Rusovsky, the CEO and co-founder of Rollout.io.

I want to take this opportunity to address recent developments with Apple and offer a preview of Rollout.io’s roadmap.

Rollout’s mission since we launched in 2014 has been, and will remain: to help developers create and deploy mobile apps quickly and safely. Our platform has been used by hundreds of developers to improve the quality of their apps by fixing thousands of bugs after release. This benefits developers and end-users alike and has prevented – by a conservative estimate – millions of crashes.

Also, Rollout is safe, secured from any MiTM attacks, and allows developers to immediately patch vulnerabilities as they are discovered, without requiring users to download a new version. Learn more about our commitment to security here.  

Late yesterday (March 7) we learned that Apple has been contacting developers with a warning that any framework or “code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval” is no longer in compliance with guidelines.

While Apple has not modified its guidelines , it appears that these guidelines are now being interpreted in a more narrow way.  We are disappointed that Apple has made this change before we have had an opportunity to address any concerns. We have already reached out to Apple to discuss and are committed to adjusting our offering as needed to remain in compliance under the more narrow interpretation of the guidelines.

We want to reiterate that we have always been careful to remain within Apple’s guidelines (as detailed here); specifically the clause in its guidelines that allows developers to push Javascript to live apps as long as features and functionality are not changed.

We understand and respect the fact that Apple must have the ability to control its ecosystem, and we recognize that our appeal may not succeed.

However, Rollout.io will move forward regardless!

First, for the last year we have been readying an entirely NEW product offering which addresses the entire app development process, not only post-production. This new product, which we will be announcing and launching for developer preview in April, will be in full compliance with Apple’s more narrow interpretation of its guidelines.
Please 
sign up here to be notified with updates.

Second, by popular demand we also are working on Android support for our new product, so look for news from us there as well.

Thank you for your continuing support of Rollout.io!  

Erez Rusovsky
CEO Rollout.io

UPDATE [March 13, 2017]
We’ve released an Open Letter to Apple proposing a secure solution to JavaScript injection.

 

 

 

Erez Rusovsky

Erez is CEO and co-founder of Rollout. Erez started his career as a software engineer at Intel and then got bitten the entrepreneurship bug.

Coming soon - A Continuous Feature Release Solution

Rollout’s totally new product, a Continuous Feature Release System, lets your mobile dev team build apps at the speed your business needs, without compromising on safety. Decouple feature deployment from version releases. Decide who gets which feature and when, measure impact and respond in real-time. All without waiting for your next release. Sign up for early access
  • Matthaus Woolard

    We mention your are MITM protected however as i read your security page the code is signed by your certificate The patch file is signed with Rollout's private key, using 2048 bit RSA encryption. and not the developers own certificate. Clearly this is a massive loophole in security, only the developer should have the power to push code to their app. If you a signing with your private key and they are not signing with their own private key ( that they do not share with your) you have become the attack surface, if someone were to compromise your system (legally eg government issued court orders`, or illegally through hacking your servers) they would be able to push any and all code directly to all of your customers code bases without them even knowing it was taking place.

    you realy should be getting developer to embed their own public keys in their apps and then asking them to sign any patched code locally on their machines before they upload it to your servers.

  • J-2

    Clearly, WordPress did that Auto updates server to millions WordPress and it got compromised/hacked. You seen that it similar to your private key method?

  • devil.morpheus

    Updating iOS-Apps after they are released without going through Apple’s validation process is totally unacceptable and one of the main reasons I did not choose an Android device. Signing an App with your own certificate and not the developer’s is what I would call a MitM behavior. This reduced my trust in the app and the developer significantly. As a customer, is there any chance, I can avoid apps in the AppStore using your “framework”?

  • Eyal Keren

    You are correct, but this option exists.
    Rollout allows developer to embed their own public in the SDK and configure webhook to get the hot patch data signed

    You can read about it here (http://support.rollout.io/docs/frequently-asked-questions#section-how-do-you-protect-yourself-against-man-in-the-middle-mitm-attacks-)

  • Eyal Keren
  • George Campbell

    The primary problem is that an ecosystem grows up around what is possible. It is incumbent on Apple to notify people ahead of time before they modify their automated app rejection tools, so they have time to adjust. Now it’s possible that they found some really bad apps that were using this to do evil things and are treating it as a security emergency. But I see no reason why they can’t give people some new standards and time to adjust. Apple doesn’t seem to care if they bust up people’s businesses.

  • кяιgнтσи

    Apple thinks they’re “Legion” they have no idea what’s coming. If they don’t start being humble, when TSHTF, I’m going to laugh so hard.

  • James Campbell

    They are not transparrent about anything and my app was stolen and put on app store and they don’t care about that either

  • James Campbell

    So this framework is used for being able to roll out features but you can’t really avoid it unless apple rejects it

  • Rollout.io

    Hi James,

    Rollout is used to push patches (written in JavaScript) to live obj-c or swift apps.

    1. Pushing new features or functionality by any mechanism other than the App store is prohibited by Apple’s guidelines. Rollout is used by customers to fix live bugs, diagnose issues, or other minor app modifications. See https://rollout.io/blog/updating-apps-without-app-store/

    2. Since the patches are written in JavaScript and Rollout just works with Obj-c and Swift apps, it’s not really practical to push new features even if you wanted to. FYI, part of the reason solutions like React Native and CodePush are popular are because the app logic is written in JavaScript so you can technically push new app code to live apps. For more info see: https://differential.com/insights/react-native-codepush/

  • Rollout.io

    Hi James,

    Sorry to hear your app was stolen. That sucks!

  • Rollout.io

    Hi there,

    First of all, the techie in me wants to clarify that we are NOT not signing an app with our own certificate. We’re signing a patch which is deployed to live devices.

    This impacts more than just us. Most apps using a JavaScript framework can also inject code changes directly to live apps. This includes React Native, Apphub, CodePush, Ionic and Meteor.

    We wrote up an open letter to Apple suggesting a secure solution:
    https://rollout.io/blog/open-letter-to-apple-secure-javascript-injection-ios/

  • Rollout.io