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

421–430 of 498 posts

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

#421

Post by iOSGuy »

jameside wrote: post #398
Vinnl wrote: post #172

Earlier quoted context omitted.

I do wonder why, if they're _really_ fine with that, why they're not fine with browsers with different rendering engines on iOS. Since they're not, I wouldn't have _too much_ faith in other things not being rejected.

Apple has been fine with WebViews in apps since the beginning of the App Store, including WebViews that make calls to native code, like in the Quip app. WKWebView even has APIs for native and web code to communicate. It's OK for a WebView to call out to your native code that saves data to disk, registers for push notifications, plays a sound, and so on. React Native is very much like a WebView except it calls out to…

Well, let's be clear here. I use React Native, and it would take me about 30m to write a bridged React Native method that could execute ObjC code dynamically, including accessing all the private APIs you could want.

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

#422

Post by wolfgke »

st3v3r wrote: post #390
wolfgke wrote: post #269

Earlier quoted context omitted.

What is "code"? Everybody who has programmed in LISP or Scheme knows that there is no essential distinction between code and data (only many programming languages make it a little hard to see that it is all the same). Thus Apple would have to see not only all code, but also all data that goes onto the devices. But this would imply that Apple disallows all apps that read data from a foreign (i.e. at least not Apple-co…

"What is "code"?" Apple has decided that, and you're not going to get around their policies with a clever rhetorical question.

> "What is "code"?"

> Apple has decided that, and you're not going to get around their policies with a clever rhetorical question.

Apple cannot change mathematical facts by "decisional" rhetoric.

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

#423

Post by mahyarm »

wrasee wrote: post #197
mahyarm wrote: post #162

Earlier quoted context omitted.

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.

> No binary code being injected. A number of other posts talk explicitly of dynamic delivery of native code. If you're sure, it's a genuine question: I'm interested to know how this works. Function pointer swaps are one thing, but how would this allow you to patch bugs in the app? I can see how this could let you change the app's behaviour, even including calling private API's, but surely this would be constrained to…

I think they are confused by the downloading of JavaScript files and executing that inside a 'native context'. I looked at how rollout did their stuff in detail a while back, so i can see how its easy to confuse the two.

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

#424

Post by paddyoloughlin »

wolfgke wrote: post #422
st3v3r wrote: post #390

Earlier quoted context omitted.

"What is "code"?" Apple has decided that, and you're not going to get around their policies with a clever rhetorical question.

> "What is "code"?" > Apple has decided that, and you're not going to get around their policies with a clever rhetorical question. Apple cannot change mathematical facts by "decisional" rhetoric.

Apple doesn't need to change mathematical facts, they just don't let you publish on their AppStore.

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

#425

Post by menckenjr »

jameside wrote: post #372
marcinzm wrote: post #290

Earlier quoted context omitted.

How is this any different from native code? Afaik, you can access the native compiled source code of an app on a jailbroken phone. Sure it's more of a pain to parse through but security through obscurity isn't security.

Definitely, running "strings" on a binary is about as easy as finding the JS for a hybrid app (WebViews or React Native). Depending on your experience it could be easier to extract API keys from an IPA than from JS. In either case the root issue is about sending secrets like an unscoped API key to the client. "Client secret" is an oxymoron in this context regardless of the programming language.

You'd have to know a few things first, like (1) the IPA is a ZIP file, (2) the ZIP file is actually of a directory and (3) you can dump the actual code in the JS files (if they're in the bundle directory) much easier than you can look for strings from the binary that might look like an API key.

The API key is actually the least of the hazards, since you can hide that in the keychain. Having source code for your business logic shipping in your app is not good; having it be hackable business logic (by changing the JS in place) is very not good.

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

#426

Post by Dylan16807 »

Brotkrumen wrote: post #270
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…

"We are in full compliance. Everything is fine. The house is not on fire. The heat you are feeling is coincidential." Man, do I dislike marketing speak. A "We knew we were non-compliant, but think the security benefits of quick bugfixes outweigh the disadvantages. We will work with apple to return to compliance." would've been honest, better and not bs.

You say that as if apple hasn't repeatedly shut down apps that were in compliance. Sometimes changing the rules after, sometimes not even doing that.

"We have always been in compliance with the guidelines, and we are asking apple and trying to figure out why we're somehow not in compliance" is a fair statement, and not at all BS.

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

#427

Post by genericpseudo »

John23832 wrote: post #320
stinkytaco wrote: post #312

Earlier quoted context omitted.

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.

To some extent I agree with you, but at the same time it is not the purpose of the court to create law. It is their job to interpret. Lawyers read and understand. Evolution of the law (which involves creating new portions of the law to cover previously created portions which are considered lacking), is the responsibility of the legislative branch (in that case, Congress).

> it is not the purpose of the court to create law

In common law systems it is precisely their job to do so.

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

#428

Post by John23832 »

genericpseudo wrote: post #427
John23832 wrote: post #320

Earlier quoted context omitted.

To some extent I agree with you, but at the same time it is not the purpose of the court to create law. It is their job to interpret. Lawyers read and understand. Evolution of the law (which involves creating new portions of the law to cover previously created portions which are considered lacking), is the responsibility of the legislative branch (in that case, Congress).

> it is not the purpose of the court to create law In common law systems it is precisely their job to do so.

In the United States, creation of law is the responsibility of the Legislative branch. There is no avenue for the Judicial branch to create law.

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

#429

Post by John23832 »

st3v3r wrote: post #388
John23832 wrote: post #320

Earlier quoted context omitted.

To some extent I agree with you, but at the same time it is not the purpose of the court to create law. It is their job to interpret. Lawyers read and understand. Evolution of the law (which involves creating new portions of the law to cover previously created portions which are considered lacking), is the responsibility of the legislative branch (in that case, Congress).

Under that reasoning, wiretapping laws and privacy laws should not apply to digital communications, because they were not specifically mentioned.

Not at all. If the existing law is interpreted by the courts to apply to digital communications then it does. Congress a has the ability to remove interpretations by specification.

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

#430

Post by John23832 »

stinkytaco wrote: post #387
John23832 wrote: post #320

Earlier quoted context omitted.

To some extent I agree with you, but at the same time it is not the purpose of the court to create law. It is their job to interpret. Lawyers read and understand. Evolution of the law (which involves creating new portions of the law to cover previously created portions which are considered lacking), is the responsibility of the legislative branch (in that case, Congress).

But the common law is evolving. That's why we review previous cases and cite precedent. Because we assume the interpretation of the law will change as soon as it comes into contact with facts. There is a point where Congress needs to get involved, but until they choose to do so, the court system is where the law happens . Sometimes that includes evolution, but I suppose it's up to the appeals system to draw that line…

I can agree with this.
Post reply on HN