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

291–300 of 498 posts

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

#291

Post by wruza »

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.

From a user point of view, I see many differences and even paradigm shifts across webkit-based browsers on all platforms. When you call a browser 'just a wrapper over webkit view', I don't even know from where to begin. Specific engine is the last thing to consider today.

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

#293

Post by Jonnax »

mikeash wrote: post #284
w0utert wrote: post #283

Earlier quoted context omitted.

That seems like a strange way to put it. Apps can still do all kinds of nasty things inside their sandbox, for example calling private API's that are now supposed to be caught in the review process, but also less obvious things like hot-patching strings (e.g. URLs) in the binary, sabotaging the device by deliberately hogging the CPU, playing sounds through the speaker, popping up fake prompts for fishing, etc. I agre…

What's so bad about calling private APIs? I get why Apple doesn't want it, but as a user I don't care. The sandbox prevents apps from pulling in native code over the network. The OS won't allow pages to be marked as executable unless the code is signed by Apple.

Because a private API could give out details about you that you don't want shared to a random application or 3rd party advertising/analytics platform.

For example serial numbers, user ids, lists of installed applications, etc.

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

#294

Post by mnem »

mikeash wrote: post #284
w0utert wrote: post #283

Earlier quoted context omitted.

That seems like a strange way to put it. Apps can still do all kinds of nasty things inside their sandbox, for example calling private API's that are now supposed to be caught in the review process, but also less obvious things like hot-patching strings (e.g. URLs) in the binary, sabotaging the device by deliberately hogging the CPU, playing sounds through the speaker, popping up fake prompts for fishing, etc. I agre…

What's so bad about calling private APIs? I get why Apple doesn't want it, but as a user I don't care. The sandbox prevents apps from pulling in native code over the network. The OS won't allow pages to be marked as executable unless the code is signed by Apple.

It could be argued that because a private API has no guarantees against change, using them could lead to apps break after OS updates more frequently, which would annoy me as a user (whether or not I knew what was causing the crash).

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

#295

Post by Xylakant »

Operyl wrote: post #271
kalleboo wrote: post #223

Earlier quoted context omitted.

The rules explicitly forbid any HTML renderer or JS interpreter aside from WebKit, JIT or no JIT. I believe all the popular third party browsers today still use the non-JIT UIWebView rather than WKWebView because the former gives you more control over the request cycle

Except, apparently, Chrome https://blog.chromium.org/2016/01/a-faster-more-stable-chrom...

Chrome uses WKWebView on iOS, so it's basically safari with a different UI (so does firefox on iOS)

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

#296

Post by josefresco »

recursive wrote: post #50
cynix wrote: post #22

Earlier quoted context omitted.

> Rollout lets you push code-level changes to native iOS apps, without waiting on the App Store. What did they expect when their entire business model is based on something that's literally the opposite of what the review guideline allows?

Uber is still doing kind of ok.

So is Airbnb...

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

#298

Post by rimantas »

scarface74 wrote: post #261
menckenjr wrote: post #240

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…

You as an end user jailbreaking your own phone is not a "security hole". I'm not aware of any non-tethered jailbreak for iOS 10

Just using one to potential open many more to other apps.

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

#299

Post by mikeash »

Jonnax wrote: post #293
mikeash wrote: post #284

Earlier quoted context omitted.

What's so bad about calling private APIs? I get why Apple doesn't want it, but as a user I don't care. The sandbox prevents apps from pulling in native code over the network. The OS won't allow pages to be marked as executable unless the code is signed by Apple.

Because a private API could give out details about you that you don't want shared to a random application or 3rd party advertising/analytics platform. For example serial numbers, user ids, lists of installed applications, etc.

If a private API is a privacy or security concern then the sandbox needs to block it.

Apple blocks private APIs because they don't want to maintain their compatibility across OS releases and don't want third party apps to break when those APIs change.

Edit: I'm starting to suspect that people don't know what "private API" means, so I want to lay it out real quick. Apple ships a bunch of dynamic libraries with the OS that apps can link against and call into. Those libraries contain functions, global variables, classes, methods, etc. Some of those are published and documented and are intended for third parties to use. Some are unpublished, undocumented, and intended only for internal use.

The difference is documentation and support. The machine doesn't know or care what's public and what's private. There's no security boundary between the two. Private APIs do nothing that a third-party developer couldn't do in their own code, if they knew how to write it. The only way Apple can check for private API usage is to have a big list of all the private APIs in their libraries and scan the app looking for calls to them. This is fundamentally impossible to do with certainty, because there's an unlimited number of ways to obfuscate such calls.

Functionality that needs to be restricted due to privacy or security concerns has to be implemented in a completely separate process with requests from apps being made over some IPC mechanism. This is the only way to reliably gate access.

Apple's prohibition against using private APIs is like an "employees only" sign on an unlocked door in a store. It serves a purpose, but that purpose is to help keep well-meaning but clueless customers away from an area where they might get confused, or lost, or hurt. It won't do anything for your store's security.

Post reply on HN