内部 iPhone 企业应用程序分发的替代解决方案
客户要求我们开发一个专有的内部应用程序来管理他们的后端系统。然而，我们是一家小型开发公司，我确信他们公司的员工人数不会超过 500 人。
是否有任何替代但类似的解决方案可以在不通过 iPhone 企业计划的情况下将此应用程序分发给他们的公司？
（只是澄清一下：显然，我们希望通过官方企业计划，但看到该公司没有超过 500 名员工，这是不可能的）。
更新 (27/09)： Apple 似乎已取消企业发行版 500 名员工的限制 参见此处。所以这可能就是我们现在的路线（这很有帮助，因为应用程序即将完成）。如果有人愿意的话，我会在我们完成整个过程时更新此内容，以便其他人可以了解实际的过程是什么样的。
A client has asked us to develop a proprietary in-house app for managing their back-end systems. However, we are a small development company and I'm certain that their company does not have >500 employees.
Are there any alternative, yet similar, solutions to distributing this app to their company without going through the iPhone enterprise program?
(just to clarify: obviously, we would like to go through the official enterprise program but seeing how the company doesn't have >500 employees, this isn't possible).
UPDATE (27/09): It appears Apple have removed the 500 employee limit for the enterprise distribution See here. So this will probably be our route now (which is helpful because the app is approaching completion). I'll update this as we go through the process if anyone would like me to, so that others may get an idea of what the actual process is like.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
您可以将应用程序作为完全免费的应用程序提交到 AppStore，但要求用户登录并进行身份验证才能使用它。这样任何人都可以下载它，但您可以控制谁可以实际使用它。 Apple 会为您完成所有分发工作，您无需担心临时部署或 IT 部门。
然后，您可以在 Web 主机（或 Google AppEngine 等平台）上构建一个非常简单的配置管理系统，用于管理应用程序的身份验证。
当用户启动免费应用程序时，系统会要求他们输入用户名/密码/其他内容。该信息被发送到基于网络的配置管理系统并得到确认。如果应用程序从配置管理系统收到可接受的确认，它将自行解锁以供该用户使用。
该应用程序可以在每次启动时重新进行身份验证（如果您需要大量控制，这很有用），或者它可以在本地存储一个密钥文件，表明它已经过身份验证。如果应用程序启动时看到本地密钥文件，它会认为自己已通过身份验证，并且不再检查。
您是为每人使用一个用户帐户还是为整个公司使用一个用户帐户取决于您。
如果您想要控制谁可以使用该应用程序，但又希望获得 AppStore 提供的轻松部署功能，那么这种分发方式非常有用。
Apple 已在 AppStore 上接受了许多使用这种远程服务器身份验证方法的应用程序（Skype 就是一个完美的例子）。
如果您在配置服务器上跟踪设备 UDID，您还可以预加载它以允许特定的设备集工作。
此外，我所描述的内容都不是特定于 iPhone 的，因此如果您将来需要移植该应用程序或构建其他需要此功能的应用程序，您可以在 Android（甚至桌面）等其他平台上使用相同的配置管理系统和概念。
此外，由于验证设备的操作不是处理器或数据密集型，如果您在 Google AppEngine 上构建此操作，您可能永远不会产生成本，因为您永远不会超过免费配额，并且您将获得 Google 后端架构的稳定性和可扩展性。
由于此特定部署用于管理内部后端系统，因此通过 AppStore 部署它似乎不安全，因为应用程序中嵌入了专有信息，特别是允许其连接到后端并对其进行身份验证的信息系统。
解决方案是不在应用程序中包含此信息，而只是让该信息成为应用程序从配置管理服务器接收到的响应的一部分。基本上，该应用程序包含执行其功能所需的逻辑，但如果没有连接信息，它就无法管理任何后端系统。
如果您让应用程序每次启动时都进行身份验证，则可以更改配置服务器上的连接信息，并且应用程序将更新为新信息，而无需进行任何新部署。用户只需重新启动应用程序即可。这使您的客户可以灵活地更改其内部网络配置，而无需使您的应用程序代码无效。您还可以在应用程序中手动配置此信息，但是在每个设备上设置应用程序时您会产生 IT 成本，如果您已经打算设置配置管理系统，那么您不妨使用它。
为了进一步保护上述解决方案，您可能希望配置管理系统位于公司内部并位于公司防火墙后面，这样无论谁拥有该应用程序，他们都无法连接到配置系统，除非他们位于公司网络内。
You can submit the app as a completely free app on the AppStore but require that the user log in and authenticate to use it. That way anyone can download it but you control who can actually use it. Apple does all the distribution for you for and you don't have to worry about Ad-Hoc deployments or IT departments.
You then build a really simple configuration management system on a web host (or platform like Google AppEngine) that manages the authentication of apps.
When a user launches the free app they are asked for a username/password/whatever. That information is sent to the web-based configuration management system and confirmed. If the app receives an acceptable confirmation from the configuration management system it unlocks itself for use by that user.
The app can either re-authenticate every time it launches (useful if you want lots of control) or it can store a key file locally indicating that it has been authenticated. If it sees the local key file when the app launches it considers itself authenticated and never checks again.
Whether you use one user account per person or one for the whole company is up to you.
This style of distribution is very useful if you want to have control of who can use the app but want the ease of deployment that the AppStore provides.
Apple has accepted many apps onto the AppStore that use this method of authenticating against a remote server (Skype is a perfect example).
If you keep track of device UDID on the configuration server you can also pre-load it to allow a certain set of devices to work.
Further, nothing I have described is iPhone specific so you can use the same configuration management system and concepts on other platforms like Android (or even desktops) if you ever port the app or build other apps needing this in the future.
Also, since the action of authenticating devices is not processor or data intensive you will likely never incur a cost if you build this on Google AppEngine as you will never go over the free quotas and you will gain the stability and scalability of Google's backend architecture.
As this particular deployment is for managing an in-house back-end system deploying it through the AppStore can seem insecure because there is proprietary information embedded in the app, in particular the information that allows it to connect to and authenticate against the back-end systems.
The solution to that is to not include this information within the app and simply have that information be part of the response that the app receives from the configuration management server. Basically the app contains the logic necessary to perform its function but without the connection information it has no ability to manage any back-end system.
If you make the app authenticate every time it launches you can change the connection information on the configuration server and the app will update to the new information without any new deployment being necessary. The user just needs to restart the app. This gives your client the flexibility to change their internal network configuration without invalidating your application code. You could also make this information manually configurable within the application but then you incur an IT cost when setting up the application on each device and if you already are going to set up a configuration management system you might as well use it.
To further secure the above solution you may want to have the configuration management system be in-house and behind the company's firewall so that regardless of who gets a hold of the app they cannot connect to the config system unless they are within the company's network.
我昨天和今天都在研究这个问题，看来苹果刚刚（在过去一周内）取消了企业发展的> 500 名员工的要求。但是，我相信您需要使用客户注册的开发工具包为特定客户进行开发/部署。
因此，如果您为客户 A 和客户 B 工作，则客户 A 和 B 都需要以业务开发人员身份与 Apple 签约，此时您可以为他们（作为承包商）开发应用程序并使用他们的工具来构建和部署他们的企业内部。我认为贵公司也注册为业务开发商是个好主意。
Apple 仍然要求您拥有 Dun & 认证。 Bradstreet DUNS 号码用于注册成为业务开发人员。
I was researching this yesterday and today, and it appears that Apple has just (within the past week) removed the >500 employee requirement for enterprise development. However, I believe you will need to develop/deploy for a particular client using a development toolkit registered by the client.
So if you do work for client A and client B, both client A and B will need to sign up with Apple as business developers, at which point you can develop apps for them (as a contractor) and use their tools to build and deploy within their enterprises. I would think it would be a good idea for your company to also be registered as a business developer.
Apple does still require you to have a Dun & Bradstreet DUNS number to sign up as a Business Developer.
您唯一真正的选择是...
越狱可能听起来很可怕，但现在它实际上相当先进，并且可以很容易地管理。尽管如此，它仍然使你的保修无效（除非你愿意恢复出厂并且对此不诚实；）
不过，从技术上讲，它是一个可用的选项，并且可以使其工作，如果你愿意计划的话出去。
让我们知道您的决定以及优点和优点。该方法的缺点。
About the only real choices you have are...
Jail-broken may sound scary, but it's actually pretty advanced, now-a-days, and can be managed quite easily. Still, it voids your warrantee (unless you're willing to restore-to-factory and be not-honest about it ;)
Still, technically, it's an available option and can be made to work, if you're willing to plan it out.
Let us know what you decide, and the pros & cons of that method.
另一个明显但不一定令人愉快的方法是将您的应用程序作为应用程序提交到应用程序商店，但只能使用客户端密码进行访问。假设您可以通过应用程序商店流程，这可能对您有用。
Another obvious although not neccesarily pleasant is to submit your app to the app store as an app but can only be accessed with a client password. Assuming you can get past the aapp store process this might work for you.
奥利说：
但需要明确的是（如果我错了，请纠正我）：
所以，苹果不给我们任何选择，你真的很大吗（>500名员工）？好吧，这样你就可以做你想做的事，否则......“再见”
此外，忘记“布莱斯”之前所说的话，像他所描述的那样的应用程序将因“有限的受众”动机而被拒绝。
iOS 不适用于企业应用程序...如果您不想依赖一些聪明的黑客（即越狱）
Olie said:
But to be clear (correct me if I'm wrong):
So, Apple doesn't give us any choice, are you really big (>500 employes)?? ok so you can do what you want etc otherwise... "byebye"
Moreover, forget about what "Bryce" said before, an app like the one he described would be rejected with the "limeted audience" motivation.
iOS is not for enterprise app....if you don't want to rely on some clever hackers (i.e. jailbreak)
Ad-hoc 分发仅限于每个应用程序 100 台设备，这是事实，但是您可以将项目 n 次添加到苹果开发人员中心，因此您可以将其部署到 n * 100 台设备
Ad-hoc distribution is limited to 100 devices per app, that's true, but you can add the project n times to the apple developer center, so you can deploy it to n * 100 devices
苹果如何确保您的企业拥有超过 500 人的员工？无论如何，我都会尝试一下企业计划...
我不会越狱，我不会做特别的，因为它仅限于 100 个，而且我不会让每个人都将手机置于开发者模式。
对于未来的可维护性，企业模式是最佳选择，因此请看看您是否可以在整个过程中导航，而无需提及您可能还没有 500 个用户。
另外，我看到了您关于使用 MonoTouch 进行开发的评论。在你做任何其他事情之前，我会和苹果讨论这个问题，因为考虑到他们最近的政策变化，我很确定这会让你的应用程序被 App Store 和 Enterprise 计划拒绝。
编辑：我检查了 Mono 网页。看起来苹果可能仍然允许 Mono 应用程序进入，并且 Mono 的创建者坚持认为它是犹太洁食，但你可能随时面临着未来的应用程序从手机中撤下的风险。
更好的编辑：直接来自 mono 网站：Enterprise MonoTouch
需要指出的是，新的 iPhone 开发者协议条款适用于 AppStore 部署，而不是允许向企业中的用户部署内部应用程序的企业计划（使用企业部署计划）。
因此，只要您能进入企业计划，您就可能会很好。
How does apple ensure that your enterprise has greater than 500 people? I'd give it a go through the enterprise program anyway...
I would not jailbreak, I would not do ad-hoc because it is limited to 100, and I wouldn't make everyone put their phones in developer mode.
For future maintainability, enterprise mode is the way to go, so see if you can navigate your way through the process without mentioning that you might not be quite 500 users.
Also, I saw your comment about developing using MonoTouch. I would talk to Apple about this before you do anything else, because given their recent policy changes I am pretty sure this will get your app denied from the App Store and the Enterprise program.
Edit: I checked the Mono web page. It seems like Apple may still be letting mono apps in, and the Mono creators insist that it is kosher, but you might be running the risk of having your future app pulled from phones at any time.
A better edit: Straight from the mono website: Enterprise MonoTouch
It is important to point out that the new iPhone Developer Agreement terms are for AppStore deployment and not the Enterprise program that allows deployment of in-house application to users in the enterprise (using the Enterprise Deployment program).
So you might be good there as long as you can get into the enterprise program.
如果您将应用程序开发为纯 HTML5 解决方案，则可以完全绕过应用程序商店或企业开发人员计划审批流程。
这项技术称为网络应用程序。而且它们的功能非常先进。您将自动具备跨平台准备和非常简单的部署选项（作为 webclip，可以通过 .mobileconfig 配置文件进行分发）
请参阅 http://www.apple.com/webapps/whatarewebapps.html
You can completely bypass the App-Store or Enterprise Developer Program approval process, if you develop your app as pure HTML5 solution.
This technology is called webapps. And they can be pretty advanced in functionality. You automatically have cross platform readiness and very easy deployment options (as webclip this can be distributed via .mobileconfig configuration files)
See http://www.apple.com/webapps/whatarewebapps.html
还有另一种解决方案：自己的应用程序商店：
http://rhomobile.com/products/rhogallery/
不幸的是只能与 RhoHub 结合使用。
或者：
http://www.appcentral.com/
更多信息：
http://www.apple.com/iphone/business/integration/mdm/
http://www.cio.com/article/638175/Emerging_Tech_Alternatives_to_Apple_App_Store_For_Enterprises?page=2&taxonomyId=3002
There is another solution: an own app store:
http://rhomobile.com/products/rhogallery/
unfortunately only in combination with RhoHub.
Or:
http://www.appcentral.com/
More info:
http://www.apple.com/iphone/business/integration/mdm/
http://www.cio.com/article/638175/Emerging_Tech_Alternatives_to_Apple_App_Store_For_Enterprises?page=2&taxonomyId=3002
理论上，针对一家公司发布免费应用程序的提议解决方案是无效的，因为应用程序商店中发布的应用程序不应面向“有限受众”（无论这意味着什么），根据：
http://appreview.tumblr.com/post/952395621/cannot-be -intended-for-a-limited-audience
有人尝试过成功吗？还有其他想法吗？
In theory the proposed solution of publishing a free app meant for one company is not valid, since published apps in the app store should not be intended for a "limited audience" (whatever that means), according to:
http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience
Has anyone tried this with success? Any other ideas?