Raising the min Android version would be a proactive move to focus the development on limited set of Android versions and to keep the code modern and to avoid problems in the future.

If the app got released into F-Droid with the current min api, there will always be the chance you would need to choose in the future between having the best app or serving the highest amount of users and that would lower the value of this client compared to other clients.

I see that Raccoon for Lemmy has a great potential, but I am scared it will turn out as a generic client.

To see my point clearly, check out Summit for Lemmy, in theory in a couple of months both Raccoon and Summit would be in the same level in terms of functionality, the only competing factor in my eyes is the user experience.

Thank you for your valuable work on reviving this client.

  • Akesi Seli@lemmy.worldM
    link
    fedilink
    arrow-up
    1
    ·
    12 hours ago

    Raising the min API level does not refer to the API level the app is compiled against or targeting, nor that it cannot use newer functionalities. It just means that there are some "if"s for when a newer system API is called to exclude its usage on older devices and, instead, use a fallback when possible.

    Personally, I would not raise minSdk because that would restrict the user base, which is already quite narrow. Rather, I am going to continuously raise targetSdk because that ensures the app can use the latest features and works correctly on newest Android versions.

    Maybe you are referring to Summit supporting predictive back gestures and Raccoon not doing so. This is not related to the API level but to the fact that Raccoon uses Kotlin Multiplatform and Compose Multiplatform. Being a multiplatform app means that it’s relatively easy to get an iOS or desktop build but there are restrictions on some native features such as predictive back.

    Raccoon uses the Voyager library for navigation which still doesn’t support predictive back (issue here) due to such difficulties. I’ve considered replacing it because AndroidX Compose navigation has been ported to multiplatform but it’s not easy changing a core library like the navigation one.