Firebase-ios-sdk: 157240254: Dynamic Links reopens (Universal links) not working consistently on iOS13

Created on 16 Feb 2020  Â·  60Comments  Â·  Source: firebase/firebase-ios-sdk

Step 1: Describe your environment

  • Xcode version: 11.3.1
  • Firebase SDK version: 6.15.0
  • Firebase Component: Dynamic Links
  • Component version: 6.15.0
  • Installation method: CocoaPods

Step 2: Describe the problem

Steps to reproduce:

Dynamic Links are not working consistently on iOS13. I would say approximately 8-10% of our users are having trouble - they get redirected to the continue URL instead of getting taken to the app.

For troubled devices, the AASA file is not downloaded properly when the app is installed, as is detailed in the following topic:

https://forums.developer.apple.com/thread/123554

When running sysdiagnose and exporting, the app data looks like this:

Service: applinks
App ID: TeamID.BundleID
App Version: 1.0.0.0
Domain: domain.page.link
User Approval: unspecified
Site/Fmwk Approval: unspecified
Flags:
Next Check: 0001-01-01 03:26:23 +0000

Patterns field is missing and Site/FMwk Approval is unspecified.

On devices where the AASA file is properly downloaded, it looks like this:

Service: applinks
App ID: TeamID.BundleID
App Version: 1
Domain: domain.page.link
Patterns: {"/":"/_/","exclude":true}, {"/":"/"}
User Approval: unspecified
Site/Fmwk Approval: approved
Flags:
Last Checked: 2020-01-22 18:30:50 +0000
Next Check: 2020-01-27 18:20:51 +0000

Users on the aforementioned apple developer topic seem to have resolved the problem by serving the AASA over http/1.1 rather than http/2.

Can you please advise how best to proceed with this?

We are using the firebase supplied domain.page.link domain so have no control over how the AASA file is served.

We really need a fix for this as lots of users are complaining on app store connect.

Relevant Code:

dynamiclinks

Most helpful comment

Hey all! Thanks for looking into this.
We've had an issue related to dynamic links which may or may not be the same as this thread.
Dynamic links shared through the share sheet, in iMessage, won't redirect when clicked. Looking at the URL that is sent, it's not the deep link and it's not the long URL either, it's the preview URL. When I curl the long URL with no User-Agent, I get a 302 redirect, which leads me to the small preview HTML with the meta tags. When I curl the long URL with the iOS Safari User-Agent, I get the correct 200 response with the HTML/JS to do the App Store redirect.

My guess here is that iMessage is caching the URL _after_ the redirect that occurs because they don't set the same User-Agent as safari. I'm guessing also that you're doing this check for the User-Agent to send a small payload for preview, which is definitely a good idea but it seems like it's breaking all iOS 13 iMessage sharing. I think as a fix you could see what the User-Agent is that iMessage sets when it makes its preview HTTP GET request, and return the full page instead of just the preview. They'll cache just that and everyone's links will work again.

Just fyi, Apple recommends against checking User-Agent on the backend: https://developer.apple.com/library/archive/technotes/tn2444/_index.html (see Consistent metadata for all user agents)

In the meantime, our fix is to share the url.absoluteString instead of the url directly:

let activityViewController = UIActivityViewController(activityItems: [url.absoluteString], applicationActivities: nil)
activityViewController.popoverPresentationController?.sourceView = self.view
self.present(activityViewController, animated: true, completion: nil)

This seems to work in all apps we care about, as they do the link preview request on text as well as URLs (so does iMessage actually).

All 60 comments

I found a few problems with this issue:

  • I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
  • This issue does not seem to follow the issue template. Make sure you provide all the required information.

Hello,

We are facing the same issue in our project. Here are my two cents on this issue:

  1. As stated in Apple's documentation from iOS13 and above AASA must contain new keys and values. Right now, dynamic links support only up to iOS12 AASA format.
  2. Also, it seems Apple promotes the AASA file to reside in /.well-known/ so the URL would be instead .

Hello,

Same issue here

@dmandar, this seems like a backend issue. Can you confirm? If it is, assign it to me or Riza and we'll file a bug to the backend team.

