Apple Begins Rejecting Apps With 'Hot Code Push' Feature (apple.com)
Apple has long permitted "hot code push", a feature that allows developers to continuously deploy changes to their mobile apps and have those changes reflect in their apps instantly. This allowed developers to make quick changes to their apps without having to resubmit the new iteration and get approval from the Apple Store review team. But that's changing now. In response to a developer's query, Apple confirmed that it no longer permits "hot code push." The company told the developer: Your app, extension, and/or linked framework appears to contain code designed explicitly with the capability to change your app's behavior or functionality after App Review approval, which is not in compliance with section 3.3.2 of the Apple Developer Program License Agreement and App Store Review Guideline 2.5.2. This code, combined with a remote resource, can facilitate significant changes to your app's behavior compared to when it was initially reviewed for the App Store. While you may not be using this functionality currently, it has the potential to load private frameworks, private methods, and enable future feature changes.
As someone who has worked on ios apps big and small, I will tell you the rules for big orgs are not the same vs small. If they want to "hot push" (ghey btw) a scheduled event in Disney Kigndoms, apple won;t say shit. If you want to "hot push" (ghey btw) an update to some pixel avatar app with 3 users, you get rejected.
Seriously, unless you're part of a big corp with big corp lawyers and money behind you why develop for Apple? You have to buy your way into their walled garden, give up a significant portion of sales to them, and be put through an obscured process to get approval to be published in a store. Which, if you're lucky enough to hit on something that's both novel and popular, is going to fill up with a bunch of clones within days of the first hint of success.
If you're not doing it for the fun of being repeatedly punched in the face, what are you doing it for?
Surprised they ever allowed developers to do this? Surely in defiance of the objective of it being checked in the first place if you can just change it once approved.
so each new map in a game needs to wait for the app store review system to push it out?
The apple doesn't fall far from the tree.
"Apple has long permitted "hot code push", a feature that allows developers to continuously deploy changes to their mobile apps and have those changes reflect in their apps instantly. This allowed developers to make quick changes to their apps without having to resubmit the new iteration and get approval from the Apple Store review team."
Is it just me or does this seem like a recipe for disaster, ripe for abuse in the worst possible ways? And not just by the developer, but by anyone who hacks the developer's tool chain or system.
In other words, you could push the most intrusive, malevolent, destructive code to a user's device at will with no oversight.
Who thought having this capability was a good idea?
Just cruising through this digital world at 33 1/3 rpm...
Seems like the timing of this might be related to the information released by WikiLeaks about what the CIA has been doing. Being able to get into just about any mobile or IoT device for example.
You can't eat open source revenues. Most of the open source devs work for some corp or another, after all.
Apple is finally closing the back door that allowed malware to get passed the app review process, though they won't admit that's why. I can talk about it now that it's finally being fixed, I'm just astonished that it's taken them this long!
And all of you thought I was crazy for saying it was possible.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
In one fell swoop, Apple just broke all Meteor apps, and probably any other hybrid framework.
So I suppose we're all supposed to develop iOS apps using Apple-proprietary technologies now? No thanks. I'm old enough to remember the open internet, before the invasion of the phone-pokers.
What I'm trying to wrap my head around is where they draw the somewhat arbitrary line between downloading content and downloading functionality. I mean, any app that connects to the internet has the potential to download not just user comments, pictures, videos, and HTML, but also code, which might be executed on the client. What if my server pushes an image of a QR code to every client, which allows them to pay with bitcoin, thereby bypassing the 30% appstore surcharge? What if I want to display a web page in my app, which, by its very nature, is not approved by Apple's draconian bureaucrats??
Might makes right irrelevant.
Wow, that's one hell of a false equivalence argument.
It is apparently in response to something called Rollout.io, and looking at what it does, holy fucking hell, how the fuck has such a thing existed as long as it has, and why did those dumb fucks think Apple would be cool with them hot-patching code?
What concerns me is
which means no method swizzling and no introspection, which is absurd. You can't even implement many idiomatic Objective-C patterns without respondsToSelector. Maybe the key is "arbitrary parameters", though in that case, they should be looking for calls to NSSelectorFromString, not these methods.
This is also seems to rule out calling a web service through a JavaScript front-end published by the server. And hell, most jailbreak checks call dlopen. Apple will be screwing over anti-cheat and anti-piracy techniques so they can enforce their own security theater.
...See how silly that reasoning sounds...
That's the whole point of drawing a false parallel and then appling reductio ad absurdum, right?
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
The description of "hot code push" sounds like something Facebook and Messenger are doing on iOS. They both change the location of buttons (and occasionally some functionality)--like moving the Messages icon in the Facebook app to the top left and replacing it with a useless Marketplace icon--without needing to submit a new app, among other continual and usually annoying changes in Messenger itself. (Or at least the change isn't obviously correlated with a new app version; they don't write real changelogs, instead using a generic "we continually update this app" nonsense, and the app continues to function like it did before...until one day when it doesn't.)
I'm sure there are potentially malicious uses of hot code push rather than just annoying ones like certain apps seem to be doing, but if it makes them stop doing it too, I'll be happy enough.
R.Mo
How is that false equivalence? The original argument is that the only thing preventing everybody from doing bad things is oversight by other people. That's prima facie absurd. Most people will do the right thing even without being watched by other members of their peer group, police, etc. In much the same way, most developers will not abuse the ability to hot patch their code merely because they have that ability.
Check out my sci-fi/humor trilogy at PatriotsBooks.
If you publish on iTunes App store, as I do, you'll know that releasing a new version has the knock on effect of lowering your installs due to 2 things that happen on each new release:
1) iTunes App's have 2 ratings. An all time rating and a current version rating which goes to 0 on updates causing your app to lose popularity with installers.
2) iTunes keyword ranking is affected by current rating, not significantly, but enough to drop you a few places and 1/2 your installs until (1) improves again.
The App store is stagnating because of this. I see too many rivals who update every year or two. It creates complacency.
"Hot push" would have been for security reasons, which I'm all for. It does also have a nice side effect of preventing ratings gaming.
Apple's rumoured to be making App ratings more like Google Play in iOS 10.3.
I do hope so.
I actually agreed with the parent logic, but the reason for Apple to do this, for me, is to save their behind in the future. The prevention is not about what's going on right now (most people are doing the right thing), but it is to save their own behind in the future from even one misused case. The breech through the Internet is a lot more difficult to stop, let alone the cost to detect. Even those who are doing the right thing could make a mistake and open a hole to those who are looking to exploit.
Anyway, I don't defend Apple of doing so, but I am trying to understand why they do it.
No, not really. You're conflating "someone" with "everyone" here. The closed ecosystem provides a benefit because the odds are high that someone will do something bad. Bans on hot-patching provides a benefit only if you assume that everyone will do something bad. This difference is subtle, but critical.
Apple has a number of protections to prevent malicious apps from causing harm—blacklisting an app so that it won't even launch, removing the app from the store, banning the developer from submitting new apps, etc., all of which are made possible by that closed ecosystem. These allow Apple to provide oversight that prevents bad people from doing bad things, and are necessary because it isn't absurd to believe that some people will try to do so. What's absurd is assuming that all developers (or even a large percentage of developers) will risk destroying their reputation and livelihood to do bad things unless Apple nit-picks every single submission into the ground.
More to the point, curation is about minimizing the risk of getting complete junk apps, not about preventing bad people from doing bad things in app that only become visible after the fact. There's nothing Apple can realistically do in an app review that could detect malicious code, because it is entirely trivial for an app to ask a server what to do and then either behave normally or maliciously depending on the response. That behavior could be hard-coded into an app, and Apple would never realistically be able to detect it. The only way you could prevent a malicious developer from doing that would be to ban apps that make Internet requests. Thus, banning hot patching cannot possibly have any effect on whether malicious developers can create apps that cause harm, because it isn't necessary for apps to use hot patching to cause harm. It isn't really even all that helpful.
What hot patching can do is allow developers to flagrantly ignore app store policies. And it makes sense for Apple to crack down on developers who use it in that way, in much the same way that it makes sense for police to arrest people who commit crimes. It doesn't make sense to ban the technology under the theory that if Apple doesn't crack down constantly, the developers will all run amok, in much the same way that it doesn't make sense for police to arrest everyone because a few people might commit crimes.
Check out my sci-fi/humor trilogy at PatriotsBooks.
How's life in the hypocrite lane?
Anyone else notice the correlation between this and Uber walking-back Greyball?
I suspect Apple threatened the nuclear option. Greyball would definitely qualify for removal from the App Store on the broader issue here of undisclosed/changing app behavior as well as just plain out-and-out fraud.
I would have rather seen Uber removed from the App Store, though, than whatever back-room deal was made. There was no second chance, for example, for Kepeli/Dash. (Dash is an offline API documentation reader app. The author got bounced permanently when he let his sister use his developer account and she allegedly posted fraudulent reviews for her own app.)