Make sure that the version of the appllication is 1.0, this is the first public release and should have that version. Earlier things should only raise the build number until the first published release.
The full functionality of the app, the actual code that executes function needs to be Rust. Swift is only there to handle the UI itself. So the code has to be reviewed to make sure that we not only follow best practices for both Rust and Swift, but also make sure that Swift code is really only handling the UI areas and we don't put functionality into Swift "just because that file was open". there is a deliberate decision on where code has to be done and we must follow that.
Also the code needs to be reviewed for duplications and god-files with too many lines. The target length is below 500 lines. There need to be very good reasons to go above those lines and those reasons must be documented.
The full UI has to be tested and evaluated with regards to Apple human interface guidelines that all elements follow the actual structure how the application is supposed to be working. This includes behaviour with light and dark themes, check that all screens have proper contrast. also make sure that liquid glass is followed so the app behaves like users expect of a modern app. Align the rust crate version to this version.
make sure that proper signing is active and that the app is ready for iOS app store submission. This is not a test application anymore, it is the full thing, meant to go to users.
Make sure that the version of the appllication is 1.0, this is the first public release and should have that version. Earlier things should only raise the build number until the first published release.
The full functionality of the app, the actual code that executes function needs to be Rust. Swift is only there to handle the UI itself. So the code has to be reviewed to make sure that we not only follow best practices for both Rust and Swift, but also make sure that Swift code is really only handling the UI areas and we don't put functionality into Swift "just because that file was open". there is a deliberate decision on where code has to be done and we must follow that.
Also the code needs to be reviewed for duplications and god-files with too many lines. The target length is below 500 lines. There need to be very good reasons to go above those lines and those reasons must be documented.
The full UI has to be tested and evaluated with regards to Apple human interface guidelines that all elements follow the actual structure how the application is supposed to be working. This includes behaviour with light and dark themes, check that all screens have proper contrast. also make sure that liquid glass is followed so the app behaves like users expect of a modern app. Align the rust crate version to this version.
make sure that proper signing is active and that the app is ready for iOS app store submission. This is not a test application anymore, it is the full thing, meant to go to users.
hugo
added this to the first public update release milestone 2026-07-31 12:00:03 +00:00
Implemented the issue #24 review in commit 46cca8f (Prepare Gotcha 1.0 for release).
What changed:
Set the iPhone marketing version to 1.0, build 1, and aligned gotcha-app, gotcha-cli, and gotcha_gitea at Rust crate version 1.0.0.
Reviewed the Rust/Swift boundary and moved view semantics into Rust-owned UniFFI types: work-item state, activity icon/target, repository content/file kind, diff-line kind, and commit-value typography are now explicit records/enums rather than Swift string inference. Regenerated and committed the Swift/C UniFFI bindings.
Split the oversized Rust core/presentation, CLI work-item, Gitea issue/repository, and UIKit screen files by responsibility. Every handwritten Rust and Swift source file is now below 500 lines (largest: 495); generated UniFFI output is the only larger source.
Removed duplicate civil-date conversion and page/positive-ID validation implementations by sharing the existing Rust implementations.
Kept Swift limited to UIKit/SwiftUI presentation, native interaction, geometry, accessibility, and rendering; Gitea/API behavior, classification, routing data, and view-ready transformations remain in Rust.
Added App Store metadata: automatic signing/team configuration, version/build variables, a privacy manifest, and the non-exempt-encryption declaration. Updated TESTING.md with the signed archive verification gate.
Retained native UIKit navigation, menus, segmented controls, lists, system colors, Dynamic Type, accessibility labels, and iOS 26 Liquid Glass behavior rather than introducing custom chrome.
xcodebuild ... build for iPhone 17 Pro / iOS 26.5 Simulator
xcodebuild ... analyze
Signed Release archive succeeded; archived payload verified as 1.0 (1), arm64, bundle ID de.rfc1437.gotcha, team MU22FMRGK8, privacy manifest present, and export-compliance value false.
Installed/launched the completed build in the Simulator and on the paired iPhone 17.
UI pass covered Auto/Light/Dark appearance and contrast plus Home, Settings, repository lists, issue list/detail, commit history/detail, changed-file diff, pull-request empty state, milestone list, native back navigation, typed state icons, and iOS 26 system chrome. Auto appearance was restored afterward.
Revisit item (reason this issue remains open): App Store Connect export reaches the distribution step but the configured Apple account/team currently reports no App Store provider permission and cannot create/find an iOS App Store provisioning profile for de.rfc1437.gotcha. Project-side archive/signing metadata is in place; the team permission/profile must be fixed externally, then the App Store export and remaining release checklist scenarios can be rerun.
Implemented the issue #24 review in commit `46cca8f` (`Prepare Gotcha 1.0 for release`).
What changed:
- Set the iPhone marketing version to `1.0`, build `1`, and aligned `gotcha-app`, `gotcha-cli`, and `gotcha_gitea` at Rust crate version `1.0.0`.
- Reviewed the Rust/Swift boundary and moved view semantics into Rust-owned UniFFI types: work-item state, activity icon/target, repository content/file kind, diff-line kind, and commit-value typography are now explicit records/enums rather than Swift string inference. Regenerated and committed the Swift/C UniFFI bindings.
- Split the oversized Rust core/presentation, CLI work-item, Gitea issue/repository, and UIKit screen files by responsibility. Every handwritten Rust and Swift source file is now below 500 lines (largest: 495); generated UniFFI output is the only larger source.
- Removed duplicate civil-date conversion and page/positive-ID validation implementations by sharing the existing Rust implementations.
- Kept Swift limited to UIKit/SwiftUI presentation, native interaction, geometry, accessibility, and rendering; Gitea/API behavior, classification, routing data, and view-ready transformations remain in Rust.
- Added App Store metadata: automatic signing/team configuration, version/build variables, a privacy manifest, and the non-exempt-encryption declaration. Updated `TESTING.md` with the signed archive verification gate.
- Retained native UIKit navigation, menus, segmented controls, lists, system colors, Dynamic Type, accessibility labels, and iOS 26 Liquid Glass behavior rather than introducing custom chrome.
Verification completed:
- `cargo fmt --all -- --check`
- `RUSTFLAGS="-D warnings" cargo check --workspace --all-targets`
- `cargo clippy --workspace --all-targets -- -D warnings`
- `cargo test --workspace` (32 passed)
- `xcodebuild ... build` for iPhone 17 Pro / iOS 26.5 Simulator
- `xcodebuild ... analyze`
- Signed Release archive succeeded; archived payload verified as `1.0 (1)`, arm64, bundle ID `de.rfc1437.gotcha`, team `MU22FMRGK8`, privacy manifest present, and export-compliance value `false`.
- Installed/launched the completed build in the Simulator and on the paired iPhone 17.
- UI pass covered Auto/Light/Dark appearance and contrast plus Home, Settings, repository lists, issue list/detail, commit history/detail, changed-file diff, pull-request empty state, milestone list, native back navigation, typed state icons, and iOS 26 system chrome. Auto appearance was restored afterward.
Revisit item (reason this issue remains open): App Store Connect export reaches the distribution step but the configured Apple account/team currently reports no App Store provider permission and cannot create/find an iOS App Store provisioning profile for `de.rfc1437.gotcha`. Project-side archive/signing metadata is in place; the team permission/profile must be fixed externally, then the App Store export and remaining release checklist scenarios can be rerun.
hugo
removed the critical label 2026-08-09 14:02:04 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Make sure that the version of the appllication is 1.0, this is the first public release and should have that version. Earlier things should only raise the build number until the first published release.
The full functionality of the app, the actual code that executes function needs to be Rust. Swift is only there to handle the UI itself. So the code has to be reviewed to make sure that we not only follow best practices for both Rust and Swift, but also make sure that Swift code is really only handling the UI areas and we don't put functionality into Swift "just because that file was open". there is a deliberate decision on where code has to be done and we must follow that.
Also the code needs to be reviewed for duplications and god-files with too many lines. The target length is below 500 lines. There need to be very good reasons to go above those lines and those reasons must be documented.
The full UI has to be tested and evaluated with regards to Apple human interface guidelines that all elements follow the actual structure how the application is supposed to be working. This includes behaviour with light and dark themes, check that all screens have proper contrast. also make sure that liquid glass is followed so the app behaves like users expect of a modern app. Align the rust crate version to this version.
make sure that proper signing is active and that the app is ready for iOS app store submission. This is not a test application anymore, it is the full thing, meant to go to users.
Implemented the issue #24 review in commit
46cca8f(Prepare Gotcha 1.0 for release).What changed:
1.0, build1, and alignedgotcha-app,gotcha-cli, andgotcha_giteaat Rust crate version1.0.0.TESTING.mdwith the signed archive verification gate.Verification completed:
cargo fmt --all -- --checkRUSTFLAGS="-D warnings" cargo check --workspace --all-targetscargo clippy --workspace --all-targets -- -D warningscargo test --workspace(32 passed)xcodebuild ... buildfor iPhone 17 Pro / iOS 26.5 Simulatorxcodebuild ... analyze1.0 (1), arm64, bundle IDde.rfc1437.gotcha, teamMU22FMRGK8, privacy manifest present, and export-compliance valuefalse.Revisit item (reason this issue remains open): App Store Connect export reaches the distribution step but the configured Apple account/team currently reports no App Store provider permission and cannot create/find an iOS App Store provisioning profile for
de.rfc1437.gotcha. Project-side archive/signing metadata is in place; the team permission/profile must be fixed externally, then the App Store export and remaining release checklist scenarios can be rerun.