Apps that pass the review process are eligible to be distributed in the Emory section of the Apple App Store and Google Play Store. This article proposes additions to the manner of signing and distribution used to upload a reviewed app to the store and to publish it. This only applies to apps that are meant for public distribution.
The In order to safeguard the Emory brand, the current policy is to not share credentials or secrets with app vendors and developers, both internal to Emory and external. This means that the vendor or developer will is not be issued issued credentials to login to the Apple App Store Connect app , Apple Developer Portal or the Google Play Console app. The vendor or developer is not allowed to upload binaries to the store nor can they use Emory signing credentials, nor can they distribute an app for testing or submit it for publishing to production.
Instead, the vendor or developer will provide provides Emory with a signed binary archive (SBA) of the app – an ipa file for iOS, an apk file for Android. The vendor or developer must use their own developer account(s) to build, sign and export the app to the binary archive format which is then delivered to Emory. Emory then resigns the app, then uploads to the store, then submits it for review and publishing.
This policy was put in place nearly 10 years ago and reflected in part the practical limitations of both stores ability to create a user that was limited to a particular app or apps. In the present this is not the case: both app stores allow creating of users that are limited to a single app or set of apps.
Another limitation that has been lifted was the ability to restrict a user from performing the distribution/publishing task because Emory wants to have full control over this and not delegate this task.
This policy worked well for many years and did not need to be changed. It did so because many of the developers were Emory employees and were bound to comply with the policy. Of the The few that weren't they were willing to comply without question. The 3rd parties were in the minority and did not seem to mind not be troubled in complying with the policy. Now however, at least half check thisof many more of the apps in the Emory stores are developed by 3rd parties. Many of those are unable or unwilling to provide a signed binary archive. This started with Theater Emory who could only distribute the app by uploading it to the store. Furthermore, they wanted to update the app dozens of times a week.
Another class of vendor that is quite popular now but nearly non-existent only a few years back is the DIY vendor. This is exemplified by the case of the CBCT department who wanted to use Good Barber, a DIY vendor, to build their simple app that played MP3s of guided meditation. In this case, Good Barber's policy conflicted with Emory's. Just like Yomingo, Good Barber wanted to be the one who controlled distribution/publishing.There are many, many more mobile app vendors and developers and many of them
The EHC Patient Portal app, HealtheLife by Cerner will be the first app in which we allow a 3rd party to publish the app. Several vendors have asked for this permission in the past yet none had the clout to demand it like Cerner and were denied based on concerns about protecting Emory's brand. The Cerner app now sets a precedent whereby we can be legitimately challenged by a 3rd party who wishes to have the same access as Cerner.
There are other mobile app vendors and developers that have no desire to distribute their apps but want access to the Emory accounts simply do not understand how to build SBAs, or, have some reason why they can't or won't. Instead they want access to the store to do the upload. They have no interest in doing the distribution.
For instance, Softura, a vendor responsible for the HeathMindr, eP / P@H, and SMART apps, tried for a while to build the SBAs for eP and P@H but quit after several of requests for new ones due too technical dificulties. Instead the to technical difficulties we had resigning and uploading the SBA to App Store. First, they handed over the source, however, we are were unable to build the SBAs from the source. They have requested So they requested and have been granted access to upload directly to the store (for Apple only) to solve the problem once and for all. It seems like it is possible to create a user in a role that would allow The have been granted 3 account with Developer role permissions with access to certificates, identifiers and profiles. This makes it is possible for them to upload the app to the store but they would not be able to but not to distribute it.
What does checking "Access to Certificates, Identifiers & Profiles" on the new user screen do when they have access to only one app? Does it allow them to view all objects in the developer account or just those that are used by the app? Does it allow the user to create objects or just view and download them?
If you do not check this box does that mean you must export the signing cert and create a provisioning profile for the app and give it to the developer who must then configure Xcode to do manual signing by using them?
The vendor or developer must sign a special agreement to obtain a Developer or Admin role for one of more of their apps.
Onboarding for Client Managed Apps
MARDT Admin does this
- create app id
- create app on the app and/or play store.
Client does this:
- Client requests access to Emory store accounts.
- Invitations are accepted.
For iOS apps, the MARDT Admin does this:
- create provisioning profile
- create other certs or keys as needed
- create other developer resources as needed
- provide apple signing cert to app developer
- set app to "manual" release
For iOS apps, the Client does this:
- if using Xcode
- change team to 'Emory University'
- archive the app
- export or upload app using manually managed signing downloading profile if needed
- Apple Apps store with App Store certs can't be installed on a device from any source other than the App Store. This is unlike In-house (enterprise certs) which can be installed from multiple sources.