You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@flex.apache.org by bilbosax <wa...@comcast.net> on 2018/10/19 23:27:26 UTC

In-app Purchases

I know that this is an odd place to ask this, but there are relatively few
active forums to ask about Adobe Air. Although it had passed app review
twice, I had an app rejected recently from Apple's App Store because it does
not use the in-app purchase API. My app is a real estate app that you can
log into, or if you don't have an account, you can create it in the app and
pay for a monthly subscription. Since it is a cross-platform app for
Android, Apple, and desktop, I wanted just one payment solution to make it
simple, so I chose Stripe. I open a webview in the app to pay for the
subscription. Apple claims that my content is locked until payment is made,
so I am required to use the in-app purchase API to unlock the content. Now
that I am so far into development, this could be a huge change that adds a
lot of time to my actual release. I have two options as I see it:

1) Implement in-app purchase API somehow into my code
2) Give the user the option to Sign Up or Log In. If they choose to sign up,
redirect them to my website in safari to sign up and use Stripe as I have
already laid out. Once they have signed up they can then move back to the
app and simply Log In.

I know absolutely nothing about in-app purchases. I always thought that they
used Apple Pay, which I would prefer not to do. Can the in-app purchase API
work with my Stripe Account and subscription products that I created there,
or would I be forced to transform my whole workflow? Of the two options I
listed above, which would you choose? Any ANE recommendations?

Thanks for any insights!



--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/

Re: In-app Purchases

Posted by Greg Dove <gr...@gmail.com>.

iirc there are rules about what purchasing support you can use depending on
the app store. I think Stripe is permitted for content or products that are
not 'delivered' in-app. But for in-app items or app status subscriptions I
think you are obliged to use the in-app purchasing support via whatever app
store you are on, if it is 'in-app'. And pay their 30% or whatever the rate
is now. In the past I used milkmangames ANE for this. But there are other
options.

Please check the rules for whatever app store you intend to publish to.


On Sat, 20 Oct 2018, 12:27 bilbosax, <wa...@comcast.net> wrote:

> I know that this is an odd place to ask this, but there are relatively few
> active forums to ask about Adobe Air. Although it had passed app review
> twice, I had an app rejected recently from Apple's App Store because it
> does
> not use the in-app purchase API. My app is a real estate app that you can
> log into, or if you don't have an account, you can create it in the app and
> pay for a monthly subscription. Since it is a cross-platform app for
> Android, Apple, and desktop, I wanted just one payment solution to make it
> simple, so I chose Stripe. I open a webview in the app to pay for the
> subscription. Apple claims that my content is locked until payment is made,
> so I am required to use the in-app purchase API to unlock the content. Now
> that I am so far into development, this could be a huge change that adds a
> lot of time to my actual release. I have two options as I see it:
>
> 1) Implement in-app purchase API somehow into my code
> 2) Give the user the option to Sign Up or Log In. If they choose to sign
> up,
> redirect them to my website in safari to sign up and use Stripe as I have
> already laid out. Once they have signed up they can then move back to the
> app and simply Log In.
>
> I know absolutely nothing about in-app purchases. I always thought that
> they
> used Apple Pay, which I would prefer not to do. Can the in-app purchase API
> work with my Stripe Account and subscription products that I created there,
> or would I be forced to transform my whole workflow? Of the two options I
> listed above, which would you choose? Any ANE recommendations?
>
> Thanks for any insights!
>
>
>
> --
> Sent from: http://apache-flex-users.2333346.n4.nabble.com/
>

Re: In-app Purchases

Posted by bilbosax <wa...@comcast.net>.

Yeah, sadly, our business model is a subscription service at this point for
real estate investors.  So individual users subscribe to our service.  Apple
considers a subscription to be an in-app purchase situation.  Now that they
actually KNOW that people could come to my website to sign up, they are
telling me that they will reject the app if it only appears with a login.

But giving Apple 30% just nauseates me.  My investors don't even get that
much. I feel like starting a developers #MeToo movement because it just
feels like I am being taken advantage of LOL

