The Joys of Custom Clienteling App Distribution

In the third of the series of technical leaning blog entries, our EMEA Technical Lead follows on from the second part on white label apps to their distribution. Barry refers to his personal experience and knowledge of being in Retail Technology for 30 years.

Get it from the store

Currently, the Proximity Insight (PI) branded clienteling app is distributed free of charge on the Apple App Store and soon the Google Play Store. This allows for easy distribution of the app as users in our clientele can download the app themselves, or the company can on their behalf via Mobile Device Management (MDM).

A few of our customers don’t have MDM. Therefore, having the clienteling app on the App Store is the best of both worlds; it gives our customers the choice as well as saving us a degree of pain managing builds for each client. As covered in previous blogs, the app is a thin client and all of the UI and logic is pulled from the Salesforce org, hence the clienteling app’s code base is the same regardless of brand configuration.

However, when it comes to offering a client branded version of the white label app, then the public app store is not the ideal route. Sometimes, there are internal security policies that mean clients need to avoid using the public App Store. This therefore means that we need to consider private distribution of the clienteling app package.

Firstly, the easy one: Google Android

We recently added Android to our offering and it’s the most straightforward to handle of either app store. We have an APK build that can be provided to the client and they can distribute via MDM or by simply making it available on file share.

Ironically, the new delay with Android is listing on the Google Play Store. This is understandable as it has become the wild west of app stores, with various scam apps being made available. However, once the clienteling app is listed, it will be in line with iOS so users can download without an MDM or sideloading on their phones.

That’s it for Android – simple and easy.

Apple iOS: climbing over the garden wall

Apple’s iOS is often described as the walled garden of mobile app markets and in my opinion, that’s an accurate description. This nickname is mostly down to Apple’s main customer being end users. Apple are, of course, very keen to make sure that anything appearing on the store is not only safe to download, but offers a great experience for users.

As mentioned above, Proximity Insight uses the Apple App Store to distribute the mobile application, which is Apple’s prefered approach. Distributing apps outside of that process is challenging, especially when in a private B2B nature when you’re attempting to avoid appearing on the App Store.

There are currently two routes besides the App Store:

• Enterprise Developer Program
• Apple Business Manager

Enterprise Developer Program

Until recently, outside of the App Store and personal developer accounts, the only option to distribute custom apps to iOS devices has been via the Enterprise Developer Program (EDP). This is effectively a company level membership which individual Apple developer accounts can sit under.

When apps are compiled under an Enterprise Developer certificate, the resulting app can be distributed to any number of iOS devices via MDM or Over The Air (OTA). This bypasses the Apple App Store and its approval process, meaning the app is effectively ‘unapproved’ by Apple. The view from Apple is that the company using EDP holds the source code to the app and hence happy taking the security risk with their devices.

An important point with the Enterprise program is that this is meant for the distribution of apps within the named organisation of the membership. The terms and conditions of the membership are that apps are not distributed outside of the organisation. This is not enforced technically, only via the agreement with Apple.

This has led to unofficial app stores appearing around the world where users can download apps compiled under an Enterprise Developer certificate. Typically these apps would not pass Apple approval. How long Apple will continue to technically allow this is unknown and may move to a more controlled approach with Enterprise Developer accounts.

Additionally, a few solution providers do use Enterprise Developer to distribute apps to their clients, as we have done in the past. From a customer perspective, they can be a challenge especially if they don’t have an existing in-house developer team. This is due to the fact that the customer will need to sign up to the Enterprise Developer program to provide the supplier with the required certificates. Alternatively, they could accept the app compiled under the supplier’s account and distribute accordingly.

Moreover, when compiling the clienteling app, another certificate is added. This certificate only lasts for a given period of time, hence it is often necessary to track when the certificate will expire and obtain a fresh package even if the underlying app code hasn’t changed.

For those clients seeking a more secure app, using the Enterprise Developer program may not be the best approach. When submitting an app to Apple, a number of checks are made on the app to ensure it’s secure and safe to be distributed. This includes the prevention of using Apple APIs in a non-standard way or undocumented APIs which could cause security issues.

Applications compiled under Enterprise Developer do not go through this process, and it is on the client to ensure the app is safe and secure for use on their devices. It is of course unlikely when obtaining a white label app from a supplier under the Enterprise Developer program that access to the source code will be included. The risk is low when obtaining an app from a reliable source, so it does depend on the client’s security team for the true risk.

Apple Business Manager

As discussed above, one area that Enterprise Developer accounts are used for is to distribute B2B applications along with the potential security risk and certificate management which that brings. To address this risk, Apple revised an existing process of volume purchasing called Apple Business Manager.

The process is a variation of the existing processes to upload an app to the App Store. When the supplier is distributing an app, it is uploaded to Apple as per the normal App Store process. The change is, it will be marked as distribution via the private App Store. Apps will go through the identical security and review process as the public App Store, but will not appear on there when accepted.

Prior to formal submission to the private app store, the app build can be tested via Testflight from Apple. The client’s users download the Testflight app then install the app by invite to their own Apple ID. We have used this with one client and been very successful, due to the fact that users can provide feedback and screenshots via Testflight.

For distribution, the client will register and use Apple Business Manager to find and download the app to their MDM solution from the supplier page on Apple Store Connect. They can volume purchase as required, although this is not applicable for Proximity Insight since it’s free of charge.

The private element is applied that when a custom app is uploaded, the Apple ID of the client business can be added. This means the app will only be viewable to that Apple ID and allows the passing of branded apps or those containing custom code.

Additionally, the application still needs to pass Apple store verification to be proven as secure. It also avoids the certificate issues related to Enterprise Developer and the temporary adding of a developer to the client’s development team.

Personally, I have handled both the Enterprise Developer and Apple Business Manager approach for clients of Proximity Insight and the latter is definitely the easiest for ongoing support. This method also gives the client confidence that the clienteling app has been reviewed by Apple and is safe for deploying in their own environments.

Get in Touch

If you’re thinking of introducing Clienteling to increase customer engagement and insight to your brand, I recommend contacting us via the website, LinkedIn or hello@proximityinsight.com.

I hope this was of interest, and if there’s anything you would like to see covered in a future blog then get in touch. Thank you for taking the time to have a read.