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.
Related
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.
I just spend oodles of time getting iAd to work in my AIR app for kids and now Apple tells me that it no longer supports iAd for kids apps! Any advice? The app sometimes has tens of thousands of downloads in a day. Do I take the loss and move on or is there any way to re-release this app as not "kids only"? Has anyone done this before? Thanks!
Note: Apps designed for children are not allowed to run rich media ads
I think that there is no solution about it.
The thing that is not clear to me is if this rule is valid only for Made for Kid category, you select that category in ITC when you set the parental rating. I guess that is the only way that they can recognize that. Try to see if creating a new upgrade you can remove the "Made for kids" flag.
If I'm not wrong, you cant air ads on kids apps. Maybe contact apple developer support and get the age bracket of your app changed? Thats the only thing I can think of..
You can release an update to the app and change the setting in iTunes Connect so that you app is not "Made for kids".
However, ads in general are frowned upon in kids apps. Although they're not specifically illegal, according to COPPA.
Also, if an Apple app reviewer decides that your app is targeted at kids anyway, they might reject it based on their policy of no iADs for kids apps.
Regarding COPPA's rules on ads for kids: http://www.ftc.gov/tips-advice/business-center/guidance/complying-coppa-frequently-asked-questions
"I want to run ads on my child-directed websites and apps. What do I need to know to make sure that I am complying with COPPA?
There are a number of questions you must find answers to before you enter into an arrangement with any entity to serve advertising to run on your child-directed sites and services. These include:
Is there a way to control the type of advertising that appears on the sites and services? (e.g., can you stipulate and contract only for contextual advertising, and can you prohibit behavioral advertising or retargeting?)
What categories of information will be collected from users on the sites and services in connection with the ads they are served? Will persistent identifiers be collected for purposes other than support for internal operations? Will geolocation information be collected in connection with the ads served?
You should make informed decisions before you permit advertising to run on your sites and services. Depending on what advertising choices you make, you may be required to notify parents in your online privacy policies and in a direct notice, and obtain verifiable parental consent, before you permit advertising to occur. Remember that the amended Rule holds you liable for the collection of information that occurs on or through your sites and services, even if you yourself do not engage in such collection."
If you want to monetise your app with advertising, you have little choice but to use an ad-network that can specifically provide ads for your target age group, and that is COPPA-compliant. Apple's ad network is neither as far as I know. Try Superawesome.tv or Ads4Kids - they may have an SDK you can add to your app for delivering ad campaigns appropriate for children.
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.
I have an app that I did as a proof of concept and put on the app store just to gain experience going through the process but it turns out, it gets quite a few downloads, probably 30 a week. No Angry Birds but the app is very specific on the data it provides. It's a free app and what I would like to do now is gather some data on the users - how often they use it, where they are, what information they are searching and saving. I have no intention of touching personal data but I'd like to be able to aggregate what all the users are doing and see if there's any value in that.
Is this permitted in an iOS app? I see reports where apps are gathering more data than that (like Path pulling all your contacts) and I would think what I am looking to do is pretty standard.
Any advice is appreciated.
Check the App Store approval guidelines. That is the best resource you have.
https://developer.apple.com/appstore/resources/approval/guidelines.html
A few excerpts that may be relevant to you:
Location
4.1 Apps that do not notify and obtain user consent before collecting, transmitting, or using location data will be rejected
4.2 Apps that use location-based APIs for automatic or autonomous control of vehicles, aircraft, or other devices will be rejected
4.3 Apps that use location-based APIs for dispatch, fleet management, or emergency services will be rejected
4.4 Location data can only be used when directly relevant to the features and services provided by the App to the user or to support
approved advertising uses
Privacy
17.1 Apps cannot transmit data about a user without obtaining the user's prior permission and providing the user with access to
information about how and where the data will be used
17.2 Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
17.3 Apps that target minors for data collection will be rejected
Independent of what the guideline says, you should be mindful of your users privacy. As long as you don't pin the information you collect to individual users, I guess you might be fine.
Regarding location data, the guideline states you can't collect for analytical purposes if it is not relevant to the app's usage. However, it is referring to the gps data. You can obtain location for analytical purposes through network access information.