React-Native iOS app rejected(Guideline 4.0 - Design) on AppStore for using @magic-sdk/react-native

[raviranjan31]

✅ Prerequisites

• [yes] Did you perform a cursory search of open issues? Is this bug already reported elsewhere?
• [yes] Are you running the latest SDK version?
• [yes] Are you reporting to the correct repository (magic-sdk)?

🐛 Description

IOS app rejected by AppStore with "Guideline 4.0 - Design"

Rejection Reason provided by app store:

Guideline 4.0 - Design We noticed that the user is taken to the default web browser to sign in or register for an account, which provides a poor user experience. Next Steps To resolve this issue, please revise your app to enable users to sign in or register for an account in the app. You may also choose to implement the Safari View Controller API to display web content within your app. The Safari View Controller allows the display of a URL and inspection of the certificate from an embedded browser in an app so that customers can verify the webpage URL and SSL certificate to confirm they are entering their sign in credentials into a legitimate page.

🧩 Steps to Reproduce

Publishing App to AppStore

🤔 Expected behavior

[What you expected to happen?]

😮 Actual behavior

[What actually happened? Please include any error stack traces you encounter.]

💻 Code Sample

[If possible, please provide a code repository, gist, code snippet or sample files to reproduce the issue.]

🌎 Environment

Software	Version(s)
magic-sdk
Browser
yarn
Operating System

[ayv8er]

@raviranjan31 Thank you for bringing this to our attention. Our team will look into this and we may reach out for more information.

[ayv8er]

@raviranjan31 Would you mind confirming your implementation? Are you using @magic-sdk/react-native or magic-sdk?

[ashishmadan]

We are using "@magic-sdk/react-native": "^8.1.0",

[Ariflo]

We noticed that the user is taken to the default web browser to sign in or register for an account, which provides a poor user experience.

Hi @ashishmadan can you clarify the UX here? Are your users being taken out of the app context and sent to a safari mobile browsing context to sign in?

If you haven't done so already, I'd also like to encourage you to review our sample RN apps. Have you and your team considered switching to using our latest split package for bare RN setups?

[raviranjan31]

Hi @Ariflo ,

I have attempted to resolve the issue by implementing the new split package, but unfortunately, app has been rejected by the App Store due to non-compliance with guideline 4. The reason cited was the usage of webview, which needs to be shown through the Safari view with the URL and its certificate so user know where they are inputing their email id.

I wanted to bring to your attention that this issue has also been faced by the Auth0 Library, as referenced in the following community post: https://community.auth0.com/t/react-native-ios-app-rejected-on-appstore-for-using-react-native-auth0/36793

Thank you for your time and consideration. I am looking forward to your response.

[Ariflo]

Hi @raviranjan31, I'm very sorry to hear this is happening to you. This is the first time we've seen an app rejected for this.

To help you troubleshoot further, can you confirm which of our login features you've integrated into your app?

[raviranjan31]

We are not doing social login, we are using loginwithlink and they complaining about attached screen and asking us to show url/certificate so user know where they are entering email id. app store is saying to not use web view and use safari view for this with url and certificate should present in header.

[Ariflo]

Got it @raviranjan31, Thanks for clarifying. We'll work on getting something out asap.

[Ariflo]

@raviranjan31, we are going to do what we can to get loginWithLink to work within Apple's guidelines. Thank you again for bringing this to our attention.

In the meantime, if you need to get through the review process fast, we think it might help to integrate social login in place of loginWithLink; as it utilizes Apple's AuthSession instead of the Webview.

[Ariflo]

@raviranjan31 any updates on using social login? Assuming that's not an option:

which needs to be shown through the Safari view with the URL and its certificate so user know where they are inputing their email id.

Could you kindly reach back out to Apple with an appeal and inform them that although the WebView displays an edit button here, tapping it ultimately brings the user back to the app where they actually input their email? In other words, your app is the entity that collects the information and ergo forwards it along to us for wallet services. The user never inputs their email directly into our SDK's WebView.

[AMAN-BARBARIA]

We have implemented MagicAuth loginWithEmailOtp functionality for our mobile app. We have been working on it since last week and were planning to release it early next week. But after seeing this thread, I want to confirm if this issue is fixed as per apple's guideline. What I do not want is to release the feature in testflight for people to sign up and later remove their login in app store. If you guys suggest to go with Social Logins, we will start implementing it.

[Ariflo]

Hi @AMAN-BARBARIA unfortunately we haven't heard back from @raviranjan31. As we note above we believe loginWithEmailOtp along with the rest of our product line should pass the review process. Reach out to us here if you experience otherwise.

[AMAN-BARBARIA]

Hi @AMAN-BARBARIA unfortunately we haven't heard back from @raviranjan31. As we note above we believe loginWithEmailOtp along with the rest of our product line should pass the review process. Reach out to us here if you experience otherwise.

Hi @Ariflo, are there other apps using loginWithEmailOtp that got through the apple review process in the last month? Want to be double sure, before deciding to proceed with loginWithEmailOtp

[Ariflo]

there other apps using loginWithEmailOtp that got through the apple review process in the last month?

Yes, you should proceed with confidence. We haven't seen this issue crop up more than once. Although, I can't promise anything as things are constantly changing with Apple's review process. Please do let us know if you run into issues.

[betashop]

Hi @Ariflo

I chatted with Richard from your team at ETH Denver yesterday and he said there was some customizations being worked on that would help with this issue. Can you share any more details? He said we should be able to make it more appear that the screen is being served up by the app itself.

Also, can you provide some examples of customer apps in the app store that are using Magic.Link that we can download and reference?

Thanks!

[Ariflo]

@betashop I can't share the details on the customization being worked on, as it is still in development. But I'll reiterate, that besides this particular GH issue, we haven't seen this problem crop up with any other developers.

HeartBeat App and Snowball are two examples of apps on the App Store using Magic link. I hope this helps.

[ayv8er]

@betashop Hi again, I was referring to this feature in our docs.

If you pass showUI = false into loginWithMagicLink, you can render your own modal informing the end user to check their inbox, instead of seeing Magic's branded modal. Our popup modal that appears after the user submits their email address is web view. But if you created your own modal you wouldn't render a web view to the end user.

We are working on having this available for the other email login method loginWithEmailOTP. It is currently in development.

We are not doing social login, we are using loginwithlink and they complaining about attached screen and asking us to show url/certificate so user know where they are entering email id. app store is saying to not use web view and use safari view for this with url and certificate should present in header.