So I want to offer the widget only for paid(IAP) subscribers. Is there a way to lock the widget and unlock if once user has paid?
Widgets are made as separate target and their configuration is independent from user purchase state.
However you can configure how widgets will appear, based on user subscription state and for example disable their content, informing user that he has to be premium to see it's content.
I think it also makes more sense to alter content for widgets instead of hiding it from widgets library - to handle case when user subscription has expired, but user added it already to his screen.
Related
I have a mobile game that I developed with swift. I show some features and views in the next levels. that is, the first installer of the game will not be able to use those views and features. My question is, how can I open these features and views during the app store connect in review process. they will want to see their content.
Turning on/off remotely with firebase remote config. If I do this, existing users will also open. How can I make the views appear only during the in review process?
If there is authentication, create a user with more or less, admin power, such that you give apple the user to authenticate with and they will see the hidden content, otherwise
In your code, with the help of remote config, authenticate any new users anonymously and grant anyone who is authenticated to see the hidden content.
This means when the reviewer gets this specific version of your app, they will be the only one authenticated and therefore see the hidden content and when the review process is done, deactivate the functionality in remote config
I want ask my users to rate my Unity iOS app using the following code
Device.RequestStoreReview()
But this function returns true when the library is present and false otherwise. I want to know whether the user
Allready rated
Clicked "cancel" or clicked "not now"
So that I don't have to ask that to the user every single session
You can make a custom UI with buttons to check if the user wants to review the app or not. If the user decides to give the review you can open the app store with Application.OpenURL. You can then save user action (reviewed, ask later, don't ask again) as a flag in PlayerPrefs. Use this flag in your app to decide when and how often ask the user for a review.
As far as I know there is no way to check if the user left the review or not but if they decide to go to app store, most will leave the review and even if they don't the app just won't ask them again. It is good enough for me.
This approach is also platform independent (as long as you can use Application.OpenURL you can forward your user to any app store/website for a review).
Is it possible to detect if the user pressed the power button two times fast? Apple use the way to confirm an Appstore purchase on the new iPhone X with Face-ID. Is there any API available? Want to use it in an similar case for authenticate via Face-ID.
No. The system itself controls response to the side (sleep/wake/power) button.
iOS accepts a double-tap on side button to prompt for Face ID authentication only during an Apple-mediated financial transaction — that is, to make a purchase from iTunes / App Store, including in-app purchases, or to complete an online Apple Pay transaction. Outside such circumstances, double-tapping the side button either brings up the UI for an in-person Apple Pay transaction or (if the setting for showing Wallet on double-tap is disabled) does nothing.
Your app is welcome to prompt for Face ID / Touch ID authentication in response to any in-app or on-screen event, but not only is there no API explicitly for responding to the side button or other hardware controls, any attempt to repurpose existing API for such reasons probably wouldn’t get past App Review:
2.5.9 Apps that alter or disable the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, or other native user interface elements or behaviors will be rejected.
Our iOS camera app had a paid upfront model i.e., users has to purchase the app on app store. We have
changed it to an in app purchase. The users can download the app for free and try it out. After the user takes 20
photos he/she will be prompted to buy and unless the user purchases he cannot use the app.
We are using firebase analytics to find out the distribution of users who have
paid upfront
still in free trial(haven't taken 20 photos)
bought an IAP
haven't paid after being prompted.
I have created a custom user property for this with 4 different values which represent the above 4 kinds of users.
Firebase says "Properties are effectively sticky event parameters that are automatically logged with every subsequent
call to logEvent. After you set a user property value, it will be associated with every event logged afterwards"
If our user stops using the app after being prompted to buy and never opens the app again firebase will not update the
user property as there may not be any event afterwards. I can log an event just after setting this user property. But if the
user's internet is slow and he quits the app(app not in background) before event is logged I would still lose data.
Please tell me if my understanding is wrong.
I can filter the users who have been prompted by screen_view event. If I can find out users who stopped using the app,
then users who have been prompted to pay and stopped using the app will be the ones who didn't pay.
Is there a way to filter users who have stopped using the app in firebase?
The event after the promotion of the user property will work. Firebase does not fire events to analytics on every hit. It collects a group of events+timestamps that needs to be fired and fire those events in a bundle after the app is closed(goes to background). This is to preserve device battery and improve performance. So slow internet will not cause the event to not fire. Just set the event right after you set the user property.
Imagine a world of widgets where each widget has a unique name / identifier. For example, ABC.
I need to deliver specific content (ABC content) that they bought based on that unique identifier after payment has been confirmed by Apple.
Here's an example: They purchased a Widget, but I need to know what the specific identifier aka name of the widget was that they bought in order to get them the right widget content. Each widget has a unique identifier / name that comes from the server. There are billions of uniquely named widgets.
Ideally, I would send supplemental information with the transaction to Apple so that when the transaction success notification comes back I know exactly which Widget (such as ABC) has been bought.
Is there a way to send supplemental information that is returned to me later or do I need to manage my own queue of product purchases where each purchase has the specific name / identifier of the product? If I have to manage my own collection of attempted Widget purchases, what is good practice on doing that? Do I store an NSMutableArray of SKPaymentTransaction objects to look up later?
(BTW, there are three different kinds of boxes. Each different kind of box has a different cost and thus productIdentifier.) However, only 1 kind of box requires the named Widget feature.
Thanks!
BTW, I studied this documentation and what it links to a lot:
https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40008267
At this time, the answer is to track your own specific product information.
In the context of widgets, have your own queue (NSMutableArray) of specific widgets (or just widget names if that's all you need). This custom Widget queue is referred to after getting the green light (verified receipt) from apple.
In other words, put Widget on your own Widget queue, get green light from Apple, get Widget off of queue, and do what you need to do to deliver content.
All of this is much easier if the management of the custom queue and the interactions with Apple's Store Kit is done by a class called TransactionBroker (or whatever name you wish).