Armchair alert doesn't show up #26

New Issue

adam · 2025-12-29T18:28:18+01:00

adam commented

2025-12-29 18:28:18 +01:00

Originally created by @odedharth on GitHub (Jan 17, 2016).

Hi,

I set Armchair this way:

            Armchair.appID("1044050208")
            Armchair.significantEventsUntilPrompt(0)
            Armchair.daysUntilPrompt(0)
            Armchair.usesUntilPrompt(3)

And expected Armchair will show up on the third sessions, but nothing happened.

Originally created by @odedharth on GitHub (Jan 17, 2016). Hi, I set Armchair this way: ``` Armchair.appID("1044050208") Armchair.significantEventsUntilPrompt(0) Armchair.daysUntilPrompt(0) Armchair.usesUntilPrompt(3) ``` And expected Armchair will show up on the third sessions, but nothing happened.

adam closed this issue

2025-12-29 18:28:18 +01:00

adam commented

2025-12-29 18:28:19 +01:00

@coneybeare commented on GitHub (Jan 17, 2016):

Did you step through the code to see why?

@coneybeare commented on GitHub (Jan 17, 2016): Did you step through the code to see why?

adam commented

2025-12-29 18:28:20 +01:00

@odedharth commented on GitHub (Jan 18, 2016):

@coneybeare which object should I debug?

@odedharth commented on GitHub (Jan 18, 2016): @coneybeare which object should I debug?

adam commented

2025-12-29 18:28:21 +01:00

@coneybeare commented on GitHub (Jan 18, 2016):

I would place your breakpoint either in showPrompt or ratingConditionsHaveBeenMet

@coneybeare commented on GitHub (Jan 18, 2016): I would place your breakpoint either in [showPrompt](https://github.com/UrbanApps/Armchair/blob/master/Source/Armchair.swift#L995) or [ratingConditionsHaveBeenMet](https://github.com/UrbanApps/Armchair/blob/master/Source/Armchair.swift#L1041)

adam commented

2025-12-29 18:28:21 +01:00

@grizzly commented on GitHub (Jan 19, 2016):

same here, seems both of your mentioned functions are never called....

your incrementUseCount() only increments the values but never calls showPromt (or did i miss something?)

@grizzly commented on GitHub (Jan 19, 2016): same here, seems both of your mentioned functions are never called.... your incrementUseCount() only increments the values but never calls showPromt (or did i miss something?)

adam commented

2025-12-29 18:28:21 +01:00

@coneybeare commented on GitHub (Jan 19, 2016):

incrementUseCount is never called directly by the user, but is called before a call to showPrompt in incrementAndRate. Can you reproduce what you are seeing in the example project with a basic setup?

@coneybeare commented on GitHub (Jan 19, 2016): `incrementUseCount` is never called directly by the user, but is called before a call to `showPrompt` in `incrementAndRate`. Can you reproduce what you are seeing in the example project with a basic setup?

adam commented

2025-12-29 18:28:22 +01:00

@coneybeare commented on GitHub (Jan 19, 2016):

Actually, I see why this might be happening. Sorry it took me some time to reacquaint myself with the code.

The application lifecycle notification callback methods only call incrementUseCount and not incrementAndRate. This is fine and by design so that the user is not bombarded with a review prompt immediately after opening the app, where chances of a review are lower. The library was really designed to keep significant events as the primary trigger for a review, when the user satisfaction is highest. A user is more likely to review if you do so at a point where it does not interrupt their flow. They came to your app for a reason, and now once they are in, you are asking them to stop doing that reason while they help you out by writing a review. Let them finish that reason (beat a level, do a thing, open stuff, check this or that) then ask them upon completion of said significant event.

But, if you want to keep significant events at 0, you should manually add showPromptIfNecessary wherever it makes sense in your app. I would recommend using significant events to trigger instead though as you will get better clickthrough rates to the App Store.

This presents a minor problem for me because the default for this value is 0 (has to be) so I may add a condition to the lifecycle callbacks that checks whether or not this value is 0 and perhaps call for a prompt. I have to think about it because it could cause unintended prompts for others. My gut tells me no and that the solution is for you to add the showPromptIfNecessary call to your setup, and add this info to the readme.

Either way I decide, you have a solution now.

@coneybeare commented on GitHub (Jan 19, 2016): Actually, I see why this might be happening. Sorry it took me some time to reacquaint myself with the code. The application lifecycle notification callback methods only call `incrementUseCount` and not `incrementAndRate`. This is fine and by design so that the user is not bombarded with a review prompt immediately after opening the app, where chances of a review are lower. The library was really designed to keep significant events as the primary trigger for a review, when the user satisfaction is highest. A user is more likely to review if you do so at a point where it does not interrupt their flow. They came to your app for a reason, and now once they are in, you are asking them to stop doing that reason while they help you out by writing a review. Let them finish that reason (beat a level, do a thing, open stuff, check this or that) then ask them upon completion of said significant event. But, if you want to keep significant events at 0, you should manually add `showPromptIfNecessary` wherever it makes sense in your app. I would recommend using significant events to trigger instead though as you will get better clickthrough rates to the App Store. This presents a minor problem for me because the default for this value is 0 (has to be) so I may add a condition to the lifecycle callbacks that checks whether or not this value is 0 and _perhaps_ call for a prompt. I have to think about it because it could cause unintended prompts for others. My gut tells me no and that the solution is for you to add the `showPromptIfNecessary` call to your setup, and add this info to the readme. Either way I decide, you have a solution now.

adam commented

2025-12-29 18:28:22 +01:00

@grizzly commented on GitHub (Jan 19, 2016):

yes thats the point. if you only want to have the use count (as odedharth describes) there is no call of showPromt. Your class is incrementing the useCount value but then never tries to fire the showPromt.

Other cases have this call: if someone calls userDidSignificantEvent, the function itself calls incrementSiginificantEventAndRate, which calls showPromt.

so do we have to call showPrompt(ifNecessary.... explicid?

best
stefan

@grizzly commented on GitHub (Jan 19, 2016): yes thats the point. if you only want to have the use count (as odedharth describes) there is no call of showPromt. Your class is incrementing the useCount value but then never tries to fire the showPromt. Other cases have this call: if someone calls userDidSignificantEvent, the function itself calls incrementSiginificantEventAndRate, which calls showPromt. so do we have to call showPrompt(ifNecessary.... explicid? best stefan

adam commented

2025-12-29 18:28:23 +01:00

@coneybeare commented on GitHub (Jan 19, 2016):

Yes, that is the solution (for now) as I detailed in length above. If you are using significant events at 0 (highly unadvised) then you will have to call showPromptIfNecessary() from wherever it makes sense in your app. Fixing the lifecycle callbacks so that it automatically shows on app open or launch would introduce unwanted behavior for just about everybody who is using significant events > 0.

@coneybeare commented on GitHub (Jan 19, 2016): Yes, that is the solution (for now) as I detailed in length above. If you are using significant events at 0 (highly unadvised) then you will have to call `showPromptIfNecessary()` from wherever it makes sense in your app. Fixing the lifecycle callbacks so that it automatically shows on app open or launch would introduce unwanted behavior for just about everybody who is using significant events > 0.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/Armchair#26