Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

321–330 of 498 posts

Re: Apple starts rejecting apps with “hot code push” features

#321
post #163
post #148

Earlier quoted context omitted.

How can you ship an app with access to private APIs? There is a private API usage scanning before you can submit for review.

The scanner isn't foolproof. You could fool it if you obfuscate your calls to performSelector well enough, for example if jsonResponseFromYourBackend contains:"runThis" then performSelector:json["runThis"] and make sure you don't send a runThis param while the app is in review. Unfortunately for Apple's app review process, Apple's own objective-C language and runtime has very strong dynamic reflection capabilities.

Apple could potentially close any loopholes here by scanning new apps for their API usage, checking for any 'bad' calls, and then writing the remaining discovered calls into a permissions file that is delivered with the app in the store.

At runtime, any API calls made by the app are checked against this file; if a new API call is found, then it must have escaped Apple's code scanning logic. The API call can be rejected and logged for Apple to improve their scanner.

Re: Apple starts rejecting apps with “hot code push” features

#322
post #217

Earlier quoted context omitted.

To some extent yes but often no. Apple has close relationships with those companies so it's often a case of them reaching out to the developers rather than just blinding rejecting the app. But any idea that Apple would allow them to run ruff shot over the platform and do whatever they wanted is a bit ridiculous.

> ruff shot "Rough shod", before we get another mondegreen propagating across the internet.

As a case of point - as a matter in fact For all intensive purposes this article peaked my interest because by in large it addressed a deep ceded issue with app updates

Re: Apple starts rejecting apps with “hot code push” features

#323

Earlier quoted context omitted.

> 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. Without reading the blog, I just wanted to comment on Aereo: a lot of us think that this was the wrong decision, and not in a facetious or 'cute' way. To quote Scalia's dissent in the case: > In a dissent that expressed distaste for Aereo’s business model, Justice…

This is obviously getting off topic, but in a common law system that interpretation is just wrong. The law is an evolving thing, it is meant to be interpreted, read, and understood, not to be exploited.

Don't you think at a certain point, a loophole in a poorly-written law can be too big for the courts to close? When does a judge go from upholding the spirit to assigning new meaning?

Re: Apple starts rejecting apps with “hot code push” features

#324
post #98

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…

Sorry to be OT, but since you're the CEO I do hope you found out if Rollout supports swift as well :^)

https://news.ycombinator.com/item?id=8158046

Re: Apple starts rejecting apps with “hot code push” features

#325

Earlier quoted context omitted.

> 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. Without reading the blog, I just wanted to comment on Aereo: a lot of us think that this was the wrong decision, and not in a facetious or 'cute' way. To quote Scalia's dissent in the case: > In a dissent that expressed distaste for Aereo’s business model, Justice…

This is obviously getting off topic, but in a common law system that interpretation is just wrong. The law is an evolving thing, it is meant to be interpreted, read, and understood, not to be exploited.

Then the letter of the law means nothing.

Re: Apple starts rejecting apps with “hot code push” features

#326

Earlier quoted context omitted.

> 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. Without reading the blog, I just wanted to comment on Aereo: a lot of us think that this was the wrong decision, and not in a facetious or 'cute' way. To quote Scalia's dissent in the case: > In a dissent that expressed distaste for Aereo’s business model, Justice…

This is obviously getting off topic, but in a common law system that interpretation is just wrong. The law is an evolving thing, it is meant to be interpreted, read, and understood, not to be exploited.

Disagree -- it's not the court's job to even categorize a thing as a loophole or not. It simply applies the law. Some actions will fall inside a prohibition and some outside. Divining the intent of the drafters of the law is something fraught with problems considering the process.

Just one example -- there may have been a group of supporters of the law in question used against Aereo that only supported the law because they realized it had said 'loophole'. The rule would not have become law without the 'loophole'. Now, how should a court interpret those circumstances?

Re: Apple starts rejecting apps with “hot code push” features

#327
post #98

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…

It sucks that the success of your business sounds dependent on the policies of the company in charge of the app store.

Other than contacting Apple what can you do to combat this?

That being said, I agree with most of the people here; live patching in my opinion is kind of infringing on the users' freedoms and security.

Re: Apple starts rejecting apps with “hot code push” features

#328

Earlier quoted context omitted.

I've never understood why developers criticize OS vendors use of "private APIs". I would go so far as to say there is no such thing as a "private API". The API is a vendors promise to consuming applications that when they call a method, a certain behavior will happen. Whatever they do behind the scenes is an implementation detail that they should be allowed to change anytime without breaking consuming applications. A…

f.lux strikes me as a good example. f.lux came to the market first with its idea to control screen temperature. Apple decides "No, you're not allowed to do that...but that's a great idea!", kicks f.lux out of the app store, and then adds their own Night Mode into later versions of iOS, using API's only they are allowed to access.

I'm guessing, from Apple's perspective, things that overlay the whole screen and alter the appearance of other people's apps (such as applying a colour cast), are essentially "white hat phishing". It makes security sense to hide this capability in the OS and not in apps.

Re: Apple starts rejecting apps with “hot code push” features

#330

Earlier quoted context omitted.

> Now, I'm not a fan of Apple's policies. I think there should be a "guys, I know what I'm doing" mode where I'm allowed to download code from untrusted sources. This exists today and has for a long time, it just costs you money for this "privilege".

You can drop a .ipa file into iTunes and load/run the app on a phone that's syncing to that copy of iTunes...

Getting the .ipa signed still costs money (or has a week-long timebomb), and you can't run unsigned code.
Post reply on HN