`onFileDownload` is called with the URL that you can use to download the file.
When RNCWebView detects that the HTTP response should result in a file download,
`onFileDownload` is called. The client can then provide code to download
the file.

RNCWebView determines that a file download should take place if either of the
following is true:
1. The HTTP response contains a `Content-Disposition` header that is of type
  'attachment'
2. The MIME type of the response cannot be rendered by the iOS WebView

* [apple] Move iOS/macOS src into common apple dir

* [apple] Enable macOS as platform in podspec

* [example] Use CocoaPods & auto-linking on macOS

* [docs] Update setup for macOS

* [package] Include apple dir in distribution

* Fixes Issue #1140

Fixes https://github.com/react-native-community/react-native-webview/issues/1140
Based on a solution found at: https://stackoverflow.com/questions/56460362/how-to-force-wkwebview-to-ignore-hardware-silent-switch-on-ios
I changed the code found in the linked source from Swift to Objective-C, as required by this project. WARNING: I haven't used Swift before and very limited experience with Objective-C.

- For me this seems to work, but it is not the cleanest solution in my opinion.
- It might also be possible to play generated sound (i.e. using oscillator) instead of hardcoding the silent base64 mp3 data.
- Maybe ignoring silence switch should only be done if a parameter is supplied

* fixes import path

* adds documentation for ignoreSilentHardwareSwitch

* adds ignoreSilentHardwareSwitch parameter

* reverting back to old import path

* Update Guide.md

Co-authored-by: Dominik Beste <dominik.beste@gmail.com>

BREAKING CHANGE: 
• Props updates to `injectedJavaScript` are no longer immutable.

• `injectedJavaScript` no longer attaches a `jsEvaluationValue` property to the `onLoadingFinish` event. Check out: https://github.com/react-native-community/react-native-webview/pull/1119#issuecomment-574919464 to migrate with the same behavior.

BREAKING CHANGE: if you use onNavigationStateChange on iOS it will now trigger on # changes to the url.

* Hook the `window.history` API on iOS to generate events

The underlying WKWebView doesn't seem to generate any events in response to the `window.history` API - none of the `WKNavigationDelegate` methods fire.

Given this limitation, the only way to know when the location changes via this API is to inject Javascript into the page and have it notify the native code directly when any of these functions are called.

The `setTimeout` call gives up the current tick, allowing the location to change before firing the event.

* Remove the outdated section about hash changes

Now that this bug is fixed, the workaround is no longer required.

* Run the injectedJavaScript on DocumentStart for iOS

* Add new prop injectedJavaScriptBeforeContentLoaded
Update types
Update docs

* Self review

UIWindowDidBecomeVisibleNotification and UIWindowDidBecomeHiddenNotification seem far more reliable at detecting fullscreen video.

Tested on iOS 11, 12 and 13

* Fix Xcode warnings (enums, whitespace, string literals)

* Add nullability notations

* Add callback for WKWebView's onContentProcessDidTerminate

* Add platform information to docs

* Add new WebViewTerminatedEvent type

* Allow custom CA to be used on webview requests

* Add documentation and an example for Custom CA / SSL Pinning

* fix inconsistent backgroundColor

* remove redundant setBackgroundColor

* fix(ios):use RCTConvert to convert url instead of using URLWithStringg

* fix(iOS):remove stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding, because it's deprecated in iOS 9

