Describe the bug

When flicking down and up on the "Auswahl" screen, it breaks the top / navigation bar and also the behavior of the button on the previous screen.

Expected behaviour

The app behaves correctly and stable

Steps to reproduce the issue

Start the app in cold start (close the app beforehand)

1. Go to Report Findings -> Next
2. Scroll up and down on that screen without closing the modal view

Technical details

• iOS 13.5
• iPhone XR

On the initial onboarding view controller, an empty navigation bar is displayed. In the next view controllers in the onboarding flow, the nav bar shows a back button, but on the first one, the bar should be hidden.

Current	Fixed

Possible Fix

Hide the navigation bar when showing the view controller.

I was able to fix this issue and create pull-request #94.

Intro

The current implementation of the 'Privacy Protection screen' doesn't really look like it is ready to be included in the first release, so I edited the look & feel of it a little bit.

Suggested Enhancement

New Implementation	Current Implementation
Dark mode (new):	Dark mode (old):
Light mode (new):	Light mode (old):

Expected Benefits

Better looking UI is always a good thing and placing the short message about 'privacy' in this screen may gives the user a better feeling about their data and privacy when using the 'CWA' app.

Pull request

I already did a commit on my fork of this repo containing all needed changes, so I will link a pull request #192 for this commit down below. Feel free to request any changes here or in the Pull request discussion!

Thanks!

Describe the bug

In the ExposureNotificationSettingViewController, the TracingHistoryTableViewCell and DescriptionTableViewCell use a background color on the label that's different from the background color of the cell. While both colors appear the same in light mode, they differ in dark mode.

Expected behaviour

The same dynamic color should be used for both backgrounds.

Steps to reproduce the issue

The different colors can be seen when having dark mode turned on and opening the exposure notification setting view controller.

Possible Fix

Use the same dynamic colors

HomeViewController + HomeInteractor are in a less than ideal state. The HomeViewController is the the most important thing for both, the user and for developers. It is a central piece of code and is modified frequently. Because of that it should be easy to understand how it works and how one can change it.

It seems that many developers struggle to understand how it actually works.

We should come up with an easy to understand implementation.

Rem: This issue is currently on hold because it is discussed who will actually do it. This issue is a reminder for us to actually do it and signals to the community that we are very well aware of the shortcomings of the current implementation. That being said the current implementation served us very well up to this point. Every piece of code gets rewritten sooner or later. :)

Internal Tracking ID: EXPOSUREAPP-1958

Describe the bug

Currently, nothing posts the NotificationCenter .isOnboardedDidChange notification, so onboarding never hides.

Expected behaviour

Onboarding should hide 😛

Steps to reproduce the issue

1. Delete the app
2. Step through onboarding
3. Observe that it is not possible to dismiss the onboarding view

Possible Fix

Post the .isOnboardedDidChange as part of SecureStore isOnboarded setter.
However this means that this is the only property that posts a notification. Perhaps we should re-look at how onboarding finish is communicated to the SceneDelegate

Current Implementation

PDF vector graphics are configured in some asset catalogs as multiple scale versions instead as a single scale vector file. Open an image in an access catalog (for example "enSettings/Icons_Bluetooth" in "Assets.xcassets") and you will see slots for multiple size versions although the original file used is a vector PDF:

Suggested Enhancement

Set "Resizing" to "Preserve Vector Data" and "Scales" to "Single Scale" for all vector PDFs files in all asset catalogs:

Expected Benefits

Correct use of asset catalogs everywhere with maybe better image quality on all current and possible future devices

In ExposureSubmissionNavigationController, keyboardWillShowObserver and keyboardWillHideObserver will store tokens for a registered notification-center observation.

However, a third kind of notification is handled, keyboardWillChangeFrameNotification and its token is also stored in keyboardWillHideObserver.

Thus, the registered block will not be de-registered.

Current Implementation

Currently resources like localizable string files, xcassets and Storyboard identifiers/segues are not checked by the compiler which opens up various scenarios for bugs.

