iOS Question Tricky way to cause app to close - is it too tricky? has implications for app stores gouging 30%

[JackKirk]

Hi,

I have found a simple way to cause a B4i app to close (somewhat similar to ExitApplication in B4A).

You just have to fabricate an abend.

For example I have used:

Main.yymmdd = Main.yymmdd.SubString(-1)

where yymmdd is a variable I use elsewhere.

This works fine but I'm wondering if I will fall foul of the Apple cart masters in some way.

It would only occur in the hands of customers under certain circumstances - it would not occur in the hands of any App store testers.

Do abends get thrown up to the Apple cloud?

Thoughts?

 

[Erel]

1. Why make your app exit if it is an unwanted behavior in iOS?
2. You are causing your app to crash. It doesn't sound like a good solution for anything.

 

[JackKirk]

1. Why make your app exit if it is an unwanted behavior in iOS?
2. You are causing your app to crash. It doesn't sound like a good solution for anything.

Erel, it is not a trivial question and it could very well be a solution for a major problem - app stores gouging 30%.

Apple has just deleted a part of their legalese, this explains it pretty well:

https://au.pcmag.com/mobile-apps/90...es-let-devs-share-info-about-outside-payments

the important bit is under "Deleted from 3.1.3".

Basically what it means is that if you gleen your customer contact info from sources outside the app then you are free to contact them and offer them non-app payment options.

We know all the contact details of our customers before apps come into play, basically up till now it worked like this:

1. customer visits our website and pays upfront for a digital "ticket" to access photos and videos we have captured of them in an amusement park.
2. the customer gets sent a ticket as an SMS or email - this contains a URL with the customer's ticket number embedded in it.
3. the customer taps the URL and gets directed to a webpage which asks if he has the app installed.
4. if he responds NO he gets taken to the appropriate app store.
5. if he responds YES the app is launched via URL schemes embedded in the app - at which point the app is passed his ticket number.
6. and we are off to the races...

The downside of this approach is the customer has to pay before he installs the app and sees what he is getting - significant reasons to be hesitant.

What we want to do is:

1. customer visits our website and gets a free "preview" digital "ticket" to access preview quality photos (very low res).
2. as above
3. as above
4. as above
5. as above
6. customer looks at preview photos and decides he wants to download full res versions to his gallery and share them.
7. when he indicates this - the app disappears and he is back at the launch webpage which asks "if you are ready to pay now..."
8. he taps the pay now button in the webpage and gets directed to our own paywall.
9. once payment is made he is directed back to the app.

This all neatly (as far as we can see) fits the new legalese - at least Apples's but Google won't be far behind.

If the Android app is closed via ExitApplication or the like the webpage is there - so it's a no brainer here.

If the iOS app is closed by my trick the webpage disappears - still got to solve this - any suggestions??????????.

Sorry for the long winded response but this could be very important.

Appreciate any feedback...

 

[ilan]

why not open the web page from your app when you want to make the purchase?
Apple will reject apps that crash and they are really tough with their tests!
i am also not sure that apple allows making payments outside your app.

 

[JackKirk]

ilan,

Apple will reject apps that crash and they are really tough with their tests!

I understand this, but as I said I'm able to ensure they would not crash it during their testing - its a matter of the access ticket I give them.

What I would be interested in knowing is if there is any transmission of crash info back to the Apple cart.

i am also not sure that apple allows making payments outside your app.

I'm not sure how closely you have been following Apples (and by association Googles) legal problems in this area:

• They have recently reached agreement with Japanese regulators to dial back their gouging in return for the regulators stopping their enquiry into them - this entails letting apps that supply things like photos and videos (e.g. Netflix) have non-app payment portals.
• The Korean government has legislated to make it illegal for them to force in-app payments through their payment portals - not sure of current state of this.
• Then there is the Epic court case in the states - the judge put an injunction on them to cease and desist the practice - they are appealing parts of this.

As a result of the Epic case they have agreed to dial back some of their excesses - this is what the stuff is under "Deleted from 3.1.3" in my post #3 above.

Basically what it means is that if you gleen your customer contact info from sources outside the app then you are free to contact them and offer them non-app payment options.

why not open the web page from your app when you want to make the purchase?

I could obviously do this but run the small(?) risk that this would be judged as using the app to channel the customer to my payment portal - I think it is a bit harder to argue this if the app just stopped and voila! the webpage that launched to app is sitting there with payment options.

Incidentally, I can do this very simply with Android.

If I could just find some way to have the webpage still standing when I abort the iOS app I would have exactly what I want.