Skip to content

initial fastlane structures from IzzyOnDroid#29

Open
IzzySoft wants to merge 1 commit intowarren-bank:servicefrom
IzzySoft:fastlane
Open

initial fastlane structures from IzzyOnDroid#29
IzzySoft wants to merge 1 commit intowarren-bank:servicefrom
IzzySoft:fastlane

Conversation

@IzzySoft
Copy link

@IzzySoft IzzySoft commented Aug 8, 2025

this PR provides you with a "fastlane starter package" – to give it into your hands to define how your app is presented, and make it easy to keep descriptions & graphics in sync with your development. Some notes to sum them up in a place easy to find for you:

  • the IzzyOnDroid Fastlane Documentation can guide you with maintaining the structures here
  • take special care for limits, e.g. per-release changelogs can have max 500 chars, full_description.txt max 4,000 chars, graphics must have specific aspect ratios etc.
  • you can have "bigger graphics" here; the IoD updater takes care to resize/optimize them as needed.
  • If you could add an icon, that would be great!
  • for the full_description.txt here I've used HTML compressed into a single line, to prevent the fdroid software converting each line break to a <br>. The tags used for this are supported by F-Droid.org as well, and to my knowledge even by PlayStore.
  • whenever you add a new "type" of metadata that has not been there before (e.g. the first changelog, a featureGraphic if it wasn't yet present), please let us know so we can check and enable it.
  • Details on all this in the linked documentation.
  • Once merged, your changes will be synced whenever a new release is pulled in here – to make sure it stays up-to-date with the app itself.
  • Should you have questions, be welcome to ask 😉

And now: Enjoy!

@IzzySoft
Copy link
Author

IzzySoft commented Aug 8, 2025

Oof. I just notice we're having 3 apps here, and need a slightly different app description. How do you wish to deal with that? At IzzyOnDroid, we're flexible, and can define any "root location" for it. F-Droid would be less flexible, and need it in one of 3 specific locations:

  • /fastlane/metadata/android/<locale>/
  • /metadata/<locale>/
  • /src/<buildFlavor>/fastlane/metadata/android/<locale>/

Given your repo structure, none of those would fit. For IoD, we could but it inside the app specific directories inside android-studio-project, if that would suit you.

@IzzySoft
Copy link
Author

IzzySoft commented Oct 8, 2025

@warren-bank any word? Sending some motivation, this time as graphic from our stats. Each download implies an install, as the view was restricted to F-Droid clients:

image

So more than 100 monthly installs just for com.github.warren_bank.mock_location

@warren-bank
Copy link
Owner

I'm leaning heavily towards "no".. because I hate clutter, and this feels like a lot of extra clutter.

Is there any support for hosting these files in a separate git repo?
Preferably a single git repo that hosts them all?
..possibly one git branch per package name.

For example, I already have a single git repo that contains everything pertaining to my self-hosted f-droid repos.. which I don't update nearly as often as I should. In any case, this git branch contains the f-droid metadata for all of my apps. Unfortunately, the conventions used by f-droid seem to differ slightly from fastlane, which is annoying. But if you can pull fastlane data from a git repo that is separate from the git repo used for the source code, then I'd be willing to write a migration script.

@IzzySoft
Copy link
Author

IzzySoft commented Oct 9, 2025

Is there any support for hosting these files in a separate git repo?

Only if that git repo then is added as submodule to the app's repo. Fastlane is processed locally here, from a clone of the app's repo (which is checked out with all its submodules, if there are any).

Preferably a single git repo that hosts them all?
..possibly one git branch per package name.

One directory per app would work then (we support custom fastlane locations inside the app's repo). That directory could e.g. be the corresponding app's packageName, and the rest of the structure simplified:

/
 + com.github.warren_bank.airplay_client/metadata/en-US
 + com.github.warren_bank.bonjour_webrtc/metadata/en-US
 + ...

In any case, this git branch contains the f-droid metadata for all of my apps.

Ah! That would work as well, if it were availabe as git submodule in the app's repo. I haven't worked much with submodules, but if it's possible and you wanted to, you could "mount" the corresponding app dir as metadata – so we had metadata/<locale> in the repo root; that would correspond to F-Droid's structure, so they'd then pick it up automatically as well for the apps they have.

Would that work for you? It would for us – and we probably can simply close all the PRs I've opened for fastlane on your apps (or you could pick from them what you feel useful).

PS: the fastlane trees must have a en-US locale, as that's the default/fallback locale. So if you could rename (or symlink) en accordingly, that would do the trick.

PPS: digging deeper into the structures, I guess we need that migration you were speaking of: they are no fastlane structures 🙈

@warren-bank
Copy link
Owner

I didn't think you'd be able to reference the fastlane metadata from another repo.. but I had to ask :)

In any case, there's absolutely no way that I'd include that entire git repo of f-droid metadata as a submodule in every project; it's enormous, and nobody would appreciate that.

What is the downside of opting out? I understand that including fastlane metadata in my repos would allow me to customize the apps' descriptions in your f-droid repo. But I'm not very interested in that.. your descriptions seem good.. heck, probably more informative than I'd be :) So, would it be a problem for you if I choose to leave well enough alone? Because.. I really have no intention of adding extraneous files to any of my git repos.

@IzzySoft
Copy link
Author

IzzySoft commented Oct 9, 2025

I didn't think you'd be able to reference the fastlane metadata from another repo.. but I had to ask :)

