Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

371–380 of 498 posts

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

#371
post #151

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.

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 to draw a line here.

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

#372

Earlier quoted context omitted.

This needs a little elaboration. Cached Javascript in any hybrid app is a security hole because that can be exposed through a jailbreak. Depending on how much of your business logic you've pushed into the JS layer to enable that "80% code sharing" that makes managers go all tingly you may be exposing all kinds of things - cached access tokens, API keys and whatnot - to anyone who wants to install your app and mine it…

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.

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

#373

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.

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?

Yes, I do. This is why we have a tiered system. The judge interprets the facts of the case and if they apply the law incorrectly, a higher set of judges can overturn.

EDIT: Or Congress can get involved and change the law. Checks and balances.

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

#374
post #322
post #217

Earlier quoted context omitted.

> 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

Heh, nice! I'm a big fan of eggcorns[1] and your post is positively teaming with them!

[1]: http://eggcorns.lascribe.net

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

#375

Earlier quoted context omitted.

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.

The main reason for React Native to not be impacted is that Facebook + Instagram + Airbnb + Soundcloud + ... are using it and Apple cannot justify to their userbase to not accept those favorite apps for a technical reason.

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

#376

Earlier quoted context omitted.

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…

"You write regular Objective-C methods that are callable from JavaScript," - the objC function that I am calling from JS can be capable of calling a private API received by it in an argument - that breaks the entire claim of reactNative not supporting calls to private API. React Native must also go down.

If you deliberately write code that calls private APIs that are exposed to JS in your React Native app, I expect only your specific app to receive this warning. The same would be true in an app that doesn't use React Native at all, as we've seen with apps using Rollout.

The warning is not about React Native, it's about exposing uncontrolled access to native APIs including private ones and React Native doesn't do that.

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

#377
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

Ouch.

This post deserves more attention.

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

#378
post #21

Earlier quoted context omitted.

The first time I saw Rollout I was shocked it wasn't already banned by the App Store. No matter what they say, I can't imagine how they could do what they claim to do without flagrantly violating the guidelines.

It only started to matter when dumbasses started thinking that using Javascript everywhere was A-OK.

Please comment civilly and substantively on HN or not at all.

https://news.ycombinator.com/newsguidelines.html

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

#379
post #322

Earlier quoted context omitted.

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

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

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

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

#380

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.

And when Apple changed the private undocumented API that allows the functionality, who should get blamed? Who do you think users will blame when previously working apps that used an undocumented function breaks with a new Os?
Post reply on HN