Does anyone know if there is an alternative to the developer enterprise option for app development?
We are considering developing an app but I don't am not sure if would get approved via the App Store because the reach may not be large enough?
The app would show various data that we collect for our customers, therefore it is only really relevant to our existing customers
Would apple allow such an app on the App Store?
I don't think the enterprise package would be applicable because that appears to be targeted for people in our organisation we want to be able to distribute apps to our customers
I don't see anything in what you described that would violate the App Store Review Guidelines (Login required).
Also, for Apple to reject an app because it was only useful to a particular company's customers would go against the precedent they've set by accepting apps for banks, credit cards, brokerage accounts, Netflix, Carbonite, etc.
So would Apple reject you on that basis? Almost certainly not, but really the only way to be absolutely sure is to submit the app and find out.
Here are a few of the guidelines about functionality that may or may not apply to you here, in case you cannot access the full list:
2.12 Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may
be rejected
2.13 Apps that are primarily marketing materials or advertisements will be rejected
2.22 Apps that arbitrarily restrict which users may use the App, such as by location or carrier, may be rejected
From what I understand, none of these apply to your situation.
Related
Many companies rely on white labeled apps to provide their services in a more personal way to their customers.
With a few adjustments we can set a logo and a splash screen and even pre-configure our app to our customer needs which has a great impact in their end user experience. Without this my users would need to use the app skipping a lot of configuration steps that in a generic app wouldn't be possible to skip.
According to apple: "Apps created from a commercialized template or app generation service will be rejected"
Now what can we do to to work around this?
Today I saw 4 apps being rejected and others are waiting for revision and I can anticipate that they will have the same ending.
Here's the revision result:
"4. 3 Design: Spam"
Guideline 4.3 - Design
We noticed that your app provides the same feature set as many of the
other apps you've submitted to the App Store; it simply varies in
content or language, which is considered a form of spam.
The next submission of this app may require a longer review time.
Next Steps
When creating multiple apps where content is the only varying element,
you should offer a single app to deliver differing content to
customers. Alternatively, you may consider creating a web app, which
looks and behaves similar to a native app when the customer adds it to
their Home screen. Refer to the Configuring Web Applications section
of the Safari Web Content Guide for more information.
Review the Design section of the App Store Review Guidelines.
Ensure your app is compliant with all sections of the App Store Review Guidelines and the Terms & Conditions of the Apple Developer
Program.
Once your app is fully compliant, resubmit your app for review.
Submitting apps designed to mislead or harm customers or evade the
review process may result in the termination of your Apple Developer
Program account. Review the Terms & Conditions of the Apple Developer
Program to learn more about our policies regarding termination.
If you believe your app is compliant with the App Store Review
Guidelines, you may submit an appeal. Alternatively, you may provide
additional details about your app by replying directly to this
message.
For app design information, check out the following videos: "Best
Practices for Great iOS UI Design" and "Designing Intuitive User
Experiences," available on the Apple Developer website.
You may also want to review the iOS Human Interface Guidelines for
more information on how to create a great user experience in your app.
Of course we can develop web apps, but apple can't forget that many features are only available in native or hybrid apps.
What should we do?
References:
https://blog.summitsync.com/did-apple-just-crush-white-label-apps-4aee14d00b78
https://developer.apple.com/app-store/review/guidelines/
The current answer is out of date. Apple revised their guidelines in which the customer must have their own Apple account now, paying the $99 a year. You can then submit a white labeled app under that account. We have been doing that the past three months with no problem. They wouldnt allow this approach before but now they do.
The Apple developer account can not be an individual account, but a company, educational or government type.
If you have a few apps under the same company account you can submit the apps if they can be proven to belong to the current company. We have three apps submitted under the same company account because the apps shared similar names to the company however I wouldn't do this for different companies.
We where having the same issue. We have talked to Apple, which where very kind and understanding.
Our app is one used mainly bij employees of a company and there for Apple suggested to use B2B app distribution via Volume Purchase Program.
If your app is just white labeled app that business can use for their customers then you are out of luck. Apple will not allow any white label apps in the app store any more.
Your option is to make one app which can switch between the different customers.
If you app is like web store this can be difficult, but as per Apple's example of the fan app of a football club switch per club should be in one app.
4.3 is a complete mess. With its active enforcement, Apple has indeed opened a Pandora's box. The biggest problem is that this policy is applied randomly.
My experience suggests that there are very few App Store reviewers who are paying attention to it during the review process. However, if you stumble upon such a reviewer, they will put some flag on your file, and all other reviewers will start to evaluate your apps for spam going forward. It seems like nothing is wrong with this approach, but it can lead to a distorted market.
In our case, we are waiting for years now to see Apple apply the same rules to our competition as it did to us. And the most ironic part is that throughout these years we've been ringing all the possible bells. Emails to Apple representatives, release notes, responses in resolution centre – nothing works.
For more details about our story check my Medium post. I have also written a second part which contains the timeline of my discussions with Apple representatives in which I highlighted competitors who violate 4.3, and Apple did nothing :(
So, the first problem with 4.3 is that it distorts the competition given how selective Apple is at implementing it.
The second problem is that the policy itself is too vague. Take our company, Theory Test Revolution, as an example. We build apps which help people pass their UK Driving Test.
Although we focus on theory tests, the reality is that our apps could be used as a platform to prepare for any multiple-choice test. Imagine if we wanted to release a couple of other MCQs apps. For example, to prepare for PADI diving exam and also to prepare for some pilot's licence exam.
How would 4.3 apply in this case? Would Apple demand that we bundle all of them in one app? How would we call it? :) "Any test you can imagine"? :)
There must be some limits. There are cases when marketing needs justify releasing separate apps even if their foundation is the same, as doing otherwise would simply confuse the users. Unfortunately, Apple doesn't care about fair competition enough. I guess their goal is to reduce the number of apps using this policy, with little regard to how fair this process is.
We are waiting for almost three years now to see our competitors being treated in the same way. And who knows – how much longer do we need to wait?
Had a call with Apple on July 13, 2020, 5 PM (GMT)
I had a conversation with the app review team regarding this matter today and I have concluded the following.
You can have the same codebase, same color, and same design for multiple apps but, a big BUT, is that you need to have some unique functionality in the app which provides a different experience to users.
They clearly said it's a difficult thing to do for developers and should take a longer time.
Only a way to know if some unique feature will work out is to send it for a review. It doesn't matter how long you have spent on developing that new feature. They also said they cannot help and is not permitted to insight anything beforehand.
They cleared that this is not a technical or logical issue to be resolved. For example, they are not going to check if the app icon or color is going to match with other app and decide it a spam or not spam but they care how users will be experiencing this app with the "WOW" factor or the app usefulness.
In short, the app must give another perspective to the user and the app should insist the user to use it because it has something new to give.
According to section 4.2.6 of: https://developer.apple.com/app-store/review/guidelines/#design
Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences. Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or “picker” model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.
So, rejoice! your apps can in fact be white labeled! they just must be:
submitted directly by the provider of the app’s content
There is nothing you can do to make Apple approve a copy of your app with only images and labels changed, it was their politics since iOS 3.
The only sure way you can do it is by creating a new developer account for the company you are selling the personalized version.
And B2B is also a viable option that also saves your client the 99$ yearly Apple bill.
I'm changing one of my Mac apps from a paid model to a subscription model, by using auto-renewable subscriptions (IAP).
However, as the app is B2B, some users need to reimburse costs via their employer. While this is acceptable with payments only occurring once, with recurring payments this is simply annoying and sometimes even impossible.
Apple has a B2B Volume Purchase Program that supports companies to purchase a number of licenses and distribute this to their employees. However, IAPs (including auto-renewable subscriptions) are not supported.
I see this as a big limitation (especially knowing they take a 30% cut of sales) and the only way to solve this is to offer an additional mechanism to offer subscriptions next to IAPs, specifically for business needs.
My biggest concern is whether my app would be rejected because of this. I have been going through the (updated) guidelines and found some related items:
If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. [...] Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
This will be the case, but not exclusively because of the above mentioned limitation. I won't include a "Buy" link to the alternative method. However, I will include a text indicating that if a company wants to purchase multiple license for its employees, it can do this via our website (using a payment processor such as Stripe). Via this website codes will be made available that can be entered in the app to activate the license.
Apps distributed via the Mac App Store may host plug-ins or extensions that are enabled with mechanisms other than the App Store.
The app is distributed via the Mac App Store and it seems that they are more flexible here. However, it's a vague guideline and I'm not even sure if it's related to the problem I'm facing. What does it mean?
Hoping to read your opinions and experiences here. Thanks.
I have been emailing Apple about this but they have never replied. Also asked this question on the Apple Developer Forums but didn't got any help there too.
Decided to simply implement it and submit it to the App Store. They have accepted it without asking questions so apparently it is allowed. Important to mention is that I have not included the payment mechanism in the app. It asks for a license code that will be validated using my own service. This service also handles the payment via a web page.
Hope it helps others.
I have a client who want their own App, and only to have it in their own shop for clients, not in the iOS App Store. I was wondering if it is possible to create an App, not to submit it to App Store, but to upload it to a website, and make it available for direct download to 50 devices?
For a situation like this they should really use the Business to Business app store.
https://developer.apple.com/programs/volume/b2b/
This will enable them to limit the availability of the app to invitation only. It allows private distribution and you can set your own pricing (can be free if appropriate). This is available with the standard developer license (not the Enterprise one).
There is no officially sanctioned way to do this, that I know of, other than Enterprise-internal, or by using the developer's (your) license, which doesn't sound like what you need.
Be careful: https://www.theiphonewiki.com/wiki/Misuse_of_enterprise_and_developer_certificates
Apple has very tight control over the platform, and specifically prevent what your client wants.
I would question why your client wants to circumvent Apple here. While it is true that Apple take 30% of the price, they also provide a lot of infrastructure and security in return. Perhaps they want to maximize profit, or their content doesn't satisfy Apple's restrictions?
Developing a web app may be an alternative. When done right these can provide similar interfaces, and access can be controlled, and Apple is out of the equation.
Failing that, you could create a separate developer account for this, and the 50 devices could be registered individually by their ID. This will not be anonymous any longer, and it will have to be renewed yearly.
Technically yes you can distribute an app outside of the App Store using the Enterprise Deployment Program.
However, according to the terms of the Enterprise Deployment Program the distribution is limited to only employees of your organization, and in your scenario you mention that they want to distribute the app to their clients.
See the full details in the Apple documentation here:
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/DistributingEnterpriseProgramApps/DistributingEnterpriseProgramApps.html
is this okay to implement payment system on ios apps? I would like to make an app that can browse products on my e-commerce website then let people buy products on my app. I'm asking this question because i've heard it is violating apple's policy.
It apparently depends on the what is being sold. The definitive answer can only be gotten from your lawyer's reading of the Apple agreement, of course, but I can speak from a little experience.
Apple themselves say that: if a product is sold in-app, it must use Apple's IAP (which gives Apple their 30% cut), and not be offered for less through other channels. However, there is an extensive list of things that are not eligible for purchase with IAP at all. Chief among these are: physical products; and services performed outside the application.
I have worked on two apps, both free, that are clients for fee-based web services (continuing education classes in one case, an employee scheduling service in the other). Neither used IAP, just linked to a purchasing web page. Both were accepted by Apple without comment. It seems that since the products were (arguably) not eligible for IAP, using an alternative purchase method was permitted. I'm sure it helps that Apple itself does not compete with either of these services.
Bear in mind Apple has also rejected apps that are just "wrappers" for web sites and offer no real app functionality; or for any of a long list of sillier reasons. (e.g.: I had one app rejected for using the word "Sample" in the name; but a change to "Free", with identical functionality, made it OK.) So consult a lawyer before taking any risk predicated on the developer agreement.
[edited to add:]
For dev program members, the relevant legalese is to be found here (login required), "iOS Developer Program License Agreement", attachment 2 (about 2/3 through the document.) A few relevant phrases from the Jun 12 2012 version, emphases mine:
You may not use the In-App Purchase API to offer goods or services to be used outside of Your Application.
You may not enable end-users to purchase Currency of any kind through the In-App Purchase API, including but not limited to any Currency for exchange, gifting, redemption,
transfer, trading or use in purchasing or obtaining anything within or outside of Your Application.
Rentals of content, services or functionality through the In-App Purchase API are not allowed
You may not use the In-App Purchase API to send any software updates to Your Application or otherwise add any additional executable code to Your Application. (not that this is even physically possible. --R.)
[except] as permitted under Section 3.3.23 (In-App Purchase API), an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store or VPP/B2B Program Site.
By my reading, this means that anything besides unlocking functionality within an app is fair game for an alternative purchase mechanism, and forbidden categories of items require such. But ask a real lawyer.
[edited to add, much later:]
After a fun update fiasco with one of the above mentioned apps, these anecdotes are not entirely true anymore. Apple booted one of them because of a tenuous link to a signup web page for some paid services. So be careful, and be prepared for Apple to yank things arbitrarily if you wander anywhere close to the line.
You must use In-App Purchase via StoreKit or your app will be rejected. Implementing your own payment system violates a couple of the review guidelines, most directly:
Apps utilizing a system other than the
In App Purchase API (IAP) to purchase
content, functionality, or services in
an app will be rejected
This of course only applies to content, functionality, or services within the app, as long a the purchase is only relevant to things outside of the app they have no stake in the purchase.
Pretty sure Apple won't allow that, especially if the App is free. They are putting up the money to distribute your app, provide the development tools, etc, so they'd like to take their cut off everything you make as a result of that.
Here is App Store Review Guidelines.
Read 3.1.1.
for a client, I have been developing an app which has been tailored to make their employees every day lives easier. Think of it as a calendar designed to fit the needs of their special business.
Now it turns out that other companies in the business are interested in the very same solution too. My client suggested we could sell the app on the appstore.
Since the app is equally useful for companies with hundreds of employees as it is for a team of five, I wonder what would be the best way to sell it.
It is my understanding that a company, once they purchased one copy of the app, may install it on as many devices as they want, as long as they use the devices with the same iTunes account. This is especially true if the company would equip their employees with new devices for the purpose, like my client did. Right?
This is obviously not what I want, I'd rather like to charge a small price per device. Usually, this would cry for a volume license, which is not part of the appstore concept, except for educational institutions.
Now I am looking for a convenient way to achieve something with the same effect.
I was thinking about checking the UDID of the device against a whitelist on my server to allow each purchased license to run on just one device, while allowing migration of course.
To enable a company to purchase a "volume license", I would offer packs of additional licenses via In-App-Purchases, as well as individual licenses. The app itself would be free while featuring only demo capabilities, full functionality would be available after assigning the device to one of the purchased licenses. Means to manage licenses would be included within the app.
What do you guys think? Any technical reasons why this concept could fail?
Do you know of examples that actually implement something similar?
Any other ideas how to sell apps in volume? Maybe there are even some examples on how to implement something like this?
Do you think apple would approve this kind of use of in-app-purchases? (I know this last question is not of a kind that can be answered here without uncertainty, but let me hear what your gut feeling tells you..)
This question has been flagged as being off-topic twice, so I think I should back up the fact that I am mainly interested in a technical solution (and emphasized the important sub-questions accordingly). Of course I am interested in whether apple allows the proposed use of their appstore, however before I contemplate that further I need to know if there are technical caveats to my approach. I would love to offer code snippets to support the technical nature of my inquiry, however I'm just planning things so there is no code yet...
While the core question is still business-related here, and thus off topic, I'll bite.
The standard App Store end user license agreement has this wording:
a. Scope of License: This license
granted to You for the Licensed
Application by Application Provider is
limited to a non-transferable license
to use the Licensed Application on any
iPhone or iPod touch that You own or
control and as permitted by the Usage
Rules set forth in Section 9.b. of the
App Store Terms and Conditions (the
“Usage Rules”). This license does not
allow You to use the Licensed
Application on any iPod touch or
iPhone that You do not own or control,
and You may not distribute or make the
Licensed Application available over a
network where it could be used by
multiple devices at the same time. You
may not rent, lease, lend, sell,
redistribute or sublicense the
Licensed Application.
Therefore, if you consult the "App Store Product Usage Rules" section of the iTunes Store Terms and Conditions, you see this wording:
(i) You may download and sync an App
Store Product for personal,
noncommercial use on any iOS Device
you own or control.
(ii) If you are a commercial
enterprise or educational institution,
you may download and sync an App Store
Product for use by either (a) a single
individual on one or more iOS Devices
you own or control or (b) multiple
individuals, on a single shared iOS
Device you own or control. For
example, a single employee may use the
Product on both the employee's iPhone
and iPad, or multiple students may
serially use the Product on a single
iPad located at a resource center or
library.
(iii) You shall be able to store App
Store Products from up to five
different Accounts at a time on
compatible iOS Devices.
(iv) You shall be able to manually
sync App Store Products from at least
one iTunes-authorized device to iOS
Devices that have manual sync mode,
provided that the App Store Product is
associated with an Account on the
primary iTunes-authorized device,
where the primary iTunes-authorized
device is the one that was first
synced with the iOS Device or the one
that you subsequently designate as
primary using the iTunes application.
The rules are quite explicit about commercial enterprises not being allowed to just purchase one copy and install it on all devices at that company.
It is for this reason that Apple offers volume discounts for applications purchased in bulk (where the developer has checked the box in iTunes Connect allowing for this). I can't find the business equivalent, but here's Apple's page on the educational bulk discount program.
While I could see how you could use in-app purchase to activate functionality in an application and make sure that it was properly licensed, I've heard complaints about the practical difficulties of deploying applications using this in educational and business settings. Many applications use this approach for free Lite versions that upsell into the full paid application, so Apple has no problem with this.
One thing I do recommend is that you not abuse the ad hoc distribution system to do any licensing workarounds. The last time some geniuses did this caused Apple to clamp down on everyone's ad hoc licenses and make our lives more difficult.
The correct answer here is for the companies you sell to to purchase an Enterprise program from Apple, then for you to license the application to them. You can use over-the-air distribution to get the application onto their devices, and charge them a per-user or per-device fee.
Let anyone download the app for free in the app store, but charge for licenses/subscriptions outside of the app store. You can then require them to register each device they want to use and you charge accordingly.
Can I bypass Apple's in app purchase mechanism by outside billing?
Thq question was asked long before, but still I feel that the answer might help someone having the issue. All you need is Apple's Volume Purchase Program. It provides the option for custom B2B apps developed by third-party developers, that too can be seen and downloaded only by the authorized client. Cool, isnt it? :-)
For clarifications, see the FAQ
The client can do a bulk purchase, on which they will receive a bunch of URLs. By opening the URL in iOS device is enough to install the app. Of course, you need a Apple Developer account for download and install, I think.