Skip to content
This repository has been archived by the owner on Jun 20, 2023. It is now read-only.

compatible ipod Touch on iOS >12.5 barred from installing #3775

Open
symbolisch1234 opened this issue Nov 1, 2021 · 9 comments
Open

compatible ipod Touch on iOS >12.5 barred from installing #3775

symbolisch1234 opened this issue Nov 1, 2021 · 9 comments
Labels
enhancement Improvement of an existing feature

Comments

@symbolisch1234
Copy link

Current Implementation

I have an ipod Touch (6G) running iOS 12.5.3 - according to Bundesregierung FAQ this version is sufficient for running CWA. However, the app store bars me from installing CWA, saying i need an iPhone to run the app.

Thoughts

It might well be that iPods are missing the required hardware for GAEN, but i really don't know, i am just guessing. But even in this worst-case scenario, the functions of (a) registering and presenting vaccination certs, (b) event check-in using QR codes, are still valid use cases for the app on ipod touch. While [a] can be done with CovPass, [b] can't.

Suggested Enhancement

Let the ipod Touch models capable of running CWA (6G and 7G) install CWA. If necessary, add a warning banner explaining which functions of the app are usable, and which aren't. This is much better than giving the user no function at all.

Expected Benefits

Not having to install the stupid rapper app which doesn't respect my privacy (which can do qr-code event check-in on ipod touch running iOS >12.5, but, well, it doesn't respect my privacy).

Thanks for your time and consideration.

@symbolisch1234 symbolisch1234 added the enhancement Improvement of an existing feature label Nov 1, 2021
@cwa-bot cwa-bot bot added this to ToDo in [CM] cwa-app-ios Nov 1, 2021
@Ein-Tim
Copy link
Contributor

Ein-Tim commented Nov 1, 2021

@symbolisch1234

Yes, you're right, the iPod is missing the GAEN Framework, see #1887 (comment).

In your settings, when you click on "Begegnungsmitteilungen", what do you see?

@symbolisch1234
Copy link
Author

symbolisch1234 commented Nov 12, 2021

hey, sorry for the late reply, had a big problem to deal with.

In Settings > Exposure Notifications, there is a big grey nothing. I followed the procedure in your linked comment, and it didn't change anything. the setting for exposure notifications is listed in the menu, but there is no content. :-( i guess that is apple unhelpfully saying "GAEN required hardware missing".

@Ein-Tim thanks so much for the #1887 link, i didn't see that issue before opening this one. now that i know there is a second person wanting to install CWA on ipod Touch, I very much suspect there are a few thousand out there (but who have no idea what "a github" is).

edit: i don't think that's relevant, but i am actually on 12.5.5, not as initially claimed 12.5.3

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Nov 12, 2021

@symbolisch1234

Thank you for your reply! Yes, I guess either is the iPod missing required hardware or Apple has just not provided the ENF to iPod Touches till now, but only added the "Begegnugnsmitteilungen" settings screen (which is grey).

It's sad to say, but I fear the developers of the German Corona-Warn-App can't do anything about this, as this is an issue in Apples iOS for iPods.

@dsarkar Please decide how to proceed with this issue.

@symbolisch1234
Copy link
Author

symbolisch1234 commented Nov 12, 2021

the developers of the German Corona-Warn-App can't do anything about this

i disagree, if only a little bit. as i write in my initial comment

the functions of (a) registering and presenting vaccination certs, (b) event check-in using QR codes, are still valid use cases for the app on ipod touch

if you look at Corona Tracing Germany (which is a fork of CWA) at https://f-droid.org/en/packages/de.corona.tracing/ (package) or https://codeberg.org/corona-contact-tracing-germany/cwa-android (source) they allow installation on all kinds of android devices, even those running Android 5 and thus being far too old for GAEN. the functions GAEN is needed for (proximity tracing) don't work, but all other parts do. "Not fully compatible devices will show a notice on the main screen."

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Nov 12, 2021

@symbolisch1234

Yeah, I agree with you that it could and should be possible to also allow installation of the Corona-Warn-App on non Exposure logging compatible devices.

There is a related issue in the https://github.com/corona-warn-app/cwa-wishlist repo about this: corona-warn-app/cwa-wishlist#443

@symbolisch1234
Copy link
Author

