Recently we submitted the new version of the app for review, it hasbeen rejected
Your app crashes on iPad and iPhone running iOS 9.3.5 connected to an IPv6 network
But i only used the Alamofire 3.4.1 for API Requests, with a domain name (not IP Address), and it is IPv6 Compatible
Here is the results of the ipv6-test.com
Our ISPs not Providing IPv6 Only network, to check our app, We followed this procedure to setup the IPv6 in Mac, then it works here, after we submitted the build again, but it again rejected for the same reason
Can anybody suggest, how can we troubleshoot the issue/ is any thing wrong in my current environment
Try delete AAAA record of your domain.
So that your app can use NAT64 network to access your server other use ipv6 directly.
And it may help debug the issue.
We finally found that the issue is not regarding IPv6 or Alamofire, it is working fine - My app crashes in IPAD for the UIAlertController Popover Source Rect not set, after that we resubmitted the app and it is approved
These may help someone
https://forums.developer.apple.com/message/176301#176301
https://forums.developer.apple.com/message/176303#176303
Related
I have a weird issue, I got a sandbox wss://v2.sandbox and https://v2.sandbox links every request on the API Rest, and the socket server works fine in Wifi but when I want to try the App in 4g no a single request work. Same behavior with my browser, impossible to get access to the dashboard, API rest, or socket server with a shared connexion but work in wifi.
I checked the banip list - clear
I checked my DNS - clear (using the DNS of Google)
My partner who made the BO think that could be the app but I test several free APIs, socket servers anything works still no access to his BO.
I would appreciate some idea on this issue that is out of my spec.
I'm using a Fresh install of RN
I test both fetch API and Axios same results.
RN Version: RN 63.4
Issue solved it was DNS Propagation issue with ip
For testing purposes I tried to create IPv6 network from my Mac. I followed this tutorial: https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html
Except one thing. Instead of Thunderbolt Ethernet I used only Ethernet. WiFi was successfully created and I am able to use it.
However it seems, that the created WiFi is still not IPv6.
I ran this test: http://ipv6-test.com and in results it says Not supported under IPv6 connectivity
What is the problem? Why is my network still IPv4? How can I create proper IPv6 network?
The NAT64 test network that Apple advises you to create does not provide global IPv6 connectivity. It provides only local IPv6 connectivity between your iOS device connected to the WiFi access point and your Mac. The Mac then uses NAT64/DNS64 to send any Internet traffic via IPv4 (which is similar to what some mobile carriers do). This is why an IPv6 testing website shows you that IPv6 is not supported.
The purpose of this setup is to test IPv6 compatibility of your iOS applications on a physical device. You may download an iOS app which will show whether your device is correctly obtaining an IPv6 address from your Mac (because iOS doesn't natively show this info).
Whenever I run
npm start (react-native-scripts start)
It hosts the Application on the endpoint of 192.168.1.200:19000
The issue is my Windows computer has the IP address of 192.168.0.31
Is there a way to change this React Native hosting IP address so it is hosting on the correct IP?
The application does not start etc. The only way to run this expo app and have it connect is through the tunnel (which is 70% slower when refreshing the app etc).
Side note: This bug does not happen on my mac OS computer, Only on my Windows 10 computer development machine I am trying to transfer to.
Edit: Is there a way to always have this be my computer's router assigned IP address? I'm confused why this breaks for RN on windows vs RN on mac.
Check the below question thread.
It answers your query.
React Native Expo change default LAN IP
Hope it helps.
I have just downloaded and installed latest Rocket.chat using SNAP tool on Ubuntu (16.04 LTS). Overall, I had a smooth experience of installing and getting started with Rocket.chat. However, I did find a few serious issues.
I try to get auto SSL running by following the instructions at: https://rocket.chat/docs/installation/manual-installation/ubuntu/snaps/autossl/. But after configuring the Caddy file, the Caddy service failed to start, with the message:
Activating privacy features… 2018/04/24 17:58:09 open /root/snap/rocketchat-server/1254/.caddy/acme/acme-v02.api.letsencrypt.org/sites//.crt: no such file or directory
The second issue is with start video chat using webRTC. When I clicked on it, nothing happened. I am using Chrome browser and tried to start video chat on several devices. All the Chrome browsers have passed the webRTC tests. I don’t know why video screen is not shown.
I signed in with open.rocket.chat and compared the differences between my installation and the official site. When my browser points to open.rocket.chat site, the videochat does not work either. It does show the video window, but only displays only myself, not the remote member. Note to experiment, I signed up with 2 accounts to simulate 2 members chatting.
Also I downloaded the Android Rocketchat client. However, I couldn’t find the start video chat option. Is it true that video chat is unavailable yet on the Android client?
To summarise, we have the issue of setting up auto SSL with Caddy, and using video chat (webRTC). It could be that I missed a few basic configurations on my environment. Other functions like text messaging works fine.
We are deciding whether we should use Slack/CometChat for our instant messaging solution. It seems RocketChat has all the features we want, but it is a pity we couldn’t get it to work completely.
Appreciate someone can guide me in this.
I did some investigations on these issues, and have made some progress. I'd like to share my findings, which I hope could be of some help in future to newbies of RocketChat like me.
However, I still have a few issues unresolved, and hope someone could help.
Caddy service failed to start
Using self-signed certificate and defining the domain name in /etc/hosts, I can get Caddy service to start and https to work. My guess is that the domain name I used, even it is registered with a DNS provider, has no CNAME record, and is not mapped to any IP address. Letsencrypt, which is used by Caddy to do on-demand SSL, therefore is unable to create a SSL certificate for my domain name. It would be nice if the RocketChat documentation could make it clearer.
open.rocket.chat WebRTC-based video chat not working
after I used another Windows machine, the video chat is working. Presumably my previous computer does not have the latest Windows update. But I am glad with open.rocket.chat site, every feature I tested is working.
On my self-hosted Rocket-chat (i.e. a Linux server at home), however, the video chat is still not working. When I clicked on the "start video chat" button, no video screen is launched on my browser window. On the remote browser (which was used for simulating the conversation partner), there is a notification "xxx invites you to video chat, do you accept?". I clicked on "Yes". After that, nothing happens on the remote browser. The only issue I can think of is that I didn't use https to connect to the self-hosted Rocket-chat. Because I am using several computers in my home wireless network. I only use http://192.168.0.3:3000 to point to the chat server. I am wondering if secure connection is required in order to use video chat?
On the Android Rocket Chat app, I couldn't find any links to start a video chat, nor can I receive any video chat invite. Is it by design or a defect?
Hope someone can enlighten me on these issues.
I made further investigation as to why webRTC does not work on my self-hosted Rocket-chat instance. It is related to secured connection. There is a related discussion in the RocketChat forum:
https://github.com/RocketChat/Rocket.Chat/issues/1813
Basically, the connection to the Rocket.chat server must be secure for WebRtc to work. After I configure Caddy to support HTTPS listening on Rocket.Chat (currently using self-signed certificate), WebRTC works. It would really help users if the documentation can make this clear.
Now the remaining issue for me is to figure out if Android Rocket Chat app supports Web RTC.
I code sign the IBM AppCenter client for iOS using my Enterprise Certificate. I used a unique bundle identifier and provisioning profile for the same. The OTA installation works fine in most of the iOS devices.
In few devices iPhone5S powered with iOS 7.1.1, it fails to download and install and gives the error message "Unable to Download App" - App Center could not be installed at this time". I have checked the Code Signing properties in my codebase. Every thing looks fine. Note sure why this fails in few devices and works fine in most of the devices.
There could be multiple reasons:
as Idan said already, iOS 7.1 requires SSL (https) with a real SSL certificate, that is, self signed certificates don't work. Application Center must run on a server that has a CA authorized SSL certificate that matches the server URL. Earlier versions of iOS did not have this restriction.
the app might not be provisioned for the device. This depends on your provisioning profile. Development profiles are limited to preregistered devices. If you are able to side-load the app on the same device, the provisioning profile must be correct. Typically, when the provisioning profiles is wrong, the app appears to be downloaded to ca 75% and then the failure occurs.
the Apple server to validate the provisioning profile is not reachable. This happens seldom and is normally not specific to a device. This can only explain occasional random failures to install the app, but it cannot explain when an app fails always on the same device.
there might be a connection problem between the Application Center server and the device. In this case, you don't see the download to go to 75% but it stops earlier in the download process. In Worklight 6.1, the Application Center uses resumable downloads, hence a temporary connection problem should normally get resolved automatically. But it can be a permanent connection problem on specific devices. In order to check whether it is a connection problem, you could open the Worklight AppCenter Console on the device inside Safari and try to download any app binary ... The resulting network traffic is similar to the one that occurs during installation.
I hope this helps!