I am using Mixpanel tracking in an iOS project. I can successfully send Mixpanel push notifications to many iOS clients. However, when a client logs out of my app, I no longer wish for them to receive Mixpanel push notifications.
In Mixpanel I can register many device tokens for one user with the function call
-addPushDeviceToken:
However, from what I can see, I cannot unregister a single token for a given user. The closest function I have found is:
-removePushDeviceToken
However this function will obliterate all device tokens for a given user.
The same is true for the Mixpanel web API - namely the function $unset will obliterate the entire property.
How can I handle users logging out of my app on one device without affecting Mixpanel push notifications on their remaining devices?
Thanks,
Update 9/12: as of Mixpanel 3.0.3 the function is now implemented!
Mixpanel.mainInstance().people.addPushDeviceToken(tokenData)
Mixpanel.mainInstance().people.removePushDeviceToken(tokenData)
Mixpanel currently doesn't provide a way to remove a specific token. It has been discussed on their github as an issue, so I guess what you (and I) can do is to check periodically if they update it.
See https://github.com/mixpanel/mixpanel-iphone/issues/164 and https://github.com/mixpanel/mixpanel-iphone/pull/419
Related
I've added Push Notification to my IONIC App using this tutorial: Using Push Notifications with Firebase in an Ionic + Angular App.
For Android all works fine, but on IOS notifications are not delivered. In my Firebase console there is an information that notification was sent, but nothing appeared on my IPhone. The app is installed by TestFlight (Internal Tests).
Questions would be:
How can debug or somehow detect where might be the problem?
If there is no way to check it, maybe there is a list of common problems with that?
Check if iOS push notifications permissions are enabled
Check to see if you receive a push notifications token when you run your app (it doesn't work on simulator, must be real device)
Register push notifications key on your apple developer account and add the key to your firebase app.
Push notifications on iOS is a bit tricky. This tutorial helped me: https://devdactic.com/push-notifications-ionic-capacitor/
Check on the client that it sends a push token to the server.
Check on the server if any errors are reported when pushes are sent to apple.
Check in the console logs whether and pushes appear on your client device.
Check in the app if any push notifications are received.
In addition to following the advice already listed and assuming that you have followed the linked tutorial in detail, what helped me to understand the problems related to my experience with push notifications is to check the validity of the token received from the
// On success, we should be able to receive notifications
PushNotifications.addListener('registration',
(token: PushNotificationToken) => {
alert('Push registration success, token: ' + token.value);
}
);
is to contact this link https://iid.googleapis.com/iid/info/{{Token}}?details=true by entering your received token. If the response contains an error your configuration is incorrect and the error should be found in the changes applied to AppDelegate.swift. Furthermore, I noticed that not always the listener to capture the token does not always activate after a registration and I had to insert in my app also the #capacitor-community/fcmplugin that offers the method
FCM.getToken ()
.then ((r) => alert (`Token $ {r.token}`))
.catch ((err) => console.log (err));
which always returns the token according to my tests, this solution has been applied only for iOS, moreover this plugin also allows you to manage topics efficiently. It's definitely not a clean solution but for me it solved a problem I've been struggling with for days. The last advice I can give you is to pay attention to the activation and deactivation of the listners and to try to use setTimeout () to understand if your failure to work derives from an incorrect initialization of the resources and if these must be moved to the app states where the resources required by the various methods are available.
Our app uses Firebase phone auth. The App Store review has rejected the app due to pushes being required:
Guideline 4.5.4 - Design - Apple Sites and Services
We noticed that your app requires push notifications in order to function.
Specifically, we noticed if the Push Notifications setting was not enabled on our device, we encountered an error message after entering our phone number within the app.
Next Steps
Push notifications must be optional and must obtain the user's consent to be used within the app.
And they've also attached the screenshot that depicts Firebase error "Remote notifications and background fetching need to be set up for the app [...]"
Firebase documentation states that APNs notifications are absolutely required for phone auth to function:
https://firebase.google.com/docs/auth/ios/phone-auth
To use phone number authentication, your app must be able to receive APNs notifications from Firebase. When you sign in a user with their phone number for the first time on a device, Firebase Authentication sends a silent push notification to the device to verify that the phone number sign-in request comes from your app. (For this reason, phone number sign-in cannot be used on a simulator.)
However App Store review guidelines state that Push Notifications must not be required in order for the app to function: https://developer.apple.com/app-store/review/guidelines/
4.5.4 Push Notifications must not be required for the app to function, and should not be used for advertising, promotions, or direct marketing purposes or to send sensitive personal or confidential information.
Users need to sign in before they can use the app (the app is about sending digital GIF invitations to your guests and sharing photos), which is why Push Notifications are basically required for the app to function, if the sign in method is Firebase phone auth.
We have tested the app a lot, and the authentication works without a problem when push notifications are enabled (on real devices, both in distribution Ad Hoc builds with production environment and development builds with sandbox environment).
Come to think of it, how did App Review team even disable Push Notifications? The notification center setting does not stop actual pushes, it just doesn't display them.
We have tested with this setting off, and firebase phone auth works fine, pushes are still coming through as expected.
I am very surprised with this issue, as Firebase is a huge service provider. Did anyone else encounter this issue?
Are there plans to remove APNs requirement for phone auth? Is there maybe some other way to use Firebase phone auth without pushes?
Firebaser here. We have released an updated Firebase Auth SDK, 4.2.0, as Leetmory mentioned, which should hopefully resolve these issues going forward.
The issue was caused by the fact that the Firebase Auth SDK using APNs to validate the request - this is to minimize the risk of SMS spam abuse or similar. The validation uses a silent APNs notification, so doesn't require explicit user consent for iOS 8 and above. However, this still failed if APNs was completely disabled, as in this review case.
The 4.2.0 release introduced the facility to use a reCAPTCHA prompt inside an SFSafariViewController (or webview for older iOS) to prevent abuse if APNs isn't available. We don't expect this to happen very much, but it accounts for the unusual state encountered here. It also enables support for testing Firebase Phone Auth on the simulator!
You'll notice there is a new uiDelegate parameter on the verifyPhoneNumber method. In most cases you wont need to use this, but it is part of the fallback verification.
What you will need to do, if you haven't already, is add the REVERSED_CLIENT_ID (from the GoogleService-Info.plist) as a custom URL scheme. This will allow the reCAPTCHA view to return validation to your app.
There is a gotchas to be aware of in the current version though:
In the callback from verifyPhoneNumber you'll need to redispatch to the main thread, using DispatchQueue.main.async {} - this will be fixed in the next version of Firebase Auth!
Other than that, things should work as normal! We definitely recommend supporting silent push where ever possible to ensure the best user experience.
For a full walk through, see the full Phone Auth developer guide.
UPD: Firebase 4.2.0 has rolled out, which fixes the issue. You will need to add your reverse-client-id which looks something like this: com.googleusercontent.apps.123456-abcdefg99 to URL schemes in your Info.plist, and you are set.
To find this
value, open the GoogleService-Info.plist configuration file, and look for the
REVERSED_CLIENT_ID key.
Firebase support has confirmed this bug and has given the response to this issue:
to me
Thank you for the detailed information Leet. This is indeed an odd situation, and our Phone Auth engineers are taking a look. I'll get back to you as soon as I have an answer.
Best,
Jeff
to me
Hi Leet,
Our engineers are working internally on a long-term fix for this, but in the meantime, would like to meet with you to see if we can figure out a workaround.
It appears that there is indeed a bug in Firebase phone auth / Firebase UI.
I contacted Firebase support and here's an excerpt:
In terms of the concern around users disabling push notifications - Disabling push notification for the app by the user does not normally prevent users from signing in using their phone number with Firebase Auth. Our requirement is that the app must set up and enable push notification, not the user. Regardless of if the user accepts or declines your app's push notification prompt phone auth will continue to work since we use silent pushes that don't require any action from the user.
I researched further and found that silent push notifications do indeed arrive to the device even when the user explicitly disables push notifications. To disable silent push notifications you would need to go to Settings -> Your App -> Background Refresh to disable it. See Is Silent Remote Notifications possible if user has disabled push for the app?
So you can tell the App Store Review team that your login will only work when Background Refresh is enabled. I don't believe this violates their terms.
EDIT
After some testing, it appears that phone auth can work when Background Refresh is disabled. However, it works for me because Firebase already has access to my APNS device token. I have found no way to disassociate my device token from Firebase - they provide no API for it. This unfortunately makes it impossible to test the scenario where a new user disables Background Refresh and Remote Notifications before doing the phone auth which I believe may be the cause of the error.
EDIT 2
I can confirm that on a fresh device with a fresh install of our app, if you disable Background Refresh then Firebase Phone Auth will not work. Once you enable it, it will work again.
The reason is that the SDK likely calls [[UIApplication sharedApplication] registerForRemoteNotifications] which is ignored by the system if a user manually disables the Background Refresh and Notifications settings.
Unfortunately there is no workaround until Firebase releases a new SDK which does not require APNs.
If I enable FCM swizzling in iOS, I found that the FCM token is still there even when user turns off the device notification setting for my app(probably saved in app data).
It seems not logical to manage this setting anymore inside the app since FCM takes care of that part for me.
I have 2 questions:
Do I need to create a Notification setting switch inside my app so that user can turn on or turn off the notification?
If I need to do #1, how do I call the FCM registration manually?
I know that this api [FIRApp configure] will do everything automatically.
I think following pointers should help you answer the question.
Generically (Regardless of which SDK you use), generating and maintaining deviceToken is completely decoupled from the permissions prompt and the response given to that prompt. There are use cases like silent pushes which can be used to send pushes to the device without even asking the user for permissions (well, these pushes invoke your app for data refresh, but can not show anything on UI)
Even when we prompt the user for permissions, denying the permission does not invalidate the token that has been generated already. The UI based pushes(Alert, Badge, Sound) sent in this case, will still land on the device but iOS will not render those notifications after checking the user's permissions.
So based on above data points, to answer your question,
Do I need to create a Notification setting switch inside my app so that user can turn on or turn off the notification?
Yes, its certainly a good idea to have it so, but note that after the initial permissions prompt the same dialog wont be shown again, hence its better to redirect the user to settings of your app where he can re-enable the notification permissions, refer to this thread on implementing the same.
If I need to do #1, how do I call the FCM registration manually? I know that this api [FIRApp configure] will do everything automatically.
I don't have experience in using Firebase directly, but, mostly you don't need to tell anything to Firebase, because it already has a token and it can sent pushes to this device anytime, the next push that comes after user modifies the setting will automatically show up according to latest preferences of the user.
We are currently implementing push notifications (for IOS only for now), and we are planning on using Urban Airship. We want to send a push message to a device if they have our app installed and push enabled, and send an SMS message if not. Our users pay for the notifications, so we want to make sure as much as possible that they always get either a push message or a SMS message. Sending the push messages itself works fine, but I am confused about how to keep track of who we can actually send push messages to.
As far as I know, the only way to really making sure if a user can receive push messages is to, before sending a push message, make an additional call to the urban airship api to check if the device exists and is active. I would prefer to not do 2 api calls for each push message, so an alternative could be to keep track of all registered devices in urban airship locally, and update that list once per hour or so. However, this would mean the 'active devices list' is not always completely accurate, and that we have to keep track of all registered devices ourselves, which feels like re-implementing a part of urban airship.
Is there any other (better) way to do this? As far as I can see, when I send a push message to urban airship the api always returns that it was sent succesfully, regardless of whether or not a device is active, or if it even exists.
I can't imagine that I am the only one with this problem. Does anyone have a better way of solving it, or am I stuck with the 2 options that I figured out myself?
Urban Airship shares the following two options:
In any case, applications should expect and handle inactive device
tokens properly. We recommend that developers either:
Register the device token every time the application is opened, like our sample app does
Use our feedback API regularly, store inactivated device tokens in your own database, and send registrations when the device token
becomes active again.
If you make an additional call to the Urban Airship to check if the device exists and is active, even then the 'active devices list' may not always be completely accurate because Urban Airship relies on periodic updates from Apple Feedback Service:
Apple tells us that the application has been uninstalled via the
feedback service, which we check on a regular basis.
Also, do remember what Apple has stated about the delivery of Push Notifications:
Important: Delivery of notifications is a “best effort”, not guaranteed. It is not intended to deliver data to your app, only to notify the user that there is new data available.
My app push notification pushing from C# Application using device token.
Once user uninstall app on device, I want to stop the push notification. Yeah of course it's working fine.
Again installed same app. But it is receiving previous user notification without login.
How to solve this problem?…
I have refereed this link http://42spikes.com/post/Sending-Apple-Push-Notifications-from-a-C-Application.aspx
My Question :
1) Is it possible to call any method while uninstalling/installing time? (possible means can I hit web services and reset device token value?).
2) Any Other idea to solve this problem while installing or uninstalling time?
No, there is no method fired when a user uninstalls your app.
Yes,
Apple has a service where you can check wether tokens are still
valid.
The option you want to implement in your C# Application is The Feedback Service:
The Apple Push Notification Service includes a feedback service to give you information about failed push notifications. When a push notification cannot be delivered because the intended app does not exist on the device, the feedback service adds that device’s token to its list. Push notifications that expire before being delivered are not considered a failed delivery and don’t impact the feedback service. By using this information to stop sending push notifications that will fail to be delivered, you reduce unnecessary message overhead and improve overall system performance.