3 ms·
I think the issue is that by changing the way watchOS works, Apple effectively removes the possibility to develop a 3rd party health-tracking tool (because the
by iamkonstantin 2y ago
I think the issue is that by changing the way watchOS works, Apple effectively removes the possibility to develop a 3rd party health-tracking tool (because the sensor data is no longer available).
Imagine AliveCor (or anyone) coming up with a better way than Apple to interpret data from the device. Or they use the data in a different use case than the watchOS health feature... there are many reasons to enable 3rd parties access to onboard sensors.
- nerdjon 2y agoUnless I am misunderstanding the article (or it is just not giving enough information), it isn't that Apple removed direct access to the hardware in watchos 5 but that they changed the algorithm. It seems the previous algorithm gave more constant readings, but that is why I am curious more about why they made the change. Given that as far as Apple is concerned, you still bought the Apple Watch. Regardless of wether the data is going to the heath app or another app, you still paid them money. Possibly even more money if that third party app is a subscription through the app store. There is no incentive for them to make this a worse situation for their users, quite the opposite actually. So the reasoning for why Apple made this change is important. As far as a developer having direct access to the sensors, that is a tricky situation. We can argue that for a heart monitor it is a good idea but I don't think every app needs access to every sensor for privacy reasons.
- iamkonstantin 2y ago> it isn't that Apple removed direct access to the hardware in watchos 5 but that they changed the algorithm Precisely why it should be possible for an app to provide their own algorithm (by accessing sensor information, or opting to re-use Apple's algorithm) but adapted to the app's use case. Apple must be transparent here. > I don't think every app needs access to every sensor for privacy reasons We already have a system in iOS to request permission to sensitive data. In fact, we have more than one - App Store Review (supposedly the guardian at the gate) and the permission prompt in the app itself. Privacy is not "degraded" when more sources can be requested by an app.
- nerdjon 2y ago> Precisely why it should be possible for an app to provide their own algorithm (by accessing sensor information, or opting to re-use Apple's algorithm) but adapted to the app's use case. Apple must be transparent here. This assumes it is possible to use the sensor as we expect it would be presented in the first place. Take the oxygen sensor, which to the best of my knowledge is largely an ML algorithm anyways. > We already have a system in iOS to request permission to sensitive data. In fact, we have more than one - App Store Review (supposedly the guardian at the gate) and the permission prompt in the app itself. Privacy is not "degraded" when more sources can be requested by an app. Yes and no, we know that users have a tendency to just accept and move on. This has been shown time and time again. There are plenty of sensors that a developer would never need direct access to and should only ever need it through an API. I would also argue that pushing all developers through API's instead help avoid apps being incompatible with later hardware revisions (within reason) which has largely been a staple of the iOS platform. We should also be clear here that the lawsuit is not about direct hardware access. It never was from the best that I can tell. It is also not clear to me if direct hardware access would actually give anything meaningful depending on how exactly this works.