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.
Related
I have a client who want their own App, and only to have it in their own shop for clients, not in the iOS App Store. I was wondering if it is possible to create an App, not to submit it to App Store, but to upload it to a website, and make it available for direct download to 50 devices?
For a situation like this they should really use the Business to Business app store.
https://developer.apple.com/programs/volume/b2b/
This will enable them to limit the availability of the app to invitation only. It allows private distribution and you can set your own pricing (can be free if appropriate). This is available with the standard developer license (not the Enterprise one).
There is no officially sanctioned way to do this, that I know of, other than Enterprise-internal, or by using the developer's (your) license, which doesn't sound like what you need.
Be careful: https://www.theiphonewiki.com/wiki/Misuse_of_enterprise_and_developer_certificates
Apple has very tight control over the platform, and specifically prevent what your client wants.
I would question why your client wants to circumvent Apple here. While it is true that Apple take 30% of the price, they also provide a lot of infrastructure and security in return. Perhaps they want to maximize profit, or their content doesn't satisfy Apple's restrictions?
Developing a web app may be an alternative. When done right these can provide similar interfaces, and access can be controlled, and Apple is out of the equation.
Failing that, you could create a separate developer account for this, and the 50 devices could be registered individually by their ID. This will not be anonymous any longer, and it will have to be renewed yearly.
Technically yes you can distribute an app outside of the App Store using the Enterprise Deployment Program.
However, according to the terms of the Enterprise Deployment Program the distribution is limited to only employees of your organization, and in your scenario you mention that they want to distribute the app to their clients.
See the full details in the Apple documentation here:
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/DistributingEnterpriseProgramApps/DistributingEnterpriseProgramApps.html
One of the customers wants my iOS app to be customised and distribute to employees of his client. I found Custom B2B approach best but he is insisting on enterprise distribution and I am sure like me he does not know much about Enterprise deployment and its limitations. I will not be giving the source code but just the customised binary. My questions :
a. Is it possible to build an ipa and sign it with the enterprise certificate and deliver it ?
b. Will there be lot of support required from my side on enterprise distribution and device management ?
c. Is it possible to limit the number of licences of app while distributing it on enterprise network ? If yes, what is the best way to achieve it ?
Apple supports three app deployment methods.
B2C - aka - the normal app store
B2B - this looks and acts like the normal app store but the app is not visible to the general public.
The only way to get an app to someone is via invitation using a redemption code. This looks to the user like a hybrid of a gift card redemption and a link to an app in the app store.
For this you "purchase" (they can be free) a set of redemption codes from Apple. They send them to you in a spreadsheet. You are then responsible for distributing the codes and tracking which have been used. Apple will send a report of those that were successfully redeemed.
This method can only be used if the app meets Apples criteria for B2B. If they feel it is something that could be on the general app store that is where they expect it to be. The sticking points are really around functionality that can only be used by your business partners, no redeeming public value.
This is also a valuable in ensuring that you don't have an app that gets poor reviews by people that can't use it because it is only useful to your partners.
B2A - aka Enterprise Deployment. This is a special and seperate development account that allows you to host an internal app store and package your own applications for in house deployment. Apple will only allow companies that meet certain requirements to have this type of account. There are strict rules around the deployment as well. Apps may only be distributed to employee devices and are not allowed to be distributed to non employees/customers/business partners.
I'm building a small app where users can browse cheap accessories like lipstick, nail polish, etc. I have Login With Amazon (http://login.amazon.com/) implemented because I originally thought that I could allow users to buy the accessories directly from my app.
But I soon realized that Apple has actually restricted that functionality. The purchase ability is available on Android and for web developers, but unfortunately not yet for iOS.
Is there some hacky way that I can allow users to make a purchase from my app (or from a web view in my app)? I have a little bit of experience with Python so I'm guessing there might be a way to write a script that presses different buttons on the Amazon web page in a web view in my app. The user is already logged in with Amazon.
You can use Shopelia SDK which enables in-app purchase of physical goods using one click payment. It is available for Amazon but also for any kind of retailers.
It works using a combinaison of automation and monetics to inject the order and process the payment.
Right now (October 2013), the product is in beta stage and can be demonstrated on Shopelia website http://www.shopelia.com
Integration is available through SDK for Android and iOS.
Disclaimer : I'm co-founder of Shopelia. Please contact me if you are interested to integrate the technology in your app.
I work for a company that makes kiosk applications. We currently use custom windows tablets for our kiosks, but we're planning to move to using an iPad for all our kiosk apps. We need to have one single app on the app store and the workflow that we show is customized based on client. We identify which client a request is coming from by the iPad's device identifier (udid). We associate this internally with a workflow on the server side and return the appropriate workflow.
So, to recap, we need to create workflows for each single iPad and the iPads are identified by deviceId. A valid workflow is needed by the device to start functioning. Ignoring that the UDID API has been deprecated for a minute, My question then is, does Apple allow this kind of deployment if we publish the app to the App Store?
Another alternate approach we were thinking about was to build a licensing infrastructure on our side. The client would get the iPad, call us for a license key and when the key is entered correctly, we populate our database with the deviceId and a workflow automatically.
Thanks,
Teja.
I would suggest using the mac address of the ipad form the webserver
you would normally present a normal application, you will need to add normal functionality to this application, such as information about the product or the company, or about how to register or buy, you will have to add some usability to it so that apple does not reject your app as being incomplete or a demo
After that you will need to register the mac address of the iPad and authenticate it on the server, if the ipad gets authenticated, then you will present the fully functional application that the kiosk buyers will use.
Hope this will help you
Apple says,
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected.
For example my IOS app will be used to make consultations with a web service and will be given free to users by my customer, since the web service is ours and flexible, it can offer different and hunderds of types of consultations (e.g first-aid guide, TV troubleshooting, Internet Connection trouble shooting..etc) and this can all be updated in web service by user. But this does not mean that users can use the app to buy some new guides. It will be offered to the users for free with a specific description of "This app includes this 10 guides" but we are charging the customer for license of using out web service and iPhone is one of the many ways we are offering client to access the web service and get that knowledge.
Is this possible? and what are the Apple restrictions?
Can I sell this app to CompanyX which offers 10 different troubleshooting guides?
Then sell CompnayQ another build with supports 50 different guides?
Apple have made it clear in their terms for the App Store that you must not offer anything for sale - neither products nor services - from inside an app unless it uses their purchasing APIs. This is why e. g. Amazon had to remove the buy-a-book feature from their Kindle app for iOS. You must not even have a link to a website in your app that would take the user to your website for purchase in Safari. AFAIK even a text hint on some screen inside your app telling people to go to your website for purchase of further services might be problematic in the review process.
In my opinion (which is just that, an opinion) you will probably be good with different apps for CustomerX and CustomerY, each offering free access to a specific subset of your web services. You will even be good if existing users of any of the apps can buy access to additional services on your website and then use them in their respective apps, as long as you do not link to that page from your app. You will, of course, still have to implement some kind of user-id system to recognize which users have access to the additional services, and which don't.
I suggest you take a look at how Amazon does it, because their Kindle app has certainly had a lot of scrutiny from the reviewers. Follow their lead and you should be good.
If you sell guides in the app you probably have to use in app purchases, where apple will remain 30% of the money. otherwise your app will probably get rejected.
if you have an developer account you can check the app store review guidelines.. point 11.2:
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy" button that goes to a web site to purchase a digital book, will be rejected