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

211–220 of 498 posts

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

#211

Post by averagewall »

DaiPlusPlus wrote: post #188
huhtenberg wrote: post #168

Earlier quoted context omitted.

You are thinking "source code". "Code" is another term for what you are referring to as "binary".

Recently Apple added (and actively encourages) the ability for developers to upload bytecode to the App Store instead of ARM binaries so Apple can more easily dynamically recompile for new architectures and optimisations. Of course bytecode is considerably easier to revert back into readable source-code (especially as Swift/ObjectiveC retain (some) symbol names in compiled output) - so it's not outside the realm of p…

Can you identify a type of app for which reverse engineering it would be easier than writing their own? Software is usually easier to write than to read. If an app has such a magic secret sauce, and it's of value, then it should be protected by patent or copyright anyway.

An example that comes to mind is a high speed image compression app for taking rapid sequences of photos. Apple bought the company or the rights so they could include it themselves.

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

#212

Post by jahewson »

mahyarm wrote: post #139
tedd4u wrote: post #91

Earlier quoted context omitted.

This is true. The problem is bad actors can use this to bypass Apple's review. As an iOS app publisher I slightly regret this inconvenience. As an iPhone user, I appreciate Apple looking out for my security.

Apple's review isn't that useful in this case as a pre-check, it is possible to avoid it if you want. Apple review does automated code checks & a reviewer manually using your app. With that review process you can deliver executable code after the fact in any way you want and only get caught after the fact if it's even noticeable. You can even get sneaky and add some security exploit to make it look like a mistake. It…

Given that Apple's automated review tools detect many ways in which executable code can be injected into apps, and OP's link is itself about that very thing - what you say is mostly false.

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

#214

Post by jahewson »

stevehiehn wrote: post #109

I've recently been looking into React-Native. I'm hesitent to commit because i believe there's 'hot code push' potential and Apple will be a b *h about it. I not sure if this is the case thou.

There's hot code push potential in Swift and Obj-C too.

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

#215

Post by scintill76 »

orless wrote: post #191
teknologist wrote: post #100

It seems that most people are overlooking one of the more significant points Apple have made here: "Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app." Source: https://github.com/bang590/JSPatch/issues/746

I'm not buying the MITM argument in general. If remote code is downloaded via HTTPS, it could not be hijacked, at least not easily.

HTTPS is sufficient against MITM, until someone disables all verification to use their self-signed cert, or adds their poorly-secured "CA" cert to the allowed CA's for the download, or adds a weak cipher to the list. Do you trust every app developer to do those right (if they even use HTTPS!)[0], or would you rather trust Apple to get it right in the centralized system they designed for app updates for all apps?

I'm not even fond of Apple, but I'd rather trust them, and I'm glad they're protecting their users.

[0] Caveat: I don't know how likely/possible these are to occur on iOS. I assume a sufficiently motivated & misguided developer could do them within their own app's context.

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

#216

Post by jamespo »

sametmax wrote: post #204
threeseed wrote: post #170

Earlier quoted context omitted.

To some extent yes but often no. Apple has close relationships with those companies so it's often a case of them reaching out to the developers rather than just blinding rejecting the app. But any idea that Apple would allow them to run ruff shot over the platform and do whatever they wanted is a bit ridiculous.

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?

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

#217

Post by pjc50 »

threeseed wrote: post #170
sametmax wrote: post #165

Earlier quoted context omitted.

Unless you are Facebook or Google. Then it's fine and you get a free pass.

To some extent yes but often no. Apple has close relationships with those companies so it's often a case of them reaching out to the developers rather than just blinding rejecting the app. But any idea that Apple would allow them to run ruff shot over the platform and do whatever they wanted is a bit ridiculous.

> ruff shot

"Rough shod", before we get another mondegreen propagating across the internet.

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

#218

Post by justsid »

Angostura wrote: post #159
justinhj wrote: post #83

Earlier quoted context omitted.

Most likely most games are updating only game related data and graphics files. Very few games actually use internal scripting that would be needed to do code updates

The only app I've got that appears to actually update itself without going through the AppStore is the HSBC mobile banking app. I'd be interested in hearing the discussions going on between Apple and HSBC at the moment.

I was thinking of the HSBC app the whole time while reading this. In my opinion Apple should reject that piece of shit and force HSBC to write a native app that works properly.

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

#219

Post by jahewson »

Aissen wrote: post #201
simplehuman wrote: post #13

From https://rollout.io/how-it-works/ : Does Rollout comply to Apple’s Guidelines? Yes. As per Apple’s official guidelines, Rollout.io does NOT alter binaries. ... With over 50 million devices already running our SDK, it is safe to say that Rollout complies with with Apple’s development and App Store guidelines. Ouch. Just like the company's future is in danger.

It won't be the first $10m+ company killed by Apple's App Store policy. I hope it will be among the last though.

So you're routing for ${FutureAbusiveSpamCompany}?

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

#220

Post by runholm »

marak830 wrote: post #81
Nutomic wrote: post #59

Earlier quoted context omitted.

Google definitely forbids self-updating apps on Google Play. But I'm not sure how well this is enforced.

Horribly. I get a few games from the Japanese market, and almost each one requires in immediate internal download and update. Although those updates never trigger the Android update service, so I'm not sure if they are just downloading more resources of if they are able to request new permissions(I would like to assume not.)

The internal download and update is allowed when it consists of media resources and such which is not native executed code.
Post reply on HN