Here's a quick pass at

java.io.InputStream

.

It's only the NS one we don't have

You can write it as an extension function but it will not be available to call from Swift or Objective-C then. See https://github.com/square/okio/issues/1113 for another example gone awry

For my use case, I only need the extension in Kotlin though. The code I'm working on is a KMM wrapper API for a database, which mirrors the JVM database API with Kotlin expect declarations. The actual implementations for android either typealias to the underlying SDK or call through to the underlying, when typealias is inadequate. The ios actual implementation similarly calls through to the ObjC SDK, massaging the underlying API to align with the Kotlin definition and converting between platform types.

Although, I could see how an extension could be useful when utilizing the database API in Swift/ObjC if the user wished to use an Apple native

NSInputStream

instead of okio's

Source

API. But it wouldn't be a strict requirement to provide such an API.

For the most part, users would be consuming the API in a KMM module in Kotlin though.

Would also want to avoid actually converting between streams multiple times anyway, considering the data copying required.

Here's a crack at

BufferedSource.inputStream(): NSInputStream

.

And here's

NSInputStream.source(): Source

. In this direction, you can actually avoid the data copy, as

ByteArray

can be written to as a

CPointer

.

I added some tests with these

NSInputStream

additions on this branch. Let me know what you think. I can make a PR.