Simple app that tracks who has paid for an event.
- Overview (list of oustanding events)
- Events (list of events for payment)
- People (lists of recurring payees)
Thanks to all those who have contributed to this project so far!
# Start Metro bundler (with hot reload)
npm run start
# Start Metro bundler after clearing build cache
npm run start -- --clearDeveloping in WSL2 requires some additional configuration and different start up process.
Releases can be deployed through Expo Go (for testing) or the Expo managed build system (for release). The app version is taken from the package.json, which should be updated before every major deployment. App environment configuration is possible with the expo-updates package, which exposes the value of the releaseChannel used when building the app.
NOTE: Remember to update the
versioninpackage.jsonbefore each release/deployment! This is especially important for App Store releases
Testing releases are released through Expo Go, which allows releasing for several environments. Specific release channels can be tested by visiting the release channel link, stored at the top of this file.
# Publish to a default environment
expo publish
# Publish to a specific environment
expo publish --release-channel <ENVIRONMENT>NOTE: Remember to properly set the release channel for each deployment (if needed)!
Production builds and releases are handled with EAS Build and EAS Submit.
NOTE: Remember to properly update the
version(package.json) and increment theandroidVersionCode/iosBuildNumber(app.config.ts) before each release intended for submission!
Production builds utilize the EAS CLI and EAS Build to automatically upload and build native artifacts for later submission. The EAS CLI requires some minor input for both Android and iOS platforms (credentials, paths, etc), which could be abstracted to eas.json but is not for security. Once the build(s) have been started, links are provided to view the build progress. An artifact download link will be generated once the build has completed; however, EAS Submit can automatically pull builds from EAS Build.
# Build for all platforms
eas build
# Build for a specific platform
eas build --platform android
eas build --platform iosBy default, these artifacts are intended for submission and cannot be used for testing (due to output format). EAS Build has documention for testing APKs as well as building for ios Simulators.
Production builds utilize the EAS CLI and EAS Submit to automatically submit builds to the app stores. The EAS CLI requires some minor input for both Android and iOS platforms (bundle, credentials, etc), similar to the build workflow. Submission is typically a very fast process, and once the apps have been submitted they may be included in app store releases.
# Submit for a specific platform
eas submit --platform android
eas submit --platform iosOnce a production app has been built and submitted, a release can be created in the appropriate app store.
Google Play submissions are automatically released to the "Internal" track, which does not require submission approval before testing. After internal testing, the app can be promoted to either a Closed/Open test, or directly to production, after it has been approved. Release notes and details can be specified each time a release is promoted, although typically they will be changed only when promoting out of Internal testing. Promoting an app to the production track will officially release the new version to users.
Apple submissions are not automatically released to an internal testing track, but instead must have a new release created from the App Connect dashboard. The new release will inherit information from previous releases, and needs to have its version updated, release notes added, and a bundle selected. The release can then be submitted to TestFlight, allowing internal testing, before submitting for production review.
Production updates are currently only available with the expo-updates package (not configured in this project), but there will soon be public support for EAS Update.
Coming Soon!
Components are based on the React Native Paper library, an interpretation of the Material Design guidelines for React Native.
Vector images are taken from UnDraw and edited in Affinity Photo to remove the background.
Icons were generated with the Build Icon tool.
Since the upgrade to Expo SDK 43, @react-native-community/eslint-config does not properly install all dependencies (Mac only). After spending too much time trying to debug the issue, I have installed all its dependencies manually to get around the issue.
Version 4.10.0 of react-native-paper has issues with TypeScript for any component based upon the Text component. Downgrading to 3.9.2 resolves the issues without missing many additional features.
By default, the BottomNavigation component mounts tabs lazily. However, this caused several issues that resulted in disabling (via patch) the lazy mounting. The biggest issue was that navigating to "EventDetails" (from Home) before mounting the "EventsTab" would mean the "EventList" screen was not included in history, resulting in strange back behaviour.
The @react-navigation/material-bottom-tabs introduced an Android issue in Expo SDK 43 when nesting a stack navigator inside a Material bottom tab navigator. After the first time the nested stack navigator is accessed, it will no longer be accessible (apparently clipped out entirely)? This can be resolved by surrounding the nested Stack navigator with a non-collapsable View (source). However, this is a workaround that has not been fixed yet!
- Explore localized date formatting with (
i18n Formatting) (alternative at Brains and Beards) - Improve theme colors (especially dark theme)