We have been using git-flow like since the beginning of SUEP development, but I don't think git-flow works well for development efficiency and accuracy. The reasons are as follows.

1. no need to keep past versions
2. the develop branch is almost the same as the main branch

In particular, the only difference between the develop branch and the main branch is whether logs are displayed in console.log or not.
Therefore, I think it is appropriate to discontinue git-flow and proceed with the transition to GitHub Flow.

• Making style variables in each files into an external file
  For now, each screen or function has its own style, so it's neccesary to create some files with the common style functions.
  Eg: a file w/ color styles and w/ font size styles, w/ margin and padding values etc.

• Change of notation from mere JS functions to JSX and make component files
  In some files, mere functions are used extensively. Therefore, it's necessary to convert mere functions to JSX to reduce the amount of code. Also, the components used in each screen should be managed in an external file to improve code readability.

For safe and fast development, we believe it is time to separate the program to be executed in the development and production environments. Specifically, we should separate the APIs to be used in the production and development environments as follows,

• https://zenn.dev/hal1986/articles/20220202-eas-build-use-env

There are ways to distinguish between development and production environments using variables provided on the Expo side. These should be implemented as soon as possible (preferably in time for the major update in June).

• https://blog.tawa.me/entry/2019/02/01/210000

• Regarding data persistence
  Currently, using AsyncStorage slows down the reading and writing of data noticeably, especially on Android devices. In order to solve this problem, I assume it would be a good idea to move to Realm.

• Performance tuning of FlatList, etc.
  In particular, FlatList may cause unintended re-rendering due to unrelated state changes.

• UseContext
  There are mainly two methods to manage states globally, Redux and useContext. useContext is currently the only method used in SUEP. useContext has its own disadvantages, so we should consider migrating to Redux.

Problem

In the format for storing lecture information, there is a mixture of notations such as '月1', '月 1' (single-byte space), and '月　1' (double-byte space).

Ideal Sate

Unify these notations into a 'day + number' (no space in between) expression such as '月1'.

Since the EAS build cannot perfectly support Sentry, another method (e.g., Crashlytics) must be taken to examine the app's logs.

Depending on the screen size of the user's smartphone, tweets may be displayed incorrectly as shown in the image below.

This is because of the design of the margin for embedding tweets regardless of the screen size.
This is not a fatal bug, but we would like to fix it as soon as possible.

Is your feature request related to a problem? Please describe.
Currently, the backend system consists of Google Clouad Platform and uses several Google related services. In the future, I plan to move to a system using FIrebase and Cloud Functions that are not used now. Although the difficulty of implementation and learning costs will increase, I would like to use these to make the system configuration more robust.

Describe the solution you'd like

1. determine the format of information to be obtained on the frontend side
2. modify the current back-end codes to match the information requested above
3. migrate to Firebase first (since there is abundant documentation on the Expo side and it is relatively easy)
4. port part of the GAS code to Cloud functions

Describe alternatives you've considered
Nonde

Additional context
None