• If a localized key has been added, changed or removed the AppStrings.swift and AppInformationDetailModelData.swift files needs to be updated manually. If this gets forgotten a wrong or no localized string will be shown to the user.
• If an asset for example an icon has been added, changed or removed the corresponding usage must be updated manually. If this gets forgotten a wrong or no asset will be displayed.
• If a color has been added, changed or removed the UIColor+ColorStyle.swift file needs to be updated manually. If this gets forgotten the wrong color will be displayed.
• If a Storyboard identifier has been added, changed or removed the AppStoryboard.swift file needs to be updated manually. If this gets forgotten the app could potentially crash.
• If a Storyboard segue name has been added, changed or removed the corresponding usage must be found within the project and updated manually. If this gets forgotten the app could potentially crash or a wrong ViewController gets displayed.

Suggested Enhancement

Implementing SwiftGen via a build script phase to auto-generate the Swift code for localized strings, xcassets, Storyboard identifiers and segues.

Expected Benefits

• Auto-completion for any kind of resources
• Compiler checked resources which eliminates all kind of bugs where the usage of a specific resource has not been updated alongside to its modification.

Internal Tracking ID: EXPOSUREAPP-3006

After clicking on accept notifications on last screen during the onboarding process home screen doesnt show up.

Describe the bug

The RiskLegend.storyboard is missing a button to dismiss the page sheet.

Expected behaviour

A close button in the top right corner, to over a button to close the sheet as stated in the development guidelines by apple.

People dismiss a card by:

• Swiping down from the top of the screen
• Swiping down from anywhere on the screen when card content is scrolled to the top
• Tapping a button

Human Interface Guidelines – Modality

Steps to reproduce the issue

1. Open the app
2. Click on the information icon in the top right corner

Possible Fix

Include a close button in the top navigation bar on the RiskLegend page

Congratulations on the great work done so far!

As an interested third party contributor I ran into difficulties getting the app to run out of the box. Two issues were the reason:

1. The required entitlements com.apple.developer.exposure-notification are not easily accessible for common developers without an official background, see https://developer.apple.com/documentation/exposurenotification
2. After the "onboarding" the activation check for the exposure manager is mandatory

I was able to workaround both:

1. I ran the app in the simulator, which does not require the entitlement
2. For the actual device I removed the entitlements
3. I commented out the check

In order to allow more participation it would be great to have some of these settings for DEBUG builds already in place.

I'll provide a PR for allowing to skip the exposure check when running in the simulator.

Good luck for your work! And stay healthy.

Rating: Medium

Description:

The app implements its own URI scheme coronawarnapp:// which accepts several parameters consisting of the different backends with which the app communicpates.
An attacker could abuse the URI scheme to create malicious links with their own domains functioning as proxy between the app and the actual backend. This would allow an attacker to receive all communication between the app and the backend.
This attack vector either requires social engineering to convince the target of clicking the link or another vulnerability or malicious app on the phone which can trigger the URL. As long as there is no name check for the provided domains or certificate pinning implemented, this functionality should not be included in the release version.

Proof of Concept:

An attack can be as simple as getting the victim to click this link:

<html>
<body>
<a href="corona-warn-app://configure?distributionBaseURL=https://malicious.dcdn.proxy&submissionBaseURL=https://malicious.scdn.proxy&verificationBaseURL=https://malicious.vcdn.proxy/">Click Me</a>
</body>
</html>

Alternatively, a malicious app can invoke the request itself, via webview or via an installed browser, given the called app is aware of the custom URI scheme. This is basically only limited by the creativity of an attacker.

Are there are any plans to introduce a dedicated cwa SDK/Framework for the Apple platform?

A cwa-sdk-ios would be beneficial in points of separation of concerns, code consistency and coherency.

The following parts of the cwa-app-ios project could be moved into a dedicated framework:

• Model-Layer (including Google Protobuf files)
• Network-Layer (HTTPS Communication)
• REST-API Layer when performing a specific request to the cwa-server/cwa-verification-server
• Cryptography-Layer
• BackgroundTask-Management
• Persistence-Layer
• ExposureNotification-Tracing-Layer