@morganchen12 yes, this needs some changes to the way the AASA file is created. Please add https://developer.apple.com/documentation/safariservices/supporting_associated_domains_in_your_app?language=objc in the bug and cc me on it.

Filed b/149877386

@robereng quick sanity check:

  • Can you check the firebase project setting on firebase console is consistent with cloud project on developer console (or pantheon)?
  • Also, can you share the generated AASA file contents?

Hi @morganchen12

The project settings (project name & project id) are identical on both consoles.

The AASA generated by firebase is here:

https://shapedbyiris.page.link/apple-app-site-association

Thanks,
rob

Hey guys, same issue here.

My AASA generated by firebase.

https://dragonvcapp.page.link/apple-app-site-association

Hey all, not sure the relevance here, but I was also having issues with my Universal links and learned it was because i needed to implement SceneDelegate's (scene(_:continue:)) function.
https://developer.apple.com/documentation/uikit/uiscenedelegate/3238056-scene

You must support that and the App Delegate equivalent. After I refactored my project to use SceneDelegate and implemented that, everything was working again for Universal links (although i broke other things in the process).

If everyone has already done this, then please disregard

@sschizas, we confirmed that the same AASA is also hosted from /.well-known/ . The AASA file format needs to support iOS12 and older devices by default. Per the apple doc https://developer.apple.com/documentation/safariservices/supporting_associated_domains_in_your_app?language=objc : "Tip

iOS 12 uses the paths array and is not aware of the appIDs key. If you have multiple applications, use the singular appID key and specify a separate details dictionary for each application."

Are you able to isolate the problem to certain device/OS versions?

@dmandar it happens randomly but based on the reports received by our customers the devices seem to affect more are iPhone 11, 11 Pro, X. IMO, I think there is an issue with iOS13 that's why I mention in my previous post about iOS13 AASA new format.

We'll need some more information to debug this issue. I'll keep the issue open in case anyone else runs into it. In the meantime, if you're able to isolate the issue concretely (to OS version, device model, or anything else), please let us know.

The same issue is happening on two of my apps (I was able to test/reproduce in iOS 13.x.x).
@morganchen12 can you try updating the AASA to the new format? Do we have an ETA (I have a feature that depends on universal links functionality)?

Thanks in advance

+1

According to this document the older AASA format should still be valid on iOS 13.

Tip

iOS 12 uses the paths array and is not aware of the appIDs key. If you have multiple applications, use the singular appID key and specify a separate details dictionary for each application.

If you have the time, can you see if it's reproducible without dynamic links? i.e. host an AASA in the older format from a service like Firebase Hosting and try to set up universal links on that domain?

Same issue here on 3 apps, lots of users reporting the issue, all using iOS 13. Have replicated the issue on my device, which is iPhone Xs running iOS 13.3.1, app using Firebase 6.18.0 and Firebase Dynamic Links 4.0.7. App preview page loads asking to install app, even though app is already installed.

Have added Firebase Dynamic Links diagnostic and it outputs no errors. I too am using a Firebase generated link, so have no control over AASA file.

Have checked and old format AASA is available at both locations below..
https://vpxk8.app.goo.gl/apple-app-site-association
https://vpxk8.app.goo.gl/.well-known/apple-app-site-association

Suspect iOS 13 requires new format AASA.

@bensheehan-r38 are you able to test on iOS 12? Does the link open the app as expected?

@morganchen12 app opens as expected on iOS 12.4.5

According to this document the older AASA format should still be valid on iOS 13.

Tip
iOS 12 uses the paths array and is not aware of the appIDs key. If you have multiple applications, use the singular appID key and specify a separate details dictionary for each application.

The documentation mention "You can include both paths and components array in the same details dictionary". So, the following format should be valid:

{
  "applinks": {
      "apps": [],
      "details": [
           {
             "appID": "ABCDE12345.com.example.app",
             "paths": [ "/buy/*", "/help/*" ],
             "components": [
                  {
                       "/": "/buy/*",
                       "description": "Matches any URL with path start with buy"
                   },
                  {
                       "/": "/help/*",
                       "description": "Matches any URL with path start with help"
                   }
              ]
           }
           {
             "appID": "ABCDE12345.com.example.app2",
             "paths": [ "/buy/*", "/help/*" ],
             "components": [
                  {
                       "/": "/buy/*",
                       "description": "Matches any URL with path start with buy"
                   },
                  {
                       "/": "/help/*",
                       "description": "Matches any URL with path start with help"
                   }
              ]
           }
       ]
   }
}

