Closed sarsonj closed 1 year ago
I found a few problems with this issue:
Thanks for reporting, @sarsonj. As a workaround, you may try to follow step 3 here by setting the FirebaseDeepLinkPasteboardRetrievalEnabled
key to NO
in your app's Info.plist
file.
Thanks for reporting, @sarsonj. As a workaround, you may try to follow step 3 here by setting the
FirebaseDeepLinkPasteboardRetrievalEnabled
key toNO
in your app'sInfo.plist
file.
@rizafran , won't that have the side effect of reducing FBDL's ability to match the install and retrieve the universal link data on first launch?
Yes, it will. Currently with FDL you can have either exact matching and pasteboard popups or fuzzier matching and no popups.
Yes, it will. Currently with FDL you can have either exact matching and pasteboard popups or fuzzier matching and no popups.
@morganchen12 , It seems like there may be a third way according to https://developer.apple.com/wwdc22/10096:
In iOS 15, when an application programmatically accessed the pasteboard without using system provided Paste interfaces, a banner would appear to indicate that the pasteboard was accessed. New to iOS 16, the system behavior has changed. Now, instead of a banner, we will display an alert that asks for permission to use the pasteboard. System paste interfaces that the users interact with provide implicit access to the pasteboard and will avoid the alert. If you have custom paste controls, you can replace them with the new UIPasteControl that looks and behaves like a filled UIButton. It is enabled whenever the pasteboard gets content compatible with the control's paste target.
It seems like if developers create a paste button (that Apple are looking for interactions with at runtime?), and some CTA UI around it explaining why to tap it, we can avoid the popup. For now, this is what I'll be proposing to my UX team.
Big picture thinking: can the workflow of FDL change such that the copy/paste consent of the preview page move its way from before app install to within the app itself? This would be a big change in how we work with FDL today, but maybe a necessary one to preserve everyone's desired UX?
It seems like if developers create a paste button (that Apple are looking for interactions with at runtime?), and some CTA UI around it explaining why to tap it, we can avoid the popup. For now, this is what I'll be proposing to my UX team.
Well, we can even use UIPasteControl instead of UIButton with label "Next" in our onboarding wizard, but I am not sure that it is what Apple intended this new control to be used for.
I am worried that any use that will not be close to "paste" usage will be rejected sooner or later during App Review.
But is'nt there any other way to attribute link after app installation? Don't use AppsFlyer or others different technique?
@sarsonj
Well, we can even use UIPasteControl instead of UIButton with label "Next" in our onboarding wizard, but I am not sure that it is what Apple intended this new control to be used for.
Yes, and we shouldn't be tricking users to paste here. We should be showing some info around the paste button asking them something along the lines of "tap paste to continue where you left off" or whatever is appropriate for your use-case. From the WWDC what's new in privacy talk, It sounded like a button with a paste icon was sufficient.
But is'nt there any other way to attribute link after app installation? Don't use AppsFlyer or others different technique?
Yes, and in fact FDL already does this with the pasting option turned off. It's called something like "probabilistic matching" depending on what the vendor wants to call it (Adjust also does this), where it tries to build a fingerprint of your device based on time, ip, screen-size, OS version, etc. It works, but it's not 100% guaranteed to work like the pasting method does.
@sarsonj would you be up for a short call regarding your use case w/ FDL?
@cpsloal was there a call with @sarsonj regarding this?
Please see https://developer.apple.com/videos/play/wwdc2022/10096 @9:24-11:19 for context about how Apple will offer apps the chance to remove the need for the paste alert if they implement a paste button confirming user intent via UIKit paste controls.
This can come earlier, but marking the milestone to make sure we review before the Firebase 10 release.
We finally do tests in our app and we can live with "weak" match type in most cases and in the case where not, the processing will not be as automatic as now.
However, we realised, that now we can enable or disable pasteboard usage globally, not only for iOS 16 users - the property is taken from Info.plist. Or did I miss something, is it possible to decide it on application level?
We just hit this issue and it is going to be very problematic for our solution as we found that by using the weak matching in the past there was about a 20% failure rate.
My team is experimenting with a mixture of using Firebase Dynamic Links and App Clips to achieve 100% attribution. Will update here if it proves successful.
Following. That extra paste warning on app install is sure to confuse a lot of users - and many will say no, as well.
Apple does not seem to realize outside of California, people care way more about being actually able to use an app vs. privacy protection.
Wonder if there's a solution in Flutter with a custom paste / next button - that would be extremely appropriate for our use case.
@abhi0987 , we found that using App Clips in conjunction with dynamic links worked, although our product team was not happy with the number of popups that the user needed to go through to achieve the desired effect.
@asowers1 How are you using App Clips in conjunction with dynamic links when Firebase specifically mentions that dynamic links cannot send users to App Clips when users have not installed the App (deferred dynamic link)? Firebase docs
@abhi0987 , what we did was configure the Firebase dynamic link to route to a specific path on our website; not our app. When the browser hits this path on our website, iOS presents an App Clip to the user. When the App Clip launches, it will need to write data to a shared preference group or keychain so that the data you expect is available in your app bundle when users convert to using your full app. One thing we did not need to do for our use-case was inject data into the App Clip from our site; all we needed was the context of launching the App Clip from a specific route, so I don't have a solution for that if that's what you're looking for, although there may be one and I'd be curious to hear if you find a way. You can learn more about configuring App Clips on your site here: https://developer.apple.com/documentation/app_clips/associating_your_app_clip_with_your_website
@asowers1 Could you explain me what is the need for FDLs then in your use case? Cause the way I see it, you are not able to track attribution neither serve dynamic content using FDL.
It would be great to have this issue fixed. Having this copy paste popup is not a viable solution for most of the usecases.
Can the fuzzier could be a fallback approach instead of a switch @rizafran in the case the copy paste is not successfull?
@abhi0987 , what we did was configure the Firebase dynamic link to route to a specific path on our website; not our app. When the browser hits this path on our website, iOS presents an App Clip to the user. When the App Clip launches, it will need to write data to a shared preference group or keychain so that the data you expect is available in your app bundle when users convert to using your full app. One thing we did not need to do for our use-case was inject data into the App Clip from our site; all we needed was the context of launching the App Clip from a specific route, so I don't have a solution for that if that's what you're looking for, although there may be one and I'd be curious to hear if you find a way. You can learn more about configuring App Clips on your site here: https://developer.apple.com/documentation/app_clips/associating_your_app_clip_with_your_website
Hot did you achieve the app clip to show up automatically?
Up
@eeoom , https://developer.apple.com/videos/play/wwdc2021/10012/ 3:33
Is there anyone who tried with having FDL and PasteboardButton to avoid the popup. I tried having a pasteboard button on the initial screen, but still i get the dialog.
PasteButton(payloadType: String.self) { strings in print(strings[0]) } .labelStyle(.iconOnly) .circleCrop() .tint(Colors.primaryBackground) .frame(width: 50, height: 50)
Is there anyone used pasteboardbutton and avoided the dialog ? Branch also using this approach but doesn't work for me
It seems like if developers create a paste button (that Apple are looking for interactions with at runtime?), and some CTA UI around it explaining why to tap it, we can avoid the popup. For now, this is what I'll be proposing to my UX team.
@asowers1 did you succeed with this approach or have example of this approach . I tried the same but i still get the dialog
I have some troubling news there.
Firebase Dynamic Links is no longer recommended for new projects. In the future, the Dynamic Links service will shut down, but you will have at least 12 months from the announcement date to migrate. Around the end of Q2-2023, we will announce more information.
Yes
I have some troubling news there.
Firebase Dynamic Links is no longer recommended for new projects. In the future, the Dynamic Links service will shut down, but you will have at least 12 months from the announcement date to migrate. Around the end of Q2-2023, we will announce more information.
Yes I am aware of that too. But we have got time to change to another provider.. so meantime trying to find a solution with FDL :(
The Firebase Dynamic Links service will be shutdown on August 25, 2025. In the meantime, only critical or security issues will be fixed in the SDK.
More at https://firebase.google.com/support/dynamic-links-faq
[REQUIRED] Step 1: Describe your environment
CocoaPods
iOS
[REQUIRED] Step 2: Describe the problem
Steps to reproduce:
I understand, that this is new iOS 16 privacy restriction and it is used instead of not so disruptive small warning that was presented in iOS 15. However, looks like we have to found workaround for this functionality, because showing this dialog to every new user is the problem.