Does this sdk still have active support?

[djk12587]

There have not been any commits or new branches in the past 11 months. There are a lot of open issues, and issues do not get many replies. Is anyone actively supporting this sdk?

[agologan]

I honestly wonder what the value of such an issue is, and whether it truly matters?
Are you asking because there are genuine problems with the lib that need addressing or are you just gaging engagement?

I do have to admit I currently maintain AppAuth for Android, and a big part of it is about providing support on integrating the library: which is usually explained in the documentation and sometimes other issues. I spend time debugging users' issues for free as neither me nor my employer have any stake in it. I also constantly deal with issues about the OS, browsers or IDPs which are not even the lib responsibility.

[djk12587]

Are you asking because there are genuine problems with the lib that need addressing or are you just gaging engagement?

Gauging engagement.

I'd rather not integrate a dormant 3rd party SDK into a project. If something is broken or breaks in the future, then fixing that problem falls solely on me. I'd like to know this type of information up front. This helps me gauge how much of a risk using this SDK is.

Seems like this SDK no longer has official active support, so use it at your own risk.

[agologan]

I haven't been very explicit previously but per the license (actually most OSS licenses) the software is provided "AS IS" which in turn means that as the user if you want to use the software, you are the solely responsible and any help or improvements coming from the maintainers or other contributors are strictly from their "goodness of their heart".

Fortunately some OSS projects have corporate backing which brings an incentive to the maintainers to do a go job but that's not always the case.

The way I view AppAuth today is that the project has enough maturity that it doesn't need constant maintenance. Users do need to invest time to understand the specification and the way the lib works and try to help other users do the same. I appreciate every user that helps another resolve their issue without invoking one of the contributors.

As for active contributions I understand the situation and I see William has tried to bring others onboard to help. Unfortunately very few users have an interest to do so, most just choose to integrate it and move on. Corporate support hasn't been great either as I've seen the libs forked by major IDPs to create their own flavour without bringing their contributions back which created good products for their own use, but siloed those contributions to users of the specific providers.

Lastly it is really up to the community to keep a project alive. To even put into a perspective iOS devs may understand, do you consider AFNetworking not worth using? yes, but only because the same contributors created Alamofire. Is AFNetworking still a solid library? absolutely and I'd be happy to use it if I need to despite not having new commits in the last 8 months. Maybe AppAuth needs a swift/kotlin fork to rejuvenate the community but for now this is all we've got.

[ThomasCle]

@agologan I hear you and understand what you are saying: It is definitely also a community problem. But in this case there are perfectly good PRs - made by the community - which would solve current problems in AppAuth, but no one merges them or even reacts on them.
I think @djk12587's issue was created due to this complete inactivity from the openid site. The community is worried, because we would love to see AppAuth continue and be in a more active state. There is not blaming, just pure interest and worries 😅
As you said: It is a good and solid library as it is. But iOS moves fast and there are some build issues and warnings, which could be fixed with some of the current PRs. Good examples of this are #488 and #604.

And lastly, thank you for your commitment to the AppAuth projects! 👍🏻

[howlingblast]

I totally understand and get that it's a mature and stable framework and with all OSS we should be grateful it exists at all and for free. While warnings like in #604 are annoying they do not block one from using the solution.

Nonetheless I've want to add that https://github.com/google/GoogleSignIn-iOS/ has a dependency on this project and as time passes more of such issues can become a blocker. So I wonder if someone from Google is reading this and might help to resolve the maintenance issue. They have an invested interest to make Google Sign-in available to developers on iOS beyond annoying warnings.

[agologan]

Good point. I did try to reach out separately to @WilliamDenniss to help out but maybe @petea or somebody else @google might want to chime in and contribute to the project.

[markusfassbender]

@agologan @WilliamDenniss @petea any updates here? I am slowly looking around for other SDKs, that are maintained and up to date, since this is super important to mobile systems.
I am one of the "waiting" PR guys of #488

[iainmerrick]

I'm curious too. I just started using this library, and hit a bug reported over a year ago (#479) with a one-line fix provided a few months ago (#656) that hasn't been merged or reviewed.

Sorry if this comes across as entitled—I know it takes hard work to maintain a repo like this, and it's appreciated! But members of the community can't fix these issues on their own; we need the repo owners to approve and merge fixes.

[oliverfoggin]

Are there any alternatives to this framework? It seems dead and it's not enjoyable trying to work out what doesn't work because it's broken, vs what doesn't work because it was removed, vs what doesn't work because it hasn't been updated yet.