Has anyone been able to use things like GoogleSign...

# compose-ios

[Joel Denke]

Has anyone been able to use things like GoogleSignIn or such without using Cocoapods in Compose iOS? Like adding as SPM and use code in Kotlin for iosMain.

[Pablichjenkov]

I have done something similar with Firebase SDK. Now, is not so simple as adding the swift-package and use code in kotlin. You have to create manually the expect/actual interfaces, expects in kotlin and implementation (actuals), in swift using the library.

[Joel Denke]

I have expect / actual using GoogleSignIn for iOS and Androidx credentials for Android target. The main issue is I get so many problems with the Kotlin Cocoapods I want it gone.
Wonder if theres another alternative, like embed the entire library or some easy plugin not sure.
I need to ass the SPM in XCode anyway, to correctly link the things in my app.

[Joel Denke]

One potential solution I was thinking about, which I had in the past. Is to make interface send into my core DI component, where need to send in Swift implementation of GOogleSignIn on the iOS side.
Meaning I will not use the GoogleSignIn at Kotlin level at all anymore. But then going against my sturcture, avoid haivng native things in any platform, causing fragmentation.

[Pablichjenkov]

Yes that is what I was talking about. I think that, until the library ecosystem grows at a certain level or until direct Interoperability between swift and kotlin is achieved. This will be the simplest alternative.
Notice the Apple ecosystem is trying to move away from cocoapods too. Meaning less and less SDKs and libraries will be available in pods.

[Pablichjenkov]

Hopefully more companies, including Google start releasing full KMP libraries.

[Joel Denke]

I would say its the worst alternative, to put the things native in iOS, causing a lot of architecture downsides.
I dont understand why Jetbrains started with cocoapods in Kotlin at all, it was bad even back then.
But yeah Google already has full KMP libs. But even then not working, as some of them using Cocoapods plugin causing issues 😄

[Joel Denke]

Transtivie deps in Gradle vs SPM/COcoapods seems to be uhm complex to overlap.

[Joel Denke]

Like androidx lifecycle and viewmodel is now KMP, including datastore and collections and paging 🙂

[Pablichjenkov]

Yep. Although I would say, you can still keep most of your code in kotlin side. In other words, you really don't need to implement anything on the swift side, other than a thin wrapper on top of the original API. You will still have your implementation in kotlin as if you imported the library using cocoapods.

[Joel Denke]

Yeah probably worth it for now, but also want more stuff in Kotlin communicating with old school iOS libs 😛
Do you have any recommended pattern to make this interface as thin as possible can and get proper Kotlin autocomplete in XCode when write the Swift layer? 😄

[Pablichjenkov]

In general the pattern I follow is,
• creating an interface with the same API as the swift library.
• Create another interface in kotlin, this is the abstraction the commonMain code depends on.
• Then have a class in kotlin that glue this 2. Basically an adapter class, it implements the commonMain abstraction and receives as parameter the implementation of the swift library in step 1.
You can take a look at this 2 classes for example:
https://github.com/pablichjenkov/macao-marketplace/tree/dev/auth-firebase%2Fsrc%2FiosMain%2Fkotlin%2Fcom%2Fmacaosoftware%2Fplugin%2Faccount

[Pablichjenkov]

interface FirebaseAuthKmpWrapper is the one in step 1. It is implemented in a separate project which is an SPM project, here: https://github.com/pablichjenkov/firebase-kmp/tree/main/FirebaseAuthKmp%2FSources

[Pablichjenkov]

But you can just implement it in your same project for simplicity.

[Joel Denke]

Cool, yeah I have something similar but more thin. The main complexity for me I need to call from @Composable lambda, to access COntext in Android properly 😛

[Pablichjenkov]

Then class FirebaseAccountPlugin is what I mean in step 3 above.

[Joel Denke]

In general I need to do something like this:

class IosGoogleLoginLauncher2(
    private val loginRepository: LoginRepository,
    private val googleCredentialsProvider: GoogleCredentialsProvider
): GoogleLoginLauncher {

    @Composable
    override fun uiResultLauncher(
        result: (LoginResult) -> Unit,
    ): UiResultLauncher {
        val coroutineScope = rememberCoroutineScope()
        return UiResultLauncher {
            val credentials = googleCredentialsProvider.credentials()
            coroutineScope.launch {
                result(loginRepository.authorize(credentials))
            }
        }
    }
}

[Joel Denke]

interface GoogleCredentialsProvider {
    fun credentials(): Credentials
}

This is the interface I am now write only in Swift layer 🙂

[Pablichjenkov]

