Usage in iOS app

[PasiSalenius]

I'm very interested in using Ikiga in my iOS app for parsing JSON messages, but was not able to build Ikiga as part of my project because of the NIO dependency. It seems to be there only because of ByteBuffer.

I could use Ikiga with Data instead of ByteBuffer. Is there an easy way to remove the NIO and ByteBuffer related code?

[Joannis]

👋 This is the next big focus point for me.

SwiftNIO is specifically popular in Server-Side Swift, which is where I started using it initially. The internals need to change a little bit to replace ByteBuffer with another data type internally, probably just Pointers themselves. I'll still maintain SwiftNIO in SPM and I'll also support using SwiftNIO on iOS.

For those who are interested in not using SwiftNIO, try using Ikiga 2.0 for now. Otherwise, I'll be closing this issue once I finished implementing this request. So be patient for that.

[PasiSalenius]

Hi @Joannis I got IkigaJSON v2 built along with the rest of my Xcode 11-GM based iOS project, with a small change in the code.

It does parse the JSON correctly but I'm seeing about double the CPU usage compared to using the native JSONSerialization.

So I'm comparing
let json = try? JSONObject(data: data)
with
let any = try? JSONSerialization.jsonObject(with: data, options: [])

Any idea what could cause the high CPU usage with IkigaJSON compared to the native decoding?

[Joannis]

This is an old issue, so I'm closing it. Sorry that I overlooked a later comment.
Most likely solution is to compile IkigaJSON on release. Native iOS tools (such as Foundation) are precompiled libraries with optimisations. Swift optimisations are a huge factor, and debug configurations will be severely slower.