I'm working on a Flutter app for Philips Hue lights, so I obviously need to connect to the local network. I'm using discover.quickDiscoverClients() method from upnp plugin: https://pub.dev/packages/upnp Everything is working like a charm until I started Beta testing. None of my beta testers get the Local Network permission alert:
nor Local Network privacy permission in iPhone Settings -> app
I've already added NSLocalNetworkUsageDescription in plist file as well as BonjourServices and the Local Network Permission dialog is still NOT showing up for my beta users.
Also, the weird thing is it works on my phone and on my wife's phone as we are internal testers, however it does NOT pass for beta testers.
What shall I do, please to allow Local Networks for beta testers?
Could requesting multicast entitlement help? https://developer.apple.com/contact/request/networking-multicast
It looks like the reason was that there was a router in the local network that does NOT support UPnP => Therefore, this dialog will NOT even be triggered.
Related
My iOS app, 'QuickSupport' connects with Local IoT Wi-Fi network and executes some SFTP Commands on the click of a button. I have used Obj C based NMSSH Library for this. It works fine with Simulator but when I test on Real Device using Testflight by clicking that button, it crashes and I get a pop-up message:
When I allow this and try again it works.
I tried to give permissions through my iPhone by going to Settings --> Privacy --> Local Networks but my app's name didn't appear. It appears after the crashes when the pop-up appears to Allow connection to Local Networks. Experts, How can I give permission to my app to be able to access Local networks or is there any other workaround?
I was able to resolve this issue. With iOS 14, there is a Security and privacy concern that is why it doesn't allow connection to Local network by default. But we can manually trigger it. Below is the link:
https://www.iosapplication.net/2020/12/22/local-network-in-ios-14/
Following iOS 14 new policy of blocking access to local network, a com.apple.developer.networking.multicast special entitlement is needed to access the local network, and this access should be confirmed by user during an authorization dialog. Although this new feature is not thoroughly documented, Apple engineers have indicated in forums that this authorization dialog popup is only triggered when the app tries to send traffic, causing an issue for apps reading only the network, as indicated in iOS 14 How to trigger Local Network dialog and check user answer?
Unfortunately, the advice of sending some data to trigger the authorization dialog does not seem to work in our case, as we never got the popup dialog appearing.
Our app usually only receive UDP broadcast (no transmit except in a few cases). We have got the com.apple.developer.networking.multicast entitlement, have added it to our app entitlements, have added the requested NSLocalNetworkUsageDescription in our Info.plist and are signing our app manually using XCode 12.0 with a provisioning profile including this entitlement (manual code signing is needed in this case as indicated in https://developer.apple.com/forums/thread/656773?answerId=628537022). Since then, situation has somewhat improved as the UDP packet reception that was fully blocked before adding the entitlement started to work sometimes, but unfortunately not always (situation seems worse on iOS 14.0.1 than on iOS 14 and on iPhone than on iPad).
Most importantly, we never got the authorization dialog displayed and our app does not appear as authorized in Privacy/Local Network (even when UDP reception works). We suspect this may be the cause for this spurious reception issue. As it seems the authorization dialog is only shown when sending data, we configured our app to send data to the local network to try to trigger the dialog, using all below methods:
TcpSocket class (using CFStreamCreatePairWithSocketToHost) to connect to 192.168.1.1 on port 80 and send a few bytes (there is a device at this address)
using GCDAsyncSocket to connect and send a test TCP packet to same address/port
using GCDAsyncUdpSocket to create a UDP socket, enabling it for broadcast, then joinMulticastGroup 224.0.1.0 and broadcasting a test UDP packet on port 80.
using GCDAsyncUdpSocket to create a UDP socket, enabling it for broadcast, then broadcasting a test UDP packet on port 80 to 255.255.255.255.
reusing the example from Apple article (https://developer.apple.com/news/?id=0oi77447) sending multicast packets with NWConnectionGroup to 224.0.1.0
and finally using the triggerDialog() method of class LocalNetworkPermissionService indicated in iOS 14 How to trigger Local Network dialog and check user answer?
None of the above actions triggered the authorization dialog on iOS 14.0 and iOS 14.0.1, and our app is still not listed as authorized in Privacy/Local Network, with spurious reception of UDP packets.
If somebody has encountered the same issue and found a solution, many thanks for your advice.
Thanks to #Columbo and help from Apple, a solution has been found, although the root cause of the issue is not yet fully understood.
Our app was built with a iOS release deployment target of 9.0 because we tried to preserve compatibility with older devices. It seems a deployment target lower 12.0 may cause issue with the network privacy management. The solution was then:
to rebuild the app after updating the iOS deployment target to 12.0 or higher.
for all iOS 14.0 and 14.0.1 devices having a previous version of the app already installed, to fully delete the app and install it again (updating the app was not sufficient, the network privacy alert was still not shown).
Of course, this procedure is not ideal for users that will have to reinstall the app from scratch and configure it again. I will update this thread if a future version of iOS avoids this issue.
Update: when using iOS 14.2, the app is correctly triggering the network privacy alert even after an upgrade (without full deletion and reinstall). We then recommended our users to upgrade to 14.2 before upgrading our app. We have kept the deployment target at 12.0
To those who suddenly find that APP ask this authorization, and don't suppose it appear. The answer is that maybe your APP trying to connect to your test server which in same LAN with your iPhone running iOS 14.
For 14.2, the local network access is handled little better and there is a sample code used to trigger this alert as mentioned in https://developer.apple.com/forums/thread/663768
Also you can create dummy connection using NWConnection, this will trigger system dialogue for asking permission (if system dialogue is not shown anytime before) and check the local network access is allowed or not as mentioned in https://developer.apple.com/forums/thread/663769 , this is available from iOS 14.2.
I'm trying to connect apple tv with my xcode to debug my app. But I'm getting below dialog and it will never go. So I tried following steps to fix but no use.
Waited for 10 mins and checked but still the same.
I restarted/reset apple tv and checked but no use.
Tried with different versions of xcode but no use.
Tried using wifi, mobile hotspot with different networks.
Some times I will get this dialog and it will never go.
If I try to run app in this state then I will get this alert in xcode
So I'm not understanding the why its behaving like this. And how to fix this issue ?
Wireless Debugging on Apple TV
Dive has some great recommendations about using Apple TV with your machine, connected via Ethernet. So far this is also my preferred way to connect, develop and deploy to Apple TV, however debugging on Wifi isn't the best experience.
Here are a few things you could try.
Remove current pairing by using Device and Simulator window.
Try downloading Apple Configurator 2 and use that to first pair your Apple TV to your machine. This is great tool to ensure you can connect to your iOS/tvOS devices for some super user type setup. ( Main Menu -> Paired Devices)
For this to work you have to be on a specific screen on your Apple TV.
Settings -> Remote and Devices -> Remote App and Devices ( This uses multipeer connectivity)
If you are successful pairing your TV using apple configurator then it's a good sign as you can rule our networking issues with your Wifi.
Try pairing with Xcode after it's paired with your machine in the step above. The dialog window you see above is expected and takes some time ( longer in some cases) but should eventually complete.
If step 3 wasn't a success, unpair from Xcode and Apple Configurator ( if they show as connected but not aren't really paired), restart your machine and Apple TV and start the same steps again.
Lan Set up :
You can connect to your Apple TV via a switch or usually Modem/Routers have inbuilt switch ( extra ethernet ports).
Try the same steps and you should be able to pair with Xcode.
Troubleshooting: Try using Console app on your machine if you still can not figure out the root cause and this should help you debug the pairing issue.
There is a helpful instruction from Apple - Pair a wireless device with Xcode (iOS, tvOS) and I assume that you did as they recommend.
Such issues usually appear due to the following reasons:
Something is wrong with your network configuration. The easiest way to check is to try to wirelessly connect your iPhone to be sure that you do not have the same problem. If this is the case then try to white-list the IP address for the Apple TV on your router and open necessary ports;
About port, Apple recommends the following configuration: Communication to network devices uses port 62078. Some networks block specific ports. You may need to check your network settings or ask your system administrator to open this port;
Your Xcode version has to be in sync with tvOS. From the screenshots, I see that you have tvOS 13.3.1. It means that it is better to use Xcode 11.3.1 in this configuration. But you mentioned that you already tried this.
The option that always works to me is to use an Ethernet connection. I connect my AppleTV via the ethernet cable to my router and access it from my MacBook without problems:
Connect the device to the same network using an Ethernet cable.
For an Apple TV, connect using the Ethernet port in the back of the device.
Yesterday, I submitted my app for review, but I got this message from Apple:
We discovered one or more bugs in your app when reviewed on iPad iPhone running iOS 9.3.2 on Wi-Fi connected to an IPv6 network.
Specifically, upon review we have found the application still experiences a loading issue and unable to review the application content.
My app uses ionic framework, how can I fix this problem?
I already used domain to access my server, but this problem still exists.
Yes. According to apple's policy , your application must supports IPV6. so, please check your application supports IPV6. Supporting IPv6 in iOS 9
To test, if your application supports IPV6 or not please check this ,
Supporting IPv6 DNS64/NAT64 Networks
To check with creating follow this steps , which indicate on apple's page .
To set up a local IPv6 Wi-Fi network using your Mac
1) Make sure your Mac is connected to the Internet(with ethernet), but not through Wi-Fi.
2) Launch System Preferences from your Dock, LaunchPad, or the Apple menu.
3) Press the Option key and click Sharing. Don’t release the Option key yet. (don't forget to press option key)
4)Select Internet Sharing in the list of sharing services.
5)Release the Option key.
6)Select the Create NAT64 Network checkbox.
7)Choose the network interface that provides your Internet connection, such as Thunderbolt Ethernet or Only Ethernet.
8)Select the Wi-Fi checkbox.
9)Click Wi-Fi Options, and configure the network name and security options for your network.
10) Select the Internet Sharing checkbox to enable your local network.
11)When prompted to confirm you want to begin sharing, click Start
12) Now your mac mini is working as a hotspot and useing IPv6 NAT64 network
(looks like above image when hotspot created)
Now connect your iphone with your mac mini's hotspot. and Test your Application it's working properly or not.
I hope this answer is helpful you.
Edit :- Don't forget to add below frameworks.
1) WebKit
2) CFNetwork
You will find all the information on this link related to ipv6 policy. Supporting IPv6 DNS64/NAT64 Networks
We also faced the same issue.
Just registered your website with any CDN like cloudFlare and your app will be approved next time no need to shift the whole site to any other server. This is the easiest way to get approval from app store.
I think Apple has something wrong with this error!
I have an app (ionic app) rejected 3 times (during Nov 2016) for the same error and lastly accepted without making any change related to IPv6!
You may need to check your app for startup errors if you think that you have nothing to do with IPv6.
By the way: I did not check IPv6 compatibility on my app, and even more the app - in its inner views - has a connection to a webpage that hosted on a shared host with no IPv6 support!!
Please note that sometimes the mobile app works in the test environment but not in the Apple own test environment. Following this and this link can be very helpful in determining what's the problem with apple rejections.
It is clearly stated that the test environment is not exactly the same
I am using Xcode 7 and iOS 9. I'm having trouble in launching my app on my device using the new feature that Xcode 7 has, that allows us to try applications without having an Apple Developer Program
Here's what I get from Profile when I try to trust and verify apps. It keeps telling me that I need to connect to the internet but I'm always connected. I try to delete my profile and my app and restarting my phone but it doesn't work.
Any suggestions?
Error1
Error2
I'm currently having this problem right now too, Cellular, and quitting Settings didn't help.
This article (https://support.apple.com/en-ca/HT204460) mentions you need to be able to connect to http://ppq.apple.com to verify the app. As of right now (Dec 4th, 2015), it seems to be down.
"An Internet connection is required to verify the app developer's certificate when establishing trust. If you're behind a firewall, make sure it's configured to allow connections to https://ppq.apple.com. If you aren't connected to the Internet when you trust an app, the device displays "Not Verified" instead. In order to use the app, you need to connect to the Internet, and tap the Verify App button."
So I assume if that site is down, you can't trust apps.
I had the same issue. I tried to switch between WIFI and Cellular data but no results. I was testing on iPad Pro with ios 9.3.2 and I even updated it to the latest software update available which is 9.3.3.
Again the efforts were in vain! I still got the error message "No Internet Connection Error".
Then I noticed my Timezone and DataTime was different and when I set it to "Set Automatically", VOILA ! Afterwards, I could trust the developer and verify app successfully.
So make sure, you set the DATE TIME and TIMEZONE correctly while you trust a developer and verify apps.
Something has changed in the last day. Not sure if it's a Apple verification server issue or WiFi issue with iOS 9.0.2.
Anyway, the workaround is this. We have clients doing this today.
Disconnect from WiFi and connect via cellular. You may have to hotspot to a phone if your iPad is WiFi only.
Clear the Settings iOS app out of memory.
Re-launch the Settings app and go to Profiles.
Click Verify link again and should verify / work.
This worked for me. Stop debugging. Close Settings app (double tap on home and swipe up). Open Settings app again and got to General>Device Management>Select the app certificate> trust. This works
this happens when the phone has no wifi or 3G/4G signal. You may have run out of minutes on your data plan for example or disabled your wifi etc.
For me, the problem was that I was using a VPN (Charles proxy) and I forgot about it. Just turned off the VPN, accepted the profile, and switch the VPN on.
As of iOS 13.1.3, this now seems to be the message received when your distribution certificate is revoked. It used to just appear to force quit the app, but now it displays this message and refuses to verify. Rebuilding the app with a current certificate should fix it in this case.