From this page (http://developer.apple.com/programs/ios/distribute.html) I've read this
Custom B2B Apps
You can also offer custom B2B apps directly to your business customers
who have a Volume Purchase Program account. A custom B2B app provides
a unique, tailored solution to address a specific business need or
requirement.
Does anyone have any more details about this? i have an app idea that is specific for a individual company, say I am building an app for Company ABC, this app is solely for company ABC & no one else, how do I distribute such an an app (to Company ABC) & can I charge a monthly subscription for this app?
Thanks
kb
B2B Apps need to go through Apples review just like normal apps do, but they will appear in some sort of a private store to which you may grant your client access. It is my understanding that, aside from that, normal rules apply.
That means you might be able to offer In App Purchases and lock most of the app down, unless the user purchases a subscription.
I do not know however if subscriptions can be purchased via the Volume Purchase Program.
As a rule of thumb, before entering "uncharted waters" by just developing your idea, you should just contact Apple about what you like to do. Ultimately it is their decision what they will approve, so I wouldn't rely on the opinion of someone on the internet before putting too much effort into it.
You should also be aware that the Volume Purchase Program is available in the United States only.
Have you seen this:
http://www.apple.com/business/vpp/
"Custom B2B Apps for Business
In addition to offering volume purchasing of apps in the App Store, the Volume Purchase Program provides your business with an easy way to procure custom B2B apps built by third-party developers. Custom B2B apps are built to address a unique business need, and therefore are not available to the general public for purchase. "
Yes you can create an app for Company ABC only, and restrict only them as purchasers. I don't think you can make it a subscription though. Oh, and it's US businesses only.
https://developer.apple.com/programs/volume/b2b/
Look at bottom of page for other countries you can distribute to.
Related
I want to share In-App purchased product identifiers from one app(say "App1") to another app(say "App2"). Both run on iOS 7 devices. And more importantly since "App2" was released long time back, both the apps have different Team IDs. When the user clicks on a "Restore purchase from App1" button I want "App2" to unlock certain features based on the purchases the user has made in "App1". What is the best way to achieve this?
I dont want to use UIDocumentInteractionController or UIActivityViewController because that would require unnecessary user interaction.
Key chain items or iCloud key-value storage cannot be shared because both the apps have different Team IDs.
Can't use an exclusive server through which the two apps can communicate.
You cannot do this by using the IAP API. You could store the information on your server and unlock it for a user, however, this is against the App Store Review Guidelines:
Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected.
And technically you would not be using the API if you checked against your own server and provided the content through that.
Now this looks possible for subscriptions with App Bundles: https://developer.apple.com/documentation/storekit/in-app_purchase/offering_a_subscription_across_multiple_apps
You can offer customers auto-renewable subscription services that are accessible through multiple apps across one or more operating systems.
In order to offer this functionality, your server must grant access to the subscription content across all apps, despite the user having purchased the subscription within a specific app. You can use a unified account management database along with server-side receipt validation to validate a user's purchase and ensure in-app transactions are handled. By entitling subscription access from your server, you can provide users the ability to access your subscription across multiple apps.
It's Possible using Authentication API
step 1: When purchased product successfully to store status inside API
step 2: Then call API every time of didFinishLaunching to check purchase status and use multiple APP
Another benefit is make payment without any payment gateway...
The scenario is the following:
Company A has an app that I'm customizing for company B.
Company B would like to initially keep the app private within Company B and authorized resellers of Company B's products.
In the future, Company B may want to make the app available to the general public in the public App Store.
It seems that the 'Custom B2B' app option is the right option as a developer and then distribute the app through the VPP to Company B, but I'm not clear on what I have to do to make the App also available in the general App Store when needed.
You can just change the VPP flag in iTunes Connect afterwards and then it will be publicly available. Not only for registered VPP customers. (And VPP is still possible, since every app in the appstore may be purchased via the VPP).
Section: Rights and Pricing
There is a checkbox called Custom B2B App.
Quoting the info Text:
An app that is set up as a custom B2B app will only be available to
the Volume Purchase Program customers that you specify in iTunes
Connect, and it will only be available in the applicable territories
(for example, U.S. Volume Purchase Program customers must use the U.S.
App Store Volume Purchase Program for Business). Custom B2B apps will
not be available to educational institutions or general App Store
customers. To learn more about the App Store Volume Purchase Program
for Business, visit http://vpp.itunes.apple.com/faq. To learn more
about how your customers can sign up for the Volume Purchase Program,
visit http://enroll.vpp.itunes.apple.com.
I have an application that we are building to be delivered to our users for free. However, the business wants to be able to sell this application to anyone else who might want it. Is there anyway we can do this?
The suggestions and concerns we've come up with are:
Submit app with price and deliver free download codes to users, but I believe that we only get something like 50 free download codes and we have more than 50 users.
Submit app for free, but make content an in-app purchase and have some mechanisim for allowing our users to validate and get the content free. We think that Apple will hate this since the application isn't functional without the content.
Submit application twice, one free and one paid and just direct our users to the free one. This means that our free version can be found and used by anyone cutting into the revenue stream.
Any suggestions/advice/hints/rants welcome.
Have you considered Software as a Service? The app is an extension of the service. Make the app free to anyone, but to get anything useful out of the app, require username/password or some other validation. You'd be hard pressed to find an app today that doesn't require some sort of signup process.
There are plenty of options you can go with.
In-App Purchase
Free/Lite version of App
Paid version of App
Just a matter of what you and your customers want. Good luck.
Why not have a very basic version of the app available for free (so that Apple is happy) and then have the rest of the app "unlocked" when the user either:
Registers their copy of the app back with your servers (covers giving it to some for free)
Makes an in-app purchase to unlock the rest of the functionality
This keeps Apple happy, gives you the functions you want, and is only minimal effort.
You can pay for and gift paid apps to iTunes account holders. Making the app appear to be "Free" to those recipients. If it's your own app, Apple will keep (only) 30% of the price you pay, so add that on to your cost of doing business.
I have an app which costs $5. I'd like to change this so that the app is free and that users must purchase an auto-renewing subscription to use it. I know how to implement the auto-renewing subscription, but the problem is dealing with users who have already bought the app for $5; I'd like to continue letting these users use my app without a subscription.
The rub is that for privacy reasons I can't store any identifying information on my server which link an account for my app to a specific person (not even UIDID). What I can do is maintain a separate database table which links UIDIDs to subscription purchase receipts which will allow me to know if a user has a subscription.
So my question is, how can I identify users who got my app when it cost $5? I know there's a way to restore in-app purchase receipts, but is there a way to to retrieve a receipt for the initial purchase of the $5 app which I could store on my server?
The poor man's solution is just to mark all current UIDIDs (i.e. the UIDIDs of people who have paid $5) in my server as paid, but then they would have to buy a subscription if they ever wanted to use my app from a different device.
The previously selected answer is outdated. The new answer is that it is possible today with the new receipts that were standardized this year (2013).
The receipt now has two additional fields: original_application_version and original_purchase_date which can be used to detect when a user purchased and therefore be used to guide logic around what users should get what features.
You can see more about 10 minutes in here: http://devstreaming.apple.com/videos/wwdc/2013/308xex4x6ybggtlw4ztv0sg5btp/308/308-SD.mov?dl=1
or if that link dies here: https://developer.apple.com/wwdc/videos/ and search for Using Receipts to Protect Your Digital Sales.
Chaning your business model like this is not very well supported by the App Store.
Your "poor mans" solution is probably one of the best of a poor set of options.
Another one would be to switch to a new app entirely (just a different bundle ID in practice). Anyone using your old app would have paid, regardless of which device they use. Anyone using the "new" app would need a subscription. Obviously you'd lose any reviews and possibly external links that you currently have.
From My Previous question
sending request to apple - from iphone custom application
Here, I have added more specified my question.
Suppose my application has implemented followings.
Lets take an simple example
I have developed an application, for mobile dealer.
User can see ten mobile items on screen.
Now, user selects two items.(mobiles)
Now, User chooses check out option.
in check out option, he will provide his apple account - id & password.
Above I have explained the process that should be implemented in my application.
Up to 4 stpes I can do programming.
But I have no idea about the last step.
Can user make payment through apple
id - from iPhone?
What kind of steps do I/programmer
have to follow?
What kind of accounts do
I/programmer are required? (If
any..)
What kind of certificates do
I/programmer are required? (If
any..)
Let's take an another example.
Suppose, Application if something like this,
User can pay for bike (new order) through iPhone - apple id - password ?
Edit :
After a round - round question ...
Let's understand it in single line
Does apple allow to use apple-ID for payment of items other than apple-store? Why ?
You cannot sell your products through the Apple Store. If you want to have an iPhone app that interfaces with your store you can do that, but you will have to provide your own store service.
To answer the edit to your question, Apple does not allow using an Apple ID to purchase products from other stores. Instead you should use something like Paypal or Google Checkout.
StoreKit allows you to sell digital content, such as books, music, ect. and get it delivered right into the application. Payment happens via the iTunes account.
However, you cannot sell physical goods with this mechanism. You may want to consider other payment methods as mentioned by Amuck.
Answering the edited short-question:
Does apple allow to use apple-ID for
payment of items other than
apple-store? Why ?
No, because they do not pose as a payment provider to third parties and I am pretty sure they never will.