App not usable for iPhone 6 and lower

[VILLAN3LL3]

Current Implementation

App is not usable with my iPhone 6 (iOS 12.4.6)

Suggested Enhancement

This app should be usable for people with older mobile phones!

Expected Benefits

This app does only work if as many people as possible use it. If you limit the usage to new mobile devices you exclude lots of people (mainly the less wealthy) which can be interpreted as a kind of discrimination - No money for a new mobile phone? Sorry, you cannot use the app!

[SebastianWolf-SAP]

The interface for the app was made available by Apple only with recent iOS updates - since 13.5. We also stated that in our FAQ: https://www.coronawarn.app/en/faq/

Unfortunately, there is nothing we can do about this as app developers.

Mit freundlichen Grüßen/Best regards, SW Corona Warn-App Open Source Team

[BUCKFAE]

So there is no chance that the app will run on anything lower than 13.5? I don't wanna upgrade to 13.5 as this would mean loosing my jailbreak (Jailbreak for 13.5.5 is still in beta).

[Argee88]

There definitely should be fallback solutions to this. If the core of the app depends on a library only available to a limited amount of users, it is pretty much worthless.

This issue should be reopened and addressed!

[melloskitten]

@Argee88 Maybe you can file a radar with Apple, so they can change it? Here's the link 😊 Unfortunately, it is up to them to support this functionality on older phones. 🤷

[Argee88]

@melloskitten will do. It doesn't change my opinion, that

Unfortunately, there is nothing we can do about this as app developers.

is utterly wrong and this issue should be reopened and addressed.

[richardbrammer]

+1 please reopen, as Apple may release a support update for iOS 12 or earlier.

[MauriceArikoglu]

@Argee88

@SebastianWolf-SAP as one of the project's developers actually concluded correctly and everything needed to be said was said.

The opinion can't be "utterly wrong" if the development team is using software, frameworks or APIs constrained by the vendor. It is simply not possible to ship software to environments, where fundamental software code the application relies on, is not bundled with.

If there was a viable way of providing support for older phones (and especially OSs), therefore increasing potential audience to help detect infection chains, obviously the application would target the oldest/earliest possible deployment target. But again, this is not the case here.

If you do not have a background in software engineering and don't understand this, I can give you a real life analogy, just ping me again.

@richardbrammer On a side note: I personally don't expect Apple to ship a software update for iOS 12 (or earlier) to deliver these APIs. There is several reasons why this seems unlikely.

To keep things organized, I vote for keeping this ticket closed until there is a valid reason to reopen.

---

How is the situation with Android? I expect this being worse, as hardware manufacturers like to tamper with the stock Android before releasing it to their devices and Android hardware half life tends to be shorter than these of iOS devices in general.

[Argee88]