Additionally, a cwa-ios-sdk would enable a clear API-Specification in terms of what kind of functionality is publicly available for the consumer (the cwa-ios-app) and which is framework internal or private.

A comparable approach can be found within the SwissCovid-App project on GitHub.
https://github.com/DP-3T/dp3t-sdk-ios
https://github.com/DP-3T/dp3t-app-ios-ch

Rating: Low

Description:
The iOS app stores sensitive data in an unencrypted sqlite Database in the
app's sandbox. An attacker with root privileges, or code execution in the
scope of the CWA app can read this information. This includes data, such as
the TeleTAN or registration token. A code comment mentions that this database
"still needs to be encrypted" 1. If this measure is implemented, the issue
is mitigated.

However, it is questionable why the TeleTAN needs to be stored at all. As it
should only be used once to create a sessionToken, there should be no need
to store the TeleTAN on disk.

Proof of Concept:
An excerpt of the binary content of the secureStore.sqlite in Library/Application Support:

secureStore.sqlite
SQLite format 3
{tablekvkv
CREATE TABLE kv (
    key TEXT UNIQUE,
    value BLOB
indexsqlite_autoindex_kv_1kv
teleTan"[REDACTED]"
isOnboardedtrue0
[...]

In point 5 of setup section it says:

"or alternatively using brew cask install fastlane"
== >Error: Cask 'fastlane' is unavailable: No Cask with this name exists.

but it should be:

or alternatively using brew install fastlane

as fastlane is not a cask.

There is a lot of unnecessary force-unwrapping or nil-coalescing in the code, e. g.:

or

The conversion from String to UTF-8 encoded Data cannot fail. A non-optional conversion can be done:

let string: String = "foobar"
let data: Data = Data(string.utf8)

Rating: Low

Description:
After the iOS app scans a QR Code, it stores the GUID in the unencrypted database, which is found at $app_Storage_Directory/Library/Application Support/secureStore.sqlite. All data in this database is in cleartext including submitted TAN as well. An attacker with root privileges, or code execution in the scope of the CWA app can read this information.

Proof of Concept:
in class ENAExposureSubmissionService:

	private func store(key: DeviceRegistrationKey) {
		switch key {
		case let .guid(testGUID):
			store.testGUID = testGUID
		case let .teleTan(teleTan):
			store.teleTan = teleTan
		}
	}

class SecureStore:

final class SecureStore: Store {
	private let fileURL: URL
	private let kvStore: SQLiteKeyValueStore

	init() {
		do {
			fileURL = try FileManager.default
				.url(for: .applicationSupportDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
				.appendingPathComponent("secureStore.sqlite")
		} catch {
			// swiftlint:disable:next force_unwrapping
			fileURL = URL(string: "file::memory:")!
		}
		kvStore = SQLiteKeyValueStore(with: fileURL)
	}

Consider the following aspects:

1. The logger should not log anything in APP_STORE builds.
2. Remove unused code from Logger.swift.
3. Improve error logging: Make errors stand out so that they can easily be spotted during development.

Describe the bug

Some UICollectionViewCells on the HomeView do not have the correct background color in the dark mode.
Currently (in the dark mode) the background color is set to black which does not contrast with the background color of the UICollectionView.

Expected behaviour

Possible Fix

A possible fix would be to set the background color of the container view in the cells to UIColor.secondarySystemGroupedBackground. That causes the cell to have a white background in light mode and the gray you can see in the image above in dark mode.

I already started fixing the cells background color.

Once #62 is merged we should write a test for getTransmissionRiskLevelFromIndex.

Feature description

As an open source project, we also leverage several open source projects from community. These projects should be shown in our app. After aligning with Ux colleagues, the screenshot looks like:

Screenshot

Actions

• Create Rechtliche Hinweise on App Informationen
• Create a static file containing all information from THIRD-PARTY-NOTICES
• Create the Rechtliche Hinweise Viewcontroller and render the contents as the screenshot showed. (No storyboard)

The current App Information screens use a custom structure to render their content.

The corresponding view controllers should be migrated to inherit from the DynamicTableViewController.

Controllers to be migrated:

• AppInformationDetailViewController
• AppInformationLegalViewController

Example usage:

• AppInformationViewController
• RiskLegendViewController
• RiskLegendViewController+DynamicTableViewModel

Current Implementation

UIImageViews are inverted when 'Smart Invert' accessibility option is on, that should not happen.

Suggested Enhancement

Add code UIImageView.appearance().accessibilityIgnoresInvertColors = true in SceneDelegate.swift

Expected Benefits

Better accessibility support for people with disabilities.

Current Implementation

Currently there is no pull request template available in the cwa-app-ios GitHub repository.

Suggested Enhancement

Adding one or more pull request templates.
https://help.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository

Expected Benefits

Standardized pull requests in terms of contribution guidelines, motivation, solution, implementation, tests, etc.

Current Implementation

Suggested Enhancement

Expected Benefits

There are a lot of classes that deal with dynamic tables. Those classes start with DynamicTable. Most of them are pure model classes and can easily be tested. Tests for those classes a very valuable since we use them a lot.

Rating: Informational

Description:
The app contains a developer menu functionality which can be used for
additional debugging and testing. This functionality is only intended
to be used in Debug and Release builds, not AppStore builds. For this
there is a compile-time check that influences the return value of the
isAllowed() function. In case of an AppStore build, this function
will return false. However, the implementation of the developer menu
will still be present in the AppStore variant. A user or an attacker
with root privileges can modify this function to return true and thus
activate the developer menu in the AppStore version of the app. To
mitigate this, the developer menu should not be compiled into the
AppStore variant of the app in the first place.

Proof of Concept:
The implementation of the isAllowed() function can be found in the
DMDeveloperMenu.swift file starting from line 70:

private func isAllowed() -> Bool {
    #if RELEASE || DEBUG
        return true
    #else
        return false
    #endif
}

Rating: Informational (Potentially Critical)

Description:
The Backend configuration can be changed via the app's custom URL scheme. More
specifically, a custom URL can be created to change the app's submission,
distribution, and verification URL settings. This enables an attacker to craft
a custom URL that, if clicked by a victim, can change their backend URLs to
attacker-controlled values.
This feature is only inteded for testing purposes. However, the check for the
APP_STORE macro, which would disable this functionality in the production
release is currently commented out. If this were not to be removed for the
release version, this issue would become highly critical. In the other case,
this can be viewed as a reminder and to track the reintroduction of the
APP_STORE check.

Proof of Concept:
In ENA/Source/SceneDelegate.swift:206-234

	func scene(_: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
		// We have to allow backend configuration via the url schema for now.
		//        #if APP_STORE
		//        return
		//        #endif

		guard let url = URLContexts.first?.url else {
			return
		}

		guard let components = NSURLComponents(
			url: url,
			resolvingAgainstBaseURL: true
		),
			let query = components.queryItems else {
			return
		}

		if let submissionBaseURL = query.valueFor(queryItem: "submissionBaseURL") {
			store.developerSubmissionBaseURLOverride = submissionBaseURL
		}
		if let distributionBaseURL = query.valueFor(queryItem: "distributionBaseURL") {
			store.developerDistributionBaseURLOverride = distributionBaseURL
		}
		if let verificationBaseURL = query.valueFor(queryItem: "verificationBaseURL") {
			store.developerVerificationBaseURLOverride = verificationBaseURL
		}
		
	}

Rating: Informational

Description:
App Transport Security (ATS) is a security feature introduced in iOS
9 to ensure that the app's network connections employ only industry-
standard protocols and ciphers without known weaknesses. ATS is
enabled by default for any iOS app. In this case, ATS is explicitly
disabled for the distribution mock server domain. The configuration
allows connections in plaintext over HTTP for the domain and all its
subdomains.
This exception is currently defined for the mock server and
presumably only required for testing. However, this configuration
should not be present in the production variant of the app or used
for production servers in the CWA ecosystem.

Proof of Concept:
The configuration can be found in the app's Info.plist file starting
on line 38:

<key>NSAppTransportSecurity</key>
<dict>
	<key>NSAllowsArbitraryLoads</key>
	<true/>
	<key>NSExceptionDomains</key>
	<dict>
		<key>distribution-mock-cwa-[...]</key>
		<dict>
			<key>NSExceptionAllowsInsecureHTTPLoads</key>
			<true/>
			<key>NSIncludesSubdomains</key>
			<true/>
		</dict>
	</dict>
</dict>

Current Implementation

The current implementation produces a large amount of code by just setting some AutoLayout Contraint (e.g

Suggested Enhancement

The use of SnapKit to set the constraints.

Expected Benefits

SnapKit will make the work with constraints much easier and will lead to a heavily reduced codesize. And as we all know, less code == less bugs. On the other side there could be some internal policies to reduce the number of used dependencies as much as possible, which would be totally acceptable.

Description

Images on Risikoermittlung page are streched when in landscape orientation.

Expected behaviour

Images should not be streched. I didn't find any other location where this happens.

Steps to reproduce the issue

• Click on Risikoermittlung gestoppt
• turn Device to landcape
  --> images streched
  --> circle doesn't fit into elemet

Technical details

Device:

• iPhone SE (2nd gen.)

OS:

• iOS 13.5

SW version

• ENACommunity
• development branch at 98a7c11

Current Implementation

Suggested Enhancement

Expected Benefits

Before pushing a public release to app store a version label should be shown somewhere in the UI. This will be beneficial for issue reporting and QA in the future.

Rating: Medium

Description:
Certificate or public key pinning is when an app communicates with entites with specific TLS Certificates/Public Key. Any other communication is denied by the app, even if the TLS Certificate is signed by a trusted CA. This provides extra protection against Man in the Middle (MitM) attacks.

iOS app does not implement this secure measure, and this increases the possibility of a MitM attack.

Internal Tracking ID: EXPOSUREAPP-2517

Describe the bug

The asset "navi_bar_icon.pdf" in "Assets.xcassets" is missing an dark appearance, so it looks off when 'dark mode' is selected as the 'userInterfaceStyle'. Also, the navigationItem is never redrawn after init creation, so even if there is an asset for the dark mode, when the app is running and the user initiates an appearance change, the navigationItem will not adapt to the new environment style.

Expected behaviour

Expected handling	Current handling

Possible fix

• Creating an asset file (vector) with a white text color to display correctly when dark mode is enabled.
• Redraw the navigationItem when the appearance is changed (dark-to-light or vice versa).

I already created a vector file with the same specs as the current asset file but with a white text color and called the redrawing of the navigationItem inside the super method 'traitCollectionDidChange' from UIViewController. If it's possible to merge my commit, I will create a pull-request for this issue, so just let me know.

Current Implementation

There's no code coverage badge for the main branch and also no way to see the difference on pull requests.

Suggested Enhancement

Add a coverage badge to the README and setup a service to automatically post coverage changes to PRs.

Expected Benefits

Long term improved code coverage and therefore also increased trust from our users (which is important for this app to become a success).

The FOSS server fossies.org offers among others a feature "Source code misspelling reports".

Although smartphone apps are not included in the portfolio of that server, due to the expected importance of the CWA app I have set up as server admin a kind of continuous source code spelling error checks for all associated CWA sub-projects (repos). This is realized by cloning the GitHub default branch ("master" resp. in case of cwa-app-ios "development") and using the tool "codespell". The according reports are generated in a special restricted "test" folder that isn't fully integrated into the Fossies standard services and should also not be accessible to search engines. The cwa-app-ios report can be found here:

  https://fossies.org/linux/test/cwa-app-ios-development-snap.tar.gz/codespell.html

That version independent URL hopefully always redirects to the report for the latest "development" version identified by the short commit ID and a year-month-day string (YYMMDD) representing the according git pull date (mostly = commit date). The refresh rate is currently half-hourly.

Although after a first review some obviously wrong matches ("False Positives" = FPs) are already filtered out (especially unsupported German words) please inform me if you find more of them so that I can force a new improved check if applicable (e.g. "seperator" -> "separator" may be a FP).

Just for information there are also three supplemental pages showing some used "codespell" configuration details, all obvious False Positives and an error history (log).

Ok, corrections of spelling errors and typos have a low priority. Additionally some of the few found errors are "only" in comments (so not directly visible or relevant for users) and that within output strings may not all handled by the development team itself (/corona-warn-app/cwa-app-android#72).

Maybe nevertheless these reports can make a (very) small contribution to the overall code quality.

Internal Tracking ID: EXPOSUREAPP-9775

Your Question

Could you please explain your QA concept. I am especially interested how much you plan to unit test and when.

Current Implementation

Currently, the info icon triggers two different behaviours. Number 1 opens another view, number 2 opens a website in Safari.

Suggested Enhancement

Use the same behaviour for the same UI elements.

Expected Benefits

To ease the use of the app, behavioural patterns should be established and the same elements trigger the same action.

A testflight now would be very nice. Or at least before the public launch

Describe the bug

Row 22 in de.lproj has a typo "Bitte versuche Sie es erneut.";

Expected behaviour

Should be "Bitte versuchen Sie es erneut.";

"Like I mentioned above I adapted the same approach which is already used for AppInformationHelp with a Model and ModelData for static strings. But as of now whenever a new dependency is added we have to maintain both places manually:

• THIRD-PARTY-NOTICES
• AppInformationLegalModelData.swift

I can think of a more generic approach to display the licensing info by reading the content of THIRD-PARTY-NOTICES directly but this requires restructuring this file (e.g. JSON or PList). Going one step further, I can think of adding this (and maybe a license check) step to CI so that each build gets an updated and accurate content for THIRD-PARTY-NOTICES file."

Originally posted by @frnkschmtt in #111 (comment)

A build step in Xcode would also be sufficient instead of adding it to the CI pipeline.

In the Onbording views the user will see a short overview about the function of the app. Step 1 and step 2 have only one button "Let's go" or "Continue"on the bottom. But step 3 (How to enable risk detection) has 2 buttons ("Continue" and "Do not activate"). Unfortunately the "Do not activate" button is on the place where the "Continue" button was in the past views. IMHO that will lead to disabled risk detection by mistake. The same thing happens in step 5 (Receive warnings, know the risk").

The users are lazy and do not want to move their finger. They capture the message and intuitively just keep typing.
With the current arrangement of the buttons they deactivate the capture of random IDs because they expect the "Continue" button at this point.

It would be better if these two buttons were swapped and the "Do not activate" button is above the "Continue" button, which is again at the same position as in the two previous views.
This is in my opinion a better user experience and leads to less involuntary "deactivations".

Steps to reproduce:

1. start the app first time (or remove the existing from your device/simulator)
2. read first and second onboarding view
3. see risk detection screen and your finger is over the "Do not activate" button

Give me a hint when I should fix it.

Feature description

Problem and motivation

Is this something you're interested in working on

Describe the bug

When skipping notification authorization during onboard, the notification settings are broken

• When accessing the notification settings, an authorization popup occurs unexpectedly
• If this popup occurence is fixed, then the settingsOff becomes pointless as a user won't be able to activate the notifications in the iOS settings app as they new will be registered

Expected behaviour

• Skipping the notification authorization will let the user enable the notifications later through the settings menu
• No unexpected popups should occour

Steps to reproduce the issue

General:

1. Perform Onboarding, but skip notification authorization
2. Open settings
3. Tap on notifications -> Popup occurs

iOS Settings issue:
Remove the authorization requests in the settings controllers

1. Perform Onboarding, but skip notification authorization
2. Open settings
3. Tap on notifications
4. Tap to open iOS Settings -> No notifications settings availabile

Technical details

• iPhone 8 Simulator w/ iOS 13.5

Possible Fix

To my best knowledge, there is no way to register notifications in the iOS settings without an pop-up appearing.

I've already created a pull request #201 that would fix this issue by tracking if a user skipped notification authorization during onboard and provide a nicer way to enable them later.
#201 was intended to get rid of the unexpected popup, but I've just realized that the underlying issue is more severe than I've initially thought.

Your Question

In my pull request (#155) CircleCI fails. The output is as follows:

[20:50:25]: ▸ 2020-06-03 20:50:25.748 xcodebuild[14456:27951] [MT] DVTAssertions: Warning in /Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-16139/IDEFoundation/Execution/RunDestinations/IDERunDestinationManager.m:911
[20:50:25]: ▸ Details:  There are multiple run destinations that support deployment for the current scheme; selecting anyObject: {(
[20:50:25]: ▸     <IDERunDestination:0x7fb8615d4b30:'Generic iOS Simulator Device' sdk:iphonesimulator13.5 variant:iphonesimulator arch:x86_64>,
[20:50:25]: ▸     <IDERunDestination:0x7fb8615de7d0:'Generic iOS Device' sdk:iphoneos13.5 variant:iphoneos arch:arm64e>
[20:50:25]: ▸ )}
[20:50:25]: ▸ Object:   <IDERunDestinationManager: 0x7fb8615adc10>
[20:50:25]: ▸ Method:   -genericRunDestinationForRunDestination:scheme:schemeCommands:executionEnvironment:requiresSupportsArchiving:requiresDeploymentPlatformMatches:allowMultipleRunDestinationMatches:allowNoRunDestinationMatches:error:
[20:50:25]: ▸ Thread:   <NSThread: 0x7fb85ed084a0>{number = 1, name = main}
[20:50:25]: ▸ Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.

It looks like the config of CircleCI doesn't provide enough information for CircleCI to chose a destination for the archive. Here is the command that is executed:

set -o pipefail && xcodebuild -workspace ./ENA.xcworkspace -scheme ENA -destination 'platform=iOS Simulator,OS=13.5,name=iPhone 11' -archivePath /Users/distiller/Library/Developer/Xcode/Archives/2020-06-03/ENA\ 2020-06-03\ 20.50.21.xcarchive archive CODE_SIGN_IDENTITY='' CODE_SIGNING_REQUIRED=NO CODE_SIGN_ENTITLEMENTS='' CODE_SIGNING_ALLOWED=NO | tee /Users/distiller/Library/Logs/gym/ENA-ENA.log | xcpretty

I haven't changed anything in the CircleCI config.

Does anyone know what's going and how I can fix it?

Also described in: https://github.com/corona-warn-app/cwa-app-android/issues/174#issue-631080966

Current Implementation

I have analyzed the High-Resolution Screenshots with the WebAIM Contrast-Checker I found that some of the contrasts do not reach WCAG AAA, sometimes not even WCAG AA.

(The following image may show other colours because of web compression. Here the Screenshot of the Android-App is shown, but the colours match those of iOS)

Screen 1 (start screen): Both the green area and the blue button do not offer enough contrast. In addition, the perception of the color "blue" decreases most with age (Source), which is why the lower button in combination with the continuous capitalization and the narrow font could cause problems for certain user groups.

Screen 2 ("Low risk") and 3 ("Risk determination") both contain a small grey font. This is just above the AA minimum of 4.5 from a contrast perspective, but in combination with the very small font could be very difficult to read for some user groups.

Screen 3 ("Risk assessment"): The switch may not be recognizable as such for some user groups - some may just see a dot.

Suggested Enhancement

For reasons of accessibility, the contrasts should be increased. At the same time, the difference between headings and "secondary text" must of course be maintained. In iOS-version this is better implemented as some headings are bolder.

Expected Benefits

The application should be easy to use for all user groups - but individual risk groups such as senior citizens are very likely to have higher usability requirements, also in terms of contrasts. In order not to exclude these user groups from using the application, WCAG AAA should be implemented in the best possible way.

The marked icons in the images seem to be too large in my opinion.

I changed some icons to either match the target size provided in Apples Human Interface Guidelines. In my opinion it looks better than right now what do you think about it?