Thanks for clarifying. I'll let the backend team know.

Hello I'm having same issue on iOS 13.3.1. I thinks it's related with apple and not with Firebase.
I'm also using the mixed json format for version 13 and early versions.
It happens on iPhone X, XR and iPhone 11 as far as I know.
It worked fine in iPhone8 with 13.3.1
iOS 12 wroks fine.

Hello I'm having same issue on iOS 13.3.1. I thinks it's related with apple and not with Firebase.
I'm also using the mixed json format for version 13 and early versions.
It happens on iPhone X, XR and iPhone 11 as far as I know.
It worked fine in iPhone8 with 13.3.1
iOS 12 wroks fine.

@aletabu Did you try re-installing the app? Because the apple-app-site-association file is cached.

Hello, I am having a similar issue on iOS13 when sharing dynamic links to the messages app. It must be an apple issue, but the messages app will share the base link url rather than the dynamic link url.

Steps to reproduce:

  1. Generate a dynamic link and open it into a UIActivityViewController in order to share it.
  2. Wait for the activity view to prefetch the url (the link favicon will appear once loaded)
  3. Share the link via the messages app. The base url will be sent instead of the dynamic link url.

I am able to consistently reproduce this issue on an iPhone X running 13.3.1

Mesmo problema aqui em 3 aplicativos, muitos usuários relatando o problema, todos usando o iOS 13. Replicaram o problema no meu dispositivo, que é o iPhone Xs executando o iOS 13.3.1, o aplicativo usando o Firebase 6.18.0 e o Firebase Dynamic Links 4.0.7 . A página de visualização do aplicativo é carregada, solicitando a instalação do aplicativo, mesmo que o aplicativo já esteja instalado.

Adicionamos o diagnóstico Firebase Dynamic Links e não gera erros. Eu também estou usando um link gerado pelo Firebase, portanto não tenho controle sobre o arquivo AASA.

Verifiquei e o formato antigo AASA está disponível nos dois locais abaixo.
Https://vpxk8.app.goo.gl/apple-app-site-association
https://vpxk8.app.goo.gl/.well-known/ associação de site de aplicativo da apple

O iOS 13 suspeito requer um novo formato AASA.