I hope i am not overstepping here, but i did a little bit of research and thought about a way to make this happen:

Method

It should be possible to leverage the onboarding process that the app already contains. On a compatible smartphone, the onboarding asks the user to enable "Exposure Notifications", which the user can decline. If this happens, the app continues its installs without problem. On the main screen there is a big warning that exposure logging is disabled, but besides that, the app works just fine. This, to me sounds basically what we would want for non-GAEN-compatible devices, such as iPods and iPads running iOS 12.5 and above.

Proposal, Step 1: WHERE

In the onboarding view controller, in line 319, there is a private func askExposureNotificationsPermissions

private func askExposureNotificationsPermissions(completion: (() -> Void)?) {

This function passes "accepted: false" to persistForDPP in line 371

which then sets self.store.exposureActivationConsentAccept to the boolean "FALSE" in line 328.

self.store.exposureActivationConsentAccept = accepted

(Just for clarification, in the line above accepted is a variable, which holds the boolean value.)

Proposal, Step 2: DEVICE DETECTION

Using utsname() and uname() it is possible to detect the device model. The following is from a completely unrelated git at https://gist.github.com/SergLam/50c0e400877d76c499c2649b109b3890, and it might need a tiny bit of a rework, but in principle the following should give us an identifier variable with the device model, which for my ipod would be the string "iPod7,1".

var systemInfo = utsname()
        uname(&systemInfo)
        let machineMirror = Mirror(reflecting: systemInfo.machine)
        let identifier = machineMirror.children.reduce("") { identifier, element in
            guard let value = element.value as? Int8 , value != 0 else { return identifier }
            return identifier + String(UnicodeScalar(UInt8(value)))
        }

As we are only talking about 2 iPods and ~10 iPads, a hardcoded list of devices is easy to create.

Proposal, Step 3: IMPLEMENTATION

In line 354ff, the exposureManager is called.

Here, the following could be added:

  1. device detection, as described above
  2. a function with the hardcoded list of non-GAEN devices, as described above
  3. a simple if-else construction

This conditional checks whether the device supports GAEN or not, and depending on the outcome of the check, either continues to perform askExposureNotificationsPermissions just as it is currently done, or instead directly sets self.store.exposureActivationConsentAccept to the boolean FALSE.

This way all internal logic assumes the user has declined to activate Exposure Notifications, and thus will never call Exposure Notifications and GAEN, which should give the same results as Exposure Notifications not being present on the non-GAEN-compatible device.

Proposal, Step 4: TIDYING UP (optional)

It would be nice to do the same three steps again near line 39 in the HomeExposureCellModel.

case .disabled, .restricted, .notAuthorized, .unknown, .notActiveApp:

This time the if-else conditional replaces the title variable in line 40 with a different wording, perhaps "Your device does not support Exposure Logging" or something similar. This needs a little bit of localisation work, of course. The icon variable (line 41) is probably not important, but it could be changed as well.

Caveat

I am not an iOS developer, my swift knowledge is somewhere between poor and non-existent. Having said that, contemporary languages aren't that different, i do know my javascript and i have written a few things. It might well be that i have overlooked something and it isn't quite as easy as i make it out here, but i can not imagine it is much more complicated either.

I hope me having laid out a possible path is of help to the person actually implementing this. In #443 in the wishlist ( corona-warn-app/cwa-wishlist#443 ) the user @thomasaugsten asked to be assigned this, so i hope it is okay if i tag them.

@symbolisch1234
Copy link
Author

@Ein-Tim very sorry to bother you with a tag, but do you know if there is anything further i could possibly do to expedite this issue? i got a "thumbs up" on my last post, but besides that, the issue has been silent for a month (at least that's what it looks like, public-facing)

i would like to see this issue resolved, and i would like to be a help, but i have no idea what i could do... if you have any idea, please tell me.

thanks for your time.

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Jan 18, 2022

@symbolisch1234

Everything you could do was done, it's now up to the project team and in the end the stakeholders (RKI/BMG) to decide when/if this will be implemented.

@Ein-Tim
Copy link
Contributor

Ein-Tim commented Apr 13, 2022

@dsarkar Please deiced how to proceed with this issue? Merge it with e.g. corona-warn-app/cwa-wishlist#443 or leave it open?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement Improvement of an existing feature
Projects
Development

No branches or pull requests

2 participants