We frequently get asked when a mobile version of Pidgin will be available or why it doesn't exist. There's actually quite a bit to it which makes for a decently sized blog post. So... Here we go!
It is completely feasible to write a libpurple user interface for Android, iOS, or any other mobile operating systems. In fact Palm Inc. used libpurple as the backend for their messaging application in WebOS since version 1.0 in 2009. But the problem for the Pidgin team is that we just don't have the resources and expertise to create and properly maintain these additional versions.
There was an attempt at libpurple on Android via a 2012 Google Summer of Code project. But that project had to manually write JNI bindings so that libpurple could be accessed from Java.
Modern innovations like GObject Introspection with JGIR have basically solved this issue and made Android development with native libraries nearly as easy as doing so with Objective-C or Swift on iOS.
So while this is technically possible, we come back to the issue of resources. Currently there are 2 people, including myself, actively working on Pidgin in their free time. However, neither of us know Android or iOS development at all.
For us to create additional user interfaces is to increase our workload immensely and take a lot of time away from Pidgin. We're currently struggling to keep Finch, our Ncurses user interface to libpurple, up to date as well. So much so that I will soon be calling for someone to step up and take over the Finch project in the near future.
The next hurdle to deal with is the terms of services for both the Android Play Store and the iOS App Store. libpurple connects directly to chat networks. What this means is that for multiple networks like Discord, Slack, Google Chat, Microsoft Teams, etc is that we are generally breaking their Terms of Service because they do not allow third party clients.
While this can be debated, this essentially counts as "unauthorized access" to these networks which is forbidden in the Android Developer Distribution Agreement § 4.9. However, the iOS App Store Review Guidelines § 5.2.2 states that you need explicit permission to connect to these networks which we won't get.
There's also the FOSS clause in the Apple Developer Program License § 3.3.4 A v which normally requires an exception to be granted by the copyright holders of the FOSS application. For Pidgin, that includes everyone in our COPYRIGHT file.
As you may have noticed, we don't have contact information for any of those people. Even if we did, it is probably safe to say that at least one of them is no longer with us, which makes this all impossible. But even if that wasn't the case, you might also have noticed that Sun Microsystems is credited in there as well.
Sun Microsystems was acquired by Oracle in 2010 and I have no idea whether or not their copyrights on their contributions to Open Source projects were included in that acquisition. This would probably require getting lawyers involved and just isn't important to us right now and I't not sure it ever will be.
So essentially the app stores are not an option. We could do the work and take the chance of being taken down, but that doesn't sound like a good use of our extremely limited time.
After that, people generally ask about side loading. While it certainly is an option on Android, it isn't nearly as easy on iOS. This could possibly change depending on the results of Epic Games v. Apple but that's just speculation.
Regardless, building an application that can only be side loaded means your potential audience is very small and that you'll have more support requests for installation and updates than you would on any other platform. For those reasons, this is not an avenue we intend to go down.
So let's pretend for a moment none of these issues existed and that the only barrier to Pidgin on mobile was resources. Even then there's a huge problem lurking in the shadows, notifications.
On mobile platforms when the device goes to sleep network connections are typically terminated to save battery and network data. This works because the mobile platforms support push notifications which are basically a way to tell the mobile device that your application needs attention. For this to work, you need to know when to send a push notification.
For Pidgin to do this, we would need a server that knows when your messages come in and then send the push notification. To know when your messages come in, we'd need your credentials and have to be logged in on the server side to receive those messages. This is not what we're trying to accomplish. We are not trying to create a cloud service nor deal with all of the complexity, privacy, and security concerns that come that.
So, without push notifications, Pidgin on mobile can't tell you when messages come in without keeping something running which will use more battery and network data than most people would like, which of course means additional support requests for a problem that we can't possibly solve.
All of these reasons are why we won't be releasing Pidgin on mobile any time soon, if ever. If you have any questions or comments, or if I got something wrong, please don't hesitate to comment!
Top comments (3)
The PostmarketOS which is a Linux for phones doesn't have this restrictions.
Similarly in the F-Droid store of FOSS apps should be ok and it has many chat clients.
For the push notifications things are more complicated but there are some solutions that may be used.
We have extremely limited resources (people) working on pidgin and pidgin related tools, focusing on something niche isn't something the core development team can seriously consider.
Very interesting and a bit sad to hear. Won't affect me much though. I'm not using a smart phone.