IOS app on MacOS 15 local network access

This is an interesting edge case. I’d expect this to work, so I’m curious how you’re testing this. Do you see this when you download the app from the App Store? Or when you run development builds on your Mac? Or both?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I've tested the app after downloading it directly from the App Store. On my MacBook running macOS 14, it worked without any issues. However, after updating to macOS 15, it stopped working. I checked the settings on my MacBook, but I couldn't find an option to grant local network access for the app.

When I download the app on an iOS device running iOS 18, it immediately prompts me to allow local network access. It seems like the request for this permission isn't appearing on macOS 15, and I've noticed the same behavior reported by other users worldwide.

I plan to test it with a development build on my Mac in the next few days.

Is there a quick fix or workaround to enable local network access for the app, even if it doesn’t prompt for permission?

Sorry it’s taken a while to get back to you. I wanted to makes sure I tested this properly, and that took a lot longer than I’d hoped [1].

My understanding is that local network privacy on macOS should apply to iOS Apps on Mac. To try this out I did the following:

1. On macOS 14.7, I create a VM running macOS 15.0.

2. I added the VM’s UDID to my account, so I’m able to run my iOS apps on it.

3. Still on macOS 14.7, I used Xcode 16.0 to create a small iOS app that triggers the Local Network alert.

4. I did a Product > Archive.

5. From the Xcode organiser, I exported an Ad Hoc signed build using Distribute App > Release Testing.

6. I copied the .ipa to the macOS 15.0 VM.

7. In the VM, I double clicked the .ipa in the Finder, which installed the app in the Applications folder.

8. I then launched the app from the Applications folder.

9. And clicked the button to trigger the Local Network alert.

10. The alert showed up as expected.

Now, that’s not to say that there isn’t a bug here. For example:

• It’s possible that this might only reproduce when you install from the App Store.

• Or that there’s some existing state on the Mac that ‘broke’ this. That’s why I use a VM to test this stuff, so I’m always starting from a ‘fresh’ Mac.

But it’s also possible that this is a bug in your code. For example, you might be suffering from a variant of the issue discussed in LNP FAQ-16.

However, I think the above confrims that this should work in general.

I plan to test it with a development build on my Mac in the next few days.

Cool. I think that’s the best next step.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] There were so many missteps )-:

Some of our macOS app customers are reporting this same issue for our app. The fixes listed in this forum and others that I have found are much too technical for our customers.

1. Will updating to a specific macOS release and uninstalling/reinstalling our app fix this issue?
2. Are there work-arounds or fixes that we can implement in our App Store app code?
3. Are there user-friendly work-arounds or fixes that our customers can perform on their own?

Some of our macOS app customers are reporting this same issue for our app

So, you have an iOS app that they’re running on the Mac?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

It's a Mac app built using Mac Catalyst based on our iOS app code. Customer complaints are only for our Mac app, not our iOS app.

It seems like (our guess) macOS uses some set of app data (e.g. app name, location, entitlements, etc) to determine if macOS should create a new entry in the Settings > Privacy & Security > Local Network list. Could some difference between a prior version of our app and our latest version of our app be causing the multiple entries in the Local Network list? Why would our app not actually have Local Network access even though all of the switches are turned on?

Any thoughts?

Thanks for the clarification.

In general, a Mac Catalyst app should behave like a normal Mac app when it comes to local network privacy.

Oh, before going further I should drop a link to TN3179 Understanding local network privacy, which covers a lot of the basics here.

macOS uses some set of app data

Right. Ideally, local network privacy on macOS would be able to identify code entirely by its code signature, which is how iOS works. However, things are not that simple on macOS. For example, it’s common for macOS code to be ad hoc signed [1], which forces macOS on to a compatibility path.

How is your app distributed? On the Mac App Store? Or directly, using Developer ID signing?

Are you sure that all the distributed copies of your app have a unique build UUID. TN3179 explains that this is critical, and also links to TN3178 Checking for and resolving build UUID problems which explains the concept in more depth.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Specifically, code that’s built locally (Sign to Run Locally in Xcode parlance) and code that’s installed via open source package managers like Homebrew.

We confirmed that we do have unique build UUIDs for all distributed apps.

Our app is distributed through the Mac App Store.

We changed our app name recently. Could that have caused this issue? Could this issue be introduced if a customer used the App Store and Test Flight to update to different versions of our app?

It's still not clear to me why turning on all Local Network switches for the app (however many there are) doesn't fix the app's Local Network permission issue. Any thoughts why?

Any thoughts why?

I have thoughts, but they’re all quite negative so it’s probably best if I keep schtum |-:

My general take on issues like this is that you should test your app in common user scenarios and see if it behaves as expected there. For example, if you’re concerned about the impact of TestFlight, do this:

1. Install a fresh copy of the relevant macOS version [1].
2. Install your app from the Mac App Store.
3. Then install a beta via TestFlight.
4. Check that local network privacy is behaving itself.
5. Then re-install from the Mac App Store.
6. And check local network privacy again.

I suspect you’ll find that this works as expected. If so, that’s strong evidence that your app is built correctly and you’re being affected by a wider problem.

That raises the question as to what you do when contacted by a user with this issue. Unfortunately, I’m short of good answers on that front. If the user is able to give you a detailed description of how they got into this situation, you could try reproducing it. However, in my experience users rarely have that sort of info to hand, which turns this into a question of “How do I fix this one user’s system?” And that’s not easy because, as I mentioned in TN3179, there’s no supported way to reset the local network privacy database )-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I usually use VMs for this sort of thing, but it’s tricky in this case because Apple silicon VMs don’t support App Store or TestFlight. One option is to use an Intel VM for this. If that doesn’t work for you, you have to use real hardware.