> On Sep 29, 2015, at 10:35 PM, [email protected] wrote: > > Then you realize it's a performance and security thing and it's pretty much > the same as the Safari Extensions API . Web views in WKWebView are actually a > separate process pool you don't own. > So you can translate the DOM stuff back to JavaScript DOM stuff
Hey, if I liked working with JavaScript DOM APIs I’d be a web developer :-p I prefer languages with fancy features, like warning me if I pass the wrong number of parameters to a function. At build time, even. In a hybrid app you’re going to need to have some communication between the web code and native code. But WKWebView hasn’t done much to enable that. On the JS side you have some really limited events you can trigger, and on the native side you can glom your stuff into a string of JavaScript code and pass it in to be evaluated — which isn’t just a PITA, it’s also very, very prone to injection attacks if you don’t quote everything correctly. You also can’t generate your own resources, except for a single HTML page. Any resources loaded from that page have to have ‘real’ URLs, and any navigation from that page goes to ‘real’ URLs. There’s no way to intercept and override the loads, or register your own URL protocol. The workaround is to run a real live in-app web server, listening on a real live TCP port. This also has some serious security implications, even if you only bind it to localhost. —Jens _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