I see, Humm that sounds tricky, anything that uses Composable. I try to reduce these wrappers to basic swift types that map easily to kotlin type. I try to avoid suspend use in the interface exported to swift too, to avoid pitfalls. Better do all that in kotlin land

[Pablichjenkov]

You are good, just create the mappings to the Credentials model in swift

[Joel Denke]

Yeah the main problem here is androidx credential manager requires you to send in Activity Context on the fly, enforce me to use @Composable for both Android and iOS, but would like to aovid it.

[Joel Denke]

I am then decouple the @Composable thing within hidden layer so iOS code not need to implement it, only need to implment GoogleCredentialsProvider

[Pablichjenkov]

Ah I see 🙈, I mean creating these wrappers is a nightmare sometimes. By the time these SDKs were created the least concern they had, was using them in a common code friendly to other platforms

[Joel Denke]

Yeah I solved this easier when using cocoapods, hence I dont want to go back this road again 😄 As I know hor horrible this is.

[Pablichjenkov]

But yes you can abstract context away I guess

[Joel Denke]

I wish androidx credentialmanager allowed you to use Application Contex,t then would not be a problem 😛

[Joel Denke]

Then I can inject context from DI layer instead.

[louiscad]

For the future you and future us:
https://twitter.com/Louis_CAD/status/1762149449864818972

[louiscad]

Google needs to support that out of the box. Please vote and share 🙂

[Joel Denke]

@louiscad Nice is this on Googles radar or what kind of ticket is this? Looks like a random forum post to me? https://firebase.uservoice.com/forums/948424-general/suggestions/46591717-support-kotlin-multiplatform
My main thing I want to have is google play service plugin KMP agnostic, how to fetch the service account data basically 😛
The rest is basic OAuth really, and some additional extra layers from GOogle to make things both easier and hrader.
Also wish list is they delete usage of Guava and start using pure Coroutines for their API:s for everything.

[louiscad]

This is Firebase's forum.

Got that link from a Firebase Product Manager

[Joel Denke]

Right, and they claimed they will be support if enough upvoting this or?

[louiscad]

I said "probably"

[louiscad]

If you don't want to vote, don't vote 😛

[louiscad]

Personally, I did, because I want to weigh in their priorities

[Joel Denke]

I want to have this ofc, just wonder whats the most efficent way of solving this.
If I recall correct this https://github.com/GitLiveApp/firebase-kotlin-sdk was already a way of Google Firebase devs doing some extra effort?

[Joel Denke]

That library is solve many things, but not the complex parts 😛

[Joel Denke]

@Pablichjenkov Btw this is how I do it today in Kotlin if helps anyone:

class IosGoogleLoginLauncher(
    private val loginRepository: LoginRepository,
): GoogleLoginLauncher {

    @Composable
    override fun uiResultLauncher(
        result: (LoginResult) -> Unit,
    ): UiResultLauncher {
        val uiController = LocalUIViewController.current
        val coroutineScope = rememberCoroutineScope()
        return UiResultLauncher {
            val clientID = Firebase.app.ios.options.clientID.orEmpty()
            val config = GIDConfiguration(clientID = clientID)
            GIDSignIn.sharedInstance.configuration = config
            GIDSignIn.sharedInstance.signInWithPresentingViewController(uiController) { result, error ->
                val idToken = result?.user?.idToken?.tokenString
                val accessToken = result?.user?.refreshToken?.tokenString
                if (idToken != null) {
                    coroutineScope.launch {
                        result(loginRepository.authorize(
                            Credentials(
                            idToken = idToken,
                            accessToken = accessToken
                        )
                        ))
                    }
                } else {
                    result(LoginResult.Failed(IllegalArgumentException("No id token found, required to login")))
                }
            }
        }
    }
}

[Pablichjenkov]

I see, you mean using cocoapods right? - bc I see you are accessing the libraries directly from kotlin.
I mean in general cocoapods is not bad, is just that the iOS community is moving towards SPM

[Pablichjenkov]

The transition is still going on and believe it or not most big projects out there still depend on cocoapods but when you talk to some iOS dev they will tell the future is definitely SPM

[Joel Denke]

Yeah sharing cocoapods version if someone else curious. Hopefully getting rid of cocoapods soon or some kind of improvement.
I like that you can write Kotlin code and interop to things , I prefer that all day long before Swift interop to Kotlin reversed. It increasing code sharing a lot.

[Eury Perez]

I did it and it was working until it stopped working because of XCode linking issues (that’s been a nightmare).

Check this to see the repo url and the issue in case anyone can help:

https://kotlinlang.slack.com/archives/C0346LWVBJ4/p1710091126616709