Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adopt fastlane for app building #49

Open
MrApplejuice opened this issue Oct 13, 2023 · 6 comments
Open

Adopt fastlane for app building #49

MrApplejuice opened this issue Oct 13, 2023 · 6 comments
Labels
enhancement New feature or request
Milestone

Comments

@MrApplejuice
Copy link
Collaborator

MrApplejuice commented Oct 13, 2023

The use IzzySoft has pointed me into the direction of https://docs.fastlane.tools/. This seems to be a very very useful tool to streamline the build and deployment process. Right now deployments are a 20-step (or so) manual list of tasks.

List of features to research

  • Checking it the play store texts/media directly on github
  • Automated screenshot updates
  • Building/testing integration
    • maybe even with GitHub actions
@MrApplejuice MrApplejuice added this to the Next release milestone Oct 13, 2023
@MrApplejuice MrApplejuice added the enhancement New feature or request label Oct 13, 2023
@MrApplejuice MrApplejuice mentioned this issue Oct 17, 2023
@MrApplejuice
Copy link
Collaborator Author

MrApplejuice commented Oct 17, 2023

Most is done... fastlane seems to be very handy, indeed, even though the first-party support seems to be mainly geared towards Apple-stuff.

I am still very much interested in the automated screenshot generation. I will give that a try and see if that can do something for the app. Seems a "nice to have". If it is too complicated, I will just drop it for now...

@IzzySoft
Copy link

Speaking about Fastlane: Maybe full_description.txt could be improved a little?

  • if bullet-point lists are ensured to "stay separate" (i.e. an empty line before and after) the description would render fine as (standard) Markdown (currently, empty lines are missing before lines 10 and 23)
  • are you sure the app description (which is e.g. shown in the F-Droid/PlayStore clients for the app) is the right place to show a full list of 3rd party attributions which is even longer than the app description itself? I mean, full ack credits should be given, but IMHO a much better place for that would be the Readme 😉

@MrApplejuice
Copy link
Collaborator Author

Hey IzzySoft!

  1. Yes, I would be very very happy if I could standardize the full_description.txt from fastlane. But I have one issue: The document was downloaded from the Google Play store. I edited it so that it renders correctly on the play-store. And editing this document and viewing the changes is super-annoying because each change always go through some Google review before I can check if things render correctly. I will get around it, but this will be a rather slow iteration, sorry.

  2. And for the 3rd-party attributions, I am bound to the license of the non-free assets I am using. They want to be mentioned on the store page like that. I cannot do much about that, unless I pay for the assets, for which there is no budget. Or switch out all assets, which also is a painful process in its own right. 🤷

Anyway, I am back on app-development right now. So there will be some progress, I hope, but I will prioritize the release of the refactored network client code for now because that will ultimately add more utility to the app.

@IzzySoft
Copy link

Hi Paul, thanks for your reply! Maybe I can help out a little there. If you check with my Wiki on Fastlane formattings you'll see something I called "Markdown Lite" – which should render fine with Play, F-Droid and my repo. Though a little different with each place: while my repo will produce beautiful HTML out of it (interpreting the content as Markdown), F-Droid would simply replace each line-break with a <br>, while Google might strip some things.

Ah yeah, non-free assets can be a pain in the … behind. Does that requirement only apply to "store" (i.e. Play Store and Apple) – or to any listing of your app? Asking because if it's not mandatory for the listing in my repo, and if you want, we could use a separate Fastlane tree there. I can set any entry point for my updater. Just my updater cannot (yet) deal with symlinks – but if the original is in "my tree", the others can. So you'd e.g. have all original content in the tree for my repo, then symlink screenshots etc. to the place for Google & Co where you have just a specific full_description.txt to care for separately.

That's just "thinking aloud" – might be a little overkill 😉

Good to hear you're back at the project! Wishing you best luck with the tasks!

@MrApplejuice
Copy link
Collaborator Author

I think that I will close this issue. fastlane is great, but I just cannot spend the time on making it fully cross platform, sorry! I will probably inch my way more and more towards and use more of its features and as I do, I might get to a point where you can use the store-listing files, but right now I cannot reserve time for that. I rather focus on more features.

What I will do however, is to add a link to your F-Droid repo and include a hint that you are redistributing the app over there. Sounds good?

@IzzySoft
Copy link

IzzySoft commented Sep 2, 2024

Sure, thanks! I just offer my advice here – I don't make demands 😄

As the last part was about full description and making it a one-liner, I could also offer you this: full_description.pl – which would allow you to maintain Fastlane as multi-line HTML and produce the "condensed" version when run. Again, just if you want it. Wasn't my work, I just liked the idea when encountering it 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants