App requesting NSBluetoothAlwaysUsageDescription

[Beryl0]

Description

When I submit my app to TestFlight I now get an email with the following:

ITMS-90683: Missing purpose string in Info.plist - Your app’s code references one or more APIs that access sensitive user data, or the app has one or more entitlements that permit such access. The Info.plist file for the “APPNAME.app” bundle should contain a NSBluetoothAlwaysUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. If you’re using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. For details, visit: https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources.

In previous submissions this never occurred, and I even tried submitting a prior release (which never had this issue before) but it now also too receives the email.

I understand I could add a NSBluetoothAlwaysUsageDescription key to the info.plist however I'd rather know what is causing / has caused this to occur as we do not use this permission, or any Bluetooth permission in the app.

Xcode version is 15.1 beta3 (has not been updated or changed since it started happening)

Steps to Reproduce

No response

Link to public reproduction project repository

No response

Version with bug

8.0.3

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

8.0.3

Affected platforms

iOS

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

No response

[SarthakB26]

May be any library you are using has some code calling these Api's.
If those are open source you should check there code

[jfversluis]

This will be pretty hard to figure out if this is a us or you problem. I would highly doubt this is something that originates in .NET MAUI. As mentioned: do you have any third-party libraries that you are using?

If you want to be really sure that this is an issue with .NET MAUI, can you create a new blank .NET MAUI app and submit that and see if you get the same feedback? If you do, there is something wrong on our side, if you don't it is something that is specific to your project.

[ghost]

Hi @Beryl0. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[Beryl0]

This will be pretty hard to figure out if this is a us or you problem. I would highly doubt this is something that originates in .NET MAUI. As mentioned: do you have any third-party libraries that you are using?

If you want to be really sure that this is an issue with .NET MAUI, can you create a new blank .NET MAUI app and submit that and see if you get the same feedback? If you do, there is something wrong on our side, if you don't it is something that is specific to your project.

Thanks, wasn't sure if there was a way to scan / locate the root cause but will try this.

Also, didn't realise this would remove s/needs-info, apologies.

[Beryl0]

This will be pretty hard to figure out if this is a us or you problem. I would highly doubt this is something that originates in .NET MAUI. As mentioned: do you have any third-party libraries that you are using?

If you want to be really sure that this is an issue with .NET MAUI, can you create a new blank .NET MAUI app and submit that and see if you get the same feedback? If you do, there is something wrong on our side, if you don't it is something that is specific to your project.

Unfortunately I've created a blank .NET MAUI project and submitted it and it is still giving the same issue.

Updated to Xcode 15.2 but still the same too.

[rogersm-uwosh]

Oh, good, so it's not just me. I'm trying to figure out what to say in the purpose string. When I launch the app, it doesn't ask about Bluetooth AFAICT, and while I've installed it on a phone I don't see the app listed in Privacy & Security >> Bluetooth. So, I'm just going to say "Bluetooth is not actually required to use this app", and hope that doesn't get it rejected.

[elio-developer]

I'm having the same issue. The Info.plist from the generated ipa file doesn't have any key related to NSBluetoothAlwaysUsageDescription but the permission windows keeps appearing. When I go to Settings and lookup my app, I see that the permission for Local Network appears

[syntaxterror7]

Also ran into this problem. Nothing is using Bluetooth

[JeroenBer]

We just converted from Xamarin to .NET8 and are now also facing this issue. This might become a problem getting this approved in the Apple Store, so I think it's important that this gets fixed in .NET8

[syntaxterror7]

We just converted from Xamarin to .NET8 and are now also facing this issue. This might become a problem getting this approved in the Apple Store, so I think it's important that this gets fixed in .NET8

I did have success manually adding a key to the plist file to the effect of " we do not require this permission but it is referenced in dotnet maui " app was accepted

[JeroenBer]

Until it's solved there is no other option, but in the past I sometimes had submissions that were refused due to wrong purpose strings while the strings had been in there for ages. So what I am trying to say is just because the submission was accepted now it doesn't mean it can't be rejected another time on this purpose string. And if that happens there is no way you can resolve it.

[Geronatsios]

I have the same problem. Any news on plans to solve this ?

[ryanlgoldmine]

Saw a link on Stack Overflow. Hopefully it helps. Stack Overflow link

[JeroenBer]

@jfversluis Beryl0 stated on januari 16 it's reproducable with a blank MAUI project. So this seems to be a MAUI problem then. Can anyone look into this ?
The dummy NSBluetoothAlwaysUsageDescription might work as a quick fix but if some Apple reviewer sees this it will probably get rejected. Also I think Bluetooth stuff shouldn't be in the app when it's not necessary just out of security reasons.

[jfversluis]

@JeroenBer unfortunately when I create a blank MAUI app I don't see it, hence I'm asking for a reproduction from your side.

My blank MAUI project might not be yours as templates get updated over time, or we might be using different versions to build our apps, which is also info that is (partly) incorporated when I see your blank MAUI project template. Just trying to pinpoint more precisely where to look for a potential cause or this.

What versions of .NET are you building with and what .NET MAUI package reference versions are you using (for example <PackageReference Include="Microsoft.Maui.Controls" Version="8.0.20" />)?

[JeroenBer]

@Beryl0 do you still have an empty solution to reproduce this for @jfversluis as stated above ?

[Beryl0]

@Beryl0 do you still have an empty solution to reproduce this for @jfversluis as stated above ?

I do not, hopefully someone else can try replicate.

[Neotrickster]

This just happen to me today, yesterday uploaded a version into store and everything was fine, then clean some code (a couple unused variables) and decide upload again and bam !! got that warning, seriously, only delete an unused i = 0; and j = 0; and got the mail from Apple, using the MAUI template with only Android and iOS using .net8 and CommunityToolkit .

[FM1973]

To me too. Simple Maui Blazor App. No additional packages included.

[graymer69]

@jfversluis @PureWeen I got this exact same issue when I added the following in my project file:

<PropertyGroup Condition="$(TargetFramework.Contains('-ios')) and $(cfg.Contains('Release'))">
	<MtouchLink>None</MtouchLink>
	<UseInterpreter>True</UseInterpreter>
</PropertyGroup>

My build size went from 52Mb to 38MB compared to a build just 1 hour earlier.
In addition to the problem in this post, I also got an ITMS-90899. I had two emails from Apple.
This project is well established, and no new packages or updates have been applied since the previous version.

Using .net8

I doubt my DevOps team changed anything within that hour, so maybe this problem has something to do with the "UseInterpreter" tag.