Clarify the use of contexts:
- **Production** (.shared)
- **Previews** (.mock → .forPreviews)
- ONLY use it in UILibrary for, well, previews
- This context has dumb profiles with UUIDs as names
- Registry is fake
- **UI Tests** (.forUITesting)
- Add new context for UI testing
- Selected based on command line arguments
- This context has mock data tuned for decent screenshots
- Registry is real
Share the same InAppProcessor in .shared and .forTesting contexts
because the app behavior was inconsistent regarding e.g. in-app
purchases.
Ready for screenshots generation, except for the tests themselves and
the TV target.
- More customizations while UI testing
- Act as full version user in IAPManager
- Override layout with default to .grid if isBigDevice
- Show module names in profile list/grid
- Improve mock Profile/ProfileManager
- Meaningful profile names
- iCloud/TV icons
- Initial modules
- Improve XCTest extensions
- Screenshot destination (attachment/temporary)
- Screenshot target (window/sheet)
- Print saved temporary URL at the end (may help with CI)
- Append device name to screenshot filename
- Tests
- Refactor actions with the [Page Object
pattern](https://swiftwithmajid.com/2021/03/24/ui-testing-using-page-object-pattern-in-swift/)
- Perform iPad screenshots in landscape
- Split simple flow tests and screenshots
- Add "Connect to" test
Closes#681
Create UITesting target with:
- AppCommandLine/AppEnvironment: strongly typed refactoring of PP_*
environment values
- AccessibilityInfo: identifies and locates elements for UI testing
Make the app behave differently when launched with `.uiTesting`, and
expose the flag to SwiftUI via `.environment(\.isUITesting)` to:
- Use the mock AppContext
- Skip onboarding
Add PassepartoutUITests target with two screenshot tests:
- Connected screen
- Profile modal
Includes:
- Credits
- Donations
- Diagnostics
- Version
Had to:
- Wrap tab view into a NavigationStack for full-screen navigation
- Take out navigation titles of about subviews
- Customize donations view layout with modifier
- Fix credits and debug log to support scrolling
Closes#914
Loading remote profiles before local profiles may cause duplicated NE
managers. This happened because if local profiles are empty, any remote
profile is imported regardless of their former existence in the local
store. The importer just doesn't know.
Therefore, revisit the sequence of AppContext registrations:
- First off
- Skip Tunnel prepare() because NEProfileRepository.fetch() does it
already
- NE is both Tunnel and ProfileRepository, so calling tunnel.prepare()
loads local NE profiles twice
- onLaunch() - **run this once and before anything else**
- Read local profiles
- Reload in-app receipt
- Observe in-app eligibility → Triggers onEligibleFeatures()
- Observe profile save → Triggers onSaveProfile()
- Fetch providers index
- onForeground()
- Read local profiles
- Read remote profiles, and toggle CloudKit sync based on eligibility
- onEligibleFeatures()
- Read remote profiles, and toggle CloudKit sync based on eligibility
- onSaveProfile()
- Reconnect if necessary
Move the following dependencies:
- OpenVPN/OpenSSL
- WireGuard/Go
up the chain until the main App/Tunnel targets, so that UILibrary and
CommonLibrary can abstract from these unnecessary details. Instead, give
module views access to generic implementations via Registry.
Incidentally, this fixes an issue preventing TV previews from working
due to OpenSSL linkage.
- Centralize context initialization/refresh in platform-specific app
delegates
- Prevent multiple calls to .onApplicationActive()
- Simplify local/remote profile fingerprint comparison
- Revert to always replacing Core Data entities
- The remote store somehow ended up having duplicates, which caused
repeated imports of remote profiles due to randomly different
fingerprints
- Optimize reload of in-app receipt
- Refactor AppUI initialization in all platforms (sort of template
method pattern)
- Make AppMenu specific to macOS by wrapping it into a folder for
consistency
- Add SizeClassProviding for repeated checks on hsClass/vsClass
Fixes#659
- Let the user close the window, the app will just remain alive in the
status bar
- Accordingly, replace "Confirm quit" preference with the option to stay
alive in the status bar
- Add "About..." item
Add a status menu via SwiftUI MenuBarExtra where to:
- Show/hide app
- Launch on login via "Login Item" target
- Toggle profiles on/off
Only weird that the login item is not added to the list of "Open at
Login", but to "Allow in the Background", see
https://github.com/pilotmoon/Scroll-Reverser/issues/165
Requires some refactoring to bring AppContext initialization to the
AppDelegate.
Fixes#617Fixes#482Fixes#696Fixes#505
Sandbox had to be enabled in order to submit binary to App Store
Connect, therefore command line arguments cannot be used to tell
if the app was started by the launcher.
However, given that launcher starts app in hidden state, we can
safely assert that if the app is hidden on start, it was started
by the launcher.
See f33380b4e2
Also drop automatic signing on Mac bundle and unused utils.
Use bundle as a means to provide Mac APIs to Catalyst app.
In order to cross the @objc wall set by the Mac Bundle mechanism,
Swift structures cannot be used directly and must be bridged
through ObjC facades.
Create NSMenu in MVVM style and install it on app launch. Make
sure to do it in AppDelegate.applicationDidFinishLaunching(),
because doing it as early as in PassepartoutApp.init() would
crash Mac code.
Use .representedObject to own view models.
With menu in place, app can be sent to background when main window
is closed. Requires multiple documents support for app not to die
instantly.
Davide