fix(mobile): deeplinks #2870
fix(mobile): deeplinks #2870
Conversation
Package Changes Through 559ef3cThere are 10 changes which include fs with patch, fs-js with patch, nfc with patch, nfc-js with patch, opener with minor, opener-js with minor, os with patch, os-js with patch, store with minor, store-js with minor Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
(some swift plugin api improvements needed)
|
can't we automatically infer |
we can infer that it's a web link, but we still cannot say that its most definitely an app link, as suggested by the linked resource |
|
missed that mb 😛 |
if we wouldn't want to support web links (app links without the verifification) we could derive it from the scheme. The current appLink config is also a breaking change. Your change makes autoVerify opt-in while before it was always enabled so if people were to simply bump the plugin version their app links would break. |
Only true for iOS. macOS is handled by tauri's cli. |
Not for universal links since ios doesn't support android's "inbetween" web links. You either have a custom scheme or use verified universal links. I'm not 100% sure if this is actually true, that's just based on what apple says in their docs, the actual behavior may be different 🤷 |
true, i thought of that when i defined it but i thought i'll just make the pr as is and ask if this could perhaps be in the next patch or minor version release for the plugin, change it accordingly so rn i can just set the default to true, or would you like something different? |
|
hmm yeah i think default true is fine |
i am not sure, i just read the docs yesterday lol but rn within the scope of this pr i am just checking if any of associated domains have app_link true and then deciding whether to generate the entitlements or not, none of the other particulars are handled in this one, i was mainly concerned with custom url schemes |
|
yeah i get that. the problem with this is cross-platform compatiblity. What if a dev wants to use web links on android but universal links on ios? probably not realistic but still a possible situation. |
i suppose they'd have to setup separate associated domains, although it really does seem like an edge case scenario |
sosweetham
force-pushed
the
feat/deep-links
branch
from
4476832 to
139f157
Compare
that's not what i wanted to hint at. right now if a dev wants to do that and uses tauri.conf.json instead of separate tauri.ios.conf.json and tauri.android.conf.json they will end up with broken links on ios. On a similar note i think we can also make the android implementation ignore the appLink config if the scheme is != http(s) to prevent misconfigurations but i guess that's not as important and raises the question of how much logic we should handle and how much we should just report back as errors. |
Hmm i understand what you mean, but as a developer, this implicit behaviour that, I am building for ios so the framework assumes that I support universal links and have already setup the surrounding infra with all the association files and assetlinks and what not is quite a bit of a stretch no? But ofc this is an opinion not a statement lol That's why I went with an opt in approach than out but the breaking change argument made sense so I backtracked it |
imo docs would be better all round, the linking stuff has a lot of components outside of tauri too so it would be better to aggregate resources/docs for the devs too than to leave implied knowledge via the plugin behavior mutating depending on just the configs unnecessarily |
|
wait so a deep link can also have a host? that's crazy 😂 EDIT: if that's true we need to tweak the validation a bit |
|
it's more of a url spec thing from what i made of it, it's supposed to be called authority, but cuz http/ftp/sftp urls are common and in those the authority is generally a host... i suppose the term got coined as host, most url parsers dont call the thing authority either it's generally called host but rn it's also possible to say, implement a ftp/sftp or whatever compatible mobile app with the plugin, so i suppose in a use case like that, calling it host makes more sense, so it can be a deeplink and also have hosts and stuff at the same time... really depends on the usecase i am not really sure i would change it though cuz someone could have deeplinks with a common "host" (authority) and build upon it with paths, identifiers and whatever, currently i dont think mentioning the "host" would cause any harm, provided the scheme is explicitly not, http or https |
|
i guess deep links are more or less free form so if you want it to have a host nothing's stopping you. But at least android explicitly allows a host config for deep links in the intent filter - no idea if it actually makes a difference though. But that's kinda why you were able to use deep links before this pr on android as well (seems like autoVerify is ignored for non http(s) schemes - or i was lied to) - "kinda" because you could set host to an empty string as well lol. iOS doesn't care, it only wants to know the scheme (for deep links). p.s. your cleanup removed android web link support, just in case. |
|
the technically correct thing might be to have either host or authority for correct semantics, but i dont really think it would make a difference |
ah i found what messed it up, the property in the config got removed for some reason? |
|
oh ok it shifted to the is app link function, i'll add the property back to fix the regression |
hmm does this mean that a lot of the manual Info.ios.plist stuff on the other plugins can finally be automated 👀 |
yesssssss |
* feat(tauri-plugin): add build::mobile::update_info_plist needed for tauri-apps/plugins-workspace#2870 * Update .changes/update-info-plist.md
Issues faced
The deep link mobile config had the following problems:
Fixes implemented
TL;DR
"http"or"https"schemes (which do).app_linkflag lets you explicitly opt-in to AppLink/UniversalLink behavior.app_link: true, avoiding unnecessary configuration.src-tauri.Associated Domain Validation
The "host" config value is now optional to provide, the validation at build time will fail and panic if, the config declares the deep link with the default scheme,
["http", "https"](web link) which requires a host as declared athttps://developer.android.com/training/app-links
even so, this is not enough information to determine whether the developer intends to support app links/universal links, which require additional logic like entitlements file generation on ios
thus a new
app_linkproperty has been introduced to determine whether the particular "AssociatedDomain" is an AppLink/UniversalLink or not.Apple does not support plain old non secure http transport, so the plugin will throw a warn at build time but will NOT panic.
Conditional Entitlements Generation
This leads to the next fix, entitlements file is now conditionally generated, not all types of deeplinks on ios/macos need those.
Known Issues
Ios/Macos plist files are not generated automatically like android,
and also no automatic registration is performed post build, developer must add the relevant(they are now generated if the patch is applied in the cargo.toml via the commit used in this pr)Info.plist(mac) orInfo.ios.plist(ios) to thesrc-taurifolder manually containing the associated schemes declared in thetauri.conf.jsonas can be observed from the example provided/updatedI was not able to bring ios to parity with android wrt intents, i tried AppDelegate but I just kept running into weird issues, so i just scratched that otherwise i would have loved a native plugin for all sorts of events data lol