Following that argumentation there wouldn't be a corona-warn-app, if both google and apple didn't provide a library for it? I'm pretty sure there would be implementations that don't have to be baked in the OS. Afterall, looking at the documentation of the architecture, the Exposure-Notification-Framework (admittingly I'm guessing that that is what we are talking about) is just a component that should be replaceable by another implementation. Using a framework does not necessarily mean, that there is no other way to implement something.

I don't see, why developing an alternative implementation and switching between implementations according to the underlying OS is something, that can't be done.

If your real life analogy explains it, I'm happy to hear and understand.

[tens0rfl0w]

Following that argumentation there wouldn't be a corona-warn-app, if both google and apple didn't provide a library for it? I'm pretty sure there would be implementations that don't have to be baked in the OS. Afterall, looking at the documentation of the architecture, the Exposure-Notification-Framework (admittingly I'm guessing that that is what we are talking about) is just a component that should be replaceable by another implementation. Using a framework does not necessarily mean, that there is no other way to implement something.

I don't see, why developing an alternative implementation and switching between implementations according to the underlying OS is something, that can't be done.

If your real life analogy explains it, I'm happy to hear and understand.

From the beginning of this project it was clear that the „Corona Warn App“ will use the Exposure Notification Framework and not a third party or self developed solution. There are many good reasons for that.

[Argee88]

I see...

[nathanlesage]

Following that argumentation there wouldn't be a corona-warn-app, if both google and apple didn't provide a library for it?

Precisely. Because otherwise you'd have to implement a lot of ugly hacks, as basically the bluetooth discovery feature is "misused" for this (you don't need to explicitly connect to a nearby device for this to work) — and as modern OSs are heavily sandboxed there's just no sane way to do so without seriously endangering the safety of the users.

But this is a highly philosophical debate going towards "Why are there only two closed-source operating systems" which is way above the level of this issue tracker.

As I mentioned in another comment: We need public pressure on both Apple and Google to provide backport fixes to older versions of their operating systems. Hence: Let's take this to Twitter!

[MauriceArikoglu]

@Argee88

Following that argumentation there wouldn't be a corona-warn-app, if both google and apple didn't provide a library for it?

Yes, exactly.

I'm pretty sure there would be implementations that don't have to be baked in the OS. Afterall, looking at the documentation of the architecture, the Exposure-Notification-Framework (admittingly I'm guessing that that is what we are talking about) is just a component that should be replaceable by another implementation. Using a framework does not necessarily mean, that there is no other way to implement something.

Simplest of many reasons this assumption is wrong: There is no public interface for devices to exchange data via bluetooth constantly, if this functionality is not supplied by the device itself. Which is the case here, hence the requirement for the OS supporting this functionality.

I don't see, why developing an alternative implementation and switching between implementations according to the underlying OS is something, that can't be done.

This would, for example, make targeting almost impossible. An iOS application supports operating systems starting from a certain version. With the EN-Framework this being from 13.5. Assuming we'd have an iOS 12 candidate supporting EN-Framework, this would result in an impossible target configuration: Valid targets: iOS 12.x and >iOS 13.5 but no version in-between (iOS 13 - 13.4)

[nathanlesage]

Assuming we'd have an iOS 12 candidate supporting EN-Framework, this would result in an impossible target configuration: Valid targets: iOS 12.x and >iOS 13.5 but no version in-between (iOS 13 - 13.4)

That's not impossible, it's perfectly valid with SemVer:

• >iOS 12.x && <iOS 13.x | >iOS 13.5 (not the right syntax but something like that)

[MauriceArikoglu]

Following that argumentation there wouldn't be a corona-warn-app, if both google and apple didn't provide a library for it?

Precisely. Because otherwise you'd have to implement a lot of ugly hacks, as basically the bluetooth discovery feature is "misused" for this (you don't need to explicitly connect to a nearby device for this to work) — and as modern OSs are heavily sandboxed there's just no sane way to do so without seriously endangering the safety of the users.

@nathanlesage This is not exactly true / out of context. You are right, bluetooth discovery can be misused to determine nearby devices but for this to work the "misusing" application or framework must be running in foreground at all times. The benefit of the EN-Framework being a system capability is constant monitoring at all times and dispatching the "results" of that to the application whenever the application requests this. Reason why the EN framework is not publicly available for other developers, this could lead to heavy misuse.

As I mentioned in another comment: We need public pressure on both Apple and Google to provide backport fixes to older versions of their operating systems. Hence: Let's take this to Twitter!

Just don't do it.

[MauriceArikoglu]

Assuming we'd have an iOS 12 candidate supporting EN-Framework, this would result in an impossible target configuration: Valid targets: iOS 12.x and >iOS 13.5 but no version in-between (iOS 13 - 13.4)

That's not impossible, it's perfectly valid with SemVer:

• >iOS 12.x && <iOS 13.x | >iOS 13.5 (not the right syntax but something like that)

It is impossible if you want to distribute your application onto actual devices. If an app targets iOS 12.x it will run on iOS 13. iOS 13 does not bundle the framework (nor has the system capabilities implemented for this to work).

That's where your problems start.

[Leseratte10]

How is the situation with Android? I expect this being worse, as hardware manufacturers like to tamper with the stock Android before releasing it to their devices and Android hardware half life tends to be shorter than these of iOS devices in general.

Google didn't put the API into Android. They put the API into the Google Play Services, which are updated like a normal system app. The Android API works with Android 6 or newer.

[Hypernut]

Assuming we'd have an iOS 12 candidate supporting EN-Framework, this would result in an impossible target configuration: If an app targets iOS 12.x it will run on iOS 13.

Is that impossible? Just let it run, check the Version on launch and tell the user to upgrade if version is lower than 13.5. But if they release an update supporting the framwork on 12.x, why should the leave out <13.5 ?

[nathanlesage]

@MauriceArikoglu

This is not exactly true / out of context.

Where is what you said different to what I just said?

If an app targets iOS 12.x it will run on iOS 13.

Yeah, but then it's a problem with Apple. I've noticed in the past that even Debian doesn't adhere to SemVer rules. Nevertheless, this could be part of a not that difficult bugfix, enabling these ranges, so I don't see that much of an issue as you seem to. Basically, as @Hypernut has said.

---

Google didn't put the API into Android. They put the API into the Google Play Services

Oh boy …

[Skeltek]

Perhaps someone should take care of the App Store claiming it to be available for iPhone6. I got an iPhone6 and the App Store clearly states the App to be available for that system. It is a minor hassle, but it leads to people trying to install it, checking their OS for upgrades, possibly even freeing up memory by deleting lots of content, because they might think updating their OS is being prevented by a memory shortage. If the AppStore claims the app to be available for the phone, but only runs on a newer OS, it is only natural to try updating the OS by any means. The App Store shouldn’t be claiming the app to be available for the hardware, when it is not applicable for any viable OS for that phone.

[ftyl]

@nathanlesage This is not exactly true / out of context. You are right, bluetooth discovery can be misused to determine nearby devices but for this to work the "misusing" application or framework must be running in foreground at all times. The benefit of the EN-Framework being a system capability is constant monitoring at all times and dispatching the "results" of that to the application whenever the application requests this. Reason why the EN framework is not publicly available for other developers, this could lead to heavy misuse.

@MauriceArikoglu Is the simple iBeacon setup of iOS not the same exact setup in the end? Using Bluetooth BLE PXP profile to implement proximity sensing between phones would work just as well? I am not sure if there would be a compatibility issue between iOS and Android, but it would definitely run in the background just fine, like loads and loads of iBeacon tools do today?!

[MauriceArikoglu]

Assuming we'd have an iOS 12 candidate supporting EN-Framework, this would result in an impossible target configuration: If an app targets iOS 12.x it will run on iOS 13.

Is that impossible? Just let it run, check the Version on launch and tell the user to upgrade if version is lower than 13.5. But if they release an update supporting the framwork on 12.x, why should the leave out <13.5 ?

Yes it's impossible as it would result in a linker error on launch. You would need target specific linker configuration which is not possible afaik.

[MauriceArikoglu]

@MauriceArikoglu

This is not exactly true / out of context.

Where is what you said different to what I just said?

@nathanlesage

as basically the bluetooth discovery feature is "misused" for this (you don't need to explicitly connect to a nearby device for this to work)

This statement is false, as you would not be able to copy the system functionality EN provides by "misusing" bluetooth capabilities. That's what my comment referred to.

[MauriceArikoglu]

Perhaps someone should take care of the App Store claiming it to be available for iPhone6. I got an iPhone6 and the App Store clearly states the App to be available for that system. It is a minor hassle, but it leads to people trying to install it, checking their OS for upgrades, possibly even freeing up memory by deleting lots of content, because they might think updating their OS is being prevented by a memory shortage. If the AppStore claims the app to be available for the phone, but only runs on a newer OS, it is only natural to try updating the OS by any means. The App Store shouldn’t be claiming the app to be available for the hardware, when it is not applicable for any viable OS for that phone.

There should be a warning on the App Store page informing about incompatibility. Pretty clear if a device is unsupported imo.

[MauriceArikoglu]

@nathanlesage This is not exactly true / out of context. You are right, bluetooth discovery can be misused to determine nearby devices but for this to work the "misusing" application or framework must be running in foreground at all times. The benefit of the EN-Framework being a system capability is constant monitoring at all times and dispatching the "results" of that to the application whenever the application requests this. Reason why the EN framework is not publicly available for other developers, this could lead to heavy misuse.

@MauriceArikoglu Is the simple iBeacon setup of iOS not the same exact setup in the end? Using Bluetooth BLE PXP profile to implement proximity sensing between phones would work just as well? I am not sure if there would be a compatibility issue between iOS and Android, but it would definitely run in the background just fine, like loads and loads of iBeacon tools do today?!

This would only work if every user ran around with his/her unlocked phone and application running in foreground at all times. In other words: this is impossible. Hence my statement to @nathanlesage - "misusing" bluetooth is not possible. This functionality is provided by system as is and is not reproducible on iOS that way.

[tens0rfl0w]

@MauriceArikoglu +1 Also implementing a solution without the use of the „EN framework“ would open possible new attack vectors and raise privacy concerns, because the app would have to handle the key/identifier database itself. The „EN framework“ does a excellent job in isolating every information that it collects and only exposing a little API to exchange identifiers with the activate tracing app. But as you already stated, the biggest downside would be the missing deep OS integration making background services not working like needed.

EDIT: As you can see on your own phone settings, till now the App did not accessed the key-identifier database once, because there are no „infected“ keys on the server to check with. That would have been not possible with a self developed tracing solution.

[MauriceArikoglu]

@MauriceArikoglu +1 Also implementing a solution without the use of the „EN framework“ would open possible new attack vectors and raise privacy concerns, because the app would have to handle the key/identifier database itself. The „EN framework“ does a excellent job in isolating every information that it collects and only exposing a little API to exchange identifiers with the activate tracing app. But as you already stated, the biggest downside would be the missing deep OS integration making background services not working like needed.

Yes. I don't understand why this is so hard to grasp. With current technical possibilities on iOS there is no way to accomplish what is needed to perform work this app does.

The only possibility for unsupported devices to become supported would be a sudden upgradeability to iOS 13.5 for these devices. Apple only did this once for iPods and if I recall correctly once for Macs as well. But I really don't see this coming: If iPhone 6 and lower were made to run iOS 13 they would've been supported from day 1. There's likely a good reason Apple decided to spare them from this update.

---

Personal side note: Apple has, by far, the longest TTL for popular-demand consumer devices. Modern Software requires modern hardware and innovation sometimes causes things to be left behind. That's life.