Skip to content

Conversation

IzzySoft
Copy link

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
  • 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

@OffRange any chance to get this merged? As we need to move on with our repo reorg at IzzyOnDroid, it would help us a lot. Thanks in advance!

Copy link
Owner

@OffRange OffRange left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great and sorry for the wait! Currently I am developing version 2 of KeyGo, which brings a new UI and features. This means that the screenshots and descriptions should be updated. However, as the v2 UI is under development and could potentially change any time, I don't want to push some temporary screenshots etc.

We could merge it into v1, where the descriptions would probably match. And I would wait until v2 is at a point where it can be released as a beta version

@IzzySoft
Copy link
Author

Thanks for your response! I could of course perform the suggested edits. But if the fastlane tree is not in the default branch, it makes no sense from our end, as we cannot sync it from alternative branches. Further, the question is if it would ever make it to the default branch that way.

You're of course free to adjust as you see fit, this is just a "starter package". So which way would you wish to process this?

Copy link
Owner

@OffRange OffRange left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Regarding the branch, I think it would be nicer including it when v2 is in beta, and screenshots can be adjusted accordingly. As they would then match the state of the default branch.

@IzzySoft
Copy link
Author

If the screenshots need to be replaced anyway, maybe we remove them from this PR, so it can match the current default branch? Everything can be updated lateron, and would then get synchronized at our end whenever a new release is being pulled in. For our current stage of repo reorg, it's mostly important to have the text part "upstream" in the app's repo.

@IzzySoft
Copy link
Author

IzzySoft commented Oct 2, 2025

@OffRange so would removing the screenshots from this PR make it possible to get it merged sooner? Having it merged would help us at IzzyOnDroid with our ongoing reorg.

@OffRange
Copy link
Owner

OffRange commented Oct 7, 2025

I considered merging it now. With v2 still moving, not only the images but also the descriptions will likely go stale before release. I’m trying to avoid changes I might forget to update later. Once the v2 strings are final, we can update the text and merge in one go. I think thats the best for all sides.

@IzzySoft
Copy link
Author

IzzySoft commented Oct 7, 2025

Thanks for the update, Davis! Any ETA for when that might be? We're about to finalize on our end this month (not this week, probably not next week either, but after that, according to our ETA). So if we know there are a few projects which would merge a few days after we plan finalizing, we certainly could adjust. And if we know which project need longer – well, then we'd know we shouldn't wait for them, and instead have an additional task later 🤷‍♂️ There will be several where the devs are currently "occupied elsewhere" (no offense meant – that's life, and our projects in most cases a hobby).

I’m trying to avoid changes I might forget to update later.

An argument I can totally understand, thanks!

@OffRange
Copy link
Owner

Unfortunately, there’s no way for me to estimate the v2 release at this time.

@IzzySoft
Copy link
Author

OK, understood, thanks! At least no "uncertainty" on our end then; we'll simply have to deal with it twice, should we finalize before you're ready.

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