in kmm why can’t we use apollo library under IOS 1...
# apollo-kotlin
m
in kmm why can’t we use apollo library under IOS 13 ?
m
There was something about WebSockets IIRC
Out of curiosity, what is the error you're getting? I remember (but I'm not 100% sure anymore) someone was able to link correctly on below versions
m
What exactly is the purpose of the NSURLSessionWebSocketTask? is that for graphql subscriptions ?
👌 1
m
yes, exactly subscriptions
m
Maybe a version without subscriptions could be released in order to serve users under iOS 13. not sure if that would be hard
for example we are not using any subscriptions whole project and we have a lot of users under ios 13
m
Do you get an error when trying to build your iOS app?
I'm asking because chances are that it's working already or that we can maybe workaround the error if any
m
Sorry for the late response, when i run the app with iphone 5 ( ios 12.4 ) i'm getting this crash
Copy code
dyld: Symbol not found: _OBJC_CLASS_$_NSURLSessionWebSocketMessage
 Referenced from: /Users/alkincakiralar/Library/Developer/Xcode/DerivedData/fizbot-alhlyiyitptqumeebpzkemzcvngh/Build/Products/Debug-iphonesimulator/Bifrost.framework/Bifrost
 Expected in: /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 12.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/Foundation.framework/Foundation
 in /Users/alkincakiralar/Library/Developer/Xcode/DerivedData/fizbot-alhlyiyitptqumeebpzkemzcvngh/Build/Products/Debug-iphonesimulator/Bifrost.framework/Bifrost
dyld: launch, loading dependent libraries
DYLD_FRAMEWORK_PATH=/Users/alkincakiralar/Library/Developer/Xcode/DerivedData/fizbot-alhlyiyitptqumeebpzkemzcvngh/Build/Products/Debug-iphonesimulator:/Users/alkincakiralar/Library/Developer/Xcode/DerivedData/fizbot-alhlyiyitptqumeebpzkemzcvngh/Build/Products/Debug-iphonesimulator/PackageFrameworks
DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 12.4.simruntime/Contents/Resources/RuntimeRoot/usr/lib
DYLD_ROOT_PATH=/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 12.4.simruntime/Contents/Resources/RuntimeRoot
DYLD_FALLBACK_FRAMEWORK_PATH=/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 12.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks
DYLD_INSERT_LIBRARIES=/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 12.4.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libBacktraceRecording.dylib:/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 12.4.simruntime/Contents/Resources/RuntimeRoot/usr/lib/
(lldb)
although i'm not using any graphql subscription method, i only use query and mutation
m
Alright 👍
SOunds like it crashes at start time, right?
m
yes at start time, also i just implement the library with spm and didn't import any viewcontroller or classes
m
I see. Mind opening an issue about this?
m
You want me to open an issue about it ?
m
Yes please. Doesn't look easy to workaround unfortunately 😞
So we'll have to go the route of separate dependencies
m
i see, im gonna open an issue thanks for your help 👍
🙏 1
m
For the record, I just bumped into the previous issue that was mentioning this
Looks like a lot of users are on iOS 13+ these days so it'll be hard to prioritize work on this but please open an issue nevertheless as some other folks from the community might be interested in contributing
m
Should i open the ticket as bug report or feature request ?
m
"it depends" 🙂
It doesn't matter much to be honest. More like a feature request I'd say because the limitation is documented currently but feel free to file it as a bug if it's blocking for you
m
thanks for your help
m
Thanks for reporting this 💙
👍 1
p
Seeing this same issue. Do you happen to have a path for the websockets stuff on 3.x? The link in the original issue appears to be broken.
m
@Paddy O'Brien do you need websockets on iOS < 13 or do you just need the regular queries to work on iOS < 13?
• Making regular queries work on iOS < 13 is a matter of removing the dependency and shuffling how the artifacts are built • Making websockets work on iOS < 13 is a whole different issue as it'll required bundling starscream or another library since the OS doesn't support WebSockets
p
Nah we just need regular queries to work, Shopify doesn’t use subscriptions. Was just looking for the path where the socket stuff has moved to as it seems to have changed between 2.x and 3.x.
I was wondering about something though. The iOS library does an excellent job of separating out this concern by introducing the
NetworkTransport
protocol was wondering why not a similar approach on Kotlin.
I guess really KMM just needs to add os version detection 😬 https://youtrack.jetbrains.com/issue/KT-37180
m
Gotcha 👍. It's 100% doable. We have the
NetworkTransport
API as well as a lower level
WebSocketEngine
one. The trick here is to do it in a backward compatible way. That certainly means splitting the current
apollo-runtime
that has a hard dependency on iOS13+ at the moment and introducing separate artifacts, one of those without the iOS13+ dependency
For the record, I don't think anything changed regarding this between 2.x and 3.x? Both versions use nsurlsessionwebsockettask
p
They do, the location of the code just changed. The link in the initial issue you found with Ellen and Ivan seems to be broken. I think I found it though. building now 😄
m
What link?
(there's gazillions links in that issue 😅 )
m
Gotcha
p
I get a 404
m
Yea, it's using
main
p
looks like everything is now in NSURLWebsocketEngine.kt
lol, beat me to it
thanks!
m
If you remove everything in that file with
TODO("make this work with iOS < 13")
, you should be able to link and run everything
p
Everything? I tried to leave it as an empty type but im getting errors
m
Something like this should do the job:
Copy code
actual class DefaultWebSocketEngine : WebSocketEngine {
  override suspend fun open(url: String, headers: List<HttpHeader>): WebSocketConnection {
    TODO("Not yet implemented")
  }

  override suspend fun open(url: String, headers: Map<String, String>): WebSocketConnection {
    TODO("Not yet implemented")
  }

}
(not tested but the API is relatively small, there shouldn't be too much needed besides that)
p
Seems to have done the trick, Thanks
m
Sure thing!