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

141–150 of 498 posts

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

#141

Post by ChuckMcM »

matthewbauer wrote: post #122
ChuckMcM wrote: post #116

Earlier quoted context omitted.

My guess is that somewhere in the giant dump of CIA malware there is an exploit that uses this to hijack an iPhone. They are pretty explicit about what they don't like and how it would be exploited.

An interesting theory but I kind of doubt the time between the release and this is enough for them to have identified these exploits.

I agree its a long shot. But perhaps they were on the fence about it and the CIA dump pushed them over the edge. Sadly there is no actual way to know for sure.

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

#142

Post by manmal »

homakov wrote: post #136

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.

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.

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

#144

Post by macspoofing »

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…

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.

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

#145

Post by BrightAlong »

It feels so wrong that app security still relies on manual code review.

Apple is afraid the app might call certain functions with certain parameters in the future. As an engineer I would not want to rely on human judgment what the code does.

The browser sandbox has been proven to work pretty well over the last years. That is why I prefer web apps over native apps.

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

#147

Post by trhway »

ChrisMorrisOrg wrote: post #138
grey-area wrote: post #131

Earlier quoted context omitted.

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…

I agree - they're definitely putting the customer's security first. If people want to use an open environment, the web browser is always available on iOS anyway. Apple are completely within their rights to restrict their application platform.

>Apple are completely within their rights to restrict their application platform.

it is like to say that GM is completely withing their rights to restrict where you can drive your GM car. Mind you, that is coming in pretty near future too - giving all the computerization/connectivity/self-driving of the cars which would make the cars into GM's "application platform" with DMCA protecting such a platform too like it protects Apple/Google/FB/etc...

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

#148

Post by chj »

jameside wrote: post #103
dilipray wrote: post #76

"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 nativ…

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

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

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

#149

Post by praseodym »

jsjohnst wrote: post #130
JohnBooty wrote: post #120

Earlier quoted context omitted.

> I'm guessing there are two things Apple is worried about. I'm sure it worries about them but there's a much larger, riskier scenario. Once you start downloading and executing binary code from untrusted sources (i.e., not the App Store) anything can go wrong. 1. An iOS app doesn't care about security, and it hot-loads code from some non-https source and gets man-in-the-middle'd 2. An iOS app hot-loads code in a secu…

> 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 compile and run apps on your own devices without a paid developer membership: https://www.google.com/amp/s/9to5mac.com/2015/06/10/xcode-7-...

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

#150

Post by chj »

ChrisMorrisOrg wrote: post #134
diminish wrote: post #129

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?

I strongly doubt Apple would ever ban web browsers. The amount browsing done on iOS is too significant, it wouldn't make sense to ban them.

At this moment Apple is effectively banning web browsers except their own safari. The other browsers you see on iOS are just a wrapper over the native webkit view.
Post reply on HN