Apple required us to remove this (see #819)

BREAKING CHANGE: UIWebView has been removed
BREAKING CHANGE: useWebkit prop removal
BREAKING CHANGE: scalesPageToFit prop removal on iOS (since it's not compatible with WKWebview)
BREAKING CHANGE: Renamed RNCWKWebView to RNCWebView on iOS

* add-javaScriptEnabled-in-IOS

* Update WebViewTypes.ts

* Adding a `contentInsetAdjustmentBehavior` prop to the WebView for iOS.
This controls the way iOS will automatically adjust the insets when the
webview is behind things like the iPhone X notch.

* Removing the code to explicitly pass contentInsetAdjustmentBehavior to the WebView since it is already passed in otherProps.

* Changes error/redbox into warning/yellowbox. So wouldn't crash production releases
* Warning added actual error, useful for debugging bad JS injected into webview
* callback runs, whether there's error or not. As used in my app (https://medium.com/wonderswipe/rethink-mobile-search-10-100x-faster-introducing-wonderswipe-6f2ff0d0e6) which injects JS into sanitized html from the wild, small error in injected JS doesn't warrant the whole JS payload from being injected/run

* Pass mainDocumentURL to onShouldStartLoadWithRequest

* Update reference

* Update typescript types

* Update WebViewTypes.ts

* Add `onScroll` callback for iOS & Android

This code was mostly extracted from https://github.com/react-native-community/react-native-webview/pull/202

I tried and tried to make it work with `Animated.event`'s `useNativeDriver`, but I was unsuccessful 😢 that'll have to be done later once I understand better how Animated's native stuff is hooked up.

* fix crash for missing onScroll

fixes #62

* [iOS] Allow focus without user interaction

* Add documentation for keyboardDisplayRequiresUserAction

* set keyboardDisplayRequiresUserAction default to true

We had the problem on iOS WebViews that local cookies (stored in local HTTPCookieStorage, set with  [react-native-cookie](https://github.com/shimohq/react-native-cookie) ) were not added in loadRequests. On Android the local stored cookies were sent like expected.
This kinda "hacky" solution is the only way we found, that works for us.
The stack overview link is in the code below.
If someone finds a better solution we would very much like to accept that.

fixes #371

* Don't allow the scrollview to scroll the WebView body.

* Readme comment

* Remove duplicate protocol def

This PR fixes two crashes when enableWebKit is true (which was the default) on iOS 9.x. The first one when the WebView component was mounted (fixes issue #150) and the second one, when the component was unmounted (fixes issue #213).

The first problem happen when the RNCWKWebView.m was loaded:

The programming guide for WebKit (version 2006) ([pdf](http://mirror.informatimago.com/next/developer.apple.com/documentation/Cocoa/Conceptual/DisplayWebContent/WebKit_DisplayWebContent.pdf)) from Apple said, that it is (was) required to check if the 'new' WebKit Framework was available. This was required when the WebKit framework was only available on Mac OS X (10.2) when the Safari was installed. 😆

Because WebKit is (currently..) a fix part of iOS we didn't need this check this anymore to determinate if WebKit is available. I also see no other reference that this is required in iOS so I just remove this code. Without this code the WebView works also on iOS 9.x.

The second issue happen when the WKWebView was removed from the native view hierarchy. Its required (only on iOS 9) to remove the UIScrollView delegate before cleaning up the webview.

Its possible to try this PR with:

```
npm install --save "react-native-webview@jerolimov/react-native-webview#fix-ios9-crash"
# or
yarn add "react-native-webview@jerolimov/react-native-webview#fix-ios9-crash"
```

If you use CocoaPods, you should also update your Pods with

```
cd ios && pod update && cd ..
```

* In order for TLS Mutual Auth to work for webviews, the caller must present a credential. Expose a setter that can be called to set a credential.

fixes #304

fixes #29
fixes #272
fixes #221
fixes #105
fixes #66

BREAKING CHANGE: Communication from webview to react-native has been completely rewritten. React-native-webview will not use or override window.postMessage anymore. Reasons behind these changes can be found throughout so many issues that it made sense to go that way.

Instead of using window.postMessage(data, *), please now use window.ReactNativeWebView.postMessage(data).

Side note: if you wish to keep compatibility with the old version when you upgrade, you can use the injectedJavascript prop to do that:

const injectedJavascript = `(function() {
  window.postMessage = function(data) {
    window.ReactNativeWebView.postMessage(data);
  };
})()`;

Huge thanks to @jordansexton and @KoenLav!

Fixes #139

Added a new cacheEnabled prop to toggle Android & iOS webview caching behavior.

BREAKING CHANGE:  This change makes caching enabled by default when previously there was no caching behavior which may cause unexpected behaviour changes in your existing implementations.

Allows the webview to be opened with an ephemeral data storage.