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.
一个客户要求我们开发一个专有的内部应用程序来管理他们的后端系统。然而，我们是一家小型开发公司，我确信他们的公司没有>500名员工。
Are there any alternative, yet similar, solutions to distributing this app to their company without going through the iPhone enterprise program?
有没有其他类似的解决方案可以在不通过iPhone企业程序的情况下将这个应用程序分发给他们的公司?
(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).
(澄清一下:很明显，我们想通过官方的企业计划，但是看到公司没有>500员工，这是不可能的)。
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.
更新(27/09):看来苹果公司已经取消了500名员工的企业分布限制，请看这里。所以这可能是我们现在的路线(这很有帮助，因为应用程序即将完成)。如果有人愿意的话，我会在整个过程中更新它，这样其他人就会知道实际过程是什么样的。
10 个解决方案
#1
22
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.
您可以在AppStore上作为一个完全免费的应用程序提交应用程序，但是需要用户登录并进行身份验证才能使用它。这样任何人都可以下载，但你可以控制谁可以真正使用它。苹果为您提供所有的发行版，您不必担心临时部署或IT部门。
You then build a really simple configuration management system on a web host (or platform like Google AppEngine) that manages the authentication of apps.
然后，在管理应用程序身份验证的web主机(或谷歌AppEngine之类的平台)上构建一个非常简单的配置管理系统。
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.
当用户启动免费应用程序时，他们会被要求输入用户名/密码/等等。该信息被发送到基于web的配置管理系统并得到确认。如果应用程序从配置管理系统接收到可接受的确认，它就会解锁供该用户使用。
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.
如果您想控制谁可以使用这个应用程序，但又想要AppStore提供的易于部署的部署，那么这种分发风格非常有用。
Apple has accepted many apps onto the AppStore that use this method of authenticating against a remote server (Skype is a perfect example).
苹果公司已经在AppStore上接受了许多应用程序，这些应用程序使用这种对远程服务器进行身份验证的方法(Skype就是一个很好的例子)。
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.
如果在配置服务器上跟踪设备UDID，还可以预加载它，以允许一组设备工作。
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.
此外，我所描述的任何东西都不是iPhone特有的，所以你可以在其他平台上使用相同的配置管理系统和概念，比如Android(甚至是台式机)，如果你在将来发布应用程序或者构建其他应用程序。
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.
此外，由于验证设备的操作不是处理器或数据密集型的，所以如果您在谷歌AppEngine上构建它，您可能不会产生成本，因为您永远不会超过免费配额，您将获得谷歌后端体系结构的稳定性和可扩展性。
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.
由于这个特定的部署是用于管理通过AppStore部署的内部后端系统，因此看起来可能不安全，因为在应用程序中嵌入了专有信息，特别是允许它连接到后端系统并对其进行身份验证的信息。
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.
如果每次启动应用程序时都进行身份验证，您可以更改配置服务器上的连接信息，应用程序将更新到新的信息，而不需要任何新的部署。用户只需重新启动应用程序，这将使您的客户能够灵活地更改他们的内部网络配置，而不会使您的应用程序代码失效。您还可以在应用程序中手动配置这些信息，但是当在每个设备上设置应用程序时，会产生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.
为了进一步确保上面的解决方案，您可能希望配置管理系统是内部的，并且在公司的防火墙之后，这样无论谁获得了应用程序，他们都无法连接到配置系统，除非他们在公司的网络中。
#2
7
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.
我昨天和今天都在研究这个问题，似乎苹果(在过去的一周内)刚刚取消了>500员工对企业发展的要求。但是，我相信您需要使用客户注册的开发工具包为特定的客户端开发/部署。
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.
因此，如果你为客户A和客户B工作，客户A和客户B都需要作为业务开发人员与苹果签约，届时你可以为他们开发应用程序(作为承包商)，并使用他们的工具在他们的企业中构建和部署。我认为你的公司也应该注册成为一个商业开发人员。
Apple does still require you to have a Dun & Bradstreet DUNS number to sign up as a Business Developer.
苹果公司仍然要求你拥有一个Dun & Bradstreet DUNS号作为一个商业开发人员。
#3
1
About the only real choices you have are...
你唯一真正的选择是……
- Up to 100 devices as ad-hoc distribution.
- 多达100个设备作为特别分发。
- Enterprize distribution (requires > 500 employees)
- 企业分配(需要> 500人)
- Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!)
- 每个人都必须将他们的设备转移到it中心，然后作为“开发人员”设备构建。(呀! !)
- Jail-broken.
- 越狱”。
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.
让我们知道你的决定，以及该方法的利弊。
#4
1
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.
另一个明显的，虽然不是必要的令人愉快的方式是将你的应用作为一个应用程序提交给应用程序商店，但是只能通过客户端密码访问。假设你能通过aapp store流程，这可能对你有用。
#5
1
Olie said:
使用橄榄说:
About the only real choices you have are... Up to 100 devices as ad-hoc distribution. Enterprize distribution (requires > 500 employees) Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!) Jail-broken.
你唯一的选择是……多达100个设备作为特别分发。Enterprize distribution(需要> 500名员工)每个人都必须将他们的设备推广到IT-central，并将其构建为“开发人员”设备。(呀! !)越狱”。
But to be clear (correct me if I'm wrong):
但是要明确(如果我错了请纠正我):
- if you use the "Ad-hoc" distribution method, your costumers will see the app vanish after exactly 3 months.
- 如果您使用“特别”分发方法，您的客户将看到应用程序在3个月后消失。
- only up to 100 devices can be used for testing (i.e. used in "developer mode") and moreover, the app will vanish after 3 months.
- 只有100台设备可以用于测试(即在“开发者模式”中使用)，而且应用程序在3个月后就会消失。
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"
所以，苹果没有给我们任何选择，你真的大(>500员工)吗?这样你就可以做你想做的事了。“再见”
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)
iOS不适合企业应用....如果你不想依靠一些聪明的黑客(比如越狱)
#6
0
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
每个应用程序的Ad-hoc发行仅限于100台设备，这是事实，但是您可以将项目n次添加到apple developer center，因此您可以将其部署到n * 100台设备
#7
0
How does apple ensure that your enterprise has greater than 500 people? I'd give it a go through the enterprise program anyway...
苹果如何确保你的企业拥有超过500人?不管怎么说，我还是要去看看企业项目……
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.
我不会越狱，我不会做临时的因为它被限制在100，我不会让每个人都把他们的手机放在开发模式。
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.
对于未来的可维护性来说，企业模式是一种方法，所以请查看您是否能够在整个过程中导航，而无需提及您可能不是500个用户。
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.
我也看到了你关于MonoTouch开发的评论。在你做其他事情之前，我会先和苹果谈这件事，因为考虑到他们最近的政策变化，我很确定这将会让你的应用程序被应用程序商店和企业程序拒绝。
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.
编辑:我检查了Mono网页。看起来苹果可能还在允许mono应用程序进入，而mono的创建者坚称它是符合犹太律法的，但你可能会冒着将来的应用程序随时被从手机上取走的风险。
A better edit: Straight from the mono website: Enterprise MonoTouch
更好的编辑:直接从mono网站:企业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).
需要指出的是，新的iPhone开发人员协议术语是用于AppStore部署的，而不是允许将内部应用程序部署到企业中的用户(使用企业部署程序)的企业程序。
So you might be good there as long as you can get into the enterprise program.
所以只要你能进入企业项目，你可能就会做得很好。
#8
0
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
如果您将应用程序开发为纯粹的HTML5解决方案，您可以完全绕过应用程序商店或企业开发人员程序审批过程。这项技术被称为webapps。它们在功能上很先进。您将自动拥有跨平台准备和非常容易的部署选项(作为webclip，可以通过.mobileconfig配置文件进行分发)，请参见http://www.apple.com/webapps/whatarewebapps.html
#9
0
There is another solution: an own app store:
还有另一个解决方案:建立自己的应用商店:
http://rhomobile.com/products/rhogallery/
http://rhomobile.com/products/rhogallery/
unfortunately only in combination with RhoHub.
不幸的是，只有与RhoHub合并。
Or: http://www.appcentral.com/
或: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://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
#10
-1
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:
从理论上讲，提出的为一家公司发布免费应用程序的解决方案是无效的，因为在app store中发布的应用程序不应该是针对“有限的受众”(无论这意味着什么)，根据:
http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience
http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience
Has anyone tried this with success? Any other ideas?
有人尝试过吗?任何其他想法?
#1
22
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.
您可以在AppStore上作为一个完全免费的应用程序提交应用程序，但是需要用户登录并进行身份验证才能使用它。这样任何人都可以下载，但你可以控制谁可以真正使用它。苹果为您提供所有的发行版，您不必担心临时部署或IT部门。
You then build a really simple configuration management system on a web host (or platform like Google AppEngine) that manages the authentication of apps.
然后，在管理应用程序身份验证的web主机(或谷歌AppEngine之类的平台)上构建一个非常简单的配置管理系统。
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.
当用户启动免费应用程序时，他们会被要求输入用户名/密码/等等。该信息被发送到基于web的配置管理系统并得到确认。如果应用程序从配置管理系统接收到可接受的确认，它就会解锁供该用户使用。
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.
如果您想控制谁可以使用这个应用程序，但又想要AppStore提供的易于部署的部署，那么这种分发风格非常有用。
Apple has accepted many apps onto the AppStore that use this method of authenticating against a remote server (Skype is a perfect example).
苹果公司已经在AppStore上接受了许多应用程序，这些应用程序使用这种对远程服务器进行身份验证的方法(Skype就是一个很好的例子)。
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.
如果在配置服务器上跟踪设备UDID，还可以预加载它，以允许一组设备工作。
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.
此外，我所描述的任何东西都不是iPhone特有的，所以你可以在其他平台上使用相同的配置管理系统和概念，比如Android(甚至是台式机)，如果你在将来发布应用程序或者构建其他应用程序。
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.
此外，由于验证设备的操作不是处理器或数据密集型的，所以如果您在谷歌AppEngine上构建它，您可能不会产生成本，因为您永远不会超过免费配额，您将获得谷歌后端体系结构的稳定性和可扩展性。
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.
由于这个特定的部署是用于管理通过AppStore部署的内部后端系统，因此看起来可能不安全，因为在应用程序中嵌入了专有信息，特别是允许它连接到后端系统并对其进行身份验证的信息。
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.
如果每次启动应用程序时都进行身份验证，您可以更改配置服务器上的连接信息，应用程序将更新到新的信息，而不需要任何新的部署。用户只需重新启动应用程序，这将使您的客户能够灵活地更改他们的内部网络配置，而不会使您的应用程序代码失效。您还可以在应用程序中手动配置这些信息，但是当在每个设备上设置应用程序时，会产生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.
为了进一步确保上面的解决方案，您可能希望配置管理系统是内部的，并且在公司的防火墙之后，这样无论谁获得了应用程序，他们都无法连接到配置系统，除非他们在公司的网络中。
#2
7
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.
我昨天和今天都在研究这个问题，似乎苹果(在过去的一周内)刚刚取消了>500员工对企业发展的要求。但是，我相信您需要使用客户注册的开发工具包为特定的客户端开发/部署。
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.
因此，如果你为客户A和客户B工作，客户A和客户B都需要作为业务开发人员与苹果签约，届时你可以为他们开发应用程序(作为承包商)，并使用他们的工具在他们的企业中构建和部署。我认为你的公司也应该注册成为一个商业开发人员。
Apple does still require you to have a Dun & Bradstreet DUNS number to sign up as a Business Developer.
苹果公司仍然要求你拥有一个Dun & Bradstreet DUNS号作为一个商业开发人员。
#3
1
About the only real choices you have are...
你唯一真正的选择是……
- Up to 100 devices as ad-hoc distribution.
- 多达100个设备作为特别分发。
- Enterprize distribution (requires > 500 employees)
- 企业分配(需要> 500人)
- Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!)
- 每个人都必须将他们的设备转移到it中心，然后作为“开发人员”设备构建。(呀! !)
- Jail-broken.
- 越狱”。
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.
让我们知道你的决定，以及该方法的利弊。
#4
1
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.
另一个明显的，虽然不是必要的令人愉快的方式是将你的应用作为一个应用程序提交给应用程序商店，但是只能通过客户端密码访问。假设你能通过aapp store流程，这可能对你有用。
#5
1
Olie said:
使用橄榄说:
About the only real choices you have are... Up to 100 devices as ad-hoc distribution. Enterprize distribution (requires > 500 employees) Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!) Jail-broken.
你唯一的选择是……多达100个设备作为特别分发。Enterprize distribution(需要> 500名员工)每个人都必须将他们的设备推广到IT-central，并将其构建为“开发人员”设备。(呀! !)越狱”。
But to be clear (correct me if I'm wrong):
但是要明确(如果我错了请纠正我):
- if you use the "Ad-hoc" distribution method, your costumers will see the app vanish after exactly 3 months.
- 如果您使用“特别”分发方法，您的客户将看到应用程序在3个月后消失。
- only up to 100 devices can be used for testing (i.e. used in "developer mode") and moreover, the app will vanish after 3 months.
- 只有100台设备可以用于测试(即在“开发者模式”中使用)，而且应用程序在3个月后就会消失。
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"
所以，苹果没有给我们任何选择，你真的大(>500员工)吗?这样你就可以做你想做的事了。“再见”
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)
iOS不适合企业应用....如果你不想依靠一些聪明的黑客(比如越狱)
#6
0
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
每个应用程序的Ad-hoc发行仅限于100台设备，这是事实，但是您可以将项目n次添加到apple developer center，因此您可以将其部署到n * 100台设备
#7
0
How does apple ensure that your enterprise has greater than 500 people? I'd give it a go through the enterprise program anyway...
苹果如何确保你的企业拥有超过500人?不管怎么说，我还是要去看看企业项目……
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.
我不会越狱，我不会做临时的因为它被限制在100，我不会让每个人都把他们的手机放在开发模式。
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.
对于未来的可维护性来说，企业模式是一种方法，所以请查看您是否能够在整个过程中导航，而无需提及您可能不是500个用户。
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.
我也看到了你关于MonoTouch开发的评论。在你做其他事情之前，我会先和苹果谈这件事，因为考虑到他们最近的政策变化，我很确定这将会让你的应用程序被应用程序商店和企业程序拒绝。
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.
编辑:我检查了Mono网页。看起来苹果可能还在允许mono应用程序进入，而mono的创建者坚称它是符合犹太律法的，但你可能会冒着将来的应用程序随时被从手机上取走的风险。
A better edit: Straight from the mono website: Enterprise MonoTouch
更好的编辑:直接从mono网站:企业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).
需要指出的是，新的iPhone开发人员协议术语是用于AppStore部署的，而不是允许将内部应用程序部署到企业中的用户(使用企业部署程序)的企业程序。
So you might be good there as long as you can get into the enterprise program.
所以只要你能进入企业项目，你可能就会做得很好。
#8
0
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
如果您将应用程序开发为纯粹的HTML5解决方案，您可以完全绕过应用程序商店或企业开发人员程序审批过程。这项技术被称为webapps。它们在功能上很先进。您将自动拥有跨平台准备和非常容易的部署选项(作为webclip，可以通过.mobileconfig配置文件进行分发)，请参见http://www.apple.com/webapps/whatarewebapps.html
#9
0
There is another solution: an own app store:
还有另一个解决方案:建立自己的应用商店:
http://rhomobile.com/products/rhogallery/
http://rhomobile.com/products/rhogallery/
unfortunately only in combination with RhoHub.
不幸的是，只有与RhoHub合并。
Or: http://www.appcentral.com/
或: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://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
#10
-1
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:
从理论上讲，提出的为一家公司发布免费应用程序的解决方案是无效的，因为在app store中发布的应用程序不应该是针对“有限的受众”(无论这意味着什么)，根据:
http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience
http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience
Has anyone tried this with success? Any other ideas?
有人尝试过吗?任何其他想法?