Re:Apple starts rejecting apps with “hot code push” features
by wrasee on Wednesday March 08, 2017 @04:09AM
(#13819022)
> No binary code being injected.
A number of other posts talk explicitly of dynamic delivery of native code. If you're sure, it's a genuine question: I'm interested to know how this works. Function pointer swaps are one thing, but how would this allow you to patch bugs in the app? I can see how this could let you change the app's behaviour, even including calling private API's, but surely this would be constrained to calling pre-existing behaviour?
Or by adding new behaviour is this to mean new javascript behaviour.
Re:Apple starts rejecting apps with “hot code push” features
by mahyarm on Wednesday March 08, 2017 @01:42PM
(#13822495)
I think they are confused by the downloading of JavaScript files and executing that inside a 'native context'. I looked at how rollout did their stuff in detail a while back, so i can see how its easy to confuse the two.
Re:Apple starts rejecting apps with “hot code push” features
by burntrelish1273 on Wednesday March 08, 2017 @06:00AM
(#13819450)
Swizzling is incredibly useful. AFNetworking, MagicalRecord and GPGMail use it, just to name a few.
For swift they basically patch the app before it gets compiled so that every function, if it meets the conditional would execute their javascript code handler instead.
No binary code being injected.