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

301–310 of 498 posts

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

#301

Post by menckenjr »

marcinzm wrote: post #290
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…

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.

You aren't "parsing" through compiled (and linked) code; you're decompiling it, which is a much trickier thing to do and get right. Having your app logic in Javascript in the sandbox cache is just serving it up on a plate.

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

#302

Post by joncrane »

axemclion wrote: post #88
htormey wrote: post #29

Earlier quoted context omitted.

Yep. I use code push in several apps. It's gonna be fun times next time I need to submit an app. I think it might be safe because it doesn't push native code and rollout is all about pushing native changes.

PM on the CodePush team here. The rejection notice seems to explicitly call out the native methods that are a cause of the issue. CodePush cannot inject private frameworks or expose any methods that React Native already exposes. I would also recommend not using CodePush to completely what an app does.

I accidentally what the app does.

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

#303

Post by menckenjr »

woah wrote: post #277
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…

Huh? Are you saying that the security hole is that a user could see stuff in the memory of their own phone?

Or someone that steals your phone, or picks it up when you lose it somewhere. Yes, there's the lock screen and passcode but...

http://www.wikihow.com/Bypass-iPhone-Passcode

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

#304

Post by jinglebells »

robk wrote: post #239
algesten wrote: post #195

Earlier quoted context omitted.

Judging by how sluggish and annoying the HSBC app is, I think it is a web app framed in a thin launcher from the app store. I.e. it downloads a bunch of javascript/html/css and that executes within a UIWebView/WKWebView. Using caching and localStorage, you can construct such an app to not need to download everything on each launch. The reason that's allowed is because everything executes within a sandboxed browser en…

Is it possible to do that and use the fingerprint sensor for login in a secure way? I thought the same as you until they enabled Touch login.

Yeah, https://github.com/EddyVerbruggen/cordova-plugin-touch-id shows how.

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

#305

Post by toyg »

scarface74 wrote: post #260
sametmax wrote: post #204

Earlier quoted context omitted.

It's not ridiculous, they have been doing it for a long time now. E.G: Apple uses private APIs ( http://sourcedna.com/blog/20151018/ios-apps-using-private-ap... ) to build some of their software and reject apps doing the same, effectively killing competition. But Google and facebook uses them because they want to create products that can compete with apple's features. E.G: https://daringfireball.net/2008/11/google_mo…

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…

> why developers criticize OS vendors use of "private APIs"

The point is not that these APIs exist; the problem is when vendors actively block others from using them, with hacks and/or policy bans. That's extremely hypocritical and anti-competitive. I can see why unofficial APIs must be discouraged (because let's be honest, developers will bitch and moan when they change -- Microsoft in particular was strong-armed into legacy support for decades by the likes of Adobe and Symantec), but it should never be an excuse to ostracize or tilt the playing field.

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

#306

Post by recursive »

wyager wrote: post #123
recursive wrote: post #108

Earlier quoted context omitted.

They run an illegal taxi service. There's an app for it too.

"Illegal" doesn't mean "I have a beef with it". Uber is legal in the vast majority of cities.

I know. I'm using "illegal" to mean "against the law".

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

#307

Post by froindt »

jamespo wrote: post #216
sametmax wrote: post #204

Earlier quoted context omitted.

It's not ridiculous, they have been doing it for a long time now. E.G: Apple uses private APIs ( http://sourcedna.com/blog/20151018/ios-apps-using-private-ap... ) to build some of their software and reject apps doing the same, effectively killing competition. But Google and facebook uses them because they want to create products that can compete with apple's features. E.G: https://daringfireball.net/2008/11/google_mo…

Do you have examples more recent than 2008?

I'm not sure if it's still the case, but I don't think you could record iPad screens at the start, though Apple demonstrated it as a possibility during their live demos.

I'm not sure if Apple made it available to other companies privately though.

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

#308

Post by libertymcateer »

macspoofing wrote: post #144
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…

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…

> 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.

Without reading the blog, I just wanted to comment on Aereo: a lot of us think that this was the wrong decision, and not in a facetious or 'cute' way.

To quote Scalia's dissent in the case:

> In a dissent that expressed distaste for Aereo’s business model, Justice Antonin Scalia said that the service had nevertheless identified a loophole in the law. “It is not the role of this court to identify and plug loopholes,” he wrote. “It is the role of good lawyers to identify and exploit them, and the role of Congress to eliminate them if it wishes.”

https://www.nytimes.com/2014/06/26/business/media/supreme-co...

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

#309

Post by oneplane »

toyg wrote: post #305
scarface74 wrote: post #260

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…

> why developers criticize OS vendors use of "private APIs" The point is not that these APIs exist; the problem is when vendors actively block others from using them, with hacks and/or policy bans. That's extremely hypocritical and anti-competitive. I can see why unofficial APIs must be discouraged (because let's be honest, developers will bitch and moan when they change -- Microsoft in particular was strong-armed in…

It's not about marketing, economics or other MBA-feuled non-technical ideas. It's about a software vendor saying: this is our platform, here are API's for you to use, don't go outside it.

It is perfectly reasonable, and so far, any other interpretation seems to be a skewed view to facilitate some sort of non-compliant piece of software.

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

#310

Post by artursapek »

ma2rten wrote: post #111
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…

You were relying on a huge loophole. The code runs inside JavascriptCore but it injects native code into the app.

That sounds like a huge hack. They built a company around that?
Post reply on HN