Hello, do you have any sollution? i have the same problem :(

@bensheehan-r38 also facing the same issue did you find a solution ?
@aletabu @morganchen12 any update on this issue ?

Same Issue, just appears page.preview.link but not redirect to the app

I tried to use different domains to test and I found it that it works
perfect when I configure the Universal link with Azure (same app conf and
same json).
The only relevant difference Ifound is the time of response. Azure
services resolves DNS lookup and SSL handsahke and response in less than
300ms.

Other sites that are failing the whole process takes more than 500 millis.
My hypothesis is that the background job to fetch the json file is
interrupted if requests takes too long.
That also exmplains why it begins working without doeing any change in 1 or
2 days..

On Tue, Mar 24, 2020 at 8:04 PM Ignacio Hernández Piña <
[email protected]> wrote:

Same Issue, just appears page.preview.link but not redirect to the app

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-ios-sdk/issues/4914#issuecomment-603549422,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6NVDKLBU5C2NRIV7IANCTRJE36BANCNFSM4KWFTD3A
.

--
Alejandro Taboada ([email protected])

@aletabu thanks for the feeback
if I understand correctly our suggestion is to put the AASA to an azure server ?

I am using firebase inside unity and this strange
it works well in iOS 13.3 and 13.4 for an Iphone SE
but when clients try on iphone 11 or X it doesnt open the app

I include the same aasa file on azure web and other 2 domains, using
similar headers, and it worked only on azure. The only difference I found
is the response time.

It only happens with certain devices.

On Wed, Mar 25, 2020 at 7:51 AM ghus86 notifications@github.com wrote:

@aletabu https://github.com/aletabu thanks for the feeback
if I understand correctly our suggestion is to put the AASA to an azure
server ?

I am using firebase inside unity and this strange
it works well in iOS 13.3 and 13.4 for an Iphone SE
but when clients try on iphone 11 or X it doesnt open the app

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-ios-sdk/issues/4914#issuecomment-603772970,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6NVDP5B3XV4WPWEK6KQZDRJHO4BANCNFSM4KWFTD3A
.

--
Alejandro Taboada ([email protected])

Hi @paulb777

Any idea how to fix this without using aletabu solution ?

The app was working fine but since ios 13.3 people are complaining that the app doesnt open properly.
it works well in iOS 13.3 and 13.4 for an Iphone SE
but when clients try on iphone 11 or X it doesnt open the app
this is so strange

Thanks in advance for any tip

+1

@paulb777 @morganchen12

Guys, we have A LOT of issues open regarding DynamicLinks. All of them with similar complaints. I know how open source can be hard, but it seems that it is not receiving the attention it should be. I'll link here just a few issues that are probably regarding the same bug: #5000, #5122 and #5200.

Here we are experiencing a lot of users complaining, it's something happening for about 10% of the people. Please give us a position, are you guys on it?

It's a very important feature of our app that runs entirely upon Firebase.

Please don't get me wrong, I appreciate your hard work a lot.
Thank you.

I'm experimenting the same issue.

5S iOS 11 -> it works well
X IOS 13.3.1 -> it doesnt open the app

Ive found an Apples forum thread talking about the trouble, maybe it could be helpful

https://forums.developer.apple.com/thread/123554

---- Firebase Dynamic Links diagnostic output start ----
Firebase Dynamic Links framework version 4.0.7
System information: OS iOS, OS version 13.3.1, model iPhone
Current date 2020-03-27 17:45:44 +0000
Device locale en-BR (raw en_BR), timezone America/Sao_Paulo
Specified custom URL scheme is {App bundle id} and Info.plist contains such scheme in CFBundleURLTypes key.
AppID Prefix: {AppID}, Team ID: {AppID}, AppId Prefix equal to Team ID: YES
performDiagnostic completed successfully! No errors found.
---- Firebase Dynamic Links diagnostic output end ----

@morganchen12 I believe that i found the problem, server-side redirects are forbidden by Apple in the apple-app-site-association and Firebase do it a lot. Maybe in this new iOS release they are blocking it.

I’ve just made a version using universal link and it worked as expected.

Same problem here. Used to work. Not anymore since updating to iOS 13.4. One thing I noticed is that the documentation states to enter the App ID (prefix) in the Settings but the only setting I see is Team ID. Our Team ID is totally different than the App Prefix in some cases. Yet Firebase is using the TeamID to build the App ID (prefix + bundle ID) when generating the AASA file so I have to put the AppID prefix in the Team ID field instead of the real Team ID. Please update your docs. https://firebase.google.com/docs/dynamic-links/ios/receive

Ensure that your app's App Store ID and your App ID prefix is specified in your app's settings. To view and edit your app's settings, go to your Firebase project's Settings page and select your iOS app.

You can confirm that your Firebase project is properly configured to use Dynamic Links in your iOS app by opening the following URL:

https://your_dynamic_links_domain/apple-app-site-association

If your app is connected, the apple-app-site-association file contains a reference to your app's App ID prefix and bundle ID. For example:

{"applinks":{"apps":[],"details":[{"appID":"1234567890.com.example.ios","paths":["/*"]}]}}

If the details field is empty, double-check that you specified your App ID prefix. Note that your App ID prefix may not be the same as your Team ID.

My app AASA is properly configured as when I tap my universal links, the app launches. It has to do with using firebase AASA and redirect not working.

@c0diq So changing the TeamID for the AppID in the config fixed the issue for you ?

It was working yesterday but not today after updating to iOS 13.4.

@c0diq
I have found this page from apple
https://developer.apple.com/documentation/safariservices/supporting_associated_domains_in_your_app
they also talk in app identifier not teamID and that

A validation may fail and the association will be denied if:
The JSON file is invalid or doesn’t contain the application identifier.

they also mention that starting iOS12 it should include webcredentials

Include the following JSON with your domain for the webcredentials service.

@morganchen12 @paulb777 is it possible that the AASA needs to be updated ?

Hey! The fact is that after some hours/days begins working without making
any change.
That means that the json content is fine, otherwise wouldn’t work.

Ios 13 on new devices handles the domain info in a different way. Pleas
check that device logs and will see that the domain wasnt verified and the
next validation date is an invalid date in the past. Meaning that os will
check in the future when the os consider it. Thats why it begins working
afterwards.
Is not a redirection problem, not a header.
Please check your response time (full connection + response ) to see if its
good enough

El El sáb, 28 mar. 2020 a la(s) 09:42, ghus86 notifications@github.com
escribió:

@c0diq https://github.com/c0diq
I have found this page from apple they also talk in app identifier not
teamID and that

https://developer.apple.com/documentation/safariservices/supporting_associated_domains_in_your_app

A validation may fail and the association will be denied if:
The JSON file is invalid or doesn’t contain the application identifier.

they also mention that starting iOS12 it should include

Include the following JSON with your domain for the webcredentials service.

@morganchen12 https://github.com/morganchen12 @paulb777
https://github.com/paulb777 is it possible that the AASA needs to be
updated ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-ios-sdk/issues/4914#issuecomment-605442522,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6NVDO3OW5IGC7TSAURMSDRJXWEDANCNFSM4KWFTD3A
.

>

Alejandro Taboada ([email protected])

Rebooting the phone fixed it.

On Mar 28, 2020, at 11:46 AM, Alejandro Taboada notifications@github.com wrote:


Hey! The fact is that after some hours/days begins working without making
any change.
That means that the json content is fine, otherwise wouldn’t work.

Ios 13 on new devices handles the domain info in a different way. Pleas
check that device logs and will see that the domain wasnt verified and the
next validation date is an invalid date in the past. Meaning that os will
check in the future when the os consider it. Thats why it begins working
afterwards.
Is not a redirection problem, not a header.
Please check your response time (full connection + response ) to see if its
good enough

El El sáb, 28 mar. 2020 a la(s) 09:42, ghus86 notifications@github.com
escribió:

@c0diq https://github.com/c0diq
I have found this page from apple they also talk in app identifier not
teamID and that

https://developer.apple.com/documentation/safariservices/supporting_associated_domains_in_your_app

A validation may fail and the association will be denied if:
The JSON file is invalid or doesn’t contain the application identifier.

they also mention that starting iOS12 it should include

Include the following JSON with your domain for the webcredentials service.

@morganchen12 https://github.com/morganchen12 @paulb777
https://github.com/paulb777 is it possible that the AASA needs to be
updated ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-ios-sdk/issues/4914#issuecomment-605442522,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6NVDO3OW5IGC7TSAURMSDRJXWEDANCNFSM4KWFTD3A
.

>

Alejandro Taboada ([email protected])
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@c0diq
ok thanks
but did you kept using the team iD or the app id ?

I kept the app ID in place of the team ID. Just make sure your aasa file at https://xxxx.app.goo.gl/apple-app-site-association has the right app id with correct prefix.

Testing with 13.3.1 iPhone6s atm and am not seeing any issues. Can folks try restarting the device to see if the AASA is getting downloaded again?

I'm not getting the point... Will we have to advice all our users experiencing this issue to reboot their iPhones?

Thanks for clarifying. I'll let the backend team know.

@morganchen12 did you have news from the backend team?

Is there another repo where we should report it? Give us a light!

I`ve tested on iOS 13.3.1 and 13.4 on iPhone X and it still does not working even after reboot.

has no sense to use the app id instead of the team ID since app id is
strict for Appstore. Enterprise and developer debug apps doesn't use app ID

On Mon, Mar 30, 2020 at 3:43 PM Rômulo Oliveira notifications@github.com
wrote:

I`ve tested on iOS 13.3.1 and 13.4 on iPhone X and it still does not
working even after reboot.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-ios-sdk/issues/4914#issuecomment-606173362,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB6NVDLQ6QJMVZLT2DSHUJLRKDR4RANCNFSM4KWFTD3A
.

--
Alejandro Taboada ([email protected])

I was able to reproduce this bug with an app not using Firebase Dynamic Links (Google Docs) by restarting my phone, putting the device in airplane mode, and then tapping on a universal link. This did not reproduce consistently with other apps that I had used recently. Unfortunately I couldn't find any conclusive error messages in the device logs, but this seems to be potentially an Apple issue: https://forums.developer.apple.com/thread/123554

For those of you running into this issue, are you able to reproduce it by manually hosting your own AASA file? Is it reproducible for other apps on the same device?

@morganchen12 I made a version using universal link ( hosting my own AASA file ) and it worked as expected.

Interesting. We still have not been able to reproduce the issue, even on the device and OS version combinations mentioned by others in this thread.

@roremeol did you re-host the Firebase-generated AASA or did you generate your own?

@morganchen12 i did my based on Amazon’s AASA but i didn't see any difference for yours AASA.

Hey all! Thanks for looking into this.
We've had an issue related to dynamic links which may or may not be the same as this thread.
Dynamic links shared through the share sheet, in iMessage, won't redirect when clicked. Looking at the URL that is sent, it's not the deep link and it's not the long URL either, it's the preview URL. When I curl the long URL with no User-Agent, I get a 302 redirect, which leads me to the small preview HTML with the meta tags. When I curl the long URL with the iOS Safari User-Agent, I get the correct 200 response with the HTML/JS to do the App Store redirect.

My guess here is that iMessage is caching the URL _after_ the redirect that occurs because they don't set the same User-Agent as safari. I'm guessing also that you're doing this check for the User-Agent to send a small payload for preview, which is definitely a good idea but it seems like it's breaking all iOS 13 iMessage sharing. I think as a fix you could see what the User-Agent is that iMessage sets when it makes its preview HTTP GET request, and return the full page instead of just the preview. They'll cache just that and everyone's links will work again.

Just fyi, Apple recommends against checking User-Agent on the backend: https://developer.apple.com/library/archive/technotes/tn2444/_index.html (see Consistent metadata for all user agents)

In the meantime, our fix is to share the url.absoluteString instead of the url directly:

let activityViewController = UIActivityViewController(activityItems: [url.absoluteString], applicationActivities: nil)
activityViewController.popoverPresentationController?.sourceView = self.view
self.present(activityViewController, animated: true, completion: nil)

This seems to work in all apps we care about, as they do the link preview request on text as well as URLs (so does iMessage actually).

@bsansouci Good finding! Our issue happens only when sharing the link through iMessage, indeed. Thanks for sharing the workaround 🙌

@bsansouci Thanks for the hard working ant time spent trying to help us but in my case the problem occurs anywhere I put the link ( WhatsApp, slack, .... ) however I`ll try your workaround and came back with the results.

@bsansouci filed b/152989387 for the iMessage issue, which is a separate issue from this issue. Thanks for investigating!

So is there any news about this, any fix?
I'm using firebase for Unity but I also have this issue since is iOS stuff.

We are working on a fix for the iMessage send bug. The other issue we have not yet been able to reproduce, nor have we isolated the root cause.

@dmandar did you able to find the issue? It happens from last 8-9 weeks. Kindly help us solving this issue @firebase-ios-github-robot @firebase-db-ci @firebase-ops @firebase-promo

This issue is driving me crazy.
I don't understand if its an iOS bug, bad configuration or if firebase needs to update something.

My app is not opening even having installed it. Is it possible that firebase need to change the generation of AASA format? Here says that for iOS 13 and 12 are different
https://developer.apple.com/documentation/safariservices/supporting_associated_domains_in_your_app?language=objc

Seems to be an Apple bug.
Seems to only happen sharing link through iMessage per this comment.
Can be worked around by using Universal links instead.

Might be helpful to reboot phone per this comment. (mixed results)

No evidence this is a Firebase issue, so I'm locking this thread from further "When are you going to fix it" comments. Leaving open for iOS gurus to comment on, address, or close out as they see fit.

Was this page helpful?
0 / 5 - 0 ratings