I made the free app to measure the oxygen level in blood using a phone's camera.
Apple rejected app said this:
Guideline 1.4.1 - Safety - Physical Harm
We noticed that your app claims to take health measurements using only
iOS device sensors, which is not a functionality these device sensors
support.
Specifically, your app claims to measure a user’s bloody oxygen
saturation.
Next Steps
To resolve this issue, please remove any unverified health measuring
functionality from your app that uses the device sensors.
Alternatively, you may submit documentation in the App Review
Information section in App Store Connect that clearly discloses data
and methodology to support accuracy claims relating to these health
measurements. If the level of accuracy or methodology cannot be
validated, we will reject your app.
What documentation I have to submit?
Sounds like you need to conduct some tests using a real pulse oximeter, and your app, to show that your app gives similar readings to the pulse oximeter.
The tests would need to be thorough enough to convince a sane person that your app is decently accurate compared with a real pulse oximeter.
Apple needs to know that your app is accurate before it allows people to use it.
Basically you need to do some science 🧬⚗️. For example, multiple tests on a number of different people of varying health / age / skin tone. Document your experiments. Attach the findings. Apple wants to see that.
Related
Apple definitely computes HRV(Heart Rate Variability) when someone uses Breathe App (in Mindfulness) on their Apple Watch and when we closely look at the details of data collected in HealthKit app, it depicts Algorithm Version as 2 But Apple also records HRV in some other scenarios which depicts Algorithm Version as 1. What are those scenarios?
Are there any limitations imposed by Apple when using beacons APIs?
For example can I design an App that uses iBeacons as part of a game and not for providing in-store marketing?
Is the app likely to be rejected?
No there isn't. As an example we've delivered an app for a wearable that broadcasts itself as a beacon in order to initiate syncing on the phone (or the start of a detected activity or state change).
If you're sticking to their APIs then indeed there's plenty of use cases that have nothing to do with marketing or even location.
It's a common misconception that Apple iBeacon technology is all about marketing. Not only does Apple not restrict use of the technology, it is happy to approve apps that make novel uses. I have build all kinds of beacon apps and had them approved in the store that do things with beacons like:
Indoor navigation at the Consumer Electronics Show
Scavenger hunts
Getting info about plants at a botanical garden
Opening gates at parking garages
Identifying people who are nearby to kick off a chat session
If you are worried about an app being rejected due to using beacons, be more careful to see that it isn't unnecessarily using location background mode. This is the main reason that I have seen beacon-based apps get rejected in the past.
I'm working on an app that retrieves iBeacon UUIDs from a backend server, that means there are no hard-coded UUIDs in the app and these IDs are constantly changing. UUIDs can be updated on the backend and the app will receive a new set of UUIDs to monitor for.
Based on this post here, Apple is rejecting apps that support manual input of UUIDs and I'm not sure if my app is going to make it to the App store.
I would like to hear your feedback if you've gone through this path or have worked on a similar concept and made it through the review process.
I have also had an app rejected for allowing manual input of ProximityUUIDs. My understanding of Apple's position is that this applies only to transmitting as a beacon, and that it is allowed to have manual user input of ProximityUUIDs for detection purposes. The reason they don't want you to transmit with a manually entered ProximityUUIDs is because it allows creation of an easy hacker tool for "spoofing" other folks' beacons.
That said, your use case is different still, because you are getting the ProximityUUIDs from a server, not directly from user input. I have several apps in the AppStore that do exactly this, and it is a common practice, so I don't anticipate it will be a problem for you.
Interesting discussion on UUIDs. Given the ibeacon protocol requires you to know the UUIDs, having to add them to your app in advance is a major limitation. How does one request an official UUID from Apple David, your company "Radius" makes beacons, is the UUID it ships them configured with an "officially" agreed one you setup with Apple?
I have read in a business newspaper the following use case for iBeacon :
Clarks (US) - Prompting users to download their app as soon as they walk in-store
I saw nothing in terms of features that is dealing with such an opportunity, so I am quite confused.
On the other hand, the native AppStore application does support iBeacon (as seen in Apple Store to provide contextual services such as Genius Bar, etc). So it is technically possible that some sets of UUID x major x minor are used to invite users to discover an application with a specific store ID - and we still not will be at the OS level, but still at an application level.
So, what's the point ?
A future new release of iBeacon that is currently tested a kind of partnership between Apple and Clarks? Or am missing something ?
I think the simplest explanation is that the reporter got it wrong. The only reference to this I can find is this Marketing Week article,
Which says:
Beacons examples
Clarks (US) - Prompting users to download their app as soon as they walk in-store
As you have suggested, this is not possible without another app already on the phone that does the iBeacon detecting. While it is technically possible that the Apple store app could be helping do this, I think that does not sound at all like something Apple would agree to do. It is more likely that some marketing network has embedded something that does this in a common library in popular free downloadable games. This would only work for people have downloaded apps with this embedded library.
However, given that the claim of this article is dubious, and there is no available evidence to support it, I would be skeptical.
So I've spent a lot of time making an iPhone game and have recently realized that I don't have to limit myself to just Apple - I know there are app stores for Palm and Android, but does anybody know of a good "app store" for the plain old PC? I would like to have one where individual developers can publish an app and not have to worry about all the billing and piracy issues!
Valve has Steam, although that's a bit of a game store. It comes with DRM so it might be what you want. http://store.steampowered.com/
From what I can see, their website has an email to coontact them about distribution and that's it. steamworks#valvesoftware.com
Stardock has Impulse, which is more of a general app store although it does have games as well. No DRM baked in, and it has a very liberal return policy. http://www.impulsedriven.com/
Impulse has a page with more info and a contact form - https://developer.impulsedriven.com/#publishing
The page states the base rate is 70% which is likely more than Steam gives you.