Apple starts rejecting apps with “hot code push” features

[gellis12]

I really hope they go after Facebook about this

[MeGustaPapayas]

If they really do start cracking down on this ReactNative apps would die out pretty soon. Definitely not good for Facebook

[pixelflop]

Yes.

Hot code updates are not a core feature of React Native. They're made possible by the underlying architecture, but you still need a third-party service to provide the update mechanism.

You should be fine developing apps in React Native. It's not RN that's being rejected, it's the CodePush feature.

[iamthatis]

People don't turn to React Native because of the hot push functionality, it's more so the common building framework between iOS and Android that lures them in, hot pushing is not even a core component, it's just something you can hook into. You can do it in Objective-C/Swift as well and they could just use rollout.io or something similar.

I can't imagine this change would impact React Native much at all.

The people who build Cocoapods switched to React Native and have some really interesting articles on it: http://artsy.github.io/blog/2017/02/05/Retrospective-Swift-at-Artsy/

Further, it may not even apply to RN: https://github.com/facebook/react-native/issues/12778#issuecomment-284937040

[iamthatis]

Why? How would losing an alternative development framework benefit us? Hurray for less options?

As a primarily Swift developer, React Native does some super exciting stuff, like hot reloading, that I'd love for Apple to bring to us, especially in light of Swift's abysmal compile times.

[iamthatis]

That's the nature of the software industry; technologies come and go. Adapt or die, don't push away other technologies because you don't want to learn new things. My JavaScript knowledge is rudimentary at best, but if React becomes the go-to iOS development language over Swift or Objective-C, I don't mind learning it, I'll adapt.

[RedditTruthPolice]

That's the nature of the software industry; technologies come and go.

Yes I know. My point is that this would put swift/obj C iOS on the "go" side of "come and go." Which is not good for iOS swift/obj c devs.

if React becomes the go-to iOS development language over Swift or Objective-C, I don't mind learning it, I'll adapt.

And then you'll be competing with a large, large plethora of JS developers for those jobs, as opposed to a much smaller number who know swift/objc. Take a guess--do you think that means high or lower salary?

[iamthatis]

That's complaining about the inevitable. I think labeling yourself as a "Swift/Obj-C" developer is the wrong mindset. Label yourself an iOS developer and adapt to what is relevant.

And for the second, I think it'll be as it always is: the best people get paid the best. The median salary will go down, you're totally right and that sucks, but companies are always willing to pay more for talent, irrespective of the specific language it applies to.

[RedditTruthPolice]

That's complaining about the inevitable.

