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.
Apple starts rejecting apps with “hot code push” features
401–410 of 498 posts
Re: Apple starts rejecting apps with “hot code push” features
#402Earlier 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.
Re: Apple starts rejecting apps with “hot code push” features
#403Earlier 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?
Re: Apple starts rejecting apps with “hot code push” features
#404Earlier 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?
Re: Apple starts rejecting apps with “hot code push” features
#405Earlier 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…
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
#406Earlier 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?
Please?
...pretty please?
Re: Apple starts rejecting apps with “hot code push” features
#407Just 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.
Re: Apple starts rejecting apps with “hot code push” features
#408Earlier 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.
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
#409Earlier 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)…
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
#410Earlier 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)…