Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

401–410 of 498 posts

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

#401
post #172

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…

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.

Webkit is the only acceptable browser engine on iOS. Firefox and Chrome both use webkit on iOS.

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

#402

Earlier quoted context omitted.

Uber is still doing kind of ok.

Uber may be good at skirting local laws, but as a company it's a ticking bomb.

Uber is not a ticking time bomb if it is able to convince a sizable portion of the regulators of the markets it operates in to continue to operate for the foreseeable future

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

#403
post #224

Earlier quoted context omitted.

CNCopyCurrentNetworkInfo gives any app network info, including the SSID.

Does this still work? A cursory googling says it was deprecated in iOS 9 betas but may have been re-enabled?

Depreciated is not removed. Apple is usually very conscientious about depreciating things, then waiting a while before removing them. In some cases they have gone to great lengths... for example the now 5 year depreciation of OpenSSL: first they marked it depreciated, which generates a compiler warning, then after a few years they removed the headers from the MacOS SDK so you couldn't compile new software but left the binary in place so that old software would continue to work. The next step will probably be to remove that binary, something I would expect in MacOS 10.13 (sometime this year) or 10.14 (presumably next year).

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

#404
post #266

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…

Rather than a speculating on what really boils down to semantics once ToS is involved maybe someone could actually try submitting an app and reporting back on whether it triggers the same failure?

I haven't heard any reports of Expo developers or React Native developers (who aren't using Rollout or JSPatch) getting this warning.

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

#405

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.

Disagree -- it's not the court's job to even categorize a thing as a loophole or not. It simply applies the law. Some actions will fall inside a prohibition and some outside. Divining the intent of the drafters of the law is something fraught with problems considering the process. Just one example -- there may have been a group of supporters of the law in question used against Aereo that only supported the law becaus…

> Divining the intent of the drafters of the law is something fraught with problems considering the process.

And yet judges talk about the "spirit of law", as distinct from the "letter of the law", all the time.

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

#406

Earlier quoted context omitted.

I'm guessing, from Apple's perspective, things that overlay the whole screen and alter the appearance of other people's apps (such as applying a colour cast), are essentially "white hat phishing". It makes security sense to hide this capability in the OS and not in apps.

You can see, I trust, how this could lead down a monopolistic slippery slope. For instance, virus-scanning is a dangerous enterprise, given that it exposes a greater attack surface if the antivirus program is poorly written. Should Apple and Microsoft remove the ability for third-party antivirus apps to exist? How about third-party firewalls?

> Should Apple and Microsoft remove the ability for third-party antivirus apps to exist?

Please?

...pretty please?

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

#407

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?

Apple would not, because they don't allow apps to provide a JavaScript runtime. It would be possible to build a browser without JavaScript though.

Possible, but forbidden by Apple as well. ( section 2.5.6 of https://developer.apple.com/app-store/review/guidelines/ )

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

#408

Earlier quoted context omitted.

Disagree -- it's not the court's job to even categorize a thing as a loophole or not. It simply applies the law. Some actions will fall inside a prohibition and some outside. Divining the intent of the drafters of the law is something fraught with problems considering the process. Just one example -- there may have been a group of supporters of the law in question used against Aereo that only supported the law becaus…

> Divining the intent of the drafters of the law is something fraught with problems considering the process. And yet judges talk about the "spirit of law", as distinct from the "letter of the law", all the time.

> And yet judges talk about the "spirit of law", as distinct from the "letter of the law", all the time.

No, they don't; I've read lots of legal decisions, and that phrase or anything like it is rarely invoked. Pundits, not judges, are prone to talk about the spirit of the law as opposed to the letter; judges are more prone to talk about legislative intent (not "spirit of the law"), not distinct from the letter of the law, but as part of the analysis of which of several facially plausible meanings the letter of the law should be given in the context of the specific fact pattern presented in the case they are dealing with.

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

#409
post #349

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

I believe carefully crafted update should mostly mitigate that risk.

Also current policy don't prevent app developers to implement a "kill switch" that will prompt user to update (or wait for update) at splash screen and abort loading the malfunctioning version.

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

#410
post #349

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]
Post reply on HN