[macsb] Convert a paid App Store app into an In-App-Purchase app

[Thomas Tempelmann [e-mail] [macsb]]

I am considering turning my pre-paid app into one that's available for
free, with the option to buy an upgrade later via IAP in the App Store. Has
anyone accomplish this yet?

I am unclear on a few things:

1. How can my app detect that a user has fully paid for it before I
switched to IAP? E.g, can I find some purchase date in the receipt, or is
there some way to set up IAP so that previous owners get the full license
when they do "restore purchases"?

2. My app is "grandfathered" in, not needing Sandboxing. Will IAP work
without sandboxing?

3. What are good and bad approaches to get people to buy the upgrade via
IAP? In my indie version, I put up a nag screen occasionally and show a few
big "unpaid" button in their face constantly. But I guess those won't be
allowed in the App Store. So what's a good technique there?

[Duncan Wilcox [e-mail] [macsb]]

Hi Thomas,

1. we did this with Sparkle, the original purchase version is always written in the MAS receipt, even if the user re-downloads the app. Receipt parsing is iffy and we had a bug, mainly because the App Store test environment (also called sandbox) always puts 1.0 in the original purchase version so you can’t really test multiple cases

2. that means you never released an update since the sandbox became mandatory? AFAIK the next version you release will need to be sandboxed.

3. nag screens will be rejected by MAS review, but making it clear that a feature can’t be used until an IAP is purchased is also a requirement

Duncan

I am considering turning my pre-paid app into one that's available for free, with the option to buy an upgrade later via IAP in the App Store. Has anyone accomplish this yet?
1. How can my app detect that a user has fully paid for it before I switched to IAP? E.g, can I find some purchase date in the receipt, or is there some way to set up IAP so that previous owners get the full license when they do "restore purchases"?
2. My app is "grandfathered" in, not needing Sandboxing. Will IAP work without sandboxing?
3. What are good and bad approaches to get people to buy the upgrade via IAP? In my indie version, I put up a nag screen occasionally and show a few big "unpaid" button in their face constantly. But I guess those won't be allowed in the App Store. So what's a good technique there?
--
Thomas Tempelmann, http://www.tempel.org/ <http://www.tempel.org/>
Follow me on Twitter: https://twitter.com/tempelorg <https://twitter.com/tempelorg>
Read my programming blog: http://blog.tempel.org/ <http://blog.tempel.org/>

[Thomas Tempelmann [e-mail] [macsb]]

Hi Duncan,

1. we did this with Sparkle, the original purchase version is always

Post by Duncan Wilcox ***@wilcox.it [macsb]
written in the MAS receipt, even if the user re-downloads the app. Receipt
parsing is iffy and we had a bug, mainly because the App Store test
environment (also called sandbox) always puts 1.0 in the original purchase
version so you can’t really test multiple cases

Would you be willing to share the code that gets this information from the
receipt? Or at least give some hints to keep other from making the same
mistake?

2. that means you never released an update since the sandbox became

Post by Duncan Wilcox ***@wilcox.it [macsb]
mandatory? AFAIK the next version you release will need to be sandboxed.

No, that's what I meant by "grandfathered". I only fixed bugs since, and
that allowed me to keep releasing updates (and let's just assume my IAP
change is not an issue either because it's effectively not a new feature,
which are forbidden to such apps, but rather a change of pricing, which is
allowed).

So the question remains yet to be answered: Does IAP work without
sandboxing? I see no reason why it shouldn't but you never know with
Apple...

[Duncan Wilcox [e-mail] [macsb]]

Would you be willing to share the code that gets this information from the receipt? Or at least give some hints to keep other from making the same mistake?

The code is intertwined with our receipt checking so nothing really that would be useful. Assuming you have extracted the receipt contents like many of the code snippets out there do, the information you need is in the “Original Application Version” attribute of the receipt payload.

So the question remains yet to be answered: Does IAP work without sandboxing? I see no reason why it shouldn't but you never know with Apple


Afraid I can’t help with this.

Duncan

[Pierre Bernard [e-mail] [macsb]]

Hallo Thomas!

Ich nutze eine abgeÀnderte Version von validatereceipt.m: https://github.com/rmaddy/VerifyStoreReceiptiOS/blob/master/VerifyStoreReceipt.m

Ich habe die wiederum abgeÀndert um auch noch ein Kaufdatum zu erraten:

// Date
if (attr_type == 12 || attr_type == 18) {
int str_type = 0;
long str_length = 0;
const uint8_t *str_p = p;
ASN1_get_object(&str_p, &str_length, &str_type, &xclass, seq_end - str_p);

if (str_type == V_ASN1_IA5STRING) {
switch (attr_type) {
case 12:
key = @"ProbableReceiptDate";
break;
case 18:
key = @"ProbablePurchaseDate";
break;
}

if (key) {
NSString *string = [[NSString alloc] initWithBytes:str_p
length:(NSUInteger)str_length
 encoding:NSUTF8StringEncoding];
[info setObject:string forKey:key];
}
}
}



