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

161–170 of 498 posts

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

#161

Post by teknologist »

jameside wrote: post #135
teknologist wrote: post #93

Earlier quoted context omitted.

This appears to affect apps using JSPatch which is not pushing Objective-C but JavaScript. Source: https://github.com/bang590/JSPatch/issues/746 (in Chinese)

The key part of JSPatch is that it exposes arbitrary, uncontrolled access to native APIs. You could use it to call private APIs even because Objective-C doesn't distinguish between public and private APIs at runtime, so Xcode's compiler checks and Apple's static analysis can't anticipate which APIs are possibly called. In contrast, React Native doesn't expose uncontrolled access to native APIs. You write regular Obje…

I'm not sure why people are concerned about React Native being targeted by this new enforcement of the rule. It is not the same thing at all.

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

#162

Post by mahyarm »

ma2rten wrote: post #111
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…

You were relying on a huge loophole. The code runs inside JavascriptCore but it injects native code into the app.

An objc swizzle is not native code injection, it's a function pointer swap. They swizzle the method to their general objc message handler which then executes a piece of javascript code.

For swift they basically patch the app before it gets compiled so that every function, if it meets the conditional would execute their javascript code handler instead.

No binary code being injected.

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

#163

Post by 0x0 »

chj wrote: post #148
jameside wrote: post #103

Earlier quoted context omitted.

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.

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.

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

#164

Post by briandear »

trhway wrote: post #147
ChrisMorrisOrg wrote: post #138

Earlier quoted context omitted.

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

Not the same thing. It's like GM telling aftermarket accessories manufacturers that if they want to sell their products through GM dealers that they must meet GM standards. The inability to use Rollout has no real impact on consumers.. except by improving safety.

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

#165

Post by sametmax »

abcd_f wrote: post #151
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…

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

Unless you are Facebook or Google. Then it's fine and you get a free pass.

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

#166

Post by trhway »

briandear wrote: post #164
trhway wrote: post #147

Earlier quoted context omitted.

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

Not the same thing. It's like GM telling aftermarket accessories manufacturers that if they want to sell their products through GM dealers that they must meet GM standards. The inability to use Rollout has no real impact on consumers.. except by improving safety.

>if they want to sell their products through GM dealers that they must meet GM standards.

i wonder whether you're intentionally skipped that part or just don't know that in case of non-jailbroken iPhone the "GM dealers" is the only way to get "aftermarket accessories". There is no "if they want to sell their products through", instead there is "if they want to sell their products at all".

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

#168

Post by huhtenberg »

mahyarm wrote: post #158
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.

They don't 'see' the code. They run a program on the binary for some obvious checks and do a QA smoke test of the app itself.

You are thinking "source code".

"Code" is another term for what you are referring to as "binary".

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

#169

Post by jvzr »

chj wrote: post #150
ChrisMorrisOrg wrote: post #134

Earlier quoted context omitted.

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.

Probably a controversial opinion, but seeing how Safari is the only browser behaving correctly on macOS (performance- and battery-wise), I'd assume only Apple has the motivation to make a correct browser for iOS.

Imagine the kerfuffle if Google had Chrome on iOS. 2% of "PC" users complain of Chrome hitting their battery hard on macOS. iOS has a much bigger market share.

Competition is healthy, I agree. But sometimes the best interest of the vendor and the users don't align, and I'm more confident Apple is prioritizing battery life and performance over other things, while Google will prioritize those other things (like ads and data collection). I can't imagine them allowing adblockers on iOS (exactly as they don't on Android, afaik)

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

#170

Post by threeseed »

sametmax wrote: post #165
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.

Unless you are Facebook or Google. Then it's fine and you get a free pass.

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.

Post reply on HN