Earlier quoted context omitted.
Unless "The Singularity" (and subsequent mind-uploading) actually pans out.
That only delays the inevitable.
[Till the sun runs down][1]
Apple starts rejecting apps with “hot code push” features
331–340 of 498 posts
Re: Apple starts rejecting apps with “hot code push” features
#332Earlier 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.
Can you get confirmation that CodePush won't be impacted?
Re: Apple starts rejecting apps with “hot code push” features
#333Earlier quoted context omitted.
> Now, I'm not a fan of Apple's policies. I think there should be a "guys, I know what I'm doing" mode where I'm allowed to download code from untrusted sources. This exists today and has for a long time, it just costs you money for this "privilege".
You can compile and run apps on your own devices without a paid developer membership: https://www.google.com/amp/s/9to5mac.com/2015/06/10/xcode-7-...
They've nerfed this so that the app will only run for a week before you must push another build.
Re: Apple starts rejecting apps with “hot code push” features
#334Earlier quoted context omitted.
> ruff shot "Rough shod", before we get another mondegreen propagating across the internet.
As a case of point - as a matter in fact For all intensive purposes this article peaked my interest because by in large it addressed a deep ceded issue with app updates
Thank you! As a fellow "Correct Idiom Usage Nazi" that made my day. Have an upvote :)
Re: Apple starts rejecting apps with “hot code push” features
#335Earlier quoted context omitted.
> And ultimately it's their store and their rules. It wouldn't be as bad if their store weren't also the only store available for the platform. Because of this forced monoculture, the criticisms are well within scope.
Yeah, so we can have one store with strict policies that protect users and the value of the hardware; and a bunch of other shit stores that offer apps that can hijack our devices. That makes sense! And then Apple is to blame, and can spend tons of dollahs and man hours to fix problems caused by your "open" alternatives.
remember a few years back when windows was trying to promote their mobile app store and they were paying people to write shit apps just to have them hosted in the store? Or android where (at least they used to ) have fake apps that tell you how to "get" the real app ?
Re: Apple starts rejecting apps with “hot code push” features
#336Earlier 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…
f.lux strikes me as a good example. f.lux came to the market first with its idea to control screen temperature. Apple decides "No, you're not allowed to do that...but that's a great idea!", kicks f.lux out of the app store, and then adds their own Night Mode into later versions of iOS, using API's only they are allowed to access.
I love f.lux and have a soft spot for the very nice developer couple behind the app.
That being said, it's hard to argue that Apple (or Android) shouldn't be able to set boundaries on behaviors which are only allowed to be done by the OS as a opposed to an app. Apple's tight control of device screen characteristics makes it pretty understandable that they don't want one app able to control how another app looks on the screen.
The optics of the f.lux situation is just really, really bad. But considering the f.lux never really charged, they have a claim to fame that few can match: creating a feature good enough that Apple incorporated into both iOS and MacOS (now in beta).
Re: Apple starts rejecting apps with “hot code push” features
#337I'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
Hah, neat
Re: Apple starts rejecting apps with “hot code push” features
#338Re: Apple starts rejecting apps with “hot code push” features
#339Earlier quoted context omitted.
No, what you end up doing is effectively destroying the security protections Apple puts in place to protect the user from unknown/bad code from running on their device. Apple signs apps for a reason -- now we have to trust you to deliver that code safely to the user without being manipulated in transit. I also have to trust that you will respect my privacy. And I don't. It also seems clearly against their EULA, so yo…
> And ultimately it's their store and their rules. It wouldn't be as bad if their store weren't also the only store available for the platform. Because of this forced monoculture, the criticisms are well within scope.
ios has as many stores as Android, all you need to do is jailbreak.
Re: Apple starts rejecting apps with “hot code push” features
#340Earlier 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…
> The reason that's allowed is because everything executes within a sandboxed browser environment. No native code is downloaded. That's the same thing Rollout does. In fact, iOS apps can't download and run native code. The OS won't let you mark pages as executable unless they're appropriately signed, and only Apple has those keys.
[deleted]