3 ms·

It's covered after the first paragraph of the article. There are lots of apps that could be published as public apps, but you don't want to add confusion to reg

It's covered after the first paragraph of the article. There are lots of apps that could be published as public apps, but you don't want to add confusion to regular users. If Acme publish apps to the store for the public, they may not want their expenses app for employees to be listed alongside the apps. There are also very specialist apps that require sign-ins or accounts that aren't available to the public. You might have a messaging app for end users, but have an eDiscovery app that's only available for a few enterprise customers that relies on some access that regular user accounts don't have.

krono 5y ago
Your explanation is much appreciated, thanks. What's not yet clear to me, though, is why you'd choose to distribute these non-public applications through the appstore in the first place, rather than just make them available as direct downloads and have them "sideloaded".
- zerkten 5y ago
  >> What's not yet clear to me, though, is why you'd choose to distribute these non-public applications through the appstore in the first place, rather than just make them available as direct downloads and have them "sideloaded". For most situations where you want to do this, you want the apps to download and update like any other app. At the point of distribution, you want to have some differentiation as described in my original post. As soon as the user initiates app installation, you want the App Store to do the heavy lifting for you. There is no benefit to side loading an application in many cases because you have to then have users repeat those steps again and again. With this mechanism, it's a standard App Store app so you can also deploy it via MDM or other management mechanism. I completely understand why lack of side loading is an impediment to freedom and using a device how you wish. The challenge is that there is real value for many to Apple's tools and mechanisms when they are more composable. They are likely to offer up things like this as the pressure mounts to offer real sideloading.

krono 5y ago

Your explanation is much appreciated, thanks. What's not yet clear to me, though, is why you'd choose to distribute these non-public applications through the appstore in the first place, rather than just make them available as direct downloads and have them "sideloaded".

zerkten 5y ago
>> What's not yet clear to me, though, is why you'd choose to distribute these non-public applications through the appstore in the first place, rather than just make them available as direct downloads and have them "sideloaded". For most situations where you want to do this, you want the apps to download and update like any other app. At the point of distribution, you want to have some differentiation as described in my original post. As soon as the user initiates app installation, you want the App Store to do the heavy lifting for you. There is no benefit to side loading an application in many cases because you have to then have users repeat those steps again and again. With this mechanism, it's a standard App Store app so you can also deploy it via MDM or other management mechanism. I completely understand why lack of side loading is an impediment to freedom and using a device how you wish. The challenge is that there is real value for many to Apple's tools and mechanisms when they are more composable. They are likely to offer up things like this as the pressure mounts to offer real sideloading.