Sure! And you're not that far off with that. We supported that in the past, when we used to sync fastlane "online" by utilizing the corresponding forge's API. But that was taking ages, and we ran into "API limits" far too often (despite of having tokens). For example, our monthly quality check (cross-checking whether repos were still there, open, had fastlane added/dropped, new fastlane features added, etc) was taking more than 13h to complete, and missed several items due to API limit shenanigans. Having moved the fastlane part to local clones, it now is through in less than half an hour – and uses far less resources (we try to be as "green" as possible, too)…

What is the downside of opting out?

That any updates you think needed (screenshots to replace, features added/dropped needing an update to the description, etc), would require you to open an issue with us – and us then to perform manual actions, eating time on both ends we could otherwise invest into other things (our current task list is longer than the Amazon river – or at least feels that way; so see just a part of it, take a look here).

We have about 1.3k apps to cover. So the more automation, the better.

including fastlane metadata in my repos would allow me to customize the apps' descriptions in your f-droid repo.

Not only there. For apps available at f-droid.org, they'd be synchronized automatically as well (i.e. affect the listing there).

your descriptions seem good.. heck, probably more informative than I'd be :)

Thanks! 🤗 You're welcome to adopt them if you wish – be it via these PRs, or by simply copy-pasting 😉

So, would it be a problem for you if I choose to leave well enough alone? Because.. I really have no intention of adding extraneous files to any of my git repos.

Well, they run the risk of becoming outdated (I've opened hundreds of similar PRs, upstreaming our metadata, and had that case more than once: "those graphics are outdated, could you use the newer ones" / "I've updated the description, it was no longer fully correct" / …). We cannot manually watch-and-keep-updated those metadata for all the apps we cater for.

TL;DR: they'd be rather static, and require manual actions from both (you and us) to be updated – while with the metadata in the app's repo, you could simply update+commit+push, and they'd be automatically synced here when the next release is being pulled in.

We prefer them in the app's repo – so "highly recommended", but not exactly mandatory.

@warren-bank
Copy link
Owner

I'm good with static details..
I can promise that I won't send PRs to you with updates to descriptions :)

The overview of my apps never change; each app sets out to do one thing.
I may add the occasional feature or bug fix, but the fundamentals are set in stone.

@IzzySoft
Copy link
Author

IzzySoft commented Oct 9, 2025

OK, then I'll mark them to be kept as "local metadata" here. Just to make sure: can you please go over the PRs I've opened with your apps to ship fastlane, and see if all's good? Then close them each, which I then take as signal "all fine, mark local". And should there be something that needs to be adjusted, just leave a comment with the closure?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants