
Apple starts rejecting apps with “hot code push” features - dylanpyle
https://forums.developer.apple.com/thread/73640
======
adjunct
I'm Erez Rusovsky, the CEO of Rollout.io

Rollout's mission has always been, and will always be about helping developers
create and deploy mobile apps quickly and safely. Our current product has been
a life saver for hundreds of apps by allowing them to patch bugs in live apps.

We were surprised by Apple's actions today. From what we've been able to
gather, they seem to be rejecting any app which utilizes a mechanism of live
patching, not just apps using Rollout.

Rollout has always been compliant with Apple's guidelines as we've detailed in
the past here: [https://rollout.io/blog/updating-apps-without-app-
store/](https://rollout.io/blog/updating-apps-without-app-store/)

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.

I'll post updates as I have them.

Erez Rusovsky CEO Rollout.io

~~~
macspoofing
Oh man. You were surprised? Really? You blog sounds like the PR spin that came
out of Aereo, a company that spent an inordinate amount of effort to stay
within the absolute letter of a law. Predictably they got killed by lawsuits
because judges aren't idiots and the law isn't inflexible to the point where
the intent and context isn't considered. Your case is even worse because you
engineered a solution to adhere to the letter of a EULA of a tightly
controlled ecosystem run by a very capricious company.

I hate the app store review process and a lot of apple policies around the app
store and I feel for you and I totally think there should be a less onerous
update/review process ... but ... you clearly and blatantly circumvented a
core policy, and what happened to you was absolutely predictable.

Get your money back from the lawyer that told you Apple wouldn't shut you
down. You got bad advice.

~~~
abcd_f
> _Oh man. You were surprised? Really?_

Exactly!

Apple has always been adamant that they see _all_ code that goes onto devices.
Live patching is so bloody obvious against their EULA.

~~~
wolfgke
What is "code"? Everybody who has programmed in LISP or Scheme knows that
there is no essential distinction between code and data (only many programming
languages make it a little hard to see that it is all the same). Thus Apple
would have to see not only all code, but also all data that goes onto the
devices. But this would imply that Apple disallows all apps that read data
from a foreign (i.e. at least not Apple-controlled) server if one does not
want to get into a self-contradiction.

~~~
Spivak
Which is why you're not allowed to use a Lisp interpreter or use any method of
evaluating data as code. In this model the only thing that data can do is
change which code paths run, not what they do.

~~~
kazinator
That characterization isn't enough to distinguish a Turing complete
interpreter from something that trivially manipulates an input datum. An
interpreter is just a program containing code paths, which are activated in
response to the input (the interpreted code).

~~~
wolfgke
> That characterization isn't enough to distinguish a Turing complete
> interpreter from something that trivially manipulates an input datum. An
> interpreter is just a program containing code paths, which are activated in
> response to the input (the interpreted code).

It is surprisingly simple to make an interpreter that is "accidentally" Turing
complete (this IMHO so often happens by accident that I love to say that if an
interpreter is not "obviously" more restricted than a Turing machine, it
probably is Turing complete).

This is not just my opinion - there lots of pages in the internet of things
that are "accidentally" Turing complete, for example:

[http://beza1e1.tuxen.de/articles/accidentally_turing_complet...](http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html)

[https://www.gwern.net/Turing-complete](https://www.gwern.net/Turing-complete)

------
dilipray
"Hi there -- I believe that title isn't quite accurate; Apple specifically is
referring to behavior of a library called Rollout which lets people
dynamically inject Objective-C/Swift. They are doing hot delivery of native,
Objective-C code. It's really not about React Native nor Expo.

Expo (and the React Native library we use) doesn't do any of that. We also
make sure we don't expose ways to dynamically execute native code such as the
dlopen() function that Apple mentioned in that message. We also haven't
received any messages from Apple about Expo, nor have we heard of any Expo
developers receiving the same." \- Exponent Team

~~~
jameside
Hi, I work on Expo (YC S16) and also am a core contributor to React Native.

Apple's message reads to me that they're concerned about libraries like
Rollout and JSPatch, which expose uncontrolled and direct access to native
APIs (including private APIs) or enable dynamic loading of native code.
Rollout and JSPatch are the only two libraries I've heard to be correlated
with the warning.

React Native is different from those libraries because it doesn't expose
uncontrolled access to native APIs at runtime. Instead, the developer writes
native modules that define some functions the app can call from JavaScript,
like setting a timer or playing a sound. This is the same strategy that
"hybrid" apps that use a UIWebView/WKWebView have been using for many years.
From a technical perspective, React Native is basically a hybrid app except
that it calls into more UI APIs.

Technically it is possible for a WebView app or a React Native app also to
contain code that exposes uncontrolled access to native APIs. This could
happen unintentionally; someone using React Native might also use Rollout. But
this isn't something specific to or systemic about React Native nor WebViews
anyway.

One nice thing about Expo, which uses React Native, is that we don't expose
uncontrolled or dynamic access to native APIs and take care of this issue for
you if your project is written only in JS. We do a lot of React Native work
and are really involved in the community and haven't heard of anyone using
Expo or React Native alone having this issue.

~~~
menckenjr
This needs a little elaboration. Cached Javascript in any hybrid app is a
security hole because that can be exposed through a jailbreak. Depending on
how much of your business logic you've pushed into the JS layer to enable that
"80% code sharing" that makes managers go all tingly you may be exposing all
kinds of things - cached access tokens, API keys and whatnot - to anyone who
wants to install your app and mine its secrets.

~~~
scarface74
You as an end user jailbreaking your own phone is not a "security hole".

I'm not aware of any non-tethered jailbreak for iOS 10

~~~
nb777
I think he's talking about application wide (not user specific) "secrets" in
the javascript layer.

~~~
menckenjr
Yes, I am. As for untethered jailbreaks,
[http://pangu8.com/10.html](http://pangu8.com/10.html) mentions a few.

------
teknologist
It seems that most people are overlooking one of the more significant points
Apple have made here:

"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."

Source:
[https://github.com/bang590/JSPatch/issues/746](https://github.com/bang590/JSPatch/issues/746)

~~~
orless
I'm not buying the MITM argument in general. If remote code is downloaded via
HTTPS, it could not be hijacked, at least not easily.

~~~
scintill76
HTTPS is sufficient against MITM, until someone disables all verification to
use their self-signed cert, or adds their poorly-secured "CA" cert to the
allowed CA's for the download, or adds a weak cipher to the list. Do you trust
every app developer to do those right (if they even use HTTPS!)[0], or would
you rather trust Apple to get it right in the centralized system they designed
for app updates for all apps?

I'm not even fond of Apple, but I'd rather trust them, and I'm glad they're
protecting their users.

[0] Caveat: I don't know how likely/possible these are to occur on iOS. I
assume a sufficiently motivated & misguided developer could do them within
their own app's context.

~~~
orless
You see, this whole thing:

"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."

Basically says "only we, Apple, can do HTTPS right, you can't, and even if you
try you can easily be MiTMed". Which is I don't agree with.

What you say is correct, but it's not the argument I criticize. You point is
that they don't trust developers to implement secure loading of code and don't
have technical means to control it and can't or don't want to check it in the
review. But it's completely different to "you could be easily hijacked if
you're not Apple".

~~~
teknologist
I'd trust Apple to do right more than I'd trust a small team at a startup
trying to deliver features at breakneck speed. I really like the fact that
Apple is looking out for its customers here.

------
mmmBacon
Seems like people have been aware of concerns about violating the TOS with
these hot patch frameworks.

From April 2016

>>Rollout is aware of the concerns within the community that patching apps
outside of the App Store could be a violation of Apple’s review guidelines and
practices. Rollout notes both on their FAQ site and in a longer blog post that
their process is in compliance.

[https://www.fireeye.com/blog/threat-
research/2016/04/rollout...](https://www.fireeye.com/blog/threat-
research/2016/04/rollout_or_not_the.html)

~~~
obstinate
A ton of games do this and it is incredibly annoying. I don't want to download
an update, then have to download an update. I only wish the same restriction
applied to my Android device.

~~~
justinhj
Most likely most games are updating only game related data and graphics files.
Very few games actually use internal scripting that would be needed to do code
updates

~~~
Angostura
The only app I've got that appears to actually update itself without going
through the AppStore is the HSBC mobile banking app. I'd be interested in
hearing the discussions going on between Apple and HSBC at the moment.

~~~
algesten
Judging by how sluggish and annoying the HSBC app is, I think it is a web app
framed in a thin launcher from the app store.

I.e. it downloads a bunch of javascript/html/css and that executes within a
UIWebView/WKWebView. Using caching and localStorage, you can construct such an
app to not need to download everything on each launch.

The reason that's allowed is because everything executes within a sandboxed
browser environment. No native code is downloaded.

~~~
mikeash
> The reason that's allowed is because everything executes within a sandboxed
> browser environment. No native code is downloaded.

That's the same thing Rollout does. In fact, iOS apps _can 't_ download and
run native code. The OS won't let you mark pages as executable unless they're
appropriately signed, and only Apple has those keys.

~~~
orbitur
If they're using JSC, then they can definitely download JS and execute native
methods. They could subclass any UIKit object and make it conform to JSExport.
Done, now they're "running native code."

~~~
mikeash
Sure, and an app displaying a web page using WebView can provide hooks that
allow doing that sort of thing too. Neither one is downloading native code.

~~~
orbitur
Only UIWebView, which is going away soon.

But surely you can see the difference between executing limited actions inside
a web view, and making available any native method to a web view.

~~~
mikeash
WKWebView allows the app to execute arbitrary JS within the loaded page, and
intercept URL loads and other actions made by JS code. That's all you need to
build a bridge.

I don't see any fundamental difference here. Both (UI|WK)WebView and JSC allow
bridging. Neither one grants full access to JS code automatically, the
programmer has to put some effort into it. And even if there is some important
difference, _neither one is native code_ which is what I was disputing above.

------
simplehuman
From [https://rollout.io/how-it-works/](https://rollout.io/how-it-works/) :

Does Rollout comply to Apple’s Guidelines?

    
    
        Yes. As per Apple’s official guidelines, Rollout.io does NOT alter binaries. ... With over 50 million devices already running our SDK, it is safe to say that Rollout complies with with Apple’s development and App Store guidelines.
    
    

Ouch. Just like the company's future is in danger.

~~~
eridius
The first time I saw Rollout I was shocked it wasn't already banned by the App
Store. No matter what they say, I can't imagine how they could do what they
claim to do without flagrantly violating the guidelines.

~~~
geofft
I'm guessing there are two things Apple is worried about. The first is using
hot code push to change the _purpose_ of the app after release, e.g.,
switching a business app into a video game. The second is using hot code push
to violate app store review guidelines, like the use of private APIs.

You can do hot "code" push techniques that allow the first but not the second,
by letting apps update HTML and JS that calls back into pre-existing native
code. That's what Cordova / PhoneGap does. I'd guess that Apple will just ban
the app and the developer if they catch it.

It appears that Rollout started using some API that would enable it to do the
second, and Apple is preemptively making sure that it doesn't happen. The
wording of the rejection is based on passing computed parameters to
introspection routines.

~~~
amluto
> The second is using hot code push to violate app store review guidelines,
> like the use of private APIs.

I've never understood this part. Why doesn't iOS simply prevent apps from
calling private APIs?

~~~
euyyn
Preventing it in a technical way is far from easy: If your app calls public
API X, which as part of its implementation calls private API Y, your compiler
only needs a declaration of Y to output the function call / ObjC message send.
Nothing in the language prevents it, and the code is executed natively unlike
Java.

~~~
tluyben2
They control the software and the hardware though: seems possible to allow a
specific region of memory (aka their public API) to call a specific region of
memory (private API) and segfault for all the rest that does that?

~~~
jahewson
Many private APIs are methods on objects which are part of public APIs, so
there's no "region" of memory which cleanly corresponds to private APIs.

~~~
tluyben2
But they can theoretically create that as they own the entire chain; dev env,
tools, OS, software, hardware (CPU included). I know it is not currently the
case, sure, but they can do it was my point.

~~~
euyyn
They "own" _a_ compiler, but not all of them.

Say they implement the scheme you mention in clang and the LLVM linker, so the
function bodies of their public APIs end up placed in that privileged region
of memory, and those of their private APIs end up in the restricted region.

Nothing prevents gcc from producing object files that tell the linker "this
user function is part of Apple's public APIs". And nothing prevents people
from using a different linker anyway, one that would put private API body
functions out of the restricted region of memory.

The only real way to achieve that would be to move all their frameworks to the
kernel, which would be all sorts of problematic.

~~~
Dylan16807
> Say they implement the scheme you mention in clang and the LLVM linker, so
> the function bodies of their public APIs end up placed in that privileged
> region of memory, and those of their private APIs end up in the restricted
> region.

Agreed that this design is fundamentally flawed, but that's because the coder
is providing the implementations of private code. Providing that is Apple's
job.

Put privileged code into a dynamically-linked library that Apple provides.
Only code in that block of memory can call private APIs. Pretty
straightforward to implement, and requires nothing fancy from the kernel.

Of course this only works if you can prevent the attacker from corrupting
memory.

~~~
euyyn
I don't know if iOS does randomization of loading addresses, but if so, that'd
be a disadvantage.

And well, in any case they need to maintain compatibility with current apps
for who knows how many years.

~~~
Dylan16807
> I don't know if iOS does randomization of loading addresses, but if so,
> that'd be a disadvantage.

Such a scheme wouldn't stop ASLR. The loader just needs to tell the
verification code where it put the privileged libraries.

> And well, in any case they need to maintain compatibility with current apps
> for who knows how many years.

Do they? I think Apple could easily order everyone to switch over to a more
secure compiler with a one year deadline.

------
diminish
Just imagine www didn't exist and Apple already had ios and apps. If someone
came up with the idea of www and an app called web browser , would apple
accept it in the app store? They would only accept it if they build it
themselves.

At some point is there a risk that Apple may also start to ban the web
browser, despite that it's under strict control on IOS?

~~~
grey-area
This is why you don't build on someone else's platform.

Apple/Google/Platform Owner will always do what's right for them, not the
customer, and not the developer, for example banning Amazon from selling books
in their kindle app, not allowing competing browsers (they recognise the power
of the web as a platform), not allowing competing sales mechanisms (where they
don't get a cut), and here not allowing developers to update their apps except
through the store mechanism. I have some sympathy with Apple here, and see why
they're doing it (they have to control what software is installed for security
reasons as well as platform protection), but this is all about control over
what you install on your own device. Sometimes their actions will be in the
best interests of customers, even if not the best interests of developers, but
most of the time their actions are simply aimed at preserving their control of
the platform and control of the money flowing through it.

The web is the one exception to this rule which works across all platforms and
devices (because it is so dumb and simple), and has survived attempts to
corral it to a walled-in commercial offering remarkably well.

~~~
carterehsmith
Try making e.g. a game that is not on someone else's platform. Make a game
that is not for PC or XBox or PS or Nintendo or iOS or Android or Facebook or
Java or whatever. Count money. Oops, there isn't any.

Or, try making a Photoshop clone, CAD software or similar without being on
someone else's platform. Oops.

"it don't work"

:)

~~~
Dylan16807
> Make a game that is not for PC

Or is the right challenge "make a game for PC that isn't in the microsoft app
store"? Which is in fact no hindrance at all.

It's not really "someone else's platform" just by using someone's software.
They have to be in control.

------
htormey
I wonder if this is going to hit non native code push solutions like React
Native? Or if Apple are going to start cracking down on apps like Facebook,
Twitter or Pinterest that do a lot of A/B testing.

~~~
marpstar
To date, Apple's Developer Program Guidelines states (in Section 3.3.2):

> 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.

Personally, I think that Cordova hybrid apps will continue to be okay, but I
don't know about something like React Native...

~~~
Illniyar
RN runs with JavaScriptCore.

~~~
je42
rollout as well...

------
egypturnash
I really kinda see no problem with Apple doing this. Hack the endpoint the app
checks for new code, push malicious code. Or fool the app into checking for
new code at your server, push malicious code.

I mean I read the headline, thought this sounded eminently sensible, then read
the story and saw it was a _framework_ for doing this, and my inner mental
model of my security researcher girlfriend leaned forward, started rubbing her
hands together, and wanted to start digging for those sweet new vulns.

------
RKearney
I wonder if Apple will apply this rule to everyone, which would be fair, or if
they plan on letting big name developers like Facebook or Google continue to
violate the rules without consequence.

~~~
LeoPanthera
They _should_ pull the Facebook app for this. But I'll eat my hat if they do.

~~~
empthought
Their guidelines specifically say that, with prior authorization, the
prohibitions do not apply.

------
leoh
You can accomplish some crazy stuff with hot code loading: use private APIs,
get around privacy restrictions. In theory, there are a lot of guys reasons
for Apple to prohibit this.

~~~
mikeash
You can accomplish all of that without loading new code. Apple's private API
checks, for example, are easy to get around if you're motivated.

------
akhilcacharya
There's a cynical part of me that thinks this is because Apple is going to
announce a similar feature at WWDC

~~~
madeofpalk
That doesn't seem likely. They 'just' reduced app review down to ~24 hours.

------
pyed
I've always questioned that 'hot code pushing' whenever I face an app that
does it, like how on earth is it allowed to begin with ? they basically can
send almost any functionality they want skipping Apple's reviewing all
together !

------
trishume
Hasn't this always been against the App Store terms? I thought the only
language you were allowed to download code from the internet and run was
Javascript on Apple's VM.

~~~
darren_
Rollout.io has been offering a product that leverages this to 'hotpatch'
binaries, but it looks like this is now considered not in the spirit of the
guidelines. Technicals here: [https://rollout.io/blog/under-the-
hood-2016-update/](https://rollout.io/blog/under-the-hood-2016-update/)

It basically goes:

* add their SDK, which has the ability to swizzle(swap out the implementation for) arbitrary methods in your app

* the swapped in implementations use JavascriptCore to execute javascript you supply, wrapping or replacing the 'real' invocation of the method.

* their SDK checks on startup which methods to replace and downloads the appropriate JS replacements

This is, technically speaking, only using JavascriptCore.

~~~
Retr0spectrum
That's actually quite a clever workaround to the current rules, but rather
naive of them to think Apple wouldn't fight back at some point.

~~~
mahyarm
It's really sad, because that kind of stuff lets you fix bugs / mitigate
outages in the wild without having to wait on apple's schedule.

~~~
tedd4u
This is true. The problem is bad actors can use this to bypass Apple's review.
As an iOS app publisher I slightly regret this inconvenience. As an iPhone
user, I appreciate Apple looking out for my security.

~~~
mahyarm
Apple's review isn't that useful in this case as a pre-check, it is possible
to avoid it if you want. Apple review does automated code checks & a reviewer
manually using your app. With that review process you can deliver executable
code after the fact in any way you want and only get caught after the fact if
it's even noticeable. You can even get sneaky and add some security exploit to
make it look like a mistake.

It's much like the argument 'if you ban guns only criminals will have guns'
and it's quite true in this case.

~~~
jahewson
Given that Apple's automated review tools detect many ways in which executable
code can be injected into apps, and OP's link is itself about that very thing
- what you say is mostly false.

~~~
mahyarm
It was easy to detect because they are not to trying to hide it. They just
have to check if the library exists.

------
kposehn
I'm curious if this has anything to do with the exploits that are in the
recent Wikileaks dump. Perhaps Apple saw something in there that raised alarm
and an impetus to close the loophole?

------
qq66
I wonder what they define as "code." Uber often rolls out "Kittens for a day"
style features, some of which are topical and can't have been designed before
the previous app update.

~~~
sjwright
A topical "special day" feature could easily be defined as a downloadable
content blob with zero executable or interpreted code. They probably have a
set of special event templates already coded into the application which can
then be themed with a few images, colours and text strings.

------
elmigranto
I'm not an iOS developer, so I'm not sure what's possible, but am wondering
about React Native apps (and similar technologies too). Here's a scenario:

\- you publish an app that creates collages;

\- user gives access to Photos;

\- you change your JS to upload all the photos to your server.

Substitute "photos" part to any iOS permission; isn't this security risk?
Should it be allowed under current App Store ToS? Also, what's stopping your
JS code from downloading binary code and injecting it via some iOS exploit
into "native thread"?

~~~
johnhattan
There's not much to prevent that scenario from happening. There's now a "why"
section in one of the app's descriptors where you need to describe what you're
doing with the permission. So it's not enough to say "I want access to the
photos". It's now "I want access to the photos so that I can put them on the
screen and let you draw funny pictures on them."

But there's little to prevent you from lying about it, and there are so many
iOS platform technologies out there now (native, PhoneGap, React Native, AIR,
Xamarin) that there's probably no way for Apple to see what you're doing in an
automated way.

------
homakov
From my understanding people are giving rollout push rights to their app store
accounts? So rollout can hijack all the apps it controls? It's a hell of a
central authority, a security nightmare waiting to happen.

~~~
manmal
No, it allows apps to be modified by the apps pulling JS code from rollout's
servers. App reviews would be way too slow, and they are exactly the problem
that rollout solves. However, review times have improved a lot since then.

ADDITION: It works by "swizzling" methods, which is a valid mechanism in
Apple's runtimes (like in Ruby or many other dynamic languages). In Swift,
this will only work in subclasses of NSObject or its decendants, because only
then message dispatch is used.

~~~
homakov
Ok, so there's no direct access to your App Store but idea is same - rollout
can "hot fix" aka pwn all users at once. I'd be angry if I were apple too.

~~~
manmal
Indeed, I always wondered how Rollout would not same day be rejected by Apple.

------
aamederen
How does apple understand whether the app can change behaviour according to
external factors. Maybe in other words, what is a "behavior change"?

For example, google has Tag Manager [1] which I believe is mostly used for
managing small UI related changes. Is there a clear documentation or
distinction about that?

[1] [https://developers.google.com/tag-
manager/](https://developers.google.com/tag-manager/)

------
geofft
> _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_

I would have expected dlopen and dlsym are blacklisted - you can trivially use
dlsym to access any blacklisted API. Similarly, I thought SPI ("system
programming interface" = private API) _was_ all blacklisted. Am I misreading
the message?

That said, if this is what they're focused on, it seems like it actively does
not impact any apps that hot-push HTML code (e.g., PhoneGap / Cordova).

If the only reports are coming from Rollout.io, my guess is that the latest
Rollout SDK uses one of these functions (I'd bet
method_exchangeImplementations(), i.e., swizzling) with a dynamic parameter,
and that the SDK can be changed to just stop doing that.

------
adjunct
Hi all (Erez from Rollout here) –I appreciate the discussion. Here’s our full
statement – please weigh in with any questions

[https://rollout.io/blog/rollout-statement-on-apple-
guideline...](https://rollout.io/blog/rollout-statement-on-apple-guidelines/)

------
godmodus
good, this sort of stuff screams of abuse potential.

devs should re-submit their code to apple, instead pushing "fixes" to phones.
i guess it's fair to assume 99% of those pushes are safe (80%? guess it's more
like 'benefit of the doubt'), but that 1% the escapes scrutiny is the one
piece that makes the whole platform shaky, and honestly, poses a major attack
vector. i wonder how often this was abused.

as to service like rollout.io, it's a service that was never supposed to be.
especially if it serviced hundreds of apps - as a security minded indv. i
shudder at the thought of what might have slipped through.

edit: after digging into rollout.io and finding out it's based in telaviv, is
it wrong to speculate about origins and real purpose of an israeli company
that specializes in injecting code into iphone applications?

------
Entangled
"Oh look, I found this tunnel under the border, I'll use it to feed the birds
on the other side. I swear to god I'll never use it to smuggle drugs or
people"

It is too bad people is using it for good causes but the hole has to be
closed. Sorry guys.

------
smaili
tldr - appears to affect rollout.io customers (at least for those who have
replied to the thread so far).

------
arbesfeld
We haven't noticed any issues with AppHub, our service for dynamically
updating React Native JavaScript code.

We always felt this day would come, however, so we switched directions.

------
santiagobasulto
I checked again rollout.io Disrupt presentation (great pitch btw) and the
first question they get (Alexandra Chong) is "is it going to be ok with
AppStore policies": [https://techcrunch.com/2015/09/22/rollout-io-puts-mobile-
dev...](https://techcrunch.com/2015/09/22/rollout-io-puts-mobile-developers-
back-in-control-of-their-apps/)

------
applecrazy
What will happen to YouTube? YouTube has been pushing new functionality ahead
of updates for me recently. For example, the new "double tap to rewind 10
seconds" feature appeared at random one day (without an any updates)...then
eventually the feature is announced in an App Store update.

Or is the app review process more subjective?

~~~
sb8244
They might have achieved that by pushing it in silently over time and
utilizing feature flags. Only going live in an app store update once it was
rolled out to everyone.

------
m3kw9
Should have been banned long ago, why would they have allowed an app to alter
major behaviors post review?

------
ksk
I'd say this is only going to further the arms race. One simple way around
this would be to intentionally introduce a bug with a "controlled" exploit
that lets you send a specially crafted data packet to your app, and execute
shell-code of your choice.

------
stevehiehn
I've recently been looking into React-Native. I'm hesitent to commit because i
believe there's 'hot code push' potential and Apple will be a b __*h about it.
I not sure if this is the case thou.

~~~
Mayzie
> i believe there's 'hot code push' potential

It's called CodePush, and it's a plugin for React Native (does not come with
it). It is developed by Microsoft: [https://microsoft.github.io/code-
push/](https://microsoft.github.io/code-push/)

Doubt it would get taken down.

~~~
stevehiehn
Interesting, thanks

------
anta40
Non iOS/Apple developer here.

So, with this "hot code push", is it also possible to update an app (adding
new features), and not only bug fixes, directly?

If yes, then sounds like you are trying to circumvent the App Store QA
process.

------
shmerl
Just ditch Apple. The obnoxious attempt to ban any kind of customization is
sickening. Apple like to shoot in their own foot by making life miserable for
developers.

~~~
o_____________o
But users have no idea how miserable life behind the iron XCode curtain is, so
it will continue forever.

------
algesten
That game that is topping the charts "Legacy", explicitly says when you start
it that it's downloading patches. Wonder why it isn't blocked?

~~~
jhgg
Patches could be assets - updated map data - updated textures - updated AI
scripts? I don't think these need a full app store update as it's not changing
the game from a game to a dating app (for example).

~~~
TeMPOraL
Still, how do they avoid someone writing an ad-hoc interpreter and reading
code from e.g. PNG images? Data == code, as we know.

------
reimertz
I don't see Apple blocking React Native, too many big players using it in
production.

If you use hot code push together with React Native, then you're borked.

------
Brotkrumen
A day after the Vault 7 leaks. Well well well

------
desaiguddu
Another big worry is analytics platform like 'AppSee' that is clear violation
of consumer privacy.

------
rsynnott
"Starts"? I thought this was always a rule. Maybe they're only starting to
enforce it now...

------
JulianMorrison
Hot CIA back door push is a misfeature in any app, and Apple are doing the
right thing here.

------
d--b
Could this have anything to do with Wikileak's release of iOS hacks by the
CIA?

~~~
ge0rg
Probably not, the timing is too tight, and if Apple were aware of active
exploitation, they would probably compeltely remove / block affected apps,
instead of giving the devs a notice to improve the next release.

------
josh_carterPDX
Didn't Firebase just introduce Remote Config which touts this very thing?

~~~
pscarey
AFAIK Remote Config is just a server side key value store with customisable
values based on audiences (e.g. random 50% for A/B testing, all people from
Country X). This means all behaviour changes will require code to be deployed
in the first place.

Also, from Firebase Docs[1] "Don't attempt to circumvent the requirements of
your app's target platform using Remote Config."

[1] [https://firebase.google.com/docs/remote-
config/](https://firebase.google.com/docs/remote-config/)

~~~
josh_carterPDX
From this....

[https://www.youtube.com/watch?v=_CXXVFPO6f0](https://www.youtube.com/watch?v=_CXXVFPO6f0)

"Firebase Remote Config allows you to change the look-and-feel of your app,
gradually roll out features, run A/B tests, and deliver customized content to
certain users, all from the cloud without needing to publish a new version of
your app."

~~~
pscarey
With hot code pushing, you're deploying newly written code/functionality, post
release (opening possibility of up MiTM attacks etc).

With Remote Config you deploy the code, then decide what to show to users post
release. This gives Apple a chance to review all the code submitted to the App
Store.

In the case of rolling out features an A/B tests, you'd make a release
including a feature, but only enable it x% of your users using RC. You can
then obviously enable it for everyone if it passes your A/B test or if you're
happy its working.

------
andy_ppp
React Native allows you to replace the JS bundle, will this be affected?

------
stevebmark
This has always been a requirement for Apple apps, hasn't it?

------
milkers
What about Microsoft's infamous Code Push?

------
EGreg
Does this mean all Cordova apps may be banned?

~~~
teknologist
Not necessarily. From the Apple Developer Program License Agreement:

> 3.3.2 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
> exception to the foregoing is scripts and code downloaded and run by Apple's
> builtin WebKit framework, 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.

------
lacampbell
Stuff like this is one of the big reasons I am a fan of web apps over mobile
apps. Letting apple or google have control over this channel is just too risky
for me.

~~~
swanros
You've literally got things upside-down.

------
justinzollars
The Unfree web.

------
anindha
Does this effect React Native apps?

------
pinaceae
Understandable, but there is a deeper problem of course - the app store model
is broken for apps that need hotfix capabilities (aka enterprise).

We've been meeting with Apple on this topic for years and continue to sideload
our app as we need to meet SLAs with our customers. They sign the binaries
with their dev certificates, which violates Apple's guidelines too.

But, alas, once you have critical mass in a vertical even mighty Apple gets
cold feet about shutting your customers down.

Why Apple is not able to offer a separate way for certified and audited dev
shops to hotfix their iOS apps is beyond me. SAP, MS, IBM - a shitload of big
shops would love to pay for this privilege.

~~~
tinus_hn
'Enterprise' always needs things, and then when these required things are not
available enterprise makes do with what is.

In this case it isn't required at all though because Apple allows enterprise
to sideload apps outside of the review process.

~~~
pinaceae
But not as a vendor.

Right now we get the certificates from out customers, sign the individual
binaries. Then distribute through our own infrastructure.

We have our own update mechanism (basically hot code push), cannot have the
customer's own IT shop be a barrier to deploy the fix. User sync their apps,
if there is an upgrade that gets done inbetween the normal data/content sync.

------
mayoralito
Oh, Mario Run! What are you gonna do?

------
LoSboccacc
About time, as an user it's fucking annoyng when you download an app but will
refuse to work unless you're online even when it has zero needs for it

~~~
danappelxx
To be fair that's just bad UX, there is no necessity for apps using rollout to
access the internet as (I hope) rollout caches the app.

------
rocky1138
The solution is fairly simple: just stop releasing software on that platform.
There are millions of customers on more open platforms, so there's really no
need to support them anyway.

~~~
Retra
All of life's problems are simple when suicide is your backup plan.

~~~
megous
Boycott is a valid response no matter how much you try to make false
analogies. Pulling app out of app store is by no means equivalent to suicide.
At most you change your business.

~~~
vecter
Right, like Uber, Snapchat, Facebook, Clash of Clans, Pinterest, Whatsapp,
Instagram, Twitter, Waze, Shazam, Tinder, Match, YouTube, and basically every
other app out there pulling out of the App Store would _not_ be suicide.

"At most", those companies would just have to "change their businesses".

~~~
intrasight
If all those companies did pull out, then it would be the end of Apple.

~~~
vecter
Absolutely not. Apple was fine long before these companies came into
existence, and Apple will long outlast these companies. New companies would
come in to fill the spaces these companies will have left in days.

