Hi could any one please answer to my questions.
1)Can we do device tracking using IOS MDM?
2)Many of forums are showing that an application which has device tracking functionality,Apple rejects the application.
Any answer would be appriciated.
Thanks in advance.
App Store Guidelines:
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
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
There may be more that affect you: https://developer.apple.com/appstore/resources/approval/guidelines.html
Related
We would like to publish our app, which uses the Blackberry Dynamics SDK, via unlisted store entry in the Apple app store. (https://developer.apple.com/support/unlisted-app-distribution) For this the app has to go through the store review process. The first build I uploaded got rejected because the reviewers couldn't access all parts of the app. This was somehow expected, because Blackberry Dynamics apps just show a screen to enroll your device into UEM if it's not. For testing I downloaded some other Blackberry Dynamics apps from the app store and they all do the same.
So my question is: To successfully get the app through the store review, would we have to provide Apple an account in our Blackberry UEM system? Will they actually enroll a device there for testing or is there a different way to do this?
Yes, you will need to provide the Apple App Store reviewer with credentials to activate your app with BlackBerry UEM. This could be a test instance or a dedicated BlackBerry UEM Cloud environment.
Here are BlackBerry's recommendations for App Store submissions.
Rule 3.1.1 In-App Purchase:
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected.
To ensure this issue is addressed, your submission’s Review Notes SHOULD contain the following:
PLEASE NOTE:
No additional functionality is unlocked or enabled via the activation code. The application will not function at all without activation with the BlackBerry Dynamics framework. This is similar to other App Store apps like Box needing a Box account, Evernote needing an Evernote account, etc.
All applications incorporating BlackBerry Dynamics security features are designed to work only within the BlackBerry Dynamics backend infrastructure framework. They cannot operate without the framework that ensures only authenticated end users can access an organization’s resources.
For activation and authentication of an application with the BD framework, users must enter an Authentication Passcode provided by their IT department along with their corporate email address. This is a security feature that cannot be replaced by a log
The above notes apply to all applications built with BlackBerry Dynamics. There are many BlackBerry Dynamics-based applications already in the App Store, a few of which were challenged with this rule, but accepted after further review.
Rule 3.1.2 Subscriptions:
Apps offering subscriptions must do so using In-App Purchase, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Developer Program License Agreement. To ensure this issue is addressed your submission’s Review Notes SHOULD contain the following:
PLEASE NOTE:
All applications incorporating BlackBerry Dynamics security features allow access to a server based solution (SaaS) and backend Infrastructure (IaaS).
The application does not offer a subscription and there is no in-app purchasing capability. If access to the backend infrastructure is desired, then Enterprises may only order and purchase access licenses from the developer for its users using various negotiated business terms – site licenses, perpetual licenses, etc. Access licenses are device independent, transferable.
The application can support a single user over several devices. The reason for a separate access code per device is because of BlackBerry's application management capability, where for example a customer admin has the ability to remotely wipe the enterprise data within a BlackBerry Dynamics application on a specific device.
Rule 5.5 Mobile Device Management:
BlackBerry Dynamics SDK does NOT utilize any Mobile Device Management (MDM) APIs. Additionally, enterprise data is encrypted at rest with AES-CBC using with 256 bit key and data in-transit is also encrypted over SSL/TLS connection.
BlackBerry Dynamics App Testing Requirements
When submitting an application to the Apple App Store or Google Play the developer MUST provide a valid BlackBerry Dynamics environment and information for Apple and Google to properly test the application. If you do not provide these, it is highly unlikely that your application will be approved. Specifically:
• Provide a unique set of authentication credentials (email address and activation passcode) for the setup process
• Make sure the user is provisioned in BlackBerry UEM and configured to access the application (entitlement ID) you are submitting
• Disable, or configure very weak password requirement in the BlackBerry Dynamics Profile via UEM to simplify the sign-in process
• Ensure that your application handles the provisioning cancellation use-case (see GDiOSDelegate::handleEvent with type: GDAppEventNotAuthorised and code: GDErrorProvisioningCancelled)
• Ensure that the BlackBerry Dynamics provisioning screen is the first screen in application's first launch flow
• Ensure your BlackBerry UEM Server is online if not using BlackBerry UEM Cloud.
Reference to BlackBerry Dynamics in your Application's Description
To avoid general consumers downloading the application by mistake and giving an unfavorable rating, BlackBerry suggests to include the following text right under the Application name and notify consumer users.
IMPORTANT NOTE:
[App Name] for BlackBerry will not operate without the necessary licenses from BlackBerry. It has been specially developed to operate with the BlackBerry Dynamics mobile application management(MAM) platform.
From Apple
2. 5 Performance: Software Requirements
Guideline 2.5.4 - Performance - Software Requirements
We noticed that your app declares support for location in the UIBackgroundModes key in your Info.plist file but does not have any features that require persistent location. Specifically, your app uses location background mode for the sole purpose of tracking employees, which is not appropriate on the App Store.
Next Steps
To resolve this issue, please revise your app to include additional features for your users that require the persistent use of real-time location updates while the app is in the background.
If tracking your employees' locations is your only intended use of background location, it would be more appropriate to distribute and sell your app as a custom B2B app, directly to CBS Clean, through the Volume Purchase Program. Additional information about the Volume Purchase Program and the Custom B2B Store is also available in iTunes Connect Developer Help.
Request a phone call from App Review
At your request, we can arrange for an Apple Representative to call you within the next three business days to discuss your App Review issue.
To request a call and ensure we have accurate contact information, reply directly to this message with a contact name and direct phone number to reach you.
i have developed a app for cleaners..cleaners location should be fetch in background for their payroll calculations and safety measurements..and also cleaners can view their worked places in mapview...but my app gets rejected..now what should i do..how to deal with this issue
Have a look here.
You can include the functionality and methods for the location services if your app needs Location services or remove the Location Updates from the UIBackgroundMode key in info.plist, So that your app will be approved by App Store.
I think you are using
locationManager.requestAlwaysAuthorization()
use this locationManager.requestWhenInUseAuthorization() instead.
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 am creating an iPhone app that will be free with the purchase of a set of headphones. The idea at this point is that a passcode will be included with the headphones that will let the user enable the app which is a DSP app with filter settings specifically for the headphones. The passcode only needs to be entered once and then the app will be permanently enabled. I assume that I will have to use my own server to check the passcode and return an authorization to the device. Does anyone have any advice on how to implement this functionality?
You could easily/quickly implement this feature using one of the PaaS (Platform as a Service) providers out there. Parse, StackMob, Azure, etc. They provide the database in the cloud and the REST API to access it, and you simply make a read on the password table to see if the entry exists (using the provider API). These services are very inexpensive and you could use the free tier until you get meaningful volume.
However, note my previous comment, that this would not be approved as an app for violating the App Store Guidelines.
Apps that arbitrarily restrict which users may use the App, such as by
location or carrier, may be rejected
Apps that unlock or enable additional features or functionality with
mechanisms other than the App Store will be rejected
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.