One subscription fee for multiple device installs?

Using the website to transfer the IAP right may create certain problems - how will Apple assure that you aren't monitizing that outside of IAP?

One solution is to use some sort of transfer from one device to any other device directly through the app. For example, you could use CloudKit to do it remotely and distribute, via email from within the app, a UUID that was also the CKRecordIdName. You could use MCSession to distribute the rights from one device to another device through WiFi or Bluetooth.

Also, you could post on CloudKit all websites that were currently 'enabled' by the purchase of the IAP subscription. It is unclear whether any 'device' would also need to log in to their particluar website to be able to use it (e.g. www.acme.com)

> Is that a violation of Apple policy, for this type of service? Are there any similar business models I can look into which might give me an idea?

Be sure to go over the ASRGs/Business, & look into CloudKit.

Hi,

The devices interact with an existing web app, which manages their participation in the correct parcel delivery comany. This all works fine, whether the devices are iOS or not. Cloudkit doesn't help, just adds unnessecary code.

I guess an alternative way to view it could be like Spotify. I pay for my Spotify account outside of Apple, but any app install I do from one of my devices can join my account. So, in my case, if I own a package delivery company and I pay for a web service to manage deliveries, I want to be able to join any device to that account. Technically (in code) I can already do that, but what I can't work out is how that is affected by Apple's payment rules.

Is payment for an external web service, and the app is free, a valid model? IAP doesn't really work, as the business owner won't be logged in to every device.

3.1.5 (a) Physical Goods and Services Outside of the App: If your app enables people to purchase goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.

I think this is what covers my case, but I'm not sure. A 'physical service' can be a delivery service? The app enables customers and companies to trade a service which isn't wholly contained within the app digitally.

thanks

You are asking two different questions

1) do you need to use IAP or can you use a third party payment system.

2) distributing a subscription to multiple devices

re 1) You do not need to use IAP (actually you can't use IAP) for a delivery service - real people delivering real packages. But in your case that 'isn't wholly' what you are doing:

>The app enables customers and companies to trade a service which isn't wholly contained within the app digitally.

So the app is also providing something of value separate from the fee the customer is paying the shipper for a real world service. Actually, I think the customer is separately covering the full cost of the delivery and your app is charging only for a digital connection - so I disagree with your '...isn't wholly contained within the app digitally' - I think what you are selling is wholly digital and wholly contained within the app and you must use IAP.

re 2) the web may not work since nothing prevents you from providing the subscription to FedEx in exchange for a payment to you of $26.34 outside of the IAP system. So Apple would have to trust you will not do that. For that reason I am suggesting doing it within Apple's environment, CloudKit.

thanks.

Cloudkit isn't really an option, even if Apple prefers it. It's an additional layer of code just to be able to provide Apple with 30% of the revenue. Or conversely, an additional layer of code to enable me to keep 70% of revenue. It would also lock out any Android usage, which again Apple prefers but doesn't work for me.

I can't/don't want to take IAP payments because multiple devices are being used and the business owner will not want to be signed in to the App Store with the credit card available on all devices. Particularly if a new driver/device comes online in another city, it's not even practical.

So the answer really is to keep re-engineering the business idea until it falls outside of Apple's policy. Then work out if it's still a viable idea.

thanks for your help so far, I need to keep trying to work this out I think.

cheers,

Hi,

Just thinking about your FedEx comment above. If the package delivery app was completely free, and was effectively a 'view' into the FedEx system with some simple interaction ('parcel delivered button', etc), that's ok? So the package delivery company can distribute credentials of their account on the FedEx system to their multiple devices. The FedEx system is charging the package delivery company for use of their system, but the app is free.

I guess this is also similar to any number of e-trading apps out there. The app is free, and lets you trade online through the app, but you pay fees through the trading platform for transactions.

I just found Basecamp, which is a free app and lets you signup for a free 30-day trial. Then you receive an email with a link to your account on their website. And in the website under 'admin' you can upgrade to a paid account. You can also 'invite others' to join this account. It's a business app, so you can let others (other device owners) join and collaborate on the same account.

This is perhaps closer to what I am trying to solve/understand. Multiple devices/device-owners joining a single account, paid for by a single business entity. To me, it just doesn't make sense to use IAP on each device. But I didn't explain what I was trying to do, because I didn't really understand it 🙂

So it seems you can have an external subscription for a non-physical service, so long as you don't refer to it in the iOS app? And so long as the app fully functions, seemingly even for a trial period only.

thanks again for your help.