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

391–400 of 498 posts

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

#391

Post by tomaskafka »

masklinn wrote: post #244
Angostura wrote: post #159

Earlier quoted context omitted.

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.

Supercell's games and a bunch of F2P collect-ish games also do that, when you open the game they have an update process. I'm reasonably sure that only updates static assets though, stuff like description files and graphic assets. It's actually pretty useful as it lowers the payload of the core engine and lets them do much smaller updates compared to having to bundle it all, that's especially important with things lik…

I bet it's some code too.

Worked on a F2P mobile game, we bundled a tiny Lua engine, and them pushed various promotion screens as a bundle of resources (images) and lua code (screen layout, its preconditions and what's gonna happen after you click - game provided a small API that Lua called).

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

#392

Post by euyyn »

tluyben2 wrote: post #252
jahewson wrote: post #198

Earlier quoted context omitted.

Many private APIs are methods on objects which are part of public APIs, so there's no "region" of memory which cleanly corresponds to private APIs.

But they can theoretically create that as they own the entire chain; dev env, tools, OS, software, hardware (CPU included). I know it is not currently the case, sure, but they can do it was my point.

They "own" a compiler, but not all of them.

Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region.

Nothing prevents gcc from producing object files that tell the linker "this user function is part of Apple's public APIs". And nothing prevents people from using a different linker anyway, one that would put private API body functions out of the restricted region of memory.

The only real way to achieve that would be to move all their frameworks to the kernel, which would be all sorts of problematic.

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

#393

Post by st3v3r »

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…

No. Apple has plenty of experience doing that themselves, without that. There's a reason the term "Sherlocking" exists.

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

#394

Post by cortesoft »

Spivak wrote: post #365
wolfgke wrote: post #269

Earlier quoted context omitted.

What is "code"? Everybody who has programmed in LISP or Scheme knows that there is no essential distinction between code and data (only many programming languages make it a little hard to see that it is all the same). Thus Apple would have to see not only all code, but also all data that goes onto the devices. But this would imply that Apple disallows all apps that read data from a foreign (i.e. at least not Apple-co…

Which is why you're not allowed to use a Lisp interpreter or use any method of evaluating data as code. In this model the only thing that data can do is change which code paths run, not what they do.

Changing a code path is the same as changing what they do.

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

#395

Post by [deleted] »

elldoubleyew wrote: post #371
abcd_f wrote: post #151

Earlier quoted context omitted.

> Oh man. You were surprised? Really? Exactly! Apple has always been adamant that they see _all_ code that goes onto devices. Live patching is so bloody obvious against their EULA.

So if I have an imbeded webpage inside of my app and that website is updated do I suddenly violate the EULA. What if its a social media app that provides users the ability to write custom HTML/CSS/JS to personalize their profiles and a user writes a game that runs in the header of that profile. What if that game suddenly allows the ability to access copyrighted material? I just don't understand how Apple is supposed…

[deleted]

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

#396

Post by tgragnato »

gattilorenz wrote: post #324
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…

Sorry to be OT, but since you're the CEO I do hope you found out if Rollout supports swift as well :^) https://news.ycombinator.com/item?id=8158046

bewildered ๏_๏

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

#397

Post by stinkytaco »

maverick_iceman wrote: post #358
stinkytaco wrote: post #312

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.

Justice Clarence Thomas wouldn't agree with you.

Considering his decision in Bush v. Gore compared to his other decisions surrounding voting rights and the EPC, I'd say he is not above reproach in the area of consistency. (this could be said of judges on both sides of that case)

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

#398

Post by jameside »

Vinnl wrote: post #172
jameside wrote: post #103

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 has been fine with WebViews in apps since the beginning of the App Store, including WebViews that make calls to native code, like in the Quip app. WKWebView even has APIs for native and web code to communicate. It's OK for a WebView to call out to your native code that saves data to disk, registers for push notifications, plays a sound, and so on.

React Native is very much like a WebView except it calls out to one more native API (UIKit) for views and animations instead of using HTML.

What neither WebViews nor React Native do is expose the ability to dynamically call any native method at runtime. You write regular Objective-C methods that are statically analyzed by Xcode and Apple and it's no easier to call unauthorized, private APIs.

With Expo all of the native modules are safe to use and don't expose arbitrary access to native APIs. Apps made with Expo are set up to be good citizens in the React Native and Apple ecosystems.

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

#399

Post by Cpoll »

retbull wrote: post #379
ryandrake wrote: post #334

Earlier quoted context omitted.

Thank you! As a fellow "Correct Idiom Usage Nazi" that made my day. Have an upvote :)

Holy crap its `deep ceded` not `deep seated`?

No, the reply was filled with eggcorns / mondegreens, i.e. misheard idioms.

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

#400

Post by syntheticcdo »

chii wrote: post #179
jvzr wrote: post #169

Earlier quoted context omitted.

Probably a controversial opinion, but seeing how Safari is the only browser behaving correctly on macOS (performance- and battery-wise), I'd assume only Apple has the motivation to make a correct browser for iOS. Imagine the kerfuffle if Google had Chrome on iOS. 2% of "PC" users complain of Chrome hitting their battery hard on macOS. iOS has a much bigger market share. Competition is healthy, I agree. But sometimes…

why not let the consumer decide their browser of choice? Apple isn't prevented from creating battery efficient code by allowing others to write a browser.

The consumer is free to choose Android.
Post reply on HN