5 ms·

That thing makes it annoying for the kind of applications my company does, that needs to communicate with other devices on the local network. It's annoying bec

That thing makes it annoying for the kind of applications my company does, that needs to communicate with other devices on the local network. It's annoying because it's not like other permissions, where you can ask the OS to prompt the user, and check if the user granted it or not, but it's some special permission. If the user, by mistake because it doesn't know that it's needed, doesn't give it one time it's impossible to ask again, and the app doesn't have a way to know that the permission is not granted. It's just things that the customer service has to handle, and that is bad. Sure, right to ask a permission, so make it like a regular permission as the location permission.

swiley 5y ago
If you're truly not being malicious then open source your app and get it added to the alpine repos so people can run it in ish.
t0ps0il 5y ago
> It's annoying because it's not like other permissions Normally if I want to use a permission, say location, I need to provide a value for given permission in my app's `info.plist` file, and if I don't and the app tries to grab the current location, it crashes with logs yelling at me to provide a description for the location privacy key. With local network permissions it's different. I've never had to do any local networking in my career as an iOS dev so downloaded Apple's peer to peer example app (https://developer.apple.com/documentation/network/building_a_custom_peer-to-peer_protocol https://developer.apple.com/documentation/network/building_a...) and removed the `Privacy - Local Network Usage Description` key/value pair from the `info.plist` file and ran the app on my device. I fully expected a crash with a description telling me to add this key but iOS just filled in the missing description with a default value and asked away. I wonder why that permission is treated differently from the rest?
- alerighi 5y ago
  Probably because they introduced it afterwards, and thus to not break compatibility with all other apps they tried to make it transparent to the developer. Except it's not. I get that Apple is going into the direction of forbidding local LAN communication because they want you to implement Homekit protocol in the hardware, except that is a pain, requires certification of the hardware and requires a physical chip inside the hardware.

swiley 5y ago

If you're truly not being malicious then open source your app and get it added to the alpine repos so people can run it in ish.

t0ps0il 5y ago

> It's annoying because it's not like other permissions Normally if I want to use a permission, say location, I need to provide a value for given permission in my app's `info.plist` file, and if I don't and the app tries to grab the current location, it crashes with logs yelling at me to provide a description for the location privacy key. With local network permissions it's different. I've never had to do any local networking in my career as an iOS dev so downloaded Apple's peer to peer example app (https://developer.apple.com/documentation/network/building_a_custom_peer-to-peer_protocol https://developer.apple.com/documentation/network/building_a...) and removed the `Privacy - Local Network Usage Description` key/value pair from the `info.plist` file and ran the app on my device. I fully expected a crash with a description telling me to add this key but iOS just filled in the missing description with a default value and asked away. I wonder why that permission is treated differently from the rest?

alerighi 5y ago
Probably because they introduced it afterwards, and thus to not break compatibility with all other apps they tried to make it transparent to the developer. Except it's not. I get that Apple is going into the direction of forbidding local LAN communication because they want you to implement Homekit protocol in the hardware, except that is a pain, requires certification of the hardware and requires a physical chip inside the hardware.