I've been struggling to find an approach to a problem I have with registering an iOS based application with Apple. I have an idea for a an iOS application that would require from Apple that the organization to be a registered 501c3.
What I want to do is develop the application under my personal developer account (I have apps in the store already through an LLC I have) to be able to test and prototype the idea fully with beta users via Test Flight and then if that shows promise go through the nightmare that is registering for a 501c3 entity with the IRS. This process can take a long time from what I've read and is very complex and also there are significant costs involved (probably requires hiring an attorney/accountant to wade through all the paperwork). So the bottom line is I really don't want to go down the road of setting up a corporation, registering for non-profit status, yada yada if my app just isn't what it appears to be in my head when users have it in their hands. I want to vet all the systems (which includes a fairly large backend admin web based application) prior to setting up the charitable organization. In case anyone wants to know the app is going to accept donations via Apple Pay as a part of the application which Apple requires that you're a registered 501c3 otherwise I wouldn't go down this road at all.
I read the policies on transfer of apps, and contractor scenarios in the Apple Enrollment documentation but it doesn't really answer my questions about registering an App ID under one company (my personal account/LLC) but deploying the app under another entity after being fully tested. FYI this isn't a contractor relationship as both organizations will be my own. Also transferring seems to require that the App already be on the store as well as has severe limits to its entitlements (e.g. you can't use iCloud entitlements which my app will use) neither of which would work in my case.
Anyway - to recap I want to develop and beta test with users in Test Flight using my developer account and only after it's vetted put the App into the approval process after I get my 501c3 setup and registered so Apple can approve it's ability to accept donations via Apple Pay. My concerns are mostly around technical issues related to this and/or how Xcode and entitlements/certifications/provisioning may cause issues. e.g. if I develop and then register the application name in my personal account I'm under the impression this is globally unique so my 501c3 wouldn't be able to register that same name?
Thanks for any help!
Related
Just to give you a little background, we have a software application which anyone can access through web. It is a very specific application for banking and retail industry. Currently this application is accessible on web as well as on "Windows tablet kiosk" and we have license based pricing. Windows tablets access the data through web services.
So for example, XYZ Bank can order 100 windows tablet licenses and we can charge them for the application based on our pricing model for 100 license.
We are getting lot of requests from our clients to develop the same app on iPad and we are currently researching on deployment options for the same. As per my understanding, Apple has very stringent rules when it comes to App download.
In above scenario, where organization needs a licence from us to run the application what kind of deployment strategy we should go with? I can think of 2 options:
1) To deploy the app on iTunes stores and ask the organization to download it from the iTunes store. They will have to contact us to get the license in order to run the App. Is it legal? Since we have license based pricing model, we'll keep our App for free and will charge organization for license.
2) Should we just get enterprise license for our clients/organization and deploy the system on their iPad under that enterprise license.
According to me option # 1 is the way to go. But I just want to know if this is OK to distribute the App for free and than charge for licenses? In any case this is more of a web app and iPhone is just an extension.
Option #1 is only ok in a special case, when you have a general subscription model for your service outside the App Store/IAP process, like Spotify does, for example. There's a special paragraph in the App Store guidelines for that, 11.14. But if your customers pay a one-time fee just to use the iPad app, I think Apple would consider this as circumventing the App Store payment model and would reject your app because of rule 11.1 of the guidelines.
But Apple just set up a new distribution model for cases like yours, the "Custom B2B apps". It's a way to distribute custom apps for specific customers through the App Store, without the need for Enterprise Licenses for each customer. See
http://www.apple.com/business/vpp/
Only customers that you have approved before will be able to see their custom app in the App Store. Payment goes through Apple and they keep 30% as usual. This program is US-only now but will be rolled out to Australia, Canada, France, Germany, Italy, Japan, New Zealand, Spain, and UK soon.
If you don't want to give the 30% away, your only option is indeed #2, building the app with an Enterprise License of your client. The only real downside I see is that you have to get each client to enroll in the developer program and renew it every year. If you have many clients, that could become a problem.
But once they've set you up as an agent or admin, the process is smooth. E.g. you can use a MDM service for OTA updates to your client's devices and they can set up an inhouse app store, so their user experience is almost the same as when using Apple's app store.
I've just decided to go with option #2 for an enterprise project for 3-5 clients. I would say that if you have more than about 10 clients, the extra work with all the different certificates, distribution methods etc. wouldn't be worth it and I'd rather pay Apple 30% to handle that and go with the Custom B2B program (if it's available in your country).
Option 1 is more preferable.
You can have a free app on the app store.
After that you can have a option for licensing. and from coding you can maintain that in order to use the app they needs to purchase the license.
Lots of app does that as they have their signup based on the Device ID.
I have worked with some of the apps who uses to give their services like SIP Calling with licensing like that.
so with option 1 you can achieve it.
thanks
The app that I am trying to submit is for a field sales system that is already running on Android devices, and which we are now trying to make available to Apple users. It is a cloud based application, and users synchronize data stored on their devices with data stored on a web server. The application is sold to companies rather than individuals. Each company has many users, all of whom synchronize with the same database on the server.
We maintain our own web server and provide a hosting service, and companies can also host their own servers:
For the hosting service, companies pay a monthly or annual fee, which depends on the number of users they have.
For companies that prefer to host their own servers, the app is licensed by device. Companies pay registration and upgrade fees for each device, and each user has to enter a registration key.
I understand that we are not allowed to mention the Android platform anywhere in our app. I also understand that we have to allow all subscriptions, registrations and upgrades to be paid through in-app purchases. But I have a number of questions:
I am happy for us to offer only a limited service to Apple customers, if it makes it easier for the app to be accepted. Would Apple be happy with this arrangement?
Most companies prefer to have just one administrator for their whole system, and to have him make all the purchasing arrangements. Is Apple OK with this?
Is it possible to make multiple in-app purchases of a single product (e.g. purchase 50 licenses)?
Is the use of registration keys an issue?
1) I think that as long as your clients are aware that the iOS flavour of your app/service was limited in some manner (tell them the rest is work in progress) then I cannot foresee any issue with this. You may still consider ringing Apple Developer Support and run it past them, but your chances of getting a non-vague answer from them directly are still high - they'll probably say it depends on the reviewer when you go to submit the app.
2) Sounds fine, and not uncommon in the enterprise app world. See 3) for more details.
3) You can utilise the VPP (Volume Purchase Program) to achieve this, but it's only available in the US at time of writing. See the link below for further information:
http://www.apple.com/business/vpp/
I think that another way you could consider app distribution and which would let you bypass Apple (to a degree) is to sign up for an enterprise developers' account. This will let you build the usual development & distribution builds of your app, but a distribution build can take two forms: limited to devices by their UDID (100 limit still in effect) or not at all. If the latter, you could self-host the generated .ipa app file, which is perfectly viable.
4) Registration keys for the app? (to unlock "premium" content or as the method of app activation?)
Hope this was of some help, best of luck!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I work for a company that would like to create an app that we can distribute to our customers. We manufacture industrial equipment and we would like to provide an iPhone/iPad app to our customers that can interact with their equipment.
The problem is that we would prefer that the app not be downloaded from the App Store. We would like for this application to be available for our customers free-of-charge and would also like for them to have the ability to download and install the application on as many devices as they desire. However, we do not want non-customers (ahem, competitors) to be able to download and use our application.
What options are available? We have considered allowing the app to be available through the app store but in that case the app would be locked until the user entered an application key. This would keep the app free to download and it would give us the ability to control who could use our software. I'm not sure, however, if that is allowable by the Apple TOS.
The Enterprise license sounds like a potential option. If it is, what are the specific steps necessary for installing an iOS app on an Apple device if not through the App Store? I'm also not sure if it would break the TOS to distribute our app for this purpose under the Enterprise license. Is that the case?
What options do I have? Please realize, I don't own a Mac and I've never even attempted to write or distribute an iOS application-- I'm 100% new to all of this. Thanks for you help.
EDIT
Thank you all for the wonderful responses that I have so far received. Half of the questions that I have stem from the fact that I can't find the actual TOS agreement that I would have to sign if I became a standard or enterprise developer. (Yes, I've googled it.) Does anyone have a link to such documents?
If you want to distribute your app outside the App Store, you need to get an iOS Developer Entreprise license ($299/year). You're going to need a Dun & Bradstreet (D-U-N-S) number to enroll and can only deploy to 500 (registered) devices.
Edit: Another option would be to demand the user some authentication (such as user/pass) to use the app (think Facebook or Twitter). You could provide your clients with the credentials to ensure only a certain users have access to the app.
I think #ibeitia's answer is the best one, but here's an additional option: put the app on the app store, but make it all-but-useless without a login to your server.
For example, the Google+ app is useless unless you have a Google account.
You'd have to give a login to Apple so they can vet it, and of course I can't guarantee they'll allow it, but it's an option I'd consider.
(If you do go down that route, send an email to Apple's approval team asking for clarification before you start development!)
I work for a company that would like to create an app that we can
distribute to our customers.
From http://developer.apple.com/support/ios/enterprise.html (bold is mine)
I am a developer who wants to create an in house app for my client.
Can I join the iOS Developer Enterprise Program to do that?
The iOS Developer Enterprise Program should be used to develop and
distribute proprietary in-house applications to your own employees
within your own company. As such, your company would not qualify for
direct Program enrollment in this situation. We would suggest that
your client apply for enrollment in the Program, and, once enrolled in
the Program, your client may add the appropriate developers from your
company to their iOS Development Team.
The Enterprise Developer program doesn't allow you to sell your app to your customers. It's the customer, not you, who should enroll in the program.
I think your best bet will be to use Apple's B 2 B program:
http://www.apple.com/business/vpp/
This will allow you to have apps in Apple's business app store (not the ordinary app store), and control who gets the apps. You'd provide the redemption codes to your customers.
btw, I can confirm that providing an app with a login to make it useful would be okay with Apple - I've done it before.
Well your options are really limited.
You could go with the enterprise license but this is still limited to 500 device which still need to be register with the some how. (never had to work with the enterprise license).
But could you not make your app available in the appstore foor free but only make it work with you equipment. Thus make the app search for the equipment (via bonjour of wifi) and only work when it finds the device. This will make getting the accepted a bit harder but will work. There are some IP camera manager that work that way.
If your competitors really want your app they will get it one way or an other.
Just be sure you release an app before the competitors, do that way your company has the advantage.
I'm going to develop an iPhone app, and want to make sure what I want to do is possible, and will be approved by Apple.
I'm going to create an app that will be fully branded on per submission basis. I want to have one app per customer (our customers are companies) with their logo, skin, etc.
This apps will be downloaded and installed by the employees of each one of our customers.
In other words, we would use the same base code (logic doesn't change), but will brand it for each customer. Something similar to what Magento (http://www.magentocommerce.com/product/mobile) does, they created an Ecommerce mobile app, and they brand it to their customer, but the app logic remains the same.
Would Apple consider this as duplicate apps? what is the best way to do it?
Thanks in advance.
I would have said "no problem" until I read:
This apps will be downloaded and
installed by the employees of each one
of our customers
It sounds like what your creating is (a set of) private applications, which are intended to be targeted only to specific users - i.e. employees of the company.
Apple has a separate "enterprise" development program geared towards this - allowing developers to deploy programs for their own company - and do it outside of the App Store.
If your program is very specific towards the companies, Apple may make you do this - rather than putting the Apps up for general consumption on the App store.
See here for more details:
http://developer.apple.com/programs/ios/enterprise/
Also:
If your application is really intended for a wider audience, and your could in-fact sell/distribute it a such - you could "skin" the app dynamically. For example, on first-time launch, when you "register" with some "service" - based upon your email address it could download the appropriate skinning graphics.
I can say I know of several companies built on this strategy. The code doesn't change one iota from app to app, only images and names change and they continue to bring in revenue.
EDIT: Note this is against apple policy and if they find out they have been known to ban accounts. They consider it spamming and prefer that you sell one app that provides in app purchases. Directly from their feedback on a particular group of app submissions:
Thank you for submitting your
Photography apps to the App Store.
We've completed the review of your
apps, however, we are unable to post
them to the App Store because they
provide the same feature set and
simply vary the content. Apps that
replicate functionality with different
content create clutter in the App
Store, hindering users' ability to
find apps, and do not comply with the
App Store Review Guidelines
https://developer.apple.com/appstore/resources/approval/guidelines.html:
2.20 Developers 'spamming' the App Store with many versions of
similar apps will be removed from the
iOS Developer Program
You can now use Apple's Volume Purchase Program to release differently branded versions of the same app to different customers. The app can be free or paid. Each customer must have a DUNS number (Dun & Bradstreet). See the FAQ for details.
We are developing an enterprise application and I looked at the following options:
1. Putting on itunes.
Cannot do this since our application is to be used only by our clients with a login and passwrod.
You cannot have login based app in itunes:
http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience
2. Using iOS Developer Enterprise
Cannot do this as :
The iOS Developer Enterprise Program should be used to develop and distribute proprietary in-house applications to your own employees within your own company. As such, your company would not qualify for direct Program enrollment in this situation. We would suggest that your client apply for enrollment in the Program, and, once enrolled in the Program, your client may add the appropriate developers from your company to their iOS Development Team.
Our client cannot add us.
3. Adhoc distribution.
This is only for 100 beta testers.
So are there any other options if I want our client to donwload our app.
Provide some minimal functionality to all users that does not require any proprietary data, but have the app download all proprietary data and enable proprietary features only after your enterprise customer logs in. Then submit it to the App store.
There are plenty of examples in the app store. Banking apps: they might advertise the bank, have maps to the nearest branch, perhaps include a calculator of some sort, but of course don't allow any actual banking features or download any account information until after a customer logs in. Security apps: provide a public weather web cam view to everybody, but a security cam view only to people who buy their expensive $100K security camera system.
The example private golf course app could have included public information on the club, the current weather, map info on local restaurants, and maybe who to contact to apply for the $10M membership, but then added private club info (calendar, roster) only to paid members after log in.
Make sure to create a test account with dummy (non-proprietary) data and give it to Apple.
You can absolutely have a login based app. I have helped someone submit one that got approved that sounds very similar to the one you are describing. Also, think about the Netflix app for example, login based, limited to Netflix users (although this is probably not as limited as you are talking about).
Your solution is clearly "Using iOS Developer Enterprise"...
Can you be more explicit about the "Our client cannot add us." ?
You can get your client to sign up to the iOS enterprise agreement so that they can install it on their phones, and you are simply a team member for them. That also shifts the liability for the app onto them, should anything go wrong.