Gruss,
Pierre


From: Thomas Tempelmann ***@gmail.com [macsb] <***@yahoogroups.com>
Reply: ***@yahoogroups.com <***@yahoogroups.com>
Date: 7 August 2016 at 13:18:01
To: MacSB Yahoo Group <***@yahoogroups.com>
Subject:  Re: [macsb] Convert a paid App Store app into an In-App-Purchase app

Hi Duncan,

1. we did this with Sparkle, the original purchase version is always written in the MAS receipt, even if the user re-downloads the app. Receipt parsing is iffy and we had a bug, mainly because the App Store test environment (also called sandbox) always puts 1.0 in the original purchase version so you can’t really test multiple cases

Would you be willing to share the code that gets this information from the receipt? Or at least give some hints to keep other from making the same mistake?

2. that means you never released an update since the sandbox became mandatory? AFAIK the next version you release will need to be sandboxed.

No, that's what I meant by "grandfathered". I only fixed bugs since, and that allowed me to keep releasing updates (and let's just assume my IAP change is not an issue either because it's effectively not a new feature, which are forbidden to such apps, but rather a change of pricing, which is allowed).

So the question remains yet to be answered: Does IAP work without sandboxing? I see no reason why it shouldn't but you never know with Apple...


--
Thomas Tempelmann, http://www.tempel.org/
Follow me on Twitter: https://twitter.com/tempelorg
Read my programming blog: http://blog.tempel.org/

[James Lee [e-mail] [macsb]]

I would be interested in hearing more about how any of you are handling serial generation, distribution, and updates. We seem to have hit a brick wall on Sparkle updates in our hybrid Carbon/Cocoa app. I can provide details if you are interested. Any work-arounds for Sparkle? Is it still working for anyone? What are the alternatives?

Thanks in advance,
Jim Lee at Tropical


Cheers,

James Lee
904-382-9646
***@me.com

[[e-mail] [macsb]]

Post by James Lee ***@mac.com [macsb]
I would be interested in hearing more about how any of you are handling serial generation, distribution, and updates. We seem to have hit a brick wall on Sparkle updates in our hybrid Carbon/Cocoa app. I can provide details if you are interested. Any work-arounds for Sparkle? Is it still working for anyone? What are the alternatives?

Sparkle is working fine for me - what kind of problems are you having?

My serial number generation is homegrown - I've found that the only really workable scheme is to have the software ping my server and request a license confirmation before it unlocks. That makes it so that the serial numbers are completely arbitrary and don't depend on any sort of secure encoding - whatever the user puts in just has to verify with my sales database on the server side. So when a sale goes through, I generate a relatively simple license code and record it alongside their name, email address, etc. When they enter it, it gets checked and approved if it matches. That also allows me to count the number of activations per license, track the number of actual installs when it's included with a bundle, etc.

So now all the illegal copies of my software are binary hacks rather than people running cracked serial numbers from a keygen - which is a bit better, I suppose.

- Jon

[Christopher Forsythe [e-mail] [macsb]]

Does your app work as-is with sandboxing, before you go adding in IAP?

Post by Thomas Tempelmann ***@gmail.com [macsb]
I am considering turning my pre-paid app into one that's available for
free, with the option to buy an upgrade later via IAP in the App Store. Has
anyone accomplish this yet?
1. How can my app detect that a user has fully paid for it before I
switched to IAP? E.g, can I find some purchase date in the receipt, or is
there some way to set up IAP so that previous owners get the full license
when they do "restore purchases"?
2. My app is "grandfathered" in, not needing Sandboxing. Will IAP work
without sandboxing?
3. What are good and bad approaches to get people to buy the upgrade via
IAP? In my indie version, I put up a nag screen occasionally and show a few
big "unpaid" button in their face constantly. But I guess those won't be
allowed in the App Store. So what's a good technique there?
--
Thomas Tempelmann, http://www.tempel.org/
Follow me on Twitter: https://twitter.com/tempelorg
Read my programming blog: http://blog.tempel.org/

[Thomas Tempelmann [e-mail] [macsb]]

Post by Christopher Forsythe ***@growl.info [macsb]
Does your app work as-is with sandboxing, before you go adding in IAP?

No, the app uses features that are not available in Sandbox, and without
them the app is useless.

[Chris Smolinski [e-mail] [macsb]]

I doubt you’ll be able to get an update adding IAP approved without sandboxing.

Chris Smolinski
Black Cat Systems
http://www.blackcatsystems.com

Post by Christopher Forsythe ***@growl.info [macsb]
Does your app work as-is with sandboxing, before you go adding in IAP?
No, the app uses features that are not available in Sandbox, and without them the app is useless.
--
Thomas Tempelmann, http://www.tempel.org/
Follow me on Twitter: https://twitter.com/tempelorg
Read my programming blog: http://blog.tempel.org/