Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

Post reply on HN
Print view View original

411–420 of 498 posts

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

#411

Post by [deleted] »

K0SM0S wrote: post #349
Twisell wrote: post #115

Earlier quoted context omitted.

As a client I'm pretty baffled that some developer had specifically bypassed something that I see as a security measure. If an app is modified on the fly to use an undocumented and maybe "forbidden by apple" method in order to bypass security features or worse spy on me I'm clearly not ok. Do you really think the apple ecosystem work because clients see AppStore as a evil cage and that the external developers are all…

It's actually a double-edged security sword. By not allowing developers to patch their app 'on the fly', directly, without going through a new version in the app store (which is a very lengthy process, almost forever in security terms), Apple effectively protects their iOS users from malicious code (not from the dev, which is probably to be trusted if the app is already installed, but from MITM attacks and the likes)…

[deleted]

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

#412

Post by prh8 »

elldoubleyew wrote: post #371
abcd_f wrote: post #151

Earlier quoted context omitted.

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

So if I have an imbeded webpage inside of my app and that website is updated do I suddenly violate the EULA. What if its a social media app that provides users the ability to write custom HTML/CSS/JS to personalize their profiles and a user writes a game that runs in the header of that profile. What if that game suddenly allows the ability to access copyrighted material? I just don't understand how Apple is supposed…

Web apps are fine, I believe the issue is Apple wants to prevent apps from updating their Objective-C code. Anything run by WebKit is fine. From the Rollout page linked above:

> With Rollout’s SDK you can update and modify your Objective-C methods with logic written in JavaScript so we’re good on the first condition.

I think that is the problem with Rollout.

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

#413

Post by brilliantcode »

adjunct wrote: 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…

Builds a business around a 3rd party marketplace, get surprised when they cut you off without a warning.

We've seen this over and over. The platform risk should be seriously considered. Even AWS has demonstrated recently how dependence can be catastrophic.

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

#414

Post by brilliantcode »

gattilorenz wrote: post #324
adjunct wrote: 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

I'm confused. Did he forget to post that under another account or was he one of us, a lowly HN lurker that applied and go the CEO position (by self selection).

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

#415

Post by xsmasher »

retbull wrote: post #379
ryandrake wrote: post #334

Earlier quoted context omitted.

Thank you! As a fellow "Correct Idiom Usage Nazi" that made my day. Have an upvote :)

Holy crap its `deep ceded` not `deep seated`?

No - the comment was full of intentional errors. "matter in fact" "For all intensive purposes" "peaked my interest" "by in large" "deep ceded"

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

#416

Post by Dylan16807 »

skwirl wrote: post #385
macspoofing wrote: post #144

Earlier quoted context omitted.

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 t…

My impression of the Aereo decision was that it was based on the letter of the law. Contrary to opinions often expressed here, the law wording does not specifically apply to cable companies and specific wording was not creatively interpreted to apply to Aereo. The wording of the law referred not to antennas and cables but to a more abstract notion of "public performances" of copyrighted works, and Aereo fell squarely…

Except that it's been established that 'cloud DVR' is legal. That's 90% of what Aereo did. But somehow attaching an individual antenna to each person's DVR makes it 'public performance'? That specific argument is nonsensical.

And then they got double screwed because the US copyright office declared that no matter what the supreme court said they were not a cable company and couldn't get compulsory licensing either.

As far as I can tell it's legal to run one antenna for one person, and I have absolutely no idea where the line is that you start violating copyright. I don't think the guidelines are well written.

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

#417

Post by artursapek »

vlunkr wrote: post #381
artursapek wrote: post #310

Earlier quoted context omitted.

That sounds like a huge hack. They built a company around that?

Built a company with 3 million in funding https://www.crunchbase.com/organization/rollout-io-2#/entity .

lol

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

#418

Post by menckenjr »

mikewhy wrote: post #354
menckenjr wrote: post #303

Earlier quoted context omitted.

Or someone that steals your phone, or picks it up when you lose it somewhere. Yes, there's the lock screen and passcode but... http://www.wikihow.com/Bypass-iPhone-Passcode

"This bypass won't work on iPhones running iOS 9.3 and up"

https://threatpost.com/ios-10-passcode-bypass-can-access-pho...

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

#419

Post by eridius »

tluyben2 wrote: post #121
euyyn wrote: post #67

Earlier quoted context omitted.

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.

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?

At best all they could do is change literally every single private function call everywhere to inspect the return address and see if that return address is in a system framework or is in the app image. But this would be huge overhead, a real pain in the ass, and also not even reliable, because all you have to do is pick a public function, figure out the address of the `ret` instruction, push your $pc onto the stack, and then call the private function passing the address of that `ret` instruction as the return address. The private function will see that this address is in a system framework, and so will work, and then it will return, passing control to that `ret` instruction which immediately returns back to your real caller function.

So no, there's no way for Apple to technologically make it impossible to call private functions. The only actual solution there would be to completely rewrite the OS such that literally every call into a framework that an app makes actually goes over IPC (so that way apps can't even attempt to invoke private functions since they won't be linked into the app), but that would probably be crazy slow which is why nobody does that.

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

#420

Post by mahyarm »

jahewson wrote: post #212
mahyarm wrote: post #139

Earlier quoted context omitted.

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…

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.

It was easy to detect because they are not to trying to hide it. They just have to check if the library exists.
Post reply on HN