I really thought that since it was a cross-platform service, that I could
choose any merchant I wanted, sign them up on my website, and that Apple
would accept a login-only app.  But now that they know how it operates, they
are telling me it will be rejected.  I don't know if there is any way around
this at this point.  I thought about deleting the app, and submitting a new
one with a login-only approach in a month to see if deleting the app would
also delete any notes and memory that they have on the app, but I'm probably
not the first guy who ever thought about that and it wouldn't pass.

Let me know if you have any other ideas.  I don't mind paying 4-6% like I do
with Stripe, but 30% is absurd.





--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/

Re: In-app Purchases

Posted by Scott Mathewson <sc...@matheson.it>.

Or maybe the issue is individually purchase which you had move to the web

In the case of SF etc is purchased by the company and the app users are “employees” of the purchasing company 

If that’s the case maybe your need to change your business model if that’s possible 



Sent from my iPhone

> On 22 Oct 2018, at 20:56, Scott Mathewson <sc...@matheson.it> wrote:
> 
> I have been following this thread, my company sell a service for lot of $$ and we have a iPad app that you need to login to 
> 
> look at sales force or work day, no way are they paying apple 30%
> 
> Sent from my iPhone
> 
>> On 22 Oct 2018, at 20:21, bilbosax <wa...@comcast.net> wrote:
>> 
>> Erik, I am hoping that you may be able to apply your sharp mind to this, but
>> I think I may be in an unrecoverable situation with Apple :(  I just got off
>> the phone with App Review, and at this point, they KNOW that I am offering a
>> paid subscription service, so it does not seem to matter to them that I move
>> the account handling and payment services to my website and just offer a
>> login in my app.  That may have worked when they didn't know that users paid
>> a subscription, but now that they know that payment is taken, they said the
>> app would be rejected unless I utilize in-app purchase.  I told them that I
>> do not want any new users to sign up through the app, just for current users
>> to be able to log in, and they said that if my app did not offer in-app
>> purchase, that it would be rejected.  I don't know if that means that I just
>> have to import classes and have code that can be recognized as in-app
>> purchase, or if that means that I actually have to offer a way for new
>> clients to sign up.
>> 
>> I know that they keep a lot of notes on all of these apps.  It probably
>> wouldn't work, but I thought about dropping the app from the app store and
>> submitting a new App with just a login feature, but I don't know if the
>> notes are attached to the app, or to my account.
>> 
>> Can you think of any other argument that I could make to Apple that would
>> allow me to take signups on my website, but only logins in the app?  How did
>> you get around all of this with Keiretsu Forum??
>> 
>> 
>> 
>> --
>> Sent from: http://apache-flex-users.2333346.n4.nabble.com/
>

Re: In-app Purchases

Posted by Scott Mathewson <sc...@matheson.it>.

I have been following this thread, my company sell a service for lot of $$ and we have a iPad app that you need to login to 

look at sales force or work day, no way are they paying apple 30%

Sent from my iPhone

> On 22 Oct 2018, at 20:21, bilbosax <wa...@comcast.net> wrote:
> 
> Erik, I am hoping that you may be able to apply your sharp mind to this, but
> I think I may be in an unrecoverable situation with Apple :(  I just got off
> the phone with App Review, and at this point, they KNOW that I am offering a
> paid subscription service, so it does not seem to matter to them that I move
> the account handling and payment services to my website and just offer a
> login in my app.  That may have worked when they didn't know that users paid
> a subscription, but now that they know that payment is taken, they said the
> app would be rejected unless I utilize in-app purchase.  I told them that I
> do not want any new users to sign up through the app, just for current users
> to be able to log in, and they said that if my app did not offer in-app
> purchase, that it would be rejected.  I don't know if that means that I just
> have to import classes and have code that can be recognized as in-app
> purchase, or if that means that I actually have to offer a way for new
> clients to sign up.
> 
> I know that they keep a lot of notes on all of these apps.  It probably
> wouldn't work, but I thought about dropping the app from the app store and
> submitting a new App with just a login feature, but I don't know if the
> notes are attached to the app, or to my account.
> 
> Can you think of any other argument that I could make to Apple that would
> allow me to take signups on my website, but only logins in the app?  How did
> you get around all of this with Keiretsu Forum??
> 
> 
> 
> --
> Sent from: http://apache-flex-users.2333346.n4.nabble.com/

Re: In-app Purchases

Posted by bilbosax <wa...@comcast.net>.

Erik, I am hoping that you may be able to apply your sharp mind to this, but
I think I may be in an unrecoverable situation with Apple :(  I just got off
the phone with App Review, and at this point, they KNOW that I am offering a
paid subscription service, so it does not seem to matter to them that I move
the account handling and payment services to my website and just offer a
login in my app.  That may have worked when they didn't know that users paid
a subscription, but now that they know that payment is taken, they said the
app would be rejected unless I utilize in-app purchase.  I told them that I
do not want any new users to sign up through the app, just for current users
to be able to log in, and they said that if my app did not offer in-app
purchase, that it would be rejected.  I don't know if that means that I just
have to import classes and have code that can be recognized as in-app
purchase, or if that means that I actually have to offer a way for new
clients to sign up.

I know that they keep a lot of notes on all of these apps.  It probably
wouldn't work, but I thought about dropping the app from the app store and
submitting a new App with just a login feature, but I don't know if the
notes are attached to the app, or to my account.

Can you think of any other argument that I could make to Apple that would
allow me to take signups on my website, but only logins in the app?  How did
you get around all of this with Keiretsu Forum??



--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/

Re: In-app Purchases

Posted by Erik Thomas <er...@icloud.com>.

Sounds like a good plan for now. You can assess how it's working and change it if you need to.

We don't let anyone sign up in our apps. They learn about our apps through a different channel and are directed to our website where they sign up for a membership or to be a guest for a given investor meeting and then are directed to the appropriate installer on app, or play store for mobile, or directly download and install a Mac or Windows version from the same web page.

I don't know if play store will be a problem for you in the future. We've never been rejected for our android apps. I don't believe they have a human reviewer.

There's a place to display your website URL on iOS App Store. Folks may tap that as their entry point for getting your app if they can't figure out how to sign up.

Good luck.

Erik

On Oct 22, 2018, at 8:24 AM, bilbosax <wa...@comcast.net> wrote:

Erik, thanks for all the advice and insights. I am going to move the account
information and payments to my website, but on desktops and androids, you
will be able to do it on both the website and in the app, but for iOS, it
will all be done on the website only. This is the only way I can think to
do this. I hope it is not too confusing for my users, I wanted a seamless
solution. But it is a professional tool, and I feel like if they are really
interested in the tool, they will figure it out. It is not for the casual
user.

I have only one other concern - Android. I understand that for games, they
make you do something similar to Apple with in-app purchases. But when I
submitted my apps to Android, they just simply went live as if there was no
review process. I am concerned that they may one day actually look at my
app and have an issue with it. Are people able to sign up and pay for your
Keiretsu Forum service on Android with no problems in the app, or do they
also have a policy where you can't unlock content by paying with a source
outside of in-app purchases?

I've never seen a Review Guidelines for Google. There wasn't even a place
to give them login credentials to test the app.

Thanks!

--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/

Re: In-app Purchases

Posted by bilbosax <wa...@comcast.net>.

Erik, thanks for all the advice and insights.  I am going to move the account
information and payments to my website, but on desktops and androids, you
will be able to do it on both the website and in the app, but for iOS, it
will all be done on the website only.  This is the only way I can think to
do this.  I hope it is not too confusing for my users, I wanted a seamless
solution.  But it is a professional tool, and I feel like if they are really
interested in the tool, they will figure it out.  It is not for the casual
user.

I have only one other concern - Android.  I understand that for games, they
make you do something similar to Apple with in-app purchases.  But when I
submitted my apps to Android, they just simply went live as if there was no
review process.  I am concerned that they may one day actually look at my
app and have an issue with it.  Are people able to sign up and pay for your
Keiretsu Forum service on Android with no problems in the app, or do they
also have a policy where you can't unlock content by paying with a source
outside of in-app purchases?

I've never seen a Review Guidelines for Google.  There wasn't even a place
to give them login credentials to test the app.

Thanks!



--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/

Re: In-app Purchases

Posted by Erik Thomas <er...@icloud.com>.

Bill:

I feel your pain. The big boys are making it harder and harder for the little guys to have a great idea and become successful.

>> "Are you sure that you can't get around this if a user signs up on your website to create and manage their account, and then just logs into an app from the app store?"

Yes, you can do that! It's what I would do because it's exactly how we do our flagship product Keiretsu Forum, of course a membership costs thousands so it's not going to work with in app purchase anyway.

I'd then remove the "sign up" link from your app for the iOS version--signupLink.visible = !Platform.isIOS. Problem solved. All other platforms can use your Stripe sign up from the app, but you can advertise your product in a way that gets them to sign up on the web prior to logging into your app and for those Apple users who are confused how to sign up, that is the cost of not paying apple 30%.

Or, just embrace in-app payments or change your business model to transactional, e.g., charge the seller when your user buys a property and make the app free. Of course you have overhead then. But what do I know about real estate? Cheers,

Erik

On Oct 20, 2018, at 12:27 PM, bilbosax <wa...@comcast.net> wrote:

Thanks for the reply guys. I really can't believe this. 10 months ago, I
contacted Apple Pay (since you can't talk to App Review until you submit an
app), and they told me that since I was a cross-platform "service", I could
choose any merchant that I wanted. Now I am being told that I cannot make a
payment inside of the app without in-app purchase, and now you guys are
suggesting that if I redirect them to my website to create their account
there, that Apple probably won't allow this either. This just feels like
highway robbery.

The government is going to take 40%
Apple is going to take 30%
Overhead for the business is %10 - %15

Leaving me with a measely %15!!!! Hardly seems worth all the effort!
Stripe was only going to charge me like 4%, which would leave me with 41%.
How is it even legal that Apple can charge for 30% of everything done in an
app when most financial services are between 4-6%, and there hasn't been a
class-action lawsuit?

Are you sure that you can't get around this if a user signs up on your
website to create and manage their account, and then just logs into an app
from the app store? I was told this was perfectly acceptable if you were a
service and you were not simply targeting iOS devices but were
cross-platform.

--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/

Re: In-app Purchases

Posted by bilbosax <wa...@comcast.net>.

Thanks for the reply guys.  I really can't believe this. 10 months ago, I
contacted Apple Pay (since you can't talk to App Review until you submit an
app), and they told me that since I was a cross-platform "service", I could
choose any merchant that I wanted.  Now I am being told that I cannot make a
payment inside of the app without in-app purchase, and now you guys are
suggesting that if I redirect them to my website to create their account
there, that Apple probably won't allow this either.  This just feels like
highway robbery.

The government is going to take 40%
Apple is going to take 30%
Overhead for the business is %10 - %15

Leaving me with a measely %15!!!!  Hardly seems worth all the effort! 
Stripe was only going to charge me like 4%, which would leave me with 41%. 
How is it even legal that Apple can charge for 30% of everything done in an
app when most financial services are between 4-6%, and there hasn't been a
class-action lawsuit?

Are you sure that you can't get around this if a user signs up on your
website to create and manage their account, and then just logs into an app
from the app store?  I was told this was perfectly acceptable if you were a
service and you were not simply targeting iOS devices but were
cross-platform.



--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/

Re: In-app Purchases

Posted by Erik Thomas <er...@icloud.com>.

Hey Bill:

Some more thoughts since I didn't answer all your questions.

In-app purchases will get you more subscribers than making them enter a credit card online so there is an advantage you should consider may make up the difference of the cut Apple takes.

You are transferring the pain of payment from the user to you. You go here and sign up and enter your merchant account info, and then you don't need to think about it anymore, payments will end up in your account.

https://developer.apple.com/in-app-purchase/ <https://developer.apple.com/in-app-purchase/>

Something to think about. And no, you can't use Stripe with your in-app purchases with Apple unless it's just a merchant account you can supply to Apple. That would be convenient for sure.

Anyway, read about the in-app purchases at that link, and then read the docs on the ANE as you will find it's pretty simple. Like a half-day or so of effort.

Cheers,

Erik

On Oct 20, 2018, at 11:09 AM, Erik Thomas <er...@icloud.com> wrote:

Hi Bill:

I'm assuming you expose your sign-up functionality for the Apple reviewer and that's how they know what you're doing. The reason Apple is giving you a hard time is they want their cut of your money and will do whatever they can to make you use in-app purchases for your subscription model. I'm sure this requirement is buried in your Apple developer account agreement small print somewhere, so it's not illegal, but is it ethical?

#2 doesn't necessarily get you past the Apple reviewer if they can click your sign-up link and go to Stripe. The difference between signing up in an embedded WebView hosted signup page and doing so through Safari isn't any difference in the eyes of Apple.

I think you're stuck with using in-app billing for Apple anyway. I use Distriqt ANEs and recommend this one--which will get you Android and iOS in-app purchases with a single API:

https://airnativeextensions.com/extension/com.distriqt.InAppBilling <https://airnativeextensions.com/extension/com.distriqt.InAppBilling>

You'll still have to implement a separate sign-up channel for the desktop AIR versions since the Distriqt ANE doesn't do AIR desktop. There may be an AIR desktop ANE out there somewhere but I suggest you use your existing Stripe for desktop, and use an ANE for iOS and Android. That is unless you use Mac App Store to distribute your AIR desktop app because you will likely run into this same issue for the Mac App. I also recommend hosting your Mac and Windows installers on your own website and NOT distribute through Microsoft store or Apple Store. And if you haven't done Microsoft store yet, plan on a LOT of work to make that happen. Not worth it, IMHO.

Erik

On Oct 19, 2018, at 4:27 PM, bilbosax <waspence41@comcast.net <ma...@comcast.net>> wrote:

I know that this is an odd place to ask this, but there are relatively few
active forums to ask about Adobe Air. Although it had passed app review
twice, I had an app rejected recently from Apple's App Store because it does
not use the in-app purchase API. My app is a real estate app that you can
log into, or if you don't have an account, you can create it in the app and
pay for a monthly subscription. Since it is a cross-platform app for
Android, Apple, and desktop, I wanted just one payment solution to make it
simple, so I chose Stripe. I open a webview in the app to pay for the
subscription. Apple claims that my content is locked until payment is made,
so I am required to use the in-app purchase API to unlock the content. Now
that I am so far into development, this could be a huge change that adds a
lot of time to my actual release. I have two options as I see it:

1) Implement in-app purchase API somehow into my code
2) Give the user the option to Sign Up or Log In. If they choose to sign up,
redirect them to my website in safari to sign up and use Stripe as I have
already laid out. Once they have signed up they can then move back to the
app and simply Log In.

I know absolutely nothing about in-app purchases. I always thought that they
used Apple Pay, which I would prefer not to do. Can the in-app purchase API
work with my Stripe Account and subscription products that I created there,
or would I be forced to transform my whole workflow? Of the two options I
listed above, which would you choose? Any ANE recommendations?

Thanks for any insights!

--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/ <http://apache-flex-users.2333346.n4.nabble.com/>

Re: In-app Purchases

Posted by Erik Thomas <er...@icloud.com>.

Hi Bill:

I think you're stuck with using in-app billing for Apple anyway. I use Distriqt ANEs and recommend this one--which will get you Android and iOS in-app purchases with a single API:

https://airnativeextensions.com/extension/com.distriqt.InAppBilling <https://airnativeextensions.com/extension/com.distriqt.InAppBilling>

Erik

On Oct 19, 2018, at 4:27 PM, bilbosax <wa...@comcast.net> wrote:

Thanks for any insights!

--
Sent from: http://apache-flex-users.2333346.n4.nabble.com/