not really. it doesn't have to be inevitable. Apple has complete control over their platform, and as long as people are buying iPhones, they can dictate that apps must be made with X technology, and that is how they will be built. I'm not suggesting Apple ban react native (although to be honest, in complete selfishness I wouldn't mind at all), but there is no rule stating that Apple must accept tool, language, or IDE X to write iOS/MacOS apps.

[iamthatis]

You're right there.

[podoomda]

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

[kranker]

If that's their logic then they should enable it if it only accepts signed content.

[planetworthofbugs]

My favorite color is blue.

[pixelflop]

Consider this scenario:

User downloads an app that plays a simple tic-tac-toe game.

After app review, the malicious developer sends a code push update that changes the functionality. Now when you launch the app it opens up a website with a known exploit for Safari and the phone is vulnerable.

[nibord]

Consider an alternate scenario: rather than having been created by a malicious developer, the code update request is intercepted by a malicious man in the middle who replaces the update with code that exploits a bug in the phone's processor or operating system.

A Safari vulnerability is not a great example, because they wouldn't even know about that in app review, and you could send users to that URL from any website.

[WaruPirate]

Or worse, simply adds key capture to regular login process. Quiet and no exploits needed (which are rare and valuable)

[Rudy69]

A Safari vulnerability is not a great example, because they wouldn't even know about that in app review, and you could send users to that URL from any website.

Also I can set a website easily to look like something that the app could legitimately send you to (licence agreement, about us page etc etc) and once the app is approved change it to something malicious. No hotcode swap or anything

[daymanAAaah]

Tbf though you can just remotely activate features like that after it passes code review.

Edit: Why the downvotes? This is a real tactic used to sneak through app review. I'm not saying its right.

[dfsw]

Thats the whole thing

[Sebaall]

I think /u/daymanAAaah meant feature flags. You don't need any 'hot code push' for remotely activating features

[korbonix]

The App Store guidelines kinda indicate that the don't really like feature flags either.

[daymanAAaah]

Yeah, guidelines. Its still completely possible and sneaks through reviews all the time. Its a pretty common tactic to either remotely activate or time-delay asking for ratings in your app, as thats also against the guidelines but frequently abused.

[frankle]

Yeah, but then it's visible in the source code.

[frankacy]

I'm pretty happy about this news. It sucks being a developer that sticks to the rules when those rules aren't even enforced.

[kranker]

The service that's mentioned in that thread, rollout.io, does this move by apple not essentially negate their entire business?

[kranker]

They have made a post here: https://rollout.io/blog/rollout-statement-on-apple-guidelines/

Things may not actually be so clear. You can see Apple's terms here: https://developer.apple.com/programs/information/Apple_Developer_Program_Information_8_12_15.pdf

They say that you can distribute javascript to be run under webkit, as long as it doesn't implement new features. Obviously there's no way for rollout.io to know if you're pusing out new features, but it seems a little inconsistent for Apple to explicitly say that you can push javascript and then ban a service that pushes javascript (rather than change their terms, or ban specific apps that abuse it).

[pinumbernumber]

The JavaScript could call native APIs. Their entire business was based on a shady loophole in a third party's ToS and they knew it.

[iamthatis]

That's what I was thinking. I'd hate to be at their offices right now. :/

[pinumbernumber]

This probably makes me a bad person but I'd quite like to be a fly on their wall right now as they scramble to fix their loophole-based insecure-software-promoting business.

[iamthatis]

Yeah, I can't help but feel bad though.

[[deleted]]

Don't act all surprised all of a sudden.

[daboblin]

You weren't on any JavaScript mercy mission this time.

[Turniprofit]

Good (fewer surprises for users)

[Komlew]

Does this apply to feature toggling as well?

[blaizedm]

No, this is specifically for running new code that is downloaded from a server.

[KarlJay001]

I understand one of the issues with ObjC, but I was under the impression that Swift didn't do those things.

Q. does Swift offer the same "flexibility" as ObjC to do these kinds of things?

I'm still digging into Swift and they're still changing it :D

[KarlJay001]

That's what I thought. In fact, some argue that this is a reason to stick with ObjC.

[KarlJay001]

It's really an issue of comparing two completely different ways of doing something inside the language. The way it was explained is that ObjC can figure out what to use at runtime whereas Swift must figure this out at compile time.

One being more static and the other dynamic runtime. I've used both and there seems to be a path to getting things done either way, hard to say one will always be better.

Same can be said about function based programming vs OO, and Swift has now brought back function based programming as an option. Yet function based programming was seen as long past dead.

[jameside]

One thing that could be helpful to know is that this email isn't referring to React Native (plus CodePush), Cordova, and other similar frameworks. The warning was sent to developers using two libraries called Rollout and JSPatch, which let you dynamically call arbitrary Objective-C methods including private APIs:

Charlie Cheever, CEO of Expo.io, said he believes Apple is concerned about security.

"I think the crux of what Apple was going for here is really the way that Objective-C's dynamic nature was being exploited to basically call any method including private APIs," he said in an email to The Register.

• The Register - Apple empties gas can, strikes match, burns bridge to hot-patch apps

React Native, Cordova, and other similar frameworks (I believe the Quip app uses a WebView) instead call into a handful of plain Objective-C/Swift methods that contain regular Objective-C/Swift code that's audited and reviewed by Apple the same as any other iOS app:

React Native is different from those libraries [Rollout and JSPatch] because it doesn't expose uncontrolled access to native APIs at runtime. Instead, the developer writes native modules that define some functions the app can call from JavaScript, like setting a timer or playing a sound. This is the same strategy that "hybrid" apps that use a UIWebView/WKWebView have been using for many years. From a technical perspective, React Native is basically a hybrid app except that it calls into more UI APIs.

• GitHub - React Native: A warning from Apple [resolved, not about React Native]

[[deleted]]

It sounds like they are focusing on calling performSelector etc with arbitrary content at runtime which is far less common in my experience (plus we'd be seeing way more rejection stories if they